[openssl-users] DTLS fragmentation and mem BIO

[Lorenzo Miniero]

Eureka, I got it working! Thanks to the feedback from Matt and Alfred, I
managed to create a filter that does what I need. To those who may be
interested, it's available here:

https://github.com/meetecho/janus-gateway/pull/254

Thanks for your great support!
Lorenzo


2015-06-05 13:34 GMT+02:00 Lorenzo Miniero <lminiero at gmail.com>:

> 2015-06-05 12:30 GMT+02:00 Matt Caswell <matt at openssl.org>:
>
>>
>>
>> On 05/06/15 10:20, Lorenzo Miniero wrote:
>> > Just one quick question about this: are messages/packets passed to the
>> > BIO actually splitted, and then just queued by the mem BIO in the
>> > buffer, or can there be cases where a larger than normal buffer is
>> > passed to the BIO anyway, meaning a manual splitting could be needed
>> > nevertheless from time to time?
>>
>> No, there should be no need for the BIO to do any splitting. Everything
>> that gets written to the BIO should be a datagram.
>>
>> One issue that does spring to mind is that in your filter BIO you may
>> want to implement some of the dgram ctrls that DTLS uses. This depends
>> on how you want to manage setting your MTU.
>>
>> Do you set an MTU size explicitly using SSL_set_mtu(ssl, mtu) or
>> DTLS_set_link_mtu(ssl, mtu)? Also, do you set the option
>> SSL_OP_NO_QUERY_MTU? If you use the option then you should set an MTU
>> size explicitly.
>>
>> If you don't set the SSL_OP_NO_QUERY_MTU option then the DTLS code will
>> attempt to query the underlying BIO for information about the mtu size.
>> That would mean you would have to implement the following additional
>> ctrls:
>> BIO_CTRL_DGRAM_GET_FALLBACK_MTU - returns a "default" MTU size if
>> querying fails for some reason
>> BIO_CTRL_DGRAM_QUERY_MTU - queries the transport for the MTU size to be
>> used
>> BIO_CTRL_DGRAM_SET_MTU - sets the MTU size on the underlying transport
>> BIO_CTRL_DGRAM_MTU_EXCEEDED - returns true if the datagram we just tried
>> to send failed because we exceeded the max MTU size
>>
>> Matt
>>
>>
> Hi Matt,
>
> thanks for the clarification and for the hints.
>
> I've started looking into filters and I have some doubts, though, also
> taking into account what you suggested, and I apologize again if this turns
> out to be silly. As far as I've understood, what I should do is changing
> the current pattern I use for outgoing packets:
>
>       application < memBIO < ssl
>
> to something like this:
>
>       application < memBIO < filter < ssl
>
> or this:
>
>       application < filter < memBIO < ssl
>
> that is, a new BIO filter that enforces the fragmentation I talked about.
> Not exactly sure about which one should be the way to go, but I've given
> this some thought.
>
> The first one seems conceptually correct, in the sense that the filter
> receives the properly sized packets from the stack; I see issues in how to
> progressively make them available to the memBIO, though, especially
> considering that we cannot "relay" a BIO_read call (that is, have the mem
> BIO ask for data to the next BIO in the chain when data is requested). My
> guess, looking at the BIOs code, is that this is all asynchronous, that is,
> the DTLS stack issues a BIO_write that reaches the filter, and then it's
> the filter that forwards the written data (modified or not) to the next
> BIO, in this case the mem one, using another BIO_write. My concern here is
> how to figure out when to issue such a write: in fact, if we want to make
> sure that the mem BIO never returns too much data when a BIO_read is
> issued, we should never issue a new BIO_write to feed it with new data from
> the filter until the previous one has been read, something we cannot do if
> we don't know when the data has been read in the first place.
>
> The second one, as a consequence, may actually be more suited for the
> purpose, as we can always only return what we want to in a BIO_read. The
> issue there is what I mentioned in my previous post, that is, my fear being
> that the memBIO could feed too much data to my filter in a BIO_write, which
> would force my filter to inspect the payload and manually split packets as
> I'd do in my application. But according to what you said at the beginning
> of your reply, this shouldn't be the case, right? That is, the DTLS stack
> will issue different BIO_writes towards the memBIO for each
> packet/fragment, and this would automatically we forwarded to my filter, am
> I correct? Since in this case there wouldn't be any explicit BIO_read done
> from the application that may return what's been buffered so far.
>
> Apologies if I'm adding confusion with these questions, I'm just trying to
> figure out the best approach to the new filter. As an alternative, I guess
> I could just extend the existing mem BIO to a new, custom BIO, and handle
> it all there, but my feeling is that a filter would be a cleaner way to do
> that.
>
> Thanks again!
> Lorenzo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150605/e79a7e03/attachment-0001.html>