Re: [reSIProcate] how to drop incoming packets at the socket (transport) layer
- From: Alan Hawrylyshen <alan@xxxxxxxxxx>
- Date: Fri, 6 Jan 2006 18:31:07 -0700
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