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

["Justin Matthews" <jmatthewsr@xxxxxxxxx>]

The requirement that I am looking for is one where the resip stack does no
processing of the incoming socket data.  Retrieving the source info from the
SipMessage means that the stack has already parsed/pre-parsed at least some
of the incoming data.  

I am in agreement on ACL's, adding this kind of functionality to my app
without resip supporting it directly is exactly what I am trying to do. The
problem is there is no way to do this currently without modifying the
existing transports (create local edits on the source) or creating custom
transports (cumbersome and just as much work to merge as local edits).  


I have attached a proposed solution.  The exact implementation may vary, but
it illustrates exactly what I am trying to accomplish.

Thanks,

-Justin




-----Original Message-----
From: jason.fischl@xxxxxxxxx [mailto:jason.fischl@xxxxxxxxx] On Behalf Of
Jason Fischl
Sent: Monday, January 09, 2006 12:58 PM
To: Justin Matthews
Cc: Alan Hawrylyshen; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] how to drop incoming packets at the socket
(transport) layer

On 1/9/06, Justin Matthews <jmatthewsr@xxxxxxxxx> wrote:
> Hi Jason,
>
> This solution still requires parsing a SIP message, which makes it
> vulnerable to attacks on the parser.
>
> I believe that software applications should have some awareness of system
> level security, should not assume that someone else will solve this
problem
> completely and provide whatever reasonable means to help facilitate an
> overall solution to security.  Exposing an incoming packet's source
> information, I believe, is a reasonable means of adding to an applications
> overall security solution.
>
The SipMessage object does provide access to the packet's source
already. So maybe we are discussing separate requirements. I was
addressing the point of whether the stack should do access control
lists by ip addresses (which I don't think it should). If an
application wants ACLs, it should implement them itself.

On a separate (but related note) we may want to add the ability to do
arbitrary message processing early on (in the Transport) before the
transaction kicks in. This topic has been addressed before. One of the
discussion points around this has been whether this pre and/or post
processing should be sync or async.



> Thanks,
>
> -Justin
>
> -----Original Message-----
> From: jason.fischl@xxxxxxxxx [mailto:jason.fischl@xxxxxxxxx] On Behalf Of
> Jason Fischl
> Sent: Saturday, January 07, 2006 12:01 PM
> To: Justin Matthews
> Cc: Alan Hawrylyshen; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [reSIProcate] how to drop incoming packets at the socket
> (transport) layer
>
> >
> > 1) This is directly related to security, which will be an increasingly
> > important issue in the SIP space.
>
> I think the IETF approach to this problem is to use the sip-identity
> mechanism specified in
> http://www.softarmor.com/wgdb/docs/draft-ietf-sip-identity-05.txt.
>
>
>

Attachment: TcpBaseTransport.cxx
Description: Binary data

Attachment: Transport.cxx
Description: Binary data

Attachment: Transport.hxx
Description: Binary data

Attachment: UdpTransport.cxx
Description: Binary data