Re: [Quickfix-developers] Restricting acceptor to specific IP address(es)

[Oren M. <or...@qu...>]

Well there is a natural hesitation to do something like this due to =20
the design philosophy of QuickFIX.  It is different from most vendors =20=

is that QuickFIX is designed to be a pure protocol implementation, =20
not a platform.  I'm just mentioning that because we look upon new =20
functionality that appears to be out of scope of the protocol with =20
suspicion.  In the end it means you have to sell harder to get it =20
into QuickFIX :).

One issue I have with this it feels like we are implementing firewall =20=

like functionality into the engine.  And in the end, a firewall is =20
going to do a much better job of it as that is its design.

And that leads to this problem.  Such functionality becomes =20
completely useless if you have any sort of gateway between you and =20
the client.  If you are using Stunnel for instance, having QuickFIX =20
filter by IP will do nothing at all.  So then do you build firewall =20
capabilities into Stunnel (maybe they do, I don't know)?  Or a more =20
relevant example coming up will be the presence of FIX over FAST =20
which will require FAST gateway.  So once again you must build this =20
functionality into the FAST gateway.  Or maybe you are coming into =20
QuickFIX from an application server.  Anything that stands between =20
your engine and the counterparty makes QuickFIX filtering pretty =20
useless.

In my mind the *real* feature request here, is for a QuickFIX =20
application to be able to get more details about the underlying =20
connection.  Something that has been requested in the past.  With =20
this capability you can look at the incoming IP and filter as you see =20=

fit if that is how you choose to use the information.  This is =20
something I feel more comfortable adding to the core library.

--oren

On May 17, 2006, at 2:57 PM, Ajay Kamdar wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/=20
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Ok, removal of the single port restriction should make the firewall
> solution more palatable in many situations where the number of FIX
> sessions is not high and FIX session configuration is mostly static.
> However IMHO that is still a less than desirable solution for
> organizations (like mine) which have 100+ external FIX sessions, =20
> session
> configurations change often (especially in customer staging/test), and
> the FIX session configuration and onboarding is primarily handled by a
> non-technical client services team.
>
> In general do you agree that having the engine itself support IP =20
> address
> matching before establishing the FIX session is a much cleaner and
> elegant solution than to have to work around with a separate firewall?
> If we are in agreement in principle that this would be a good thing to
> add to QuickFIX, then I can work on submitting a patch suitable for
> wider consumption. Otherwise I can simply hack something up much more
> quickly that is specific for my environment.
>
> - Ajay
>
> -----Original Message-----
> From: Oren Miller [mailto:or...@qu...]
> Sent: Wednesday, May 17, 2006 3:39 PM
> To: Ajay Kamdar
> Cc: Caleb Epstein; qui...@li...
> Subject: Re: [Quickfix-developers] Restricting acceptor to specific IP
> address(es)
>
>
> The single port restriction is no longer true with the latest CVS
> source.  You can now assign the acceptor port on a per session basis.
>
> --oren
>
> On May 17, 2006, at 2:22 PM, Ajay Kamdar wrote:
>
>> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/
>> html/index.html
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>> A) The last time I checked, QuickFIX allowed only one Acceptor port
>> for
>> all the Sessions configured to run within one QuickFIX instance.
>> B) Say I have sessions S1 through S10 defined within the config file
>> with ConnectionType=3Dacceptor. All counter parties will have to =20
>> connect
>> to the single acceptor port in (A)
>> C) The allowed IP addresses for S1-S10 are respectively IP1 through
>> IP10
>> (i.e. IP1 can logon only to S1 but not to S2-S9, IP2 only to S2 but
>> not
>> to S1,S3-S9, etc.)
>>
>> Given the above scenario, I am afraid I don't get how the local
>> firewall
>> process would know enough to accept a socket connection from IP1
>> only if
>> FIX session that would get established (as determined by the =20
>> SessionID
>> composed of BeginString,SenderCompID,TargetCompID) is S1 but not
>> accept
>> the connection if IP1 is erroneously trying to establish sessions
>> S2-S9.
>> For that match to be made correctly, the FIX engine actually has to
>> also
>> match the IP address of the socket peer with the allowed IP addresses
>> for the Session before considering the FIX Session to have been
>> successfully established.
>>
>> - Ajay
>>
>> -----Original Message-----
>> From: Caleb Epstein [mailto:cal...@gm...]
>> Sent: Wednesday, May 17, 2006 2:48 PM
>> To: Ajay Kamdar
>> Cc: Oren Miller; Zoran Cetusic;
>> qui...@li...
>> Subject: Re: [Quickfix-developers] Restricting acceptor to =20
>> specific IP
>> address(es)
>>
>>
>> On 5/17/06, Ajay Kamdar <Aja...@tr...> wrote:
>>
>>> - The local firewall process would need to be understand the concept
>>> of FIX sessions
>>
>> Why?  Just restrict access to the port(s) your Acceptor is running
>> on to
>> the IPs you want to allow.
>>
>> --
>> Caleb Epstein
>> caleb dot epstein at gmail dot com
>>
>> ---------------------------------------------------------------------=20=

>> -
>> -----
>>
>> The information in this email is confidential and may be legally
>> privileged.
>> It is intended solely for the addressee. Access to this email by
>> anyone else
>> is unauthorized. If you are not the intended recipient, any
>> disclosure, copying,
>> distribution or any action taken or omitted to be taken in reliance
>> on it, is
>> prohibited and may be unlawful.
>>
>> TradeWeb reserves the right to monitor and review the content of
>> all messages sent
>> to or from this e-mail address. Messages sent to or from this e-
>> mail address may
>> be stored on the TradeWeb e-mail system.
>>
>>
>>
>> -------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services,
>> security?
>> Get stuff done quickly with pre-integrated technology to make your
>> job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache
>> Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=120709&bid&3057&dat=12164=
2
>> _______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, =20
> security?
> Get stuff done quickly with pre-integrated technology to make your =20
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=120709&bid&3057&dat=121642=

> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>