Imported from previous forum
[ original email was from Ken Waterson - kpwaterson@fido.ca ]
Given a FIX session consisting of multiple physical connections, it is pretty much guaranteed that out of sequence messages will be received during normal processing and the receiver of those messages should sort them within a given window.
However, the protocol recommends that the message sequence number be encrypted, which matches examples I have seen on this site. As the initialization vector changes with every message, this means that any out of sequence messages will result in a security error.
As far as I can see, the only solution is to repeat the sequence number in the non-encrypted portion of the header.
Could someone please let me know if my assumptions are correct and whether there’s a different solution that I’m not seeing? Thanks.
[ original email was from Shalom Reich - shalom.reich@neonsoft.com ]
> Given a FIX session consisting of multiple physical connections, it is pretty much guaranteed that out of sequence messages will be received during normal processing and the receiver of those messages should sort them within a given window.
>
As far as I can tell, message sequence numbers will be assigned on a per session (that is TCP/IP session) basis. With this assumption, there should be no problem with out of sequence messages or encryption for each connection.
[ original email was from Ken Waterson - kpwaterson@fido.ca ]
>
> As far as I can tell, message sequence numbers will be assigned on a per session (that is TCP/IP session) basis. With this assumption, there should be no problem with out of sequence messages or encryption for each connection.
>
That’s fine if there is a one to one correspondence between FIX sessions and TCP/IP sessions. The problem I see comes with multiple physical (TCP/IP) connections under one FIX session, as stated on the top of page 11 of the FIX 4.2 specification. Am I confused here?
[ original email was from Shalom Reich - shalom.reich@neonsoft.com ]
>
> >
> > As far as I can tell, message sequence numbers will be assigned on a per session (that is TCP/IP session) basis. With this assumption, there should be no problem with out of sequence messages or encryption for each connection.
> >
>
> That’s fine if there is a one to one correspondence between FIX sessions and TCP/IP sessions. The problem I see comes with multiple physical (TCP/IP) connections under one FIX session, as stated on the top of page 11 of the FIX 4.2 specification. Am I confused here?
>
You are right. I didn’t notice that in the spec.
Also, I have only seen implementations with a single TCP/IP session per FIX session. When necessary, the parties set up multiple FIX sessions. In such situations there is no problem.
[ original email was from Ken Waterson - kpwaterson@fido.ca ]
> Also, I have only seen implementations with a single TCP/IP session per FIX session. When necessary, the parties set up multiple FIX sessions. In such situations there is no problem.
>
Thanks for the quick response. Does anyone else reading this know if there is a requirement for multiple connection support under FIX?
The 4.2 spec states "A single FIX session can exist across multiple physical connections." I can see how this might be confusing, however, the intent is to identify the fact that a TCP socket can be made through multiple routers over various networking media or links (e.g. Ethernet to frame relay to dedicated circuit to Ethernet etc.) It was not intended to indicate that multiple TCP sockets can/should be used for a single FIX session. Note that FIX was designed to be capable of being implemented over networking protocols other that TCP sockets, however, the reality is that most FIX sessions use TCP/IP and we have identified caveats if used with a non-reliable transport (e.g. UDP).
>
> >
> > As far as I can tell, message sequence numbers will be assigned on a per session (that is TCP/IP session) basis. With this assumption, there should be no problem with out of sequence messages or encryption for each connection.
> >
>
> That’s fine if there is a one to one correspondence between FIX sessions and TCP/IP sessions. The problem I see comes with multiple physical (TCP/IP) connections under one FIX session, as stated on the top of page 11 of the FIX 4.2 specification. Am I confused here?
>
[ original email was from Yevgeniy Tovshteyn - yevgeniy@javtech.com ]
There is a bigger problem with encrypting sequence numbers.
Lets say the message was lost. Next message could not be decrypted, because dynamic part of DES key is not updated right. But at least if message sequence number would be seen, FIX engine could request gap resend. Without sequence number FIX engine would not know how to recover.
Now, it is getting too difficult. Because than proccesing recovery other FIX engine would have to be stepping back were it was in DES key.
I think, the App. Note on encryption should be readdressed to regard recovery procedures.
> The 4.2 spec states “A single FIX session can exist across multiple physical connections.” I can see how this might be confusing, however, the intent is to identify the fact that a TCP socket can be made through multiple routers over various networking media or links (e.g. Ethernet to frame relay to dedicated circuit to Ethernet etc.) It was not intended to indicate that multiple TCP sockets can/should be used for a single FIX session. Note that FIX was designed to be capable of being implemented over networking protocols other that TCP sockets, however, the reality is that most FIX sessions use TCP/IP and we have identified caveats if used with a non-reliable transport (e.g. UDP).
>
> >
> > >
> > > As far as I can tell, message sequence numbers will be assigned on a per session (that is TCP/IP session) basis. With this assumption, there should be no problem with out of sequence messages or encryption for each connection.
> > >
> >
> > That’s fine if there is a one to one correspondence between FIX sessions and TCP/IP sessions. The problem I see comes with multiple physical (TCP/IP) connections under one FIX session, as stated on the top of page 11 of the FIX 4.2 specification. Am I confused here?
> >
>
[ original email was from Yevgeniy Tovshteyn - yevgeniy@javtech.com ]
There is a bigger problem with encrypting sequence numbers.
Lets say the message was lost. Next message could not be decrypted, because dynamic part of DES key is not updated right. But at least if message sequence number would be seen, FIX engine could request gap resend. Without sequence number FIX engine would not know how to recover.
Now, it is getting too difficult. Because than proccesing recovery other FIX engine would have to be stepping back were it was in DES key.
I think, the App. Note on encryption should be readdressed to regard recovery procedures.
> The 4.2 spec states “A single FIX session can exist across multiple physical connections.” I can see how this might be confusing, however, the intent is to identify the fact that a TCP socket can be made through multiple routers over various networking media or links (e.g. Ethernet to frame relay to dedicated circuit to Ethernet etc.) It was not intended to indicate that multiple TCP sockets can/should be used for a single FIX session. Note that FIX was designed to be capable of being implemented over networking protocols other that TCP sockets, however, the reality is that most FIX sessions use TCP/IP and we have identified caveats if used with a non-reliable transport (e.g. UDP).
>
> >
> > >
> > > As far as I can tell, message sequence numbers will be assigned on a per session (that is TCP/IP session) basis. With this assumption, there should be no problem with out of sequence messages or encryption for each connection.
> > >
> >
> > That’s fine if there is a one to one correspondence between FIX sessions and TCP/IP sessions. The problem I see comes with multiple physical (TCP/IP) connections under one FIX session, as stated on the top of page 11 of the FIX 4.2 specification. Am I confused here?
> >
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
It is a rather well known fact that PGP-DES-MD5 has certain problems relating to message ordering, however they generally aren’t limiting enough to render PGP-DES-MD5 non-functional.
PGP-DES-MD5 is likely completely unuseable over a non-reliable lower level protocol (like UDP) where messages can be reordered on a regular basis. However,
-
Almost all FIX is done over TCP/IP. Thus, messages cannot really be lost, corrupted, duplicated or reordered, with two exceptions: when a socket breaks and needs to be re-established, or if there is a bug in either party’s FIX engine. Generally, things like Resend Requests are only done to get in sync initially, and from there on it is smooth sailing.
-
The FIX session layer can degenerate into a nearly unuseable state if UDP or similar unreliable technologies are used, where messages are regularly dropped, duplicated, reordered and corrupted. Hence using PGP-DES-MD5 over something like UDP becomes a moot point.
One thing to note about PGP-DES-MD5 is that the DES used is in CBC (cipher block chaining) mode. This means that the last 8-byte block of ciphertext becomes the initialization vector for the next 8-byte block. So if a party sends messages 10, 11, 12, and 13, and 11 is dropped, then 12 will have the first 8 bytes corrupted, but the remainder of 12 will be intact, and 13 will be perfectly intact.
This poses a problem because the MD5 signature and message checksum cover the ciphertext, not the plaintext! Hence the checksum and signature will match on the corrupted message 12, so the application must be careful in parsing it. In this case it will be discared, and 13 will trigger a resend request of the two missing messages. It is CRITICAL that the system sending them re-encrypt them using the new IV (i.e. the last block of message 13 becomes the IV for 11, etc.) as opposed to just replaying the ciphertext.
While PGP-DES-MD5 does have problems, fixing them likely is not productive. The Encryption working group is in the process of investigating SSLv3 and TLS as alternatives. They become especially popular now that the RSA patent has expired, hence one can legally use free libraries like OpenSSL in the US. (Assuming, of course, you turn off RC4 (a trade secret) and IDEA (patented) and use 3DES.)
[ original email was from Ken Waterson - kpwaterson@fido.ca ]
> It is CRITICAL that the system sending them re-encrypt them using the new IV (i.e. the last block of message 13 becomes the IV for 11, etc.) as opposed to just replaying the ciphertext.
>
Now I’m on the garden path again - according to page 22 of the 4.2 specification, the recommended method for dealing with sequence gaps is to request a resend of the first message to infinity, rather than to the sequence of the first “good” message. This means that the sending system will not know which message to use for the new IV and its only option is to encrypt using the IV it did originally (from message 10 in your example).
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> > It is CRITICAL that the system sending them re-encrypt them using the new IV (i.e. the last block of message 13 becomes the IV for 11, etc.) as opposed to just replaying the ciphertext.
> >
> Now I’m on the garden path again - according to page 22 of the 4.2 specification, the recommended method for dealing with sequence gaps is to request a resend of the first message to infinity, rather than to the sequence of the first “good” message. This means that the sending system will not know which message to use for the new IV and its only option is to encrypt using the IV it did originally (from message 10 in your example).
Good job in catching that; yes, the best way to recover from a gap is to request from the gap until infinity. However, this does not pose any particular problems.
The IV you use comes from the last message you send, regardless of its sequence number. In this example, I will use 13’ to denote the a retransmission of message 13. When I say IV=x, I mean that the message is encrypted using an IV of the last 8 ciphertext bytes of message x.
What is sent:
10 IV=9
11 IV=10, this message accidentally dropped
12 IV=11 but the other side uses 10
13 IV=12
When the other side receives 12, they believe the IV is from message 10, as that was the last they received. However, it should have been 11 (the skipped message), hence 12 has the first 8 bytes corrupted, and is discarded. Then 13 is successfully received, which triggers a resend request from 11 to -1. What next is sent:
11’ IV=13
12’ IV=11’
13’ IV=12’
14 IV=13’ etc.
Note that each of these retransmitted messages are different from their original form because they are encrypted using different IVs.