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

[Alan Hawrylyshen]

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