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

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<mailto: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?