I realised that makeStreamParser had no implemented mechanism to prevent from flood.
Meaning that a peer transmiting random data that does not parse to a SIP message and does not contain CRLF*2 will be able to crash the server in no time.
This is due to the fact that the makeStreamParser function buffer all the received data until it came across a double CRLF.
An other easy way to take down this stack is to send a message with the Content-Length header value set to a enormous value then send random data until the server crash.
In this PR I offer to set boundary to the SIP header length and to the content length.
Those value can be configured via the options object.
When a flood attempt is detected then the source socket is closed.
I realised that makeStreamParser had no implemented mechanism to prevent from flood.
Meaning that a peer transmiting random data that does not parse to a SIP message and does not contain CRLF*2 will be able to crash the server in no time. This is due to the fact that the makeStreamParser function buffer all the received data until it came across a double CRLF.
An other easy way to take down this stack is to send a message with the Content-Length header value set to a enormous value then send random data until the server crash.
In this PR I offer to set boundary to the SIP header length and to the content length. Those value can be configured via the options object. When a flood attempt is detected then the source socket is closed.
Regards