[multipathtcp] Feedback on sha1/key exchange for MPTCP inter-op with FreeBSD

[Nigel Williams <[e-mail]>]

Dear Christoph,

I'm currently doing some interop testing between the Linux MPTCP 
implementation (built from the git repository as of October 10) and the 
FreeBSD implementation that I am working on. I have some 
questions/comments. I've cc'd the mailing list as some of this might be 
of interest to others. Please let me know if I've missed something obvious!

(1) Endianess and the sha1 hashing of local and remote keys: I initially 
had some trouble matching keys and idsns with the Linux implementation. 
Having a look through the linux code (function mptcp_key_sha1(local_key) 
in mptcp_ctrl.c) it looks like the output of sha_transform is converted 
into big-endian, and the token and idsn are then assigned (as big-endian).

Once the mptcp_key_sha1() function returns, 'idsn = ntohll(idsn) + 1;' 
is called (returning the idsn to host order). The idsn is then typcast 
as a u32 and this value is used for tcb->seq (which is the starting dseq 
value of DSN mappings). All this was calculated from 'local_key', which 
is stored locally in host order.

The problem arises then that the local_key is put onto the wire in host 
byte order, when we were expecting to receive it in network byte order. 
Is there a reason why the key is not transmitted in network byte order?

Also, is it possible to do the conversion to host order of the idsn and 
token within mptcp_key_sha1(), rather than on return? A quick glance at 
the function does not make it immediately obvious that the values should 
be converted into host order on return. Some comments in this function 
would be useful (for instance the FreeBSD sha1 returns the hash in 
network order, while Linux does not).

(2) Perhaps as a general comment/feedback, it might be worth detailing a 
little more explicitly in the implementers guide the conversions 
occurring in this process, as it is currently a little ambiguous and I 
needed to dig through the linux code in order to make my implementation 
compatible on the wire.

As far as I can tell, the process should be along the lines of:

1. generate 64-bit key (store in host order)
2. sha1 hash of key (byte order is implementation specific)
3. choose the most significant 4 bytes for the token, and least 
significant 8 bytes, taking into account the byte order of the sha output.
4. store token and idsn locally in host order.
5. get the lower portion of the idsn with an unsigned 32-bit typecast
6. when transmitting the local_key/remote_key, do so in network order. 
(currently Linux transmits in host order?)

As we need to be sure that different implementations are exchanging keys 
correctly during the handshake, it would be nice to have this 
information documented, making the endianess of things clear for 
implementers. It would also be helpful in the future to add some more 
comments to the Linux code, as it isn't always clear as why things are 
being done a certain way.

regards,
nigel