DTLS role versus RFC 4145 SDP setup attribute #167

Closed
aboba opened this Issue Dec 11, 2014 · 15 comments

Projects

None yet

7 participants

@aboba
Contributor
aboba commented Dec 11, 2014

From Roman Shpount (see http://lists.w3.org/Archives/Public/public-ortc/2014Dec/0021.html):

P.P.S. Is there a reason why DTLS role does not match the values for RFC 4145 SDP setup attribute? SDP setup attribute can be "actpass", which corresponds to auto, "active", which corresponds to client, "passive" which corresponds to server, and "holdconn" which does not match anything in the ORTC.

@aboba aboba added 1.1 1.0 and removed 1.1 labels Dec 11, 2014
@juberti
juberti commented Dec 12, 2014

Since actpass/active/passive are SDPisms, we decided to adopt the DTLS terminology of client/server.

Note that holdconn has no meaning in the DTLS environment, and actpass can be simulated by initially acting as a server, but then changing to a client if the other side says it wants to be the server.

@ibc
Contributor
ibc commented Dec 12, 2014

Question: does ORTC mandate actpass/auto for the "initiator"? I expect the
answer is "no" as here there is no such an initiator, but want to confirm
it since the SDP DTLS rules mandate that and I see no reason at all.

Since actpass/active/passive are SDPisms, we decided to adopt the DTLS
terminology of client/server.

Note that holdconn has no meaning in the DTLS environment, and actpass can
be simulated by initially acting as a server, but then changing to a client
if the other side says it wants to be the server.


Reply to this email directly or view it on GitHub
#167 (comment).

@rshpount

On Fri, Dec 12, 2014 at 1:28 PM, Justin Uberti notifications@github.com
wrote:

Since actpass/active/passive are SDPisms, we decided to adopt the DTLS
terminology of client/server.

Note that holdconn has no meaning in the DTLS environment, and actpass can
be simulated by initially acting as a server, but then changing to a client
if the other side says it wants to be the server.

From what I can see there is no way to change the role for
RTCDtlsTransport. Does it mean it will always start in auto and then switch
to client/server based on the start call?

Second question, would RTCDtlsTransport accept DTLS packets before the
start call? Currently, with SDP, an offer is sent with actpass, the client
waits for answer, but will accept DTLS handshake packets, which will switch
it into server mode. If answer is received which forces a client setup
role, DTLS transport is reset and handshake is restarted as a client. Is
this something supported by the current setup?


Roman Shpount

@ibc
Contributor
ibc commented Dec 12, 2014

Second question, would RTCDtlsTransport accept DTLS packets before the
start call? Currently, with SDP, an offer is sent with actpass, the client
waits for answer, but will accept DTLS handshake packets, which will
switch
it into server mode.

Never heard about that. Are you sure? Does it really work?

@rshpount

On Fri, Dec 12, 2014 at 5:10 PM, Iñaki Baz Castillo <
notifications@github.com> wrote:

Second question, would RTCDtlsTransport accept DTLS packets before the
start call? Currently, with SDP, an offer is sent with actpass, the
client
waits for answer, but will accept DTLS handshake packets, which will
switch
it into server mode.

Never heard about that. Are you sure? Does it really work?

This is actually quite common for plain DTLS-SRTP, since the a client can
get DTLS packets which go directly to it before the answer which needs to
go over a signaling server which can go through several intermediary steps.
In combination with ICE it is more complex, but theoretically, the answerer
can complete ICE handshake and send the first DTLS packet before its answer
got a chance to get to the offering client.


Roman Shpount

@ibc
Contributor
ibc commented Dec 12, 2014

Never seen that working. Interesting, but wont implement it :)

That's why I ask not to mandate actpass/auto for the initiator. It is mucho
better to set client/server. I do not see value in auto.

@steely-glint

How can you check the fingerprint in the answer before you have got the answer? I agree that in principle the DTLS handshake could start before the answer, but it can't safely complete and start actual media flow until the fingerprint is validated.
(The same is true for DataChannel - SCTP shouldn't flow until the answer is in)

@ibc
Contributor
ibc commented Dec 12, 2014

That is worse when using media over TCP since the DTLS ClientHello would
not be retransmitted. So what I do if the fingerprint arrives after the
ClientHello is to keep state and wait for both of them.
On 12 Dec 2014 23:54, "steely-glint" notifications@github.com wrote:

How can you check the fingerprint in the answer before you have got the
answer? I agree that in principle the DTLS handshake could start before the
answer, but it can't safely complete and start actual media flow until the
fingerprint is validated.
(The same is true for DataChannel - SCTP shouldn't flow until the answer
is in)


Reply to this email directly or view it on GitHub
#167 (comment).

@rshpount

On Fri, Dec 12, 2014 at 5:54 PM, steely-glint notifications@github.com
wrote:

How can you check the fingerprint in the answer before you have got the
answer? I agree that in principle the DTLS handshake could start before the
answer, but it can't safely complete and start actual media flow until the
fingerprint is validated.
(The same is true for DataChannel - SCTP shouldn't flow until the answer
is in)

In webrtc, you would not even be able to send a response to DTLS packet --
you will need to complete the ICE check first which will require the
ufrag/password from the answer. What this typically means is that DTLS
packet that the offering side receives before the answer would need to be
cached and processed as soon as the answer arrives. If this packet is
discarded, then DTLS handshake will be delayed for not reason.
Alternatively you can process incoming DTLS packets and cache the response.
So, I guess my question is what to do with DTLS packets received before the
start?


Roman Shpount

@rshpount

On Fri, Dec 12, 2014 at 5:52 PM, Iñaki Baz Castillo <
notifications@github.com> wrote:

Never seen that working. Interesting, but wont implement it :)

That's why I ask not to mandate actpass/auto for the initiator. It is mucho
better to set client/server. I do not see value in auto.

I do not thin we should change this. We will need auto for the interop.
There are media proxy solutions which would always want to be server. On
the other hand, normal clients would prefer to be client for the faster
call setup. You just never know what you are going to talk to before the
call setup.


Roman Shpount

@ibc
Contributor
ibc commented Dec 13, 2014

We will need auto for the interop.

No, we just need the JS shim to behave as that. But that is just an artificial need for legacy interop.

There are media proxy solutions which would always want to be server. On the other hand, normal clients would prefer to be client for the faster call setup.

So? that's the problem. Clients want to be DTLS clients as well, but in the SDP world the are SDP offeres which means announcing "actpass" (so the server decides).

In the other side, servers usually receive SDP offers, except when the don't. For example when they start a re-negotiatio (let's say a multiconference joined by a new participant in which the server may wish to send all the other participants a new SDP offer with the new "m=" lines as "Unified Plan" mandate). So, the server is the offerer and, according to SDP DTLS rules, it should announce "actpass" (so the client decides what to be regardless what the server likes to be).

You just never know what you are going to talk to before the call setup.

And I wonder, why? Why can't the "call" initiator decide what to be? why is the "called" who decides which role each party is?

BTW: shouldn't we being discussing this in the mailing list? :)

@ibc
Contributor
ibc commented Dec 13, 2014

In webrtc, you would not even be able to send a response to DTLS packet -- you will need to complete the ICE check first which will require the ufrag/password from the answer.

Yes and not. If peerA is the ICE Controlling and peerB is ICE Controlled, then peerB MUST be ready to receive a DTLS ClientHello in any interface/tuple in which a STUN Binding request has been received.

What this typically means is that DTLS packet that the offering side receives before the answer would need to be cached and processed as soon as the answer arrives. If this packet is discarded, then DTLS handshake will be delayed for not reason.

Not just delayed, but in case of media over TCP failed (since there won't be DTLS ClientHello retransmissions). So catching them is the only way (until the signaling response arrives so the fingerprint can be checked). Hard stuff anyhow.

Alternatively you can process incoming DTLS packets and cache the response.
So, I guess my question is what to do with DTLS packets received before the
start?

Set a flag: dtls_done = true and ignore incoming media until remote fingerprint is validated. This is the only way in TCP. In UDP you can just drop DTLS packets if response is not received (because DTLS packets will be retransmitted by the peer).

@aboba
Contributor
aboba commented Jan 9, 2015

Comment from Robin Raymond:
http://lists.w3.org/Archives/Public/public-ortc/2015Jan/0013.html

Proposed text:

Addition to Section 2.3.2:
While a newly constructed RTCDtlsTransport must listen for incoming DTLS packets before start() is called, to complete the negotiation it is necessary to verify the remote fingerprint, which is dependent on remoteParameters, passed to start().

Revised text for RTCDtlsRole:

RTCDtlsRole indicates the role of the DTLS transport.

auto
The DTLS role is determined based on the resolved ICE role: the 'controlled' role acts as the DTLS client, the 'controlling' role acts as the DTLS server. Since RTCDtlsRole is initialized to "auto" on construction of an RTCDtlsTransport, transport.getLocalParameters().RTCDtlsRole will have an initial value of "auto".

client
The DTLS client role. A transition from "auto" to "client" will occur if start(remoteParameters) is called with remoteParameters.RTCDtlsRole having a value of "server".

server
The DTLS server role. If RTCDtlsRole has a value of "auto" and a DTLS client initiates a connection, RTCDtlsRole will transition to "server", even before start() is called. A transition from "auto" to "server" will also occur if start(remoteParameters) is called with remoteParameters.RTCDtlsRole having a value of "client".

Question: Do we need an RTCDtlsRoleChangedEvent?

@robin-raymond robin-raymond pushed a commit that referenced this issue Jan 22, 2015
Robin Raymond Updated Section 8.3 to reflect proposed matching rules, reflecting:
#48

Update to the Statistics API, reflecting:
#85

Update on 'automatic' use of scalable video coding, as noted in:
#156

Update to the H.264 parameters, as noted in:
#158

Update to the 'Big Picture', as noted in:
#159

Added support for maxptime, as noted in:
#160

Changed 'RTCIceTransportEvent' to 'RTCIceGathererEvent' as noted in:
#161

Update to RTCRtpUnhandledEvent as noted in:
#163

Added support for RTCIceGatherer.state as noted in:
#164

Revised the text relating to RTCIceTransport.start() as noted in:
#166

Added text relating to DTLS interoperability with WebRTC 1.0, as noted in:
#167

Revised the text relating to RTCDtlsTransport.start() as noted in:
#168

Clarified handling of incoming connectivity checks by the RTCIceGatherer as noted in:
#170

Added a reference to the ICE consent specification, as noted in:
#171
a927ecf
@pthatcherg

Would anyone care that the role changed? And if they did, would something
in stats be good enough?

I'm gonna go with "don't put it in until someone really needs it".

On Fri, Jan 9, 2015 at 2:25 PM, aboba notifications@github.com wrote:

Comment from Robin Raymond:
http://lists.w3.org/Archives/Public/public-ortc/2015Jan/0013.html

Proposed text:

Addition to Section 2.3.2:
While a newly constructed RTCDtlsTransport must listen for incoming DTLS
packets before start() is called, to complete the negotiation it is
necessary to verify the remote fingerprint, which is dependent on
remoteParameters, passed to start().

Revised text for RTCDtlsRole:

RTCDtlsRole indicates the role of the DTLS transport.

auto

The DTLS role is determined based on the resolved ICE role: the
'controlled' role acts as the DTLS client, the 'controlling' role acts as
the DTLS server. Since RTCDtlsRole is initialized to "auto" on construction
of an RTCDtlsTransport, transport.getLocalParameters().RTCDtlsRole will
have an initial value of "auto".

client

The DTLS client role. A transition from "auto" to "client" will occur if
start(remoteParameters) is called with remoteParameters.RTCDtlsRole having
a value of "server".

server

The DTLS server role. If RTCDtlsRole has a value of "auto" and a DTLS
client initiates a connection, RTCDtlsRole will transition to "server",
even before start() is called. A transition from "auto" to "server" will
also occur if start(remoteParameters) is called with
remoteParameters.RTCDtlsRole having a value of "client".

Question: Do we need an RTCDtlsRoleChangedEvent?


Reply to this email directly or view it on GitHub
#167 (comment).

@steely-glint

The only reason I can think of that you might care is the server determines the encryption algorithm etc on the Dtls. So you might conceivably care, but in that case you should be specifying the Dtls role not leaving it to auto.

T.

Sent from my iPod

On 26 Jan 2015, at 20:54, pthatcherg notifications@github.com wrote:

Would anyone care that the role changed? And if they did, would something
in stats be good enough?

I'm gonna go with "don't put it in until someone really needs it".

On Fri, Jan 9, 2015 at 2:25 PM, aboba notifications@github.com wrote:

Comment from Robin Raymond:
http://lists.w3.org/Archives/Public/public-ortc/2015Jan/0013.html

Proposed text:

Addition to Section 2.3.2:
While a newly constructed RTCDtlsTransport must listen for incoming DTLS
packets before start() is called, to complete the negotiation it is
necessary to verify the remote fingerprint, which is dependent on
remoteParameters, passed to start().

Revised text for RTCDtlsRole:

RTCDtlsRole indicates the role of the DTLS transport.

auto

The DTLS role is determined based on the resolved ICE role: the
'controlled' role acts as the DTLS client, the 'controlling' role acts as
the DTLS server. Since RTCDtlsRole is initialized to "auto" on construction
of an RTCDtlsTransport, transport.getLocalParameters().RTCDtlsRole will
have an initial value of "auto".

client

The DTLS client role. A transition from "auto" to "client" will occur if
start(remoteParameters) is called with remoteParameters.RTCDtlsRole having
a value of "server".

server

The DTLS server role. If RTCDtlsRole has a value of "auto" and a DTLS
client initiates a connection, RTCDtlsRole will transition to "server",
even before start() is called. A transition from "auto" to "server" will
also occur if start(remoteParameters) is called with
remoteParameters.RTCDtlsRole having a value of "client".

Question: Do we need an RTCDtlsRoleChangedEvent?


Reply to this email directly or view it on GitHub
#167 (comment).


Reply to this email directly or view it on GitHub.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment