Subject: Re: [multipathtcp] about DSN in draft MPTCP version 02 (and 03)- further considerations

From: Sébastien Barré <[email-masked]>
Date: Mon, 26 Apr 2010 15:57:12 +0200

Hi,

back with the question of relative subflow seqnums.
I have tested MPTCP in connections between Belgium-London, 
Belgium-Finland, London-Finland.
All exhibited TCP seqnum rewriting, while keeping the MPTCP options.

I expected that middleboxes either create a new connection, with a new 
ISN (Initial Sequence Number), but then do not copy unrecognized TCP 
options. Or middleboxes just modify the existing connection, keeping 
options, but then not modifying the ISN.

My tests performed so far proved that those expectations were false. One 
or more middlebox in the paths I tried is actually changing the ISN 
*and* copying unknown options (MPC, DSN,ADDR,...). This breaks MPTCP if 
we use absolute seqnums.

So I guess that as initially proposed the right solution is to specify 
in the draft that relative subflow seqnums must be used.

regards,

Sébastien.

Ford, Alan a écrit :
> Hi Sébastien,
>
>   
>> Working with the implementation of the DSN option as described in
>> version 2 of the draft, I noticed a strange sentence:
>>
>> ------------------
>>
>> The data sequence number specified in this option is absolute,
>>    whereas the subflow sequence numbering is relative (the SYN at the
>>    start of the subflow has subflow sequence number 1).
>> ------------
>>
>>
>> What is the reason for this complication ? If we keep the sublow seqnum
>> field absolute, most of the time it will be equal to the seqnum
>> contained in the seqnum field of the segment.
>> Thus, a simple test for equality will allow validation of the segment.
>> Having it relative to the SYN requires additional operations at each
>> segment reception/sending.
>> So, why to do that ? (sorry if I missed a mail justifying that choice)
>>     
>
> Hmm, my memory's a bit hazy here. I think the reason for doing that was that it would allow middleboxes to mess with the subflow-header-level sequence numbering without needing to know about our data sequence numbering option.
>
> Would be interesting to know if that actually is a likely occurrence to work around...
>
> Cheers,
> Alan
>
>   

-- 
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium
http://inl.info.ucl.ac.be/sbarre

---

From: Sébastien Barré <[email-masked]>
Date: Tue, 27 Apr 2010 15:09:04 +0200

Hi,

Checking a bit more, I think that I have found the "guilty" middlebox 
that rewrites sequence numbers:
http://www.cisco.com/en/US/docs/security/fwsm/fwsm31/configuration/guide/protct_f.html#wp1042020

The Firewall services module (FWSM) of Cisco, present in the switch 
catalyst 6500 and the router cisco 7600,
enables by default an option called "TCP  initial sequence number 
randomization", supposed to protect flows coming from weak machines, 
like windows 98, that produce predictable ISNs, which opens 
possibilities for attackers to inject data into the TCP window of such 
flows.

I have thus adapted the Linux MPTCP implementation to use relative 
sequence numbers instead of absolute, in the DSN option. This will be 
included in release 0.4.

regards,

Sébastien.

Sébastien Barré a écrit :
> My tests performed so far proved that those expectations were false. 
> One or more middlebox in the paths I tried is actually changing the 
> ISN *and* copying unknown options (MPC, DSN,ADDR,...). This breaks 
> MPTCP if we use absolute seqnums.
>
>> Hmm, my memory's a bit hazy here. I think the reason for doing that 
>> was that it would allow middleboxes to mess with the 
>> subflow-header-level sequence numbering without needing to know about 
>> our data sequence numbering option.
>>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 27 Apr 2010 11:53:55 -0300

Hi,

> http://www.cisco.com/en/US/docs/security/fwsm/fwsm31/configuration/guide/protct_f.html#wp1042020

Good for them! (see bellow).

> possibilities for attackers to inject data into the TCP window of such

Another reason for rewriting the ISN is that, from the point of few of
nodes in the external realm of the NAT, all the TCP connections come
from the same node. If you don't rewrite the ISNs, the ISNs will not be
monotonically-increasing across TCP connections. As a result, the BSD
hack of recycling TCBs in the TIME-WAIT state will fail.

See Section 3.3 of the CPNI TCP security assessment (available at:
http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf).

Section 6.2.2 of
http://tools.ietf.org/id/draft-gont-behave-nat-security-03.txt , and the
entire http://tools.ietf.org/id/draft-gont-tcpm-tcp-timestamps-03.txt
document seem relevant, too.

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1