<div dir="ltr"><div dir="ltr"><br></div><div>Hi!</div><div><br></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den ons 20 mars 2019 kl 09:33 skrev Albin Stigö <<a href="mailto:albin.stigo@gmail.com">albin.stigo@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">I looked at GnuTLS and they have the option to use a pull and a push callback function when the SSL stack wants data and wants to send data respectively. I think it's a nice idea because it decouples the SSL stack completely from the underlying socket. It seems this is sometimes desirable..<div dir="auto"><div dir="auto"><br></div></div></div></blockquote><div><br></div><div>The "active once" emulation between the DTLS statemachine and the demultiplexer process would be like pull. But we do not do push as that would be a bottleneck.</div><div><br></div><div>Regards Ingela Erlang/OTP team - Ericsson AB<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"><div dir="auto"></div><div dir="auto"><br></div><div dir="auto">--Albin</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 16, 2019, 11:53 Albin Stigö <<a href="mailto:albin.stigo@gmail.com" target="_blank">albin.stigo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">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).<div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">--Albin</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 16, 2019, 11:00 Ingela Andin <<a href="mailto:ingela.andin@gmail.com" rel="noreferrer" target="_blank">ingela.andin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div>Hi!<div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den lör 16 mars 2019 kl 10:21 skrev Albin Stigö <<a href="mailto:albin.stigo@gmail.com" rel="noreferrer noreferrer" target="_blank">albin.stigo@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>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?</div><div dir="auto"><br></div></div></blockquote><div><br></div><div>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</div><div>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. </div><div><br></div><div>Regards Ingela Erlang/OTP Team - Ericsson AB</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"></div><div dir="auto">I might have to attempt a separate DTLS use_srtp app just for this application...</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">--Albin<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Sat, Mar 16, 2019, 09:05 Ingela Andin <<a href="mailto:ingela.andin@gmail.com" rel="noreferrer noreferrer" target="_blank">ingela.andin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Albin!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den fre 15 mars 2019 kl 17:25 skrev Albin Stigö <<a href="mailto:albin.stigo@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">albin.stigo@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">Ok thanks!</div><div dir="auto"><br></div>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...<div dir="auto"><br></div></div></blockquote><div><br></div><div>? A DTLS server will always have a demultiplexing process as UDP does not have a connection concept. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"></div><div dir="auto">What's the name in the #state that holds the pid of the controlling process (the process that receives {ssl.. data)?</div><div dir="auto"><br></div></div></blockquote><div><br></div><div>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</div><div>ssl:controlling_process/2. </div><div><br></div><div>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</div><div><br></div><div>Regards Ingela Erlang/OTP team - Ericsson AB</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"></div><div dir="auto">--Albin</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 15, 2019, 17:01 Ingela Andin <<a href="mailto:ingela.andin@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">ingela.andin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Hi Albin!</div><div><br></div><div>There is the handshake_compleation option together with the handshake_continue functions that let you pause the handshake and retrieve</div><div>the hello extensions and possibly provide more options before continuing the handshake.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den fre 15 mars 2019 kl 13:20 skrev Albin Stigö <<a href="mailto:albin.stigo@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">albin.stigo@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am I right to assume this is the single point of udp receive for dtls?<br>
<br>
<a href="https://github.com/erlang/otp/blob/702ef9b0fa0a9b7345e3b397f23d8a76a2ac4df2/lib/ssl/src/dtls_connection.erl#L906" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://github.com/erlang/otp/blob/702ef9b0fa0a9b7345e3b397f23d8a76a2ac4df2/lib/ssl/src/dtls_connection.erl#L906</a><br>
<br>
<br></blockquote><div><br></div><div>If you want to multiplex UDP packets to other processes than the DTLS connection process that is not encrypted under DTLS you</div><div>should not look at the DTLS connection process but at the </div><div><br></div><div><a href="https://github.com/erlang/otp/blob/master/lib/ssl/src/dtls_packet_demux.erl#L140" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://github.com/erlang/otp/blob/master/lib/ssl/src/dtls_packet_demux.erl#L140</a><br></div><div><br></div><div>Regards Ingela Erlang/OTP team Ericsson AB</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">--Albin<br>
<br>On Fri, Mar 15, 2019 at 1:10 PM Albin Stigö <<a href="mailto:albin.stigo@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">albin.stigo@gmail.com</a>> wrote:<br>><br>> There're all kinds of abuse of DTLS it seems :-)<br>><br>> I still think the use cases are orthogonal though... Demuxing as<br>> described in <a href="https://tools.ietf.org/html/rfc7983" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://tools.ietf.org/html/rfc7983</a> is trivial and<br>> requires no state. A demux_fun would solve that problem.<br>><br>> DTLS packets wrapped in extra headers with the need of state<br>> information is much more complicated... Maybe what is needed are two<br>> different approaches? Especially since you will need forward and<br>> backwards transform..?<br>><br>> Ingela, is there already an API for getting the key data from use_srtp<br>> (when implemented) or will that have to be added also?<br>><br>><br>> --Albin<br>><br>> On Fri, Mar 15, 2019 at 11:35 AM Andreas Schultz<br>> <<a href="mailto:andreas.schultz@travelping.com" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">andreas.schultz@travelping.com</a>> wrote:<br>> ><br>> > Albin Stigö <<a href="mailto:albin.stigo@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">albin.stigo@gmail.com</a>> schrieb am Do., 14. März 2019 um 18:49 Uhr:<br>> >><br>> >> Hi Ingela and Andreas,<br>> >><br>> >> > 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<br>> >> > headers on Rx and add it on Tx (with session information if needed).<br>> >><br>> >> I have to admit I have not encountered this practice... do you have a<br>> >> particular protocol in mind or is it a part of dtls-srtp I have<br>> >> missed? One could argue that if you add additional headers and<br>> >> maintain some kind of state you are actually dealing with a different<br>> >> transport layer...?<br>> ><br>> ><br>> > CAPWAP is doing that <a href="https://tools.ietf.org/html/rfc5415#section-4.1" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://tools.ietf.org/html/rfc5415#section-4.1</a><br>> ><br>> >> I would very much like a way where filtered out packages were sent to<br>> >> the controlling process as {udp,Socket instead of {ssl, Socket... The<br>> >> question in the latter case is if Socket should be the ssl socket or<br>> >> the transport socket. Messing with the transport socket could be<br>> >> detrimental to dtls.<br>> >><br>> >> One could also extend the filter_fun idea to a transform_fun where one<br>> >> could transform in packet in addition to demultiplexing, but like I<br>> >> said, I think additional headers to dtls packets belong to the<br>> >> transport layer.<br>> ><br>> ><br>> > Passing a State in and out of such a transform would be good.<br>> ><br>> > Andreas<br>> ><br>> >><br>> >><br>> >> I don't have in-depth knowledge of the ssl app but it seems adding a<br>> >> filter_fun would be almost trivial?<br>> >><br>> >> > Maybe transport_send as compared to the existing transport_accept. Would only work for DTLS.<br>> >><br>> >> Well either that or some way of accessing the transport socket, but<br>> >> transport_send for sure plays well with existing API!<br>> >><br>> >><br>> >> --Albin<br>> >><br>> >> On Thu, Mar 14, 2019 at 6:22 PM Ingela Andin <<a href="mailto:ingela.andin@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">ingela.andin@gmail.com</a>> wrote:<br>> >> ><br>> >> > Hi!<br>> >> ><br>> >> > Andreas, see comment below.<br>> >> ><br>> >> > Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz <<a href="mailto:andreas.schultz@travelping.com" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">andreas.schultz@travelping.com</a>>:<br>> >> >><br>> >> >> Hi<br>> >> >><br>> >> >> Ingela Andin <<a href="mailto:ingela.andin@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">ingela.andin@gmail.com</a>> schrieb am Do., 14. März 2019 um 17:34 Uhr:<br>> >> >>><br>> >> >>> Hi Albin!<br>> >> >>><br>> >> >>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stigö <<a href="mailto:albin.stigo@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">albin.stigo@gmail.com</a>>:<br>> >> >>>><br>> >> >>>> Hi Ingela,<br>> >> >>>><br>> >> >>>> Thanks for the quick reply!<br>> >> >>>><br>> >> >>>> While cb_info certainly is one way of doing it, it feels a bit<br>> >> >>>> complicated... specifically if switching between active and passive<br>> >> >>>> mode. Not sure if ssl ever use passive mode internally? Demuxing is a<br>> >> >>>> different use case, I think..<br>> >> >>>><br>> >> >>><br>> >> >>> 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.<br>> >> >>><br>> >> >>> 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.<br>> >> >>><br>> >> >>><br>> >> >>>><br>> >> >>>> Something that IMHO would be fantastic and simple (?) would be a<br>> >> >>>> dtls_filter_fun option. If true packet is passed up the ssl stack,<br>> >> >>>> otherwise passed on like a normal udp packet!<br>> >> >>>><br>> >> >>><br>> >> >>> Sounds reasonable. Otherwise sent to some other Erlang process than the "DTLS-connection" process that is.<br>> >> >><br>> >> >><br>> >> >> 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).<br>> >> >><br>> >> ><br>> >> > Maybe the demultiplexor process can have a "packet mode" that is set to "no packet" default and needs a callback handler for anything else?<br>> >> ><br>> >> ><br>> >> > Regards Ingela Erlang/OTP team - Ericsson AB<br>> >> ><br>> >> >><br>> >> >> Andreas<br>> >> >><br>> >> >>><br>> >> >>><br>> >> >>>><br>> >> >>>> There's an RFC regarding the demultiplexing of SRTP/DTLS, it basically<br>> >> >>>> boils down to looking at the first byte of the packet, if it's<br>> >> >>>> [20..63] it should be treated as DTLS otherwise something else. So<br>> >> >>>> this would be absolutely trivial to implement if there was a<br>> >> >>>> dtls_filter_fun...<br>> >> >>>><br>> >> >>>> <a href="https://tools.ietf.org/html/rfc7983" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://tools.ietf.org/html/rfc7983</a><br>> >> >>>><br>> >> >>>> Then of course there also has to be a way to bypass DTLS when sending<br>> >> >>>> data... maybe send/3 (Socket, Data, Options)...<br>> >> >>>><br>> >> >>><br>> >> >>> Maybe transport_send as compared to the existing transport_accept. Would only work for DTLS.<br>> >> >>><br>> >> >>> Regards Ingela Erlang/OTP team - Ericsson AB<br>> >> >>><br>> >> >>>><br>> >> >>>> What do you think?<br>> >> >>>><br>> >> >>>><br>> >> >>>> --Albin<br>> >> >>>><br>> >> >>>> On Thu, Mar 14, 2019 at 1:52 PM Ingela Andin <<a href="mailto:ingela.andin@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">ingela.andin@gmail.com</a>> wrote:<br>> >> >>>> ><br>> >> >>>> > Hi!<br>> >> >>>> ><br>> >> >>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stigö <<a href="mailto:albin.stigo@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">albin.stigo@gmail.com</a>>:<br>> >> >>>> >><br>> >> >>>> >> Hi,<br>> >> >>>> >><br>> >> >>>> >> I'm working on an Erlang WebRTC peer client (to send audio/video to<br>> >> >>>> >> the browser).<br>> >> >>>> >><br>> >> >>>> >> WebRTC requires dtls-srtp and that in turn requires:<br>> >> >>>> >><br>> >> >>>> >> 1. The use_srtp extension for key exchange.<br>> >> >>>> ><br>> >> >>>> ><br>> >> >>>> > 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<br>> >> >>>> ><br>> >> >>>> ><br>> >> >>>> >><br>> >> >>>> >> 2. Multiplexing of stun/turn/srtp packets on the socket.<br>> >> >>>> >><br>> >> >>>> >> I know there's been work towards use_srtp and it's even in the source,<br>> >> >>>> >> but commented out. Ingela has been working on it for OTP 2, I believe,<br>> >> >>>> >> is there an ETA on this feature?<br>> >> >>>> ><br>> >> >>>> ><br>> >> >>>> >><br>> >> >>>> >><br>> >> >>>> >><br>> >> >>>> >> Is multiplexing on the DTLS socket already possible using the cb_info?<br>> >> >>>> >> Has anyone tried that?<br>> >> >>>> >><br>> >> >>>> >> <a href="http://erlang.org/pipermail/erlang-questions/2018-October/096457.html" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">http://erlang.org/pipermail/erlang-questions/2018-October/096457.html</a><br>> >> >>>> >><br>> >> >>>> ><br>> >> >>>> > 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<br>> >> >>>> > TLS-1.3, optimizations and erlang distribution over TLS has been prioritized higher. Suggestions are welcome.<br>> >> >>>> ><br>> >> >>>> > Regards Ingela Erlang/OTP team - Ericsson AB<br>> >> >>>> ><br>> >> >>>> ><br>> >> >>>> ><br>> >> >>>> ><br>> >> >>>> >><br>> >> >>>> >><br>> >> >>>> >> --Albin<br>> >> >>>> >> _______________________________________________<br>> >> >>>> >> erlang-questions mailing list<br>> >> >>>> >> <a href="mailto:erlang-questions@erlang.org" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">erlang-questions@erlang.org</a><br>> >> >>>> >> <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>> >> >>><br>> >> >>> _______________________________________________<br>> >> >>> erlang-questions mailing list<br>> >> >>> <a href="mailto:erlang-questions@erlang.org" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">erlang-questions@erlang.org</a><br>> >> >>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>> >> >><br>> >> >> --<br>> >> >> --<br>> >> >> Dipl.-Inform. Andreas Schultz<br>> >> >><br>> >> >> ----------------------- enabling your networks ----------------------<br>> >> >> Travelping GmbH Phone: +49-391-81 90 99 0<br>> >> >> Roentgenstr. 13 Fax: +49-391-81 90 99 299<br>> >> >> 39108 Magdeburg Email: <a href="mailto:info@travelping.com" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">info@travelping.com</a><br>> >> >> GERMANY Web: <a href="http://www.travelping.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">http://www.travelping.com</a><br>> >> >><br>> >> >> Company Registration: Amtsgericht Stendal Reg No.: HRB 10578<br>> >> >> Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780<br>> >> >> ---------------------------------------------------------------------<br>> ><br>> > --<br>> > --<br>> > Dipl.-Inform. Andreas Schultz<br>> ><br>> > ----------------------- enabling your networks ----------------------<br>> > Travelping GmbH Phone: +49-391-81 90 99 0<br>> > Roentgenstr. 13 Fax: +49-391-81 90 99 299<br>> > 39108 Magdeburg Email: <a href="mailto:info@travelping.com" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">info@travelping.com</a><br>> > GERMANY Web: <a href="http://www.travelping.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">http://www.travelping.com</a><br>> ><br>> > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578<br>> > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780<br>> > ---------------------------------------------------------------------<br>
</blockquote></div></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div></div></div>
</blockquote></div></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div></div></div>