[erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support.

Albin Stigö albin.stigo@REDACTED
Sat Mar 16 11:53:14 CET 2019 

True... A callback receiving {udp, Socket, IP, InPortNo, Packet} and
deciding whether to use the the ssl demuxer or pass it on to another
process might be enough. The STUN packets could come from any IP
unsolicited when doing ICE nat traversal path discovery (as described by
WebRTC).


--Albin

On Sat, Mar 16, 2019, 11:00 Ingela Andin <ingela.andin@REDACTED> wrote:

>
> Hi!
>
> Den lör 16 mars 2019 kl 10:21 skrev Albin Stigö <albin.stigo@REDACTED>:
>
>> Ok sorry about the confusion. What's needed is a second level of
>> demultiplexing after the first... But I realize now this will be very
>> difficult to achieve with the current implementation because that relies on
>> one socket per connection. Otherwise you won't know which process to send
>> the none DTLS packets to... Or am i missing something?
>>
>>
> You will have to extend the demultiplexor process so that it sends packets
> to different processes depending on some criteria. It is ok to change the
> internals of
> the process if that is necessary. But we like the basic functionality to
> be the framework of the process and then add extended features mainly
> through callbacks.
>
> Regards Ingela Erlang/OTP Team - Ericsson AB
>
>
>> I might have to attempt a separate DTLS use_srtp app just for this
>> application...
>>
>>
>> --Albin
>>
>> On Sat, Mar 16, 2019, 09:05 Ingela Andin <ingela.andin@REDACTED> wrote:
>>
>>> Hi Albin!
>>>
>>> Den fre 15 mars 2019 kl 17:25 skrev Albin Stigö <albin.stigo@REDACTED>:
>>>
>>>> Ok thanks!
>>>>
>>>> Maybe demultiplexing should just be default when the use_srtp extension
>>>> is used, since that's how it's supposed to be used anyway... or a
>>>> rfc7983_demux option...
>>>>
>>>>
>>> ? A DTLS server will always have a demultiplexing process as UDP does
>>> not have a connection concept.
>>>
>>>
>>>
>>>> What's the name in the #state that holds the pid of the controlling
>>>> process (the process that receives {ssl.. data)?
>>>>
>>>>
>>> It is part of the "user"  in the state of the TLS/DTLS connection
>>> process. You should not have to care.  You set the controlling process with
>>> ssl:controlling_process/2.
>>>
>>> I guess what you care about is the demultiplexing process and which Pid
>>> it sends the incoming UDP packets to. All the code is defined in the
>>> dtls_packet_demux.erl
>>>
>>> Regards Ingela Erlang/OTP team - Ericsson AB
>>>
>>>
>>>> --Albin
>>>>
>>>> On Fri, Mar 15, 2019, 17:01 Ingela Andin <ingela.andin@REDACTED>
>>>> wrote:
>>>>
>>>>> Hi Albin!
>>>>>
>>>>> There is the handshake_compleation option together with the
>>>>> handshake_continue functions that let you pause the handshake and retrieve
>>>>> the hello extensions and possibly provide more options before
>>>>> continuing the handshake.
>>>>>
>>>>> Den fre 15 mars 2019 kl 13:20 skrev Albin Stigö <albin.stigo@REDACTED
>>>>> >:
>>>>>
>>>>>> Am I right to assume this is the single point of udp receive for dtls?
>>>>>>
>>>>>>
>>>>>> https://github.com/erlang/otp/blob/702ef9b0fa0a9b7345e3b397f23d8a76a2ac4df2/lib/ssl/src/dtls_connection.erl#L906
>>>>>>
>>>>>>
>>>>>>
>>>>> If you want to multiplex UDP packets to other processes than the DTLS
>>>>> connection process that is not encrypted under DTLS you
>>>>> should not look at the DTLS connection process but at the
>>>>>
>>>>>
>>>>> https://github.com/erlang/otp/blob/master/lib/ssl/src/dtls_packet_demux.erl#L140
>>>>>
>>>>> Regards Ingela Erlang/OTP team Ericsson AB
>>>>>
>>>>>
>>>>>> --Albin
>>>>>>
>>>>>> On Fri, Mar 15, 2019 at 1:10 PM Albin Stigö <albin.stigo@REDACTED>
>>>>>> wrote:
>>>>>> >
>>>>>> > There're all kinds of abuse of DTLS it seems :-)
>>>>>> >
>>>>>> > I still think the use cases are orthogonal though... Demuxing as
>>>>>> > described in https://tools.ietf.org/html/rfc7983 is trivial and
>>>>>> > requires no state. A demux_fun would solve that problem.
>>>>>> >
>>>>>> > DTLS packets wrapped in extra headers with the need of state
>>>>>> > information is much more complicated... Maybe what is needed are two
>>>>>> > different approaches? Especially since you will need forward and
>>>>>> > backwards transform..?
>>>>>> >
>>>>>> > Ingela, is there already an API for getting the key data from
>>>>>> use_srtp
>>>>>> > (when implemented) or will that have to be added also?
>>>>>> >
>>>>>> >
>>>>>> > --Albin
>>>>>> >
>>>>>> > On Fri, Mar 15, 2019 at 11:35 AM Andreas Schultz
>>>>>> > <andreas.schultz@REDACTED> wrote:
>>>>>> > >
>>>>>> > > Albin Stigö <albin.stigo@REDACTED> schrieb am Do., 14. März
>>>>>> 2019 um 18:49 Uhr:
>>>>>> > >>
>>>>>> > >> Hi Ingela and Andreas,
>>>>>> > >>
>>>>>> > >> > No, that's not enough. Some protocols put additional headers
>>>>>> in front of the DTLS packets. So there needs to be a way to strip
>>>>>> > >> > headers on Rx and add it on Tx (with session information if
>>>>>> needed).
>>>>>> > >>
>>>>>> > >> I have to admit I have not encountered this practice... do you
>>>>>> have a
>>>>>> > >> particular protocol in mind or is it a part of dtls-srtp I have
>>>>>> > >> missed? One could argue that if you add additional headers and
>>>>>> > >> maintain some kind of state you are actually dealing with a
>>>>>> different
>>>>>> > >> transport layer...?
>>>>>> > >
>>>>>> > >
>>>>>> > > CAPWAP is doing that
>>>>>> https://tools.ietf.org/html/rfc5415#section-4.1
>>>>>> > >
>>>>>> > >> I would very much like a way where filtered out packages were
>>>>>> sent to
>>>>>> > >> the controlling process as {udp,Socket instead of {ssl,
>>>>>> Socket... The
>>>>>> > >> question in the latter case is if Socket should be the ssl
>>>>>> socket or
>>>>>> > >> the transport socket. Messing with the transport socket could be
>>>>>> > >> detrimental to dtls.
>>>>>> > >>
>>>>>> > >> One could also extend the filter_fun idea to a transform_fun
>>>>>> where one
>>>>>> > >> could transform in packet in addition to demultiplexing, but
>>>>>> like I
>>>>>> > >> said, I think additional headers to dtls packets belong to the
>>>>>> > >> transport layer.
>>>>>> > >
>>>>>> > >
>>>>>> > > Passing a State in and out of such a transform would be good.
>>>>>> > >
>>>>>> > > Andreas
>>>>>> > >
>>>>>> > >>
>>>>>> > >>
>>>>>> > >> I don't have in-depth knowledge of the ssl app but it seems
>>>>>> adding a
>>>>>> > >> filter_fun would be almost trivial?
>>>>>> > >>
>>>>>> > >> > Maybe transport_send as compared to the existing
>>>>>> transport_accept. Would only work for DTLS.
>>>>>> > >>
>>>>>> > >> Well either that or some way of accessing the transport socket,
>>>>>> but
>>>>>> > >> transport_send for sure plays well with existing API!
>>>>>> > >>
>>>>>> > >>
>>>>>> > >> --Albin
>>>>>> > >>
>>>>>> > >> On Thu, Mar 14, 2019 at 6:22 PM Ingela Andin <
>>>>>> ingela.andin@REDACTED> wrote:
>>>>>> > >> >
>>>>>> > >> > Hi!
>>>>>> > >> >
>>>>>> > >> > Andreas, see comment below.
>>>>>> > >> >
>>>>>> > >> > Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz <
>>>>>> andreas.schultz@REDACTED>:
>>>>>> > >> >>
>>>>>> > >> >> Hi
>>>>>> > >> >>
>>>>>> > >> >> Ingela Andin <ingela.andin@REDACTED> schrieb am Do., 14.
>>>>>> März 2019 um 17:34 Uhr:
>>>>>> > >> >>>
>>>>>> > >> >>> Hi Albin!
>>>>>> > >> >>>
>>>>>> > >> >>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stigö <
>>>>>> albin.stigo@REDACTED>:
>>>>>> > >> >>>>
>>>>>> > >> >>>> Hi Ingela,
>>>>>> > >> >>>>
>>>>>> > >> >>>> Thanks for the quick reply!
>>>>>> > >> >>>>
>>>>>> > >> >>>> While cb_info certainly is one way of doing it, it feels a
>>>>>> bit
>>>>>> > >> >>>> complicated... specifically if switching between active and
>>>>>> passive
>>>>>> > >> >>>> mode. Not sure if ssl ever use passive mode internally?
>>>>>> Demuxing is a
>>>>>> > >> >>>> different use case, I think..
>>>>>> > >> >>>>
>>>>>> > >> >>>
>>>>>> > >> >>> The cb_info is intended so that you may replace the
>>>>>> transport layer, with most likely, an SCTP transport (can be done for  both
>>>>>> TLS and DTLS although there are some extensions needed for the DLTS version
>>>>>> to work properly). I think some people also use it to implement WebSockets.
>>>>>> > >> >>>
>>>>>> > >> >>> ssl internally uses active n for TLS (since latest release)
>>>>>> and active once for DTLS (we might change it) but an OTP supervised process
>>>>>> will not use passive recv as we do not want it to block.
>>>>>> > >> >>>
>>>>>> > >> >>>
>>>>>> > >> >>>>
>>>>>> > >> >>>> Something that IMHO would be fantastic and simple (?) would
>>>>>> be a
>>>>>> > >> >>>> dtls_filter_fun option. If true packet is passed up the ssl
>>>>>> stack,
>>>>>> > >> >>>> otherwise passed on like a normal udp packet!
>>>>>> > >> >>>>
>>>>>> > >> >>>
>>>>>> > >> >>> Sounds reasonable. Otherwise sent to some other Erlang
>>>>>> process than the "DTLS-connection" process that is.
>>>>>> > >> >>
>>>>>> > >> >>
>>>>>> > >> >> No, that's not enough. Some protocols put additional headers
>>>>>> in front of the DTLS packets. So there needs to be a way to strip headers
>>>>>> on Rx and add it on Tx (with session information if needed).
>>>>>> > >> >>
>>>>>> > >> >
>>>>>> > >> > Maybe the demultiplexor process can have a "packet mode" that
>>>>>> is set to "no packet"  default and needs a callback handler for anything
>>>>>> else?
>>>>>> > >> >
>>>>>> > >> >
>>>>>> > >> > Regards Ingela Erlang/OTP team - Ericsson AB
>>>>>> > >> >
>>>>>> > >> >>
>>>>>> > >> >> Andreas
>>>>>> > >> >>
>>>>>> > >> >>>
>>>>>> > >> >>>
>>>>>> > >> >>>>
>>>>>> > >> >>>> There's an RFC regarding the demultiplexing of SRTP/DTLS,
>>>>>> it basically
>>>>>> > >> >>>> boils down to looking at the first byte of the packet, if
>>>>>> it's
>>>>>> > >> >>>> [20..63] it should be treated as DTLS otherwise something
>>>>>> else. So
>>>>>> > >> >>>> this would be absolutely trivial to implement if there was a
>>>>>> > >> >>>> dtls_filter_fun...
>>>>>> > >> >>>>
>>>>>> > >> >>>> https://tools.ietf.org/html/rfc7983
>>>>>> > >> >>>>
>>>>>> > >> >>>> Then of course there also has to be a way to bypass DTLS
>>>>>> when sending
>>>>>> > >> >>>> data... maybe send/3 (Socket, Data, Options)...
>>>>>> > >> >>>>
>>>>>> > >> >>>
>>>>>> > >> >>> Maybe transport_send as compared to the existing
>>>>>> transport_accept. Would only work for DTLS.
>>>>>> > >> >>>
>>>>>> > >> >>> Regards Ingela Erlang/OTP team  - Ericsson AB
>>>>>> > >> >>>
>>>>>> > >> >>>>
>>>>>> > >> >>>> What do you think?
>>>>>> > >> >>>>
>>>>>> > >> >>>>
>>>>>> > >> >>>> --Albin
>>>>>> > >> >>>>
>>>>>> > >> >>>> On Thu, Mar 14, 2019 at 1:52 PM Ingela Andin <
>>>>>> ingela.andin@REDACTED> wrote:
>>>>>> > >> >>>> >
>>>>>> > >> >>>> > Hi!
>>>>>> > >> >>>> >
>>>>>> > >> >>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stigö <
>>>>>> albin.stigo@REDACTED>:
>>>>>> > >> >>>> >>
>>>>>> > >> >>>> >> Hi,
>>>>>> > >> >>>> >>
>>>>>> > >> >>>> >> I'm working on an Erlang WebRTC peer client (to send
>>>>>> audio/video to
>>>>>> > >> >>>> >> the browser).
>>>>>> > >> >>>> >>
>>>>>> > >> >>>> >> WebRTC requires dtls-srtp and that in turn requires:
>>>>>> > >> >>>> >>
>>>>>> > >> >>>> >> 1. The use_srtp extension for key exchange.
>>>>>> > >> >>>> >
>>>>>> > >> >>>> >
>>>>>> > >> >>>> > We will be implementing this as part of TLS-1.3 that we
>>>>>> are currently working on, and we will have something runnable for OTP-22.0,
>>>>>> although we are not promising that it will complete or that use_srtp will
>>>>>> be part of  OTP-22.0
>>>>>> > >> >>>> >
>>>>>> > >> >>>> >
>>>>>> > >> >>>> >>
>>>>>> > >> >>>> >> 2. Multiplexing of stun/turn/srtp packets on the socket.
>>>>>> > >> >>>> >>
>>>>>> > >> >>>> >> I know there's been work towards use_srtp and it's even
>>>>>> in the source,
>>>>>> > >> >>>> >> but commented out. Ingela has been working on it for OTP
>>>>>> 2, I believe,
>>>>>> > >> >>>> >> is there an ETA on this feature?
>>>>>> > >> >>>> >
>>>>>> > >> >>>> >
>>>>>> > >> >>>> >>
>>>>>> > >> >>>> >>
>>>>>> > >> >>>> >>
>>>>>> > >> >>>> >> Is multiplexing on the DTLS socket already possible
>>>>>> using the cb_info?
>>>>>> > >> >>>> >> Has anyone tried that?
>>>>>> > >> >>>> >>
>>>>>> > >> >>>> >>
>>>>>> http://erlang.org/pipermail/erlang-questions/2018-October/096457.html
>>>>>> > >> >>>> >>
>>>>>> > >> >>>> >
>>>>>> > >> >>>> > The code has been written to make such extensions
>>>>>> possible. There might be a need for more callbacks. I have not really had
>>>>>> time to work on that as
>>>>>> > >> >>>> > TLS-1.3, optimizations and erlang distribution over TLS
>>>>>> has been prioritized higher.  Suggestions are welcome.
>>>>>> > >> >>>> >
>>>>>> > >> >>>> > Regards Ingela Erlang/OTP team - Ericsson AB
>>>>>> > >> >>>> >
>>>>>> > >> >>>> >
>>>>>> > >> >>>> >
>>>>>> > >> >>>> >
>>>>>> > >> >>>> >>
>>>>>> > >> >>>> >>
>>>>>> > >> >>>> >> --Albin
>>>>>> > >> >>>> >> _______________________________________________
>>>>>> > >> >>>> >> erlang-questions mailing list
>>>>>> > >> >>>> >> erlang-questions@REDACTED
>>>>>> > >> >>>> >> http://erlang.org/mailman/listinfo/erlang-questions
>>>>>> > >> >>>
>>>>>> > >> >>> _______________________________________________
>>>>>> > >> >>> erlang-questions mailing list
>>>>>> > >> >>> erlang-questions@REDACTED
>>>>>> > >> >>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>>> > >> >>
>>>>>> > >> >> --
>>>>>> > >> >> --
>>>>>> > >> >> Dipl.-Inform. Andreas Schultz
>>>>>> > >> >>
>>>>>> > >> >> ----------------------- enabling your networks
>>>>>> ----------------------
>>>>>> > >> >> Travelping GmbH                     Phone:  +49-391-81 90 99 0
>>>>>> > >> >> Roentgenstr. 13                     Fax:    +49-391-81 90 99
>>>>>> 299
>>>>>> > >> >> 39108 Magdeburg                     Email:
>>>>>> info@REDACTED
>>>>>> > >> >> GERMANY                             Web:
>>>>>> http://www.travelping.com
>>>>>> > >> >>
>>>>>> > >> >> Company Registration: Amtsgericht Stendal        Reg No.:
>>>>>>  HRB 10578
>>>>>> > >> >> Geschaeftsfuehrer: Holger Winkelmann          VAT ID No.:
>>>>>> DE236673780
>>>>>> > >> >>
>>>>>> ---------------------------------------------------------------------
>>>>>> > >
>>>>>> > > --
>>>>>> > > --
>>>>>> > > Dipl.-Inform. Andreas Schultz
>>>>>> > >
>>>>>> > > ----------------------- enabling your networks
>>>>>> ----------------------
>>>>>> > > Travelping GmbH                     Phone:  +49-391-81 90 99 0
>>>>>> > > Roentgenstr. 13                     Fax:    +49-391-81 90 99 299
>>>>>> > > 39108 Magdeburg                     Email:  info@REDACTED
>>>>>> > > GERMANY                             Web:
>>>>>> http://www.travelping.com
>>>>>> > >
>>>>>> > > Company Registration: Amtsgericht Stendal        Reg No.:   HRB
>>>>>> 10578
>>>>>> > > Geschaeftsfuehrer: Holger Winkelmann          VAT ID No.:
>>>>>> DE236673780
>>>>>> > >
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190316/495556e1/attachment.htm>

More information about the erlang-questions mailing list