Re: [multipathtcp] The point about multiple listening sockets at theclient side

[William Herrin <[e-mail]>]

On Thu, Nov 12, 2009 at 2:27 AM, Ford, Alan <[e-mail]> wrote:
>> TS: TCP SYN-SYN/ACK-ACK from the server to the client which includes
>> the multipath TCP subflow join option.
>>
>> MJ: TCP packet without SYN but containing the multipath TCP join
>> option and expecting the same sort of JOIN-JOIN/ACK-ACK handshake.
>>
>> Scenarios:
>>
>> No firewall: TS succeeds. MJ succeeds.
>> Packet filter: TS fails. SYN to a random client port? Don't think so!
>> MJ succeeds.
>> Legacy Stateful firewall: TS fails. MJ fails.
>> Legacy "DSL router": TS fails. MJ fails.
>> Multipath-aware stateful firewall: TS fails. SYN to a random client
>> port? Bad plan! MJ succeeds.
>> Multipath-aware "DSL router": TS fails. SYN to a random client port?
>> Come on! MJ succeeds.
>
> So the only cases here where TS != MJ is when you're talking about
> Multipath-aware routers or firewalls?

Hi Alan,

No, basic packet filtering firewalls too. The ones we'll all move to
instead of NAT firewalls if the IPv6 folks get their way.

The point you were supposed to take is that NONE of the firewalled
cases can be reasonably expected to handle an inbound join in a TCP
SYN while MANY can be expected to handle an inbound subflow creation
crafted without using a SYN packet.

In fairness, that was mistaken. There is actually ONE firewalled case
where the TCP SYN version can be expected to suceed as well:

Multipath-aware proxy firewall: TS succeeds. MJ succeeds.

The proxy firewall isn't passing the raw SYN packet back to the
client; he's handling it himself. So in that one firewalled case, the
TCP SYN version can be expected to succeed.


> In order for them to let through
> MJ they need the existence of the Join option to override the natural
> rejection of such a packet due to coming from an unknown address. In
> which case, they could do the same for TS!

But they won't, because TCP SYN has unacceptable security implications
that a packet which contains a join option without setting the syn
flag does not.

What it boils down to is this: if there's the slightest chance that a
bad actor crafting custom packets could establish a *non-multipath*
TCP connection, it won't be allowed through the firewall. In fact, if
it so much as complicates the code which has to make the decision
about basic SYN packets, it won't be allowed through the firewall
because of the risk of introducing a security bug. Even with MJ we'll
have to do a thorough security analysis to make the case that the
packet is completely harmless if sent to a non-multipath host.

Regards,
Bill Herrin



-- 
William D. Herrin ................ [e-mail]  [e-mail]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004