[erlang-questions] DTLS UDP socket reuse / SSL passive API?

[Andreas Schultz]

Spin off from: Re: [erlang-questions] dtls error when used with chrome
webrtc

Ingela Andin <ingela.andin@REDACTED> schrieb am Di., 2. Jan. 2018 um
13:30 Uhr:

> Hi!
>
> 2017-12-29 12:21 GMT+01:00 Joe K <goodjoe2049@REDACTED>:
>
>> > Also you may try using external STUN server (check RTCPeerConnection
>> docs) and hope browser starts with DTLS hello.
>>
>> I've tried that, but the browser still sends STUN binding requests to the
>> DTLS process. And it uses the STUN server just to find out it's address.
>>
>> > It should be quite easy to implement and it would be consistent with
>> ssl:connect/2 and ssl:ssl_accept for TCP sockets.
>>
>> Will try this now. Thank you.
>>
>>
>
> Pleas let us know if this is desirable functionality. So far we reasoned
> that as UDP is not connection oriented there is not the same interest to
> reuse
> to underlying sockets as if there is an underlying connection.
>

I do have a use case that is even more complicated then simply upgrading
UDP to DTLS.
CAPWAP is runnig unencrypted and DTLS traffic on the same socket. It
distinguished between the traffic with a small header in front of the
payload packet. I therefore need a demultiplexer on the UDP socket that
removes the header and passes the encrypted payload to the DTLS stack.

There is somewhat similar problem when doing EAP-TLS over RADIUS or
DIAMETER. The TLS traffic is encapsulated within RADIUS/DIAMETER requests
and needs to be passed into the TLS stack and the replies need to
encapsultated with RADIUS/DIAMETER.

The current socket abstraction in the SSL app is not prepared to handle
this and would need invasive changes.

A simplistic workarround would be to forward the DTLS traffic on loopback
UDP socket. Hwever that would incure additional latency, signaling overhead
and would make detection of failed connections more difficult. I therefore
don't want to go there.

A supported and documented API to pass (D)TLS traffic into the SSL app and
get status change events and the decoded payload data back from the SSL app
would IMHO help a lot.
Just some quick idea:

%% Create a new passive SSL connection of given type, return a opaque
identifier.
ssl:create_connection(Protocol :: 'stream' | 'datagram', Opts) ->
ssl_connection_id().

%% Pass received SSL traffic into the connection,
%% Return error, ok or Data to return on the connection.
ssl:recv(Connection :: ssl_connection_id(), EncData :: binary()) ->
   {error, Error} | ok | {ok, {send, Data :: binary()}}.

%% Pass unencrypted traffic into the SSL app
ssl: send(Connection :: ssl_connection_id(), PlainText :: binary()) ->
  {error, Error} | ok | {ok, {send, EncData :: binary()}}.

%% The owner of the connection is then getting messages like:
%% - send encrypted data:
%%     {ssl, Connection :: connection_id(), {send, EncData :: binary()}}
%% - got plaintext data:
%%     {ssl, Connection :: connection_id(), {recv, PlainText :: binary()}}
%% - connection event:
%%     {ssl, Connection :: connection_id(), Event :: ssl_connection_event()}

Wheter ssl:recv and ssl:send return data or use a message to the owner
should depend on a mode setting (e.g. active, passive...)

What do you think? Comments?

Regards
Andreas

[...]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180103/2c7368bf/attachment.htm>