Re: Issue 173: DTLS handshake packets arrive because of connectivity checks before DTLS transport setup

I actually prefer the buffering. I think some sort of fixed size buffer
should be sufficient for most cases, so it would introduce only a limited
resource usage risk.

listen/accept would complicate implementation since it will require to deal
with accepted transport for which signaling was never received. In other
words, it need to deal with ICE check and DTLS hello received on the
IceTransport, but the actual signaling can be lost due to signaling path
failure.

_____________
Roman Shpount

On Fri, Feb 6, 2015 at 11:32 AM, Robin Raymond <robin@hookflash.com> wrote:

>
> Issue:
> What do we do about DTLS packets that can arrive before there's a DTLS
> transport to receive the DTLS packets?
>
> How this can happen:
> 1) Alice sends an offer containing ICE candidates (i.e. Alice has an
> IceGatherer but has not called IceTransport.start() because remote
> ufrag/password is not yet known)
> 2) Bob sends his response ufrag / password via signalling channel and
> starts ICE connectivity checks (i.e. he has called IceTransport.start()
> method)
> 3) Alice receives connectivity checks and responds (aka as agreed in last
> ORTC CG meeting re: issue #170 ) and she sends an ICE consent reply back to
> Bob (but she still has not received ufrag/password via signalling yet so
> she cannot call IceTransport.start() yet)
> 4) Bob receives ICE connectivity consent reply and therefor believes a
> channel is open to send the DtlsTransport client "hello" packet
> 5) Alice receives DtlsTransport client hello packet but does not have any
> IceTransport or DtlsTransport started to receive the DTLS client "hello"
> packets.
>
> While eventually Alice will receive the signalling necessary to setup an
> IceTransport and DtlsTransport, she may receive DTLS packets prematurely.
>
> Possible options:
> 1) Drop DTLS packets incoming, force DTLS client re-transmit (i.e.
> consequence is a slow started or disrupted connections);
>
> 2) Buffer DTLS packets incoming for a period of time and deliver packets
> to eventual IceTransport.start() which specifies a matching remote
> ufrag/password (i.e. consequence is insufficient buffering, over-buffering
> (DOS attack), or timeouts that drop packets pre-maturely before signalling
> arrives).
>
> 3) Put IceTransport into a .listen() mode of operation with a pre-wired
> DTLS transport (i.e. consequence is a larger / more complex ORTC API
> surface and one that must handle forking scenarios). This idea was briefly
> mentioned in last ORTC CG meeting.
>
>
> I personally favour option 2 or 3 options but not 1. If we are going to
> respond to connectivity checks (as per issue #170 ) then we are giving
> consent to the remote side to send data. To incorrectly drop incoming data
> despite giving consent seems wrong.
>
> If we do 3, then we need to be concerned with forking. If Alice sends out
> a set of offer candidates but multiple answers come back then a single
> IceTransport in .listen() mode will not be sufficient. We may want to
> consider having the gatherer in a .listen() mode [where an event is fired
> to tell of an unknown incoming connectivity consent check from an unknown
> remote ufrag never seen before) and thus having an IceTransport.accept() to
> specify where the incoming ICE connectivity checks must be processed.
>
> E.g.
>
> partial interface IceGatherer {
>   void listen();
>   attribute EventHandler onunhandledice;
> }
>
> dictionary IceUnhandledEventInit : EventInit {
>     DOMString     remoteUFrag;
> };
>
> partial interface IceTransport {
>   //...
>   void accept(DOMString remoteUFrag);
> }
>
> This API could handle forked replies too. This could also allow the
> connectivity checks to be replied from a particular IceTransport rather
> than from the IceGatherer (so long as there's a short buffering of incoming
> ICE connectivity checks exists for unhandled remote ufrag packets). This
> would also allow for wiring of a DTLS transport to handle the transport
> before the consent was given to the remote side (although replying to the
> incoming DTLS client "hello" would not be possible since no reverse ice
> consent would be granted). In other words, incoming connectivity checks are
> handled but outgoing connectivity checks are still not possible since the
> remote password would remain unknown until signalling arrived but at least
> the DTLS transport could be wired up before any DTLS packets would / could
> arrive.
>
> So IMHO, it's either buffer all packets until signalling arrives, or do a
> listen()/accept() scenario modelled after TCP listen()/accept().
>
>
> -Robin
>
>