|
|
|
|
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.
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--Albin
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
Hi! 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
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..
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!
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/rfc7983Then of course there also has to be a way to bypass DTLS when sending
data... maybe send/3 (Socket, Data, Options)...
What do you think?
--Albin
On Thu, Mar 14, 2019 at 1:52 PM Ingela Andin < [hidden email]> wrote:
>
> Hi!
>
> Den tors 14 mars 2019 kl 12:29 skrev Albin Stigö < [hidden email]>:
>>
>> 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
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
The best option is to use dtls as a server that allows sending packets from outside and receiving reply from there.
We are using this code in our webrtc stack, took it from dtls4srtp.erl file _______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
Hi Albin! 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.
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 <[hidden email]> wrote:> > Hi! > > Den tors 14 mars 2019 kl 12:29 skrev Albin Stigö < [hidden email]>: >> >> 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 >> [hidden email]>> http://erlang.org/mailman/listinfo/erlang-questions _______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
Hi Ingela Andin < [hidden email]> schrieb am Do., 14. März 2019 um 17:34 Uhr: 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).
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 <[hidden email]> wrote:> > Hi! > > Den tors 14 mars 2019 kl 12:29 skrev Albin Stigö < [hidden email]>: >> >> 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 >> [hidden email]>> http://erlang.org/mailman/listinfo/erlang-questions
erlang-questions mailing list
[hidden email]
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: [hidden email]
GERMANY Web: http://www.travelping.com
Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780
--------------------------------------------------------------------- _______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
Hi!
Andreas, see comment below. Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz < [hidden email]>: Hi Ingela Andin < [hidden email]> schrieb am Do., 14. März 2019 um 17:34 Uhr: 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 <[hidden email]> wrote:> > Hi! > > Den tors 14 mars 2019 kl 12:29 skrev Albin Stigö < [hidden email]>: >> >> 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 >> [hidden email]>> http://erlang.org/mailman/listinfo/erlang-questions
erlang-questions mailing list
[hidden email]
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: [hidden email]
GERMANY Web: http://www.travelping.com
Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780
---------------------------------------------------------------------
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
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...?
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.
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 < [hidden email]> wrote:
>
> Hi!
>
> Andreas, see comment below.
>
> Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz < [hidden email]>:
>>
>> Hi
>>
>> Ingela Andin < [hidden email]> schrieb am Do., 14. März 2019 um 17:34 Uhr:
>>>
>>> Hi Albin!
>>>
>>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stigö < [hidden email]>:
>>>>
>>>> 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 < [hidden email]> wrote:
>>>> >
>>>> > Hi!
>>>> >
>>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stigö < [hidden email]>:
>>>> >>
>>>> >> 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
>>>> >> [hidden email]
>>>> >> http://erlang.org/mailman/listinfo/erlang-questions>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> [hidden email]
>>> 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: [hidden email]
>> GERMANY Web: http://www.travelping.com>>
>> Company Registration: Amtsgericht Stendal Reg No.: HRB 10578
>> Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780
>> ---------------------------------------------------------------------
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
Albin Stigö < [hidden email]> 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...?
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 <[hidden email]> wrote:
>
> Hi!
>
> Andreas, see comment below.
>
> Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz <[hidden email]>:
>>
>> Hi
>>
>> Ingela Andin <[hidden email]> schrieb am Do., 14. März 2019 um 17:34 Uhr:
>>>
>>> Hi Albin!
>>>
>>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stigö <[hidden email]>:
>>>>
>>>> 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 <[hidden email]> wrote:
>>>> >
>>>> > Hi!
>>>> >
>>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stigö <[hidden email]>:
>>>> >>
>>>> >> 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
>>>> >> [hidden email]
>>>> >> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> [hidden email]
>>> 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: <a href="tel:+49%20391%20819099299" value="+49391819099299" target="_blank">+49-391-81 90 99 299
>> 39108 Magdeburg Email: [hidden email]
>> 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: [hidden email]
GERMANY Web: http://www.travelping.com
Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780
--------------------------------------------------------------------- _______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
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
< [hidden email]> wrote:
>
> Albin Stigö < [hidden email]> 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 < [hidden email]> wrote:
>> >
>> > Hi!
>> >
>> > Andreas, see comment below.
>> >
>> > Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz < [hidden email]>:
>> >>
>> >> Hi
>> >>
>> >> Ingela Andin < [hidden email]> schrieb am Do., 14. März 2019 um 17:34 Uhr:
>> >>>
>> >>> Hi Albin!
>> >>>
>> >>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stigö < [hidden email]>:
>> >>>>
>> >>>> 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 < [hidden email]> wrote:
>> >>>> >
>> >>>> > Hi!
>> >>>> >
>> >>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stigö < [hidden email]>:
>> >>>> >>
>> >>>> >> 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
>> >>>> >> [hidden email]
>> >>>> >> http://erlang.org/mailman/listinfo/erlang-questions>> >>>
>> >>> _______________________________________________
>> >>> erlang-questions mailing list
>> >>> [hidden email]
>> >>> 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: [hidden email]
>> >> 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: [hidden email]
> GERMANY Web: http://www.travelping.com>
> Company Registration: Amtsgericht Stendal Reg No.: HRB 10578
> Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780
> ---------------------------------------------------------------------
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
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--Albin
On Fri, Mar 15, 2019 at 1:10 PM Albin Stigö < [hidden email]> 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
> < [hidden email]> wrote:
> >
> > Albin Stigö < [hidden email]> 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 < [hidden email]> wrote:
> >> >
> >> > Hi!
> >> >
> >> > Andreas, see comment below.
> >> >
> >> > Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz < [hidden email]>:
> >> >>
> >> >> Hi
> >> >>
> >> >> Ingela Andin < [hidden email]> schrieb am Do., 14. März 2019 um 17:34 Uhr:
> >> >>>
> >> >>> Hi Albin!
> >> >>>
> >> >>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stigö < [hidden email]>:
> >> >>>>
> >> >>>> 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 < [hidden email]> wrote:
> >> >>>> >
> >> >>>> > Hi!
> >> >>>> >
> >> >>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stigö < [hidden email]>:
> >> >>>> >>
> >> >>>> >> 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
> >> >>>> >> [hidden email]
> >> >>>> >> http://erlang.org/mailman/listinfo/erlang-questions> >> >>>
> >> >>> _______________________________________________
> >> >>> erlang-questions mailing list
> >> >>> [hidden email]
> >> >>> 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: [hidden email]
> >> >> 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: [hidden email]
> > GERMANY Web: http://www.travelping.com> >
> > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578
> > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780
> > ---------------------------------------------------------------------
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
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. 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
Regards Ingela Erlang/OTP team Ericsson AB --Albin
On Fri, Mar 15, 2019 at 1:10 PM Albin Stigö <[hidden email]> 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 > < [hidden email]> wrote: > > > > Albin Stigö < [hidden email]> 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 < [hidden email]> wrote: > >> > > >> > Hi! > >> > > >> > Andreas, see comment below. > >> > > >> > Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz < [hidden email]>: > >> >> > >> >> Hi > >> >> > >> >> Ingela Andin < [hidden email]> schrieb am Do., 14. März 2019 um 17:34 Uhr: > >> >>> > >> >>> Hi Albin! > >> >>> > >> >>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stigö < [hidden email]>: > >> >>>> > >> >>>> 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 < [hidden email]> wrote: > >> >>>> > > >> >>>> > Hi! > >> >>>> > > >> >>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stigö < [hidden email]>: > >> >>>> >> > >> >>>> >> 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 > >> >>>> >> [hidden email]> >> >>>> >> http://erlang.org/mailman/listinfo/erlang-questions> >> >>> > >> >>> _______________________________________________ > >> >>> erlang-questions mailing list > >> >>> [hidden email]> >> >>> 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: [hidden email]> >> >> 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: [hidden email]> > GERMANY Web: http://www.travelping.com> > > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 > > --------------------------------------------------------------------- _______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
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...
What's the name in the #state that holds the pid of the controlling process (the process that receives {ssl.. data)?
--Albin 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. 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
Regards Ingela Erlang/OTP team Ericsson AB --Albin
On Fri, Mar 15, 2019 at 1:10 PM Albin Stigö <[hidden email]> 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 > < [hidden email]> wrote: > > > > Albin Stigö < [hidden email]> 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 < [hidden email]> wrote: > >> > > >> > Hi! > >> > > >> > Andreas, see comment below. > >> > > >> > Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz < [hidden email]>: > >> >> > >> >> Hi > >> >> > >> >> Ingela Andin < [hidden email]> schrieb am Do., 14. März 2019 um 17:34 Uhr: > >> >>> > >> >>> Hi Albin! > >> >>> > >> >>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stigö < [hidden email]>: > >> >>>> > >> >>>> 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 < [hidden email]> wrote: > >> >>>> > > >> >>>> > Hi! > >> >>>> > > >> >>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stigö < [hidden email]>: > >> >>>> >> > >> >>>> >> 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 > >> >>>> >> [hidden email]> >> >>>> >> http://erlang.org/mailman/listinfo/erlang-questions> >> >>> > >> >>> _______________________________________________ > >> >>> erlang-questions mailing list > >> >>> [hidden email]> >> >>> 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: [hidden email]> >> >> 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: [hidden email]> > GERMANY Web: http://www.travelping.com> > > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 > > ---------------------------------------------------------------------
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
Hi Albin! 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
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. 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
Regards Ingela Erlang/OTP team Ericsson AB --Albin
On Fri, Mar 15, 2019 at 1:10 PM Albin Stigö <[hidden email]> 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 > < [hidden email]> wrote: > > > > Albin Stigö < [hidden email]> 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 < [hidden email]> wrote: > >> > > >> > Hi! > >> > > >> > Andreas, see comment below. > >> > > >> > Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz < [hidden email]>: > >> >> > >> >> Hi > >> >> > >> >> Ingela Andin < [hidden email]> schrieb am Do., 14. März 2019 um 17:34 Uhr: > >> >>> > >> >>> Hi Albin! > >> >>> > >> >>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stigö < [hidden email]>: > >> >>>> > >> >>>> 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 < [hidden email]> wrote: > >> >>>> > > >> >>>> > Hi! > >> >>>> > > >> >>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stigö < [hidden email]>: > >> >>>> >> > >> >>>> >> 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 > >> >>>> >> [hidden email]> >> >>>> >> http://erlang.org/mailman/listinfo/erlang-questions> >> >>> > >> >>> _______________________________________________ > >> >>> erlang-questions mailing list > >> >>> [hidden email]> >> >>> 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: [hidden email]> >> >> 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: [hidden email]> > GERMANY Web: http://www.travelping.com> > > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 > > ---------------------------------------------------------------------
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
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?
I might have to attempt a separate DTLS use_srtp app just for this application...
--Albin Hi Albin! 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
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. 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
Regards Ingela Erlang/OTP team Ericsson AB --Albin
On Fri, Mar 15, 2019 at 1:10 PM Albin Stigö <[hidden email]> 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 > < [hidden email]> wrote: > > > > Albin Stigö < [hidden email]> 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 < [hidden email]> wrote: > >> > > >> > Hi! > >> > > >> > Andreas, see comment below. > >> > > >> > Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz < [hidden email]>: > >> >> > >> >> Hi > >> >> > >> >> Ingela Andin < [hidden email]> schrieb am Do., 14. März 2019 um 17:34 Uhr: > >> >>> > >> >>> Hi Albin! > >> >>> > >> >>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stigö < [hidden email]>: > >> >>>> > >> >>>> 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 < [hidden email]> wrote: > >> >>>> > > >> >>>> > Hi! > >> >>>> > > >> >>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stigö < [hidden email]>: > >> >>>> >> > >> >>>> >> 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 > >> >>>> >> [hidden email]> >> >>>> >> http://erlang.org/mailman/listinfo/erlang-questions> >> >>> > >> >>> _______________________________________________ > >> >>> erlang-questions mailing list > >> >>> [hidden email]> >> >>> 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: [hidden email]> >> >> 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: [hidden email]> > GERMANY Web: http://www.travelping.com> > > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 > > ---------------------------------------------------------------------
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
Hi! 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 Hi Albin! 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
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. 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
Regards Ingela Erlang/OTP team Ericsson AB --Albin
On Fri, Mar 15, 2019 at 1:10 PM Albin Stigö <[hidden email]> 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 > < [hidden email]> wrote: > > > > Albin Stigö < [hidden email]> 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 < [hidden email]> wrote: > >> > > >> > Hi! > >> > > >> > Andreas, see comment below. > >> > > >> > Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz < [hidden email]>: > >> >> > >> >> Hi > >> >> > >> >> Ingela Andin < [hidden email]> schrieb am Do., 14. März 2019 um 17:34 Uhr: > >> >>> > >> >>> Hi Albin! > >> >>> > >> >>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stigö < [hidden email]>: > >> >>>> > >> >>>> 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 < [hidden email]> wrote: > >> >>>> > > >> >>>> > Hi! > >> >>>> > > >> >>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stigö < [hidden email]>: > >> >>>> >> > >> >>>> >> 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 > >> >>>> >> [hidden email]> >> >>>> >> http://erlang.org/mailman/listinfo/erlang-questions> >> >>> > >> >>> _______________________________________________ > >> >>> erlang-questions mailing list > >> >>> [hidden email]> >> >>> 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: [hidden email]> >> >> 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: [hidden email]> > GERMANY Web: http://www.travelping.com> > > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 > > ---------------------------------------------------------------------
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
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
Hi! 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 Hi Albin! 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
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. 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
Regards Ingela Erlang/OTP team Ericsson AB --Albin
On Fri, Mar 15, 2019 at 1:10 PM Albin Stigö <[hidden email]> 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 > < [hidden email]> wrote: > > > > Albin Stigö < [hidden email]> 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 < [hidden email]> wrote: > >> > > >> > Hi! > >> > > >> > Andreas, see comment below. > >> > > >> > Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz < [hidden email]>: > >> >> > >> >> Hi > >> >> > >> >> Ingela Andin < [hidden email]> schrieb am Do., 14. März 2019 um 17:34 Uhr: > >> >>> > >> >>> Hi Albin! > >> >>> > >> >>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stigö < [hidden email]>: > >> >>>> > >> >>>> 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 < [hidden email]> wrote: > >> >>>> > > >> >>>> > Hi! > >> >>>> > > >> >>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stigö < [hidden email]>: > >> >>>> >> > >> >>>> >> 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 > >> >>>> >> [hidden email]> >> >>>> >> http://erlang.org/mailman/listinfo/erlang-questions> >> >>> > >> >>> _______________________________________________ > >> >>> erlang-questions mailing list > >> >>> [hidden email]> >> >>> 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: [hidden email]> >> >> 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: [hidden email]> > GERMANY Web: http://www.travelping.com> > > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 > > ---------------------------------------------------------------------
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
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.. 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
Hi! 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 Hi Albin! 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
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. 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
Regards Ingela Erlang/OTP team Ericsson AB --Albin
On Fri, Mar 15, 2019 at 1:10 PM Albin Stigö <[hidden email]> 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 > < [hidden email]> wrote: > > > > Albin Stigö < [hidden email]> 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 < [hidden email]> wrote: > >> > > >> > Hi! > >> > > >> > Andreas, see comment below. > >> > > >> > Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz < [hidden email]>: > >> >> > >> >> Hi > >> >> > >> >> Ingela Andin < [hidden email]> schrieb am Do., 14. März 2019 um 17:34 Uhr: > >> >>> > >> >>> Hi Albin! > >> >>> > >> >>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stigö < [hidden email]>: > >> >>>> > >> >>>> 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 < [hidden email]> wrote: > >> >>>> > > >> >>>> > Hi! > >> >>>> > > >> >>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stigö < [hidden email]>: > >> >>>> >> > >> >>>> >> 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 > >> >>>> >> [hidden email]> >> >>>> >> http://erlang.org/mailman/listinfo/erlang-questions> >> >>> > >> >>> _______________________________________________ > >> >>> erlang-questions mailing list > >> >>> [hidden email]> >> >>> 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: [hidden email]> >> >> 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: [hidden email]> > GERMANY Web: http://www.travelping.com> > > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 > > ---------------------------------------------------------------------
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
Hi!
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..
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.
Regards Ingela Erlang/OTP team - Ericsson AB
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
Hi! 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 Hi Albin! 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
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. 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
Regards Ingela Erlang/OTP team Ericsson AB --Albin
On Fri, Mar 15, 2019 at 1:10 PM Albin Stigö <[hidden email]> 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 > < [hidden email]> wrote: > > > > Albin Stigö < [hidden email]> 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 < [hidden email]> wrote: > >> > > >> > Hi! > >> > > >> > Andreas, see comment below. > >> > > >> > Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz < [hidden email]>: > >> >> > >> >> Hi > >> >> > >> >> Ingela Andin < [hidden email]> schrieb am Do., 14. März 2019 um 17:34 Uhr: > >> >>> > >> >>> Hi Albin! > >> >>> > >> >>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stigö < [hidden email]>: > >> >>>> > >> >>>> 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 < [hidden email]> wrote: > >> >>>> > > >> >>>> > Hi! > >> >>>> > > >> >>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stigö < [hidden email]>: > >> >>>> >> > >> >>>> >> 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 > >> >>>> >> [hidden email]> >> >>>> >> http://erlang.org/mailman/listinfo/erlang-questions> >> >>> > >> >>> _______________________________________________ > >> >>> erlang-questions mailing list > >> >>> [hidden email]> >> >>> 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: [hidden email]> >> >> 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: [hidden email]> > GERMANY Web: http://www.travelping.com> > > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 > > ---------------------------------------------------------------------
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
Locked
