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

[Christoph Paasch <[e-mail]>]

On Tuesday 16 October 2012 19:44:06 Nigel Williams wrote:
> > The endianness conversion in mptcp_key_sha1 is part of the SHA-1
> > algorithm.
> > SHA-1 does an endianness conversion on the input (done by sha_transform in
> > lib/sha1.c).
> > When returning the final output another conversion is done in sha1_final
> > (crypto/sha1_generic.c), part of the generic crypto-library of the linux
> > kernel.
> > 
> > However, in MPTCP we don't use the crypto-library (thus, don't call
> > sha1_final) because we want to spare some CPU cycles. So, we have to do
> > the
> > endianness conversion at the end of mptcp_key_sha1 by hand.
> 
> What caused the confusion is that the Linux key is considered to be in 
> network order after it is generated. I don't recall the draft specifying 
> what order the key is to be in when hashed, and it is apparent that it 
> should.

You should not look at the key as a 64-bit integer. It is rather a sequence of 
8 bytes. When hashing, the key has to be in the same order as it was seen on 
the wire. SHA-1 algorithm makes sure that the hash produces as a result the 
same bit-sequence on little-endian and big-endian machines.

If we would convert the key to host-byte-order, the bit-sequence input to the 
sha-1 algorithm will be different on little-endian and big-endian machines. 
Thus SHA-1 won't produce the same result anymore.

> I would argue in favour of hashing in host order for semantic reasons:
> - It seems non-standard behaviour to not perform a network-to-host byte 
> order conversion on arriving options.
> - Maintains consistency with other stack variables which are kept in 
> host byte order for simplicity of arithmetic (or other things)

Actually they are only stored in host-byte order if arithmetic operations are 
performed on them.

TCP-MD5-options are not converted. For the same reason why the MPTCP-key is 
not converted, because we are working on a sequence of bits/bytes.
Same for TCP Cookie extensions.


Christoph

-- 
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be
Université Catholique de Louvain
--