[erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support.
Andreas Schultz
andreas.schultz@REDACTED
Fri Mar 15 11:35:43 CET 2019
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
> <+49%20391%20819099299>
> >> 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/20190315/dfb7294a/attachment.htm>
More information about the erlang-questions
mailing list