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

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