< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] how to drop incoming packets at the socket (transport) layer



On Jan 5, 2006, at 09.30, Justin Matthews wrote:

Hi,

In most cases our app is deployed with known endpoints. In this scenario we
can make our app drop incoming packets from unknown endpoints.  If the
packets can be dropped at the network layer, they are never parsed and our
app is that much more secure against DoS and other attacks.

It is pretty straightforward to modify the Transport/socket related code to do this, but I am looking for a way in which the resip group would accept a more general pre-screening solution at the socket layer. One proposal would be to add a screening class when calling SipStack::addTransport. This class would be able to screen incoming data directly from a socket based on the transport. The implementation of the screening is up to the user, in my
case I would check the incoming IP address and allow or disallow the
processing of the packet.

Any thoughts?

What kind of screening? Are you talking about dropping packets (UDP) that originate from an unknown IP address and port? How would you resolve the inherent conflict between this and REGISTER- based mobility? SIP is not designed to have this particular restriction, and in any event, I don't think there would be benefit in putting this in the application / stack.

Traditionally, we have strongly resisted the addition of features to reSIProcate that are either out-of-scope or out-of-compliance. Since this feature could be trivially abused or misused by developers to break interoperability and the end-to-end, peer-to-peer nature of SIP itself, I think you might find the group hesitant to support this idea.

Ideology aside; I feel this would be the responsibility of the operating system or UDP stack itself. By getting the kernel / OS to perform this operation you will save the context switching overhead that would be required to get the packet into the software in the first place. Double win : the software is less complex and the solution is more efficient. Even though I am responsible for products that could benefit from this proposal, I think that this is not a function that should be in the SIP stack; it's purely a pre-layer 2 / 3 issue, not layer 4, 5 or 7.

I believe there would be APIs and interfaces in all modern OSes to configure the software firewall to do this for you.

Counter-thoughts?

Alan Hawrylyshen