Re: Issue 167: DTLS role versus RFC 4145 SDP setup attribute

I’m not sure I understand. Maybe a use case would help explain what you are asking?

-Robin

On January 8, 2015 at 3:53:01 AM, ರಾಜೇಂದ್ರ ಕುಮಾರ (rajendrakumara@gmail.com) wrote:

Hi All,

How do we handle a RTCP App specific events on this architecture, it will help application were RTCP App events are used for signalling.

Thanks,
Rajendra Kumar. A

On Thu, Jan 8, 2015 at 8:02 AM, Roman Shpount <roman@telurix.com> wrote:
What would happen if client request is received and then remote party role is set to "server"? I would suggest that DTLS session should be reset and transitioned to the "client" role. This would make DTLS setup more robust and will prevent DTLS sessions from failing after third party sending client_hello packets.
_____________
Roman Shpount

On Wed, Jan 7, 2015 at 8:40 PM, Robin Raymond <robin@hookflash.com> wrote:

Here’s how I think the API should work:

Creating a RTCDtlsTransport creates the transport in “auto” role mode, i.e. when “getLocalParameters()” is called. “auto” by default causes the RTCDtlsTransport to determine the client/server DTLS handshake role based upon the ICE controlling/controlled role. However, the RTCDtilsTransport must listen for incoming client requests (i.e. in a server operating mode) even before start() is called. This allows the remote party to initiate a RTCDtilsTransport.start() with a remote of “server" before the local side calls start(). If client side DTLS handshake packets come in then the RTCDtlsTransport transitions immediately from “auto” in “getLocalParameters()” to “server” instead since the role is clearly resolved to being a server role due to the incoming client DTLS handshake requests.

Alternatively, if the RTCDtilsTransport.start() is called with the remote side specified as “server” then the local side will immediately transition to the “client” role since the role of the remote party is known therefor the local role must also be known. If the RTCDtilsTransport.start() is called with the remote side specified as “client” then the local side will immediately transition to the “server” role (again since the local role is not clear). If “auto” is specified for the remote party then the client/server role is determined via the resulting ICE controlling / controlled roles. Once ICE completes, “getLocalParameters” should change from “auto” to the finalized determined role.

Calling RTCDtlsTransport.start() is required to complete the validation of the DTLS handshake since the certificates can only be validated when the remote certificates hashes have been passed into the “ RTCDtlsTransport.start()”.

This will allow RFC 4145 “actpass”, as the default RTCDtlsTransport does listen for client requests in server mode before the start is called (and before negotiation round trips have completed). If RFC 4145 “active” or “passive” is specified during negotiation, the corresponding “client” or “server” remote role can be specified to the RTCDtlsTransport.start() thus overriding the default “auto” ICE handshake determination of client / server roles. Thus an offer can be made without calling “start()” in “actpass” and the remote side can call “start()” forcing it into a client role if it chooses and the DTLS handshake can proceed even before the full answer arrives and “start()” is called.

-Robin


On January 7, 2015 at 4:54:40 PM, Bernard Aboba (bernard.aboba@microsoft.com) wrote:

Here are some thoughts on how interoperation might work with an implementation that behaves as described in RFC 5763.

 

Let us assume that we have an ORTC API implementation talking over the wire to an RFC 5763 implementation.  ICE completes and the ORTC API peer ends up being controlling and the RFC 5763 peer is controlled.  At that point, does RTCDtlsRole transition to “client” for the ORTC API peer?  What if the the ORTC API peer signals a=setup:actpass in SDP and the legacy peer answers with a=setup:active and begins a DTLS negotiation with the ORTC API peer?

 

It seems to me that even before RTCDtlsTransport.start() is called that the RTCDtlsTransport object needs to be listening for incoming DTLS connections, regardless of the value of RTCDtlsRole.  While it is not possible to complete the DTLS negotiation until RTCDtlsTransport.start() is called, the incoming DTLS packets can be queued for subsequent processing which may depend on the remote parameters passed im the start() call.

 

As per this example, if RTCDtlsRole transitions to “client” and remoteParameters.RTCDtlsRole also has a value of “client” an exception might be thrown.  However, if we don’t insist on an immediate transition of RTCDtlsRole prior to calling start() then localParameters.RTCDtlsRole is “auto” and remoteParameters.RTCDtlsRole is “client” which could be ok.   This way we can both exhibit “auto” behavior when ORTC API peers talks to each other as well as interoperating with RFC 5763 clients. 

 

Does this make sense???

 

From: Roman Shpount [mailto:roman@telurix.com]
Sent: Tuesday, January 6, 2015 10:27 AM
To: Bernard Aboba
Cc: public-ortc@w3.org
Subject: Re: Issue 167: DTLS role versus RFC 4145 SDP setup attribute

 

I am not sure that "auto" means that DTLS role is determined based on resolved ICE role. If it corresponds to actpass, then per RFC 5763 (https://tools.ietf.org/html/rfc5763#section-5):

 

The endpoint MUST use the setup attribute defined in [RFC4145].

The endpoint that is the offerer MUST use the setup attribute value of setup:actpass and be prepared to receive a client_hello before it receives the answer.  The answerer MUST use either a setup attribute value of setup:active or setup:passive.  Note that if the answerer uses setup:passive, then the DTLS handshake will not begin until the answerer is received, which adds additional latency. setup:active allows the answer and the DTLS handshake to occur in parallel.  Thus, setup:active is RECOMMENDED.  Whichever party is active MUST initiate a DTLS handshake by sending a ClientHello over each flow (host/port quartet). 

 

This also states that client_hello must be processed before answer is received and RTCDtlsTransport.start is called.

 

Finally, we need also to deal with forking, where multiple negotiations can start on the same receiving host/port with different roles.



_____________
Roman Shpount

 

On Mon, Jan 5, 2015 at 5:08 PM, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:

Justin Uberti said:

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

Roman said:

“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? “

”

 

[BA] We have RTCDtlsTransport.getLocalParameters() but no .setLocalParameters().  Since we have:

 

dictionary RTCDtlsParameters {

    RTCDtlsRole                  role = "auto";

    sequence<RTCDtlsFingerprint> fingerprints;

};

 

This means that getLocalParameters.RTCDtlsRole is always initially set to “auto” (DTLS role determined based on resolved ICE role).  However, the ICE role isn’t resolved until RTCIceTransport.start() is called.

 

However, in the sample code examples (e.g. Section 4.4) RTCIceTransport.start() isn’t called until after the capabilities are exchanged.

 

So at least in the sample code, the only possible value of RTCDtlsTransport.getLocalParameters.RTCDtlsRole exchanged between peers is “auto”.

 

Presumably after the signaling is done, RTCIceTransport.start() is called.  After that point, it becomes possible for DTLS packets to flow between the peers (and also for RTCDtlsRole to change, reflecting the resolved ICE role).

 

Roman also said:

 

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?

 

[BA] My assumption is that RTCIceGatherer needs to accept ICE connectivity checks before RTCIceTransport.start() is called (or even before an RTCIceTransport is constructed).  Similarly, it seems to me that RTCDtlsTransport needs to accept DTLS packets before RTCDtlsTransport.start() is called.  Note that by the time the RTCDtlsTransport receives a DTLS packet, the ICE role will have been resolved.  In theory, a peer with a resolved role of “client” should not be receiving incoming DTLS packets, since that would imply that the remote peer has a resolved role of “server” and yet is behaving like a “client”.  But then the question is “what happens?”  Does the RTCDtlsRole change to reflect what is going on in the DTLS negotiation?

 

 

 





--
ರಾಜೇಂದ್ರ ಕುಮಾರ್. ಅ [ Rajendra Kumar. A ]
ಗಣಕ ತಂತ್ರಜ್ಞ. [ Software Engineer ]