Logon Activity

, ,
1

Imported from previous forum

2

[ original email was from Kim Kofman - kkofman@fmco.com ]
I would really appreciate anyone’s help in following questions:

  1. Just to be sure: logon message (together with its header and trailer), which contains NEW session encryption key, would be encrypted with an OLD one (encryption key).
  2. I don’t understand how an infinite loop could happen during exchange of logon messages. Even, if the acceptor changes an encryption key, the initiator supposes to respond. The only way I could see this - is when an initiator denies a new encryption key and sends a logon message back to acceptor with an old encryption key. But, it doesn’t seem to me a full explanation of “Both parties are responsible for infinite loop detection and prevention during this phase (logon phase) of the session.”
  3. Imagine the following scenario: FIX server receives a logon message at unexpected time. May be the other party terminated the session and now try to establish session again. But FIX server doesn’t “know” yet about session termination with the other party (heartbeat interval haven’t been passed). So, what should be the behavior of FIX server? Terminate the session? Just reject the logon message?
    Thanks in advance,
    Kim Kofman.
3

  1. I, personally, do not know of anyone who uses the Logon message to change encryption keys mid-session and feel that it could create problems. The Logon message itself does not use the old session encryption key NOR does it use the new session encryption key when using PGP-DES-MD5 which is what this is referring to. Rather, the Logon message is encrypted and decrypted using PGP. The encrypted PGP payload within the Logon message contains the session encryption key to use. The language referring to "handling" messages encrypted with the old or new session key is related to non-Logon messages which are being transmitted from either side during this key change process.

  2. An infinite loop could happen if both sides want to reject each other’s keys.

  3. If you are using TCP/IP, a new socket should be opened for a new FIX session. Your FIX system should have the same “understanding” of FIX session begin/end times (the only exception being abnormal termination in which you did not receive the Logout and have to derive the fact that the counterparty dropped). Proxy firewalls and such can complicate this a little bit, but it is key that your understanding of sessions match your counterparty’s.

> I would really appreciate anyone’s help in following questions:
> 1. Just to be sure: logon message (together with its header and trailer), which contains NEW session encryption key, would be encrypted with an OLD one (encryption key).
> 2. I don’t understand how an infinite loop could happen during exchange of logon messages. Even, if the acceptor changes an encryption key, the initiator supposes to respond. The only way I could see this - is when an initiator denies a new encryption key and sends a logon message back to acceptor with an old encryption key. But, it doesn’t seem to me a full explanation of “Both parties are responsible for infinite loop detection and prevention during this phase (logon phase) of the session.”
> 3. Imagine the following scenario: FIX server receives a logon message at unexpected time. May be the other party terminated the session and now try to establish session again. But FIX server doesn’t “know” yet about session termination with the other party (heartbeat interval haven’t been passed). So, what should be the behavior of FIX server? Terminate the session? Just reject the logon message?
> Thanks in advance,
> Kim Kofman.
>
>