RE: [reSIProcate] how to drop incoming packets at the socket (transport) layer
Alan,
Thanks for the reply. Yes, I am simply talking about dropping
UDP(packets)/TCP(connections) based on originating IP/port.
I agree with you that this work would be out of scope from a SIP standpoint.
This falls into the application or system scope (firewall as you suggested).
As we all know, security is a very touchy subject both from within
organizations producing software and with end users. This is a simply a
very easy way to offer a "normally closed" configuration regarding SIP
within our application. There are customers unwilling, unable (or
uninformed) to implement and manage a firewall type scheme and so they place
the responsibility on the software company. Integrating the app with the OS
firewall is an option, but can be problematic because it is easily disabled
by the end user (disabling the entire firewall).
I also agree that out of scope additions to resip are not a good idea, but
in this case my main points for adding this are:
1) This is directly related to security, which will be an increasingly
important issue in the SIP space.
2) Because this issue deals with sockets, a resource that is not part of
resiprocate. The resip stack already realizes this in the way that
transports are added to the stack. (I know that another solution to my
problem would be to create my own udp/tcp transport classes)
3) Since this does not fall into the SIP scope, it can't directly break any
SIP compliance. The application can certainly use it to disallow SIP
processes such as the "normally open" registration model, but this is
entirely up to the application. This is the same as enabling socket
restrictions via a firewall. This feature simply gives my app the resources
to apply this restriction.
Thanks for your time,
-Justin
-----Original Message-----
From: Alan Hawrylyshen [mailto:alan@xxxxxxxxxx]
Sent: Friday, January 06, 2006 8:31 PM
To: Justin Matthews
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: 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