Subject: [multipathtcp] draft-ford-mptcp-multiaddressed-02: Need ports in ADD address

From: Magnus Westerlund <[email-masked]>
Date: Thu, 12 Nov 2009 11:17:08 +0900

Hi,

I just looked at draft-ford-mptcp-multiaddressed-02 and saw that the add
address option lacks a port number. I think that will not work for two
reasons.

1. First, there will a large amount of single flow TCP connections and
you will run into a synchronization issue and resource constrain issue
if you limit your interface port to be the same over all interfaces.

2. Your NAT traversal will fail as soon it encounters a NAT that is
unable to do port preservation. That is likelier and likelier to happen,
espeically for ISP place NATs where the load level is higher. Port
preservation will also fail as soon as two sub-flows goes over the same
NAT. Thus to enable MPTCP to work in cases where you use either an
explicit signalling protocol (UPnP, etc) or implicit methods, like STUN
to find out your external subflow address they will not be able to
preserver the port in the generic case. Thus there is need to be able to
indicate the listening port.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Pasi Sarolahti <[email-masked]>
Date: Thu, 12 Nov 2009 12:36:30 +0900

Hi,

I agree that port needs to be included.

To clarify (also to myself): the only method of adding subflows is the  
Join-option, right? That allows any port to be used with a subflow. I  
see Add Address option as a kind of a hint to the other end, asking  
its receiver to send a Join-option in the reverse direction, to come  
around certain NAT situations where direct Join does not work. I think  
the draft might need to be a bit more clear about this in section 4.3,  
saying that host should not add a subflow based on an ADDR option, but  
can rather react by sending a Join option to the given address, which  
in successful case leads to creation of a subflow.

I think including IP addresses in transport protocol is a kind of a  
layer violation and therefore little ugly, but can well see why this  
is needed here. I wouldn't mind if it was emphasized that use of this  
option is, in fact, optional. It's such an expense to the option  
space, especially with IPv6 (with which the need of this option is  
questionable anyway). In theory there might also be other address  
families than IPv4 or IPv6...

- Pasi

On Nov 12, 2009, at 11:17 AM, Magnus Westerlund wrote:

> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Costin Raiciu <[email-masked]>
Date: Thu, 12 Nov 2009 16:00:01 +0900

Hi,

There is plenty of discussion on the mailing list about this, but  
maybe it doesn't cover all the issues. Let me try to summarize again:

- for ADDITIONAL subflows (i.e. not the first one) the port number in  
the SYN packet does not matter for the host; demultiplexing is done  
using the connection token.  (this addresses point 1 - you don't need  
to reserve that port on all interfaces).
- let's first answer the question of WHEN add address option is used.  
It is only used when subflow establishment fails from A to B (which  
probably means B is behind NAT). At this point, the host with address  
A will send add address on another subflow, telling the host with  
address B please contact me here. B will send a SYN to A, with the  
proper token. If A is behind a NAT (both A and B are now natted) this  
will not work. People are arguing that if a port were signalled from  
A to B this might work. I have doubts, since this doesn't really work  
today either. However, I have nothing against putting the port in if  
people think it would help reachability.

Costin

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 18 Nov 2009 14:14:14 +0100

Hi Costin,

I have two comments related to your response.

1. Well, the rest of the world will care about port numbers. Otherwise
you have zero possibility of getting through NATs and firewalls. You
need to be able to specify where your packet should be going and that
you have that port open for listening on that interface or it will in
99.999% cases be eaten by the FW or NAT.

Especially if MPTCP actually attempts to make simultaneous open work.

It will also be critical if you try to make connections to a host behind
a NAT as the port is part of the address to reach the right host and
interface.

2. So if the MPTCP stack isn't looking at the port on arriving SYNs then
you have reduced the target space for off-path attackers with 16 bits. I
don't know how serious that is, but people seem to be attempting to keep
the entropy up.

/Magnus

Costin Raiciu skrev:
> Hi,
> 
> There is plenty of discussion on the mailing list about this, but maybe
> it doesn't cover all the issues. Let me try to summarize again:
> 
> using the connection token.  (this addresses point 1 - you don't need to
> reserve that port on all interfaces).
> - let's first answer the question of WHEN add address option is used. It
> is only used when subflow establishment fails from A to B (which
> probably means B is behind NAT). At this point, the host with address A
> will send add address on another subflow, telling the host with address
> B please contact me here. B will send a SYN to A, with the proper token.
> If A is behind a NAT (both A and B are now natted) this will not work.
> People are arguing that if a port were signalled from A to B this might
> work. I have doubts, since this doesn't really work today either.
> However, I have nothing against putting the port in if people think it
> would help reachability.
> 
> Costin
> 
> 

-- 

Magnus Westerlund

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 20 Nov 2009 20:20:13 +0900 (JST)

Hello Magnus,

Correct me if I'm wrong..
It seems to me that you want to support NAT-NAT communication (both subflow ends 
are behind NAT) in mptcp, while the current proposal try to support only 
NAT-global communication. 

If we really want to support NAT-NAT communication, I think we might need to have 
something like stun server somewhere on the Internet to know the external IP and 
port of the interface, or we need to have knowledge about our NAT or FW,
In anycase, this kind of mechanisms will be outside of mptcp, which might cause 
some issues.

If you could elaborate your target scenario, it would be very helpful.

For 2, I think having longer auth-token can mitigate this, so it might not 
be a very serious issue.

Thanks,
--
Yoshifumi Nishida
[email-masked]

From: Magnus Westerlund <[email-masked]>
Subject: Re: [multipathtcp] draft-ford-mptcp-multiaddressed-02: Need ports in ADD address
Date: Wed, 18 Nov 2009 14:14:14 +0100
Message-ID: <[email-masked]>

---

From: Costin Raiciu <[email-masked]>
Date: Fri, 20 Nov 2009 11:26:18 +0000

Hi Magnus,

In case 1, do you assume a local firewall? I guess in that case the  
stack can just inform the firewall about the open port, without  
actually binding it. I have no idea how this is done today - does the  
firewall monitor bound/listeninng ports?

2. Agree with that. We need to do a careful security analysis  
anyways, and the outcome is likely going to be stronger than the  
current token.

Cheers
Costin

>> maybe
>>> Fdrvgatan 6                | Mobile +46 73 0949079
> Fdrvgatan 6                | Mobile +46 73 0949079

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 20 Nov 2009 15:19:53 +0100

> NAT-global communication. 

It is one potential. Currently simultaneous open doesn't work particular
well in NATs. The success rate is around 40% if I remember correctly.

> In anycase, this kind of mechanisms will be outside of mptcp, which might cause 

Yes, I agree that you need external mechanism to tell you your external
bound address and port. But that exist today, thus it could potentially
be used.

> If you could elaborate your target scenario, it would be very helpful.

First, one peer behind a NAT must work.

Secondly, a peer behind a FW must work, including local host FWs. This
second requires that one use an explicit port that is opened for
reception. Thus ports matters and may potentially be different.

Third, I think the WG should at least consider what simultaneous open
means for MPTCP sub-flows. It is a feature of regular TCP. It might not
work that well with NATs and FWs.

> For 2, I think having longer auth-token can mitigate this, so it might not 

As long as you think about it.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 20 Nov 2009 15:24:52 +0100

Costin Raiciu skrev:
> stack can just inform the firewall about the open port, without actually
> binding it. I have no idea how this is done today - does the firewall
> monitor bound/listeninng ports?

Today, it appears that you bind to a socket, which makes the FW check
the rules for the application that is binding and if the port number is
allowed. Variations exist.

For non-local firewalls, you can open a particular port for a service,
thus you end up with a requirement to use a particular port, otherwise
it doesn't work.

I am convinced that you will need to be able to indicate the address and
port on which you are listening to make MPTCP to be reasonably
applicable. Otherwise you will find numerous issues where the SYN simply
 goes to dev/null.

Cheers

Magnus Westerlund

---

From: Costin Raiciu <[email-masked]>
Date: Fri, 20 Nov 2009 16:11:44 +0000

Magnus,

You've convinced me :).

Costin

On 20 Nov 2009, at 14:24, Magnus Westerlund wrote:

>> actually