mDNS module might jump to assert when a large network is formed

[Cristib05]

In context of embedded devices (MCUs using RTOS), sometimes there are limitations in terms of available memory. There are scenarios where we cannot predict how many devices could be present in a network and there is also no possibility to limit this number. We have seen some situations where the mDNS module asserts because there is no memory left to allocate capacity for an incoming query, or there are no available buffers to send a query. Could this behavior be changed and try to gracefully discard those messages? For example, in SRP server, when processing a request, if a host cannot be allocated, the execution does not assert. Could the mDNS module adopt such an approach?

[abtink]

There are pros and cons

On one hand, if a Border Router has memory limitations and cannot function properly, having it fail can be a good indicator of an issue. It can signal the problem to the user or allow mesh devices to switch to another BR in the network (assuming multiple BRs are available within mesh). Allowing the BR to operate with limited functionality might just mask the underlying problem, leading to other issues down the line.

On the other hand, I understand the desire for the graceful handling of failures. The downside I see is that a comprehensive implementation would require additional code to handle and clean up state, not only within mDNS but also throughout all other modules that use it. This would add to the overall complexity of the code and require extra testing to ensure we don't end up in corrupted states. In some cases, there may not even be a clear and proper cleanup action.

I would suggest a selective hybrid model. It may make sense to allow for graceful failure in certain situations; for example, if we cannot allocate a buffer to prepare a response, we can simply ignore the request or drop the response message. But then we keep the assert checks in other, more critical places.

Thoughts?

[marius-preda]

Hi @abtink, while thinking more about this issue I realized that asserting instead of dropping could be a vulnerability. I am thinking that this could lead to a denial of service attach where the device running OT with mDNS could be blocked. We have seen in practice mDNS multipacket queries made of 13 packets. Currently Open Thread mDNS only stores up to 10 packets but it does this for both IPv4 and IPv6 version of the same query. I am thinking that an attacker could try to block the device by sending multipacket queries made out of 10 packets in a quick succession to try to consume all the message buffers. The multipackets are stored for up to 5 minutes because each new packet resets the 400-500 ms timer. During this time, if a mDNS TX needs to happen, the code will assert because there aren't enough memory buffers left.
On a limited resources device this can happen quite easy, maybe it's more difficult on a device that has more memory resources.

Thoughts?

[abtink]

Yes. Multi-packet queue may be a good place to apply error handling, i.e. drop new (or older) messages if out of memory.