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

[Nigel Williams <[e-mail]>]

Sorry, forgot to cc the list on this one.

cheers,
nigel

 >> On Wednesday 17 October 2012 14:59:49 Nigel Williams wrote:
>> Hi Christoph, Alan,
>>
>>> On 16/10/12 20:01, Christoph Paasch wrote:
>>> 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.
>>>
>> Okay, looks like I misunderstood how the sha function worked internally.
>> Ran a little test application and now see what you mean.
>>
>> A couple of proposals for inclusion in the draft (Section 3.1):
>> - It should be stated that the generated key is hashed in network byte
>> order.
>> - Also mention that the least significant bits are the rightmost bits of
>> the sha1 digest, as per [1].
>>
>>
>> Another observation re interop testing: There is an amendment to the end
>> of section 3.1 that on first glance seems to be at odds with how we see
>> the current Linux implementation behave:
>>
>> "The initial Data Sequence Number (IDSN) on a MPTCP connection MUST be
>> hard to guess.  It is RECOMMENDED that the IDSN is generated as a
>> hash from the Key ... however a receiver MUST NOT make any assumptions
>> about the IDSN generation algorithm."
>>
>>  From out observations the Linux implementation will include a Data ACK
>> in each packet immediately after the TCP handshake (potentially before
>> the remote host has sent any packets with DSN mappings). If the remote
>> host were to use a different method to generate the IDSN, these D-ACKs
>> would be out of sequence space. Were these D-ACKs added for debugging
>> purposes?
>> [1] FIPS 180-3: Secure Hash Standard,
>> http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf
>
> Yes, we always include DATA_ACK's in the packets, because it was easier to implement.
>
> The part you are citing from the draft about the IDSN will be changed in the draft
> version 11. The IDSN generation will be made deterministic.
>
> Cheers,
> Christoph