Subject: [multipathtcp] The point about multiple listening sockets at the client side

From: Yuri Ismailov <[email-masked]>
Date: Tue, 10 Nov 2009 01:49:41 +0100

Hi all,
I've got a request to make this point on the list. It might be just the
lack of my understanding and there is no any issue around that.
The simple scenario below:
A client with let's say 3 interfaces connects to a server through one of
them for http download.
Server decides to use all three interfaces at the client side.
My question was if the client should open listening sockets for
accepting server initiated connections over other interfaces?

Regards
Yuri

---

From: "Ford, Alan" <[email-masked]>
Date: Tue, 10 Nov 2009 01:06:32 -0000

Hi Yuri,

The client (in terms of software) does not need to open listening
sockets in this case. But the MPTCP stack itself will be listening on
all interfaces for potential incoming subflows from the server, which
when initiated are joined to the existing connection. The application
does not need to do anything for this to happen (but if an extended API
were in use it could, for example, have callbacks to be informed).

Regards,
Alan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]] On
> Behalf Of Yuri Ismailov
> Sent: 10 November 2009 00:50
> To: [email-masked]
> Subject: [multipathtcp] The point about multiple listening sockets at
> theclient side
> 
> Hi all,
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Costin Raiciu <[email-masked]>
Date: Tue, 10 Nov 2009 14:50:33 +0900

Hi,

Neither the server or the client need to open listening sockets for  
additional subflows. These subflows are demultiplexed using the  
connection token, so the port is not needed as a rendezvous point.  
Thus, any port can be put in the SYN packet - it does not matter (as  
long as the 5 tuple is unique for the two hosts - which it is, if the  
client of the subflow picks a port unused in the connection).

Semantically this may seem a bit weird - but in fact its not. TCP  
semantics say that the client (i.e. the side doing the active open)  
can accept a SYN packet (n.b. not syn/ack, which it would get from a  
passive end upon receipt of syn) after it has sent his own SYN. This  
is to support simultaneous open, and effectively amounts to  
"accepting" a connection request without calling accept (the client  
calls connect). We can think of the multipath case as a natural  
extension of simultaneous open in TCP - that lasts the whole connection.

Costin

---

From: William Herrin <[email-masked]>
Date: Tue, 10 Nov 2009 15:20:32 -0500

> were in use it could, for example, have callbacks to be informed).

Hi Alan,

Two thoughts:

1. When the initiator (of the overall connection) tries to add a
subflow, he'll want to use the same destination port number and a full
syn-syn/ack-ack handshake to maximize the chances of getting through
the acceptor's firewall unscathed.

2. When the acceptor tries to add a subflow, he best not offer a syn.
The syn won't get through the initiator's firewall. Nor should it: a
SYN packet to a non-multipath host would be interpreted as a plain
connection attempt.

One implication is that adding a subflow is an asymetric operation:
the connection's initiator follows a different process than the
acceptor.

Regards,
Bill Herrin

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

---

From: "Ford, Alan" <[email-masked]>
Date: Wed, 11 Nov 2009 01:07:13 -0000

Hi Bill, all,

> the acceptor's firewall unscathed.

Agreed - and not to upset port-based traffic engineering either.

> SYN packet to a non-multipath host would be interpreted as a plain

Disagree. Well, I can see what you're saying, but subflows /need/ to be
SYN+SYN/ACKed, whichever way they go, since they are essentially
standard TCP sessions, reassembled at the endpoints. In particular,
although there may be some firewalls that would let that traffic
through, many others would not (not part of a known TCP session), not to
mention other middleboxes anywhere along the path, including many NATs,
that would not know what to do with TCP packets that do not appear to be
part of a session they know about (since they haven't seen a SYN for
that particular 5-tuple).

Regards,
Alan

---

From: William Herrin <[email-masked]>
Date: Wed, 11 Nov 2009 20:37:05 -0500

Hi Alan,

Plot the middlebox use scenarios:

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.

Or am I missing something?

Regards,
Bill Herrin

---

From: Scott Brim <[email-masked]>
Date: Thu, 12 Nov 2009 10:46:38 +0900

Ford, Alan allegedly wrote on 11/10/2009 10:06 AM:
> all interfaces for potential incoming subflows from the server, 

All or some, which can be a local config option.  In any case it's not
something the app has to be involved in.  (The app _could_ be involved.)

---

From: Yuri Ismailov <[email-masked]>
Date: Thu, 12 Nov 2009 05:23:08 +0100

William Herrin wrote:
>>> On Mon, Nov 9, 2009 at 8:06 PM, Ford, Alan <[email-masked]>
>>>       
>> wrote:
>>     
Hi,
As it looks like a client should be initiator at all times in order to
provide a smooth operation.
Would it be reasonable to send some options or needed information in the
join flow from server to client, so that the client would start
SYN-SYNACK-ACK exchange?
Regards
Yuri

---

From: "Ford, Alan" <[email-masked]>
Date: Thu, 12 Nov 2009 07:27:03 -0000

Hi Bill, all,

> Multipath-aware "DSL router": TS fails. SYN to a random client port?

So the only cases here where TS != MJ is when you're talking about
Multipath-aware routers or firewalls? 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! (Secondary point is that TS
is likely to be going to a port on the client which is already in use,
even though it's from the ephemeral range. The multipath-aware middlebox
may well be aware of this).

Regards,
Alan

---

From: William Herrin <[email-masked]>
Date: Thu, 12 Nov 2009 08:15:41 -0500

On Thu, Nov 12, 2009 at 2:27 AM, Ford, Alan <[email-masked]> wrote:
> 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
> 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