Behavior of Counter party on receiving Invalid Logon message: Send Logon response or Logoff?

, ,
1

Imported from previous forum

2

In reading the above two clauses posted by Yuval - I would argue that the validation issues described do warrant sending a Logout with Text(58) populated with exception as the validation are likely outside of this narrow constraint: “If during a logon either the SenderCompID, TargetCompID or IP address of the session initiator is invalid, it is recommended that the session be immediately terminated and no Logout message sent.”

I would also argue that we need to reword this section as even in the case of an invalid SenderCompID, what would be returned on the logout message would just be the SenderCompID, TargetCompID provided on the inbound Logon message.

3

Hi Vikash,

Again, the official document is available to download in: http://www.fixtradingcommunity.org/pg/structure/tech-specs/transport-layers-for-fix

i.e.
Doc: http://www.fixtradingcommunity.org/mod/file/download.php?file_guid=30044
PDF: http://www.fixtradingcommunity.org/mod/file/download.php?file_guid=30045

4

We had some people back in the late 1990s driving technical decisions that were overly concerned about denial of service attacks and there was a predominance of “do not send any response to errors”. This has led to thousands of lost hours of debugging and diagnosing problems because there are no diagnostics. Many implementations now more appropriately respond with a message using a Logout as opposed to being silent on the issue.

When I started with FIX, things such as disagreement on heatbeat interval would also result in a dropped connection with no response, if the sequence number on the inbound session being re-established was too low this often resulted in a dropped connection.

My strongest recommendation is that a message, such as Logout be sent in response to invalid credentials. Monitoring for denial of service or password hacking can be done via a variety of commercial monitoring systems.

For better or worse, our protocol requires a secure encrypted connection, nothing short of this provides adequate security and this may not be sufficient.

Most attempts at providing a user authentication via logon are subject to replay attacks and most firms do not protect their log files sufficiently to preclude someone within the network to use this as an exploit.

5

Thanks a lot Jim and Yuval. One of our counterparty is sending us a Logout for a Logon response we have sent and our FIX Engine does not like it - it is expecting a Logon message in response to a Logon request. The counterparty is validating a userid/password and if incorrect send a Logout response.

When I raised this with the FIX Engine support team, they are saying it is as per FIX protocol and hence wanted to know if there is something official documented somewhere.

6

According to the FIX session layer (available in: http://www.fixtradingcommunity.org/pg/structure/tech-specs/transport-layers-for-fix )

• If during a logon either the SenderCompID, TargetCompID or IP address of the session initiator is invalid, it is recommended that the session be immediately terminated and no Logout message sent. This login attempt might be an unauthorized attempt to break into your system; hence one does not want to divulge any information about one’s FIX system, such as: which SenderCompID/TargetCompID values are valid or which version of FIX is supported.

• If during a Logon one receives a second connection attempt while a valid FIX session is already underway for that same SenderCompID, it is recommended that the session acceptor immediately terminate the second connection attempt and not send a Logout message. Sending a Logout message runs the risk of interfering with and possibly adversely affecting the current active FIX connection. For example, in some FIX system implementations, sending a Logout message might consume a sequence number that would cause an out of sequence condition for the established FIX session.

  • In all other cases, if sending a Logout does not create risk or violate security, a Logout message should be sent with a descriptive text message.

===
I hope this helps,
Yuval

7

Many implementations will send a Logout(35=5) in response to a Logon that is invalid. Note that there are alternatives. If the issue is a session level issue such as a malformed message then use a Session Reject. If it is some validation or authorization issue a Logout message with the Text(tag 58) populated explaining the reason for the logout is currently implemented by many market participants.

8

I need some insight into FIX standard of how the initial Logon message exchange sequence should look like.

My side is the initiator an sends a Logon message (after proper connection)
The other side receives the Logon message and does some validations

If the validations fail, should they first send back a Logon Ack (35=A) and then send a Logoff or is it ok if they send back a Logoff (35=5) in response to my Logon (35=A)?

Basically, the question is - Is it valid as FIX that the counter party sends a Logoff in response to a Logon request?

Thanks