Re: [multipathtcp] towards a potential work item on two-ended proxy

Hi Alan,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de
> Alan Ford
> Envoyé : mardi 2 août 2016 15:53
> À : Henderickx, Wim (Nokia - BE)
> Cc : multipathtcp@ietf.org
> Objet : Re: [multipathtcp] towards a potential work item on two-ended
> proxy
> 
> Hi all,
> 
> > On 1 Aug 2016, at 20:05, Henderickx, Wim (Nokia - BE)
> <wim.henderickx@nokia.com> wrote:
> > On 01/08/16 20:42, "Rao Shoaib" <rao.shoaib@oracle.com> wrote:
> >> On 08/01/2016 07:13 AM, Henderickx, Wim (Nokia - BE) wrote:
> >>>> Why is it necessary to know that the connection has been proxied ?
> >>> WH> Otherwise the concentrator will perform the proxy function
> although the destination is the application server.
> >>> So assume an E2E MPTCP flow. The UE initiates it and the element with
> the network assisted MPTCP proxy (Concentrator) receives it. The
> concentrator should not proxy this flow. It should only act upon MPTCP
> flow that should be proxied in network assisted mode. This is the reason
> we need an indication about this
> >> This seems like a deployment issue not a protocol issue. The decision
> to
> >> proxy or not proxy should be based on the IP addresses or out of band
> >> signaling. After all the entity adding the option some how knows to add
> >> the option.
> >>
> >> I liked the initial proposal as it did not require any changes to the
> >> protocol. These change (as I have said before) seem very deployment
> >> specific and IMHO should not be part of the protocol.
> > WH> I would disagree since you don’t always control the addressing and
> it is better to have an explicit signaling in the protocol what to expect
> to happen.
> 
> I’m trying to distinguish the various use cases; can we confirm this is
> correct?
> 
> Transparent Mode
> - Source address = real source address
[Med] I would say, the transparent mode does not touch to the source IP address of the initial subflow. The source address of secondary subflows will be rewritten to be the same as for the initial subflow.  

> - Destination address = real destination address
[Med] This is only true for the first subflow. Subsequent subflows are sent with a destination address of the MPTCP proxy. This is the same as in the plain mode.

> - Transparent proxies create MPTCP functionality in the stream, adding and
> removing the MPTCP headers, mapping seq numa, etc
> - Latest proposal is to add an indicator to say “this is proxied” so that
> a proxy can intercept it
> 
> Plain Mode
> - Source address = real source
> - Destination address = proxy destination address
[Med] Yes, for all subflows.

> - Signalling protocol inside indicates real destination address
[Med] and the source address if source address preservation is required (e.g., IPv6).

> 
> So - please correct me if this is wrong - but the main difference is that
> Plain Mode is targeted towards a proxy server whereas the transparent mode
> does not change src/dst addresses?
[Med] No, see above. A major difference is how the first subflow is established and how a state is built in the MPTPC proxy. The plain mode can operate in both transparent mode (that is preserve an IP address of the CPE/host) or not. Configuration parameters are available to instruct the MPTCP behavior, e.g.,
* preserve the source IP address
* preserve the initial subflow IP address
* N:1 address rewriting
* 1:1 address rewriting
*..

The plain mode as currently written allows to provide: IPv4 bonding over IPv6-only networks, IPv6 bonding over IPvx networks, etc.

> 
> The issue I see with a generic proxy bit is that it does not contain any
> context about what kind of proxy is being intercepted. You could be
> sending in good faith expecting it to be picked up by Proxy from Operator
> A, but in fact is picked up by Operator B.

[Med] The use cases we are targeting assumes these networks are managed by the same operator. 

> 
> As I’ve said before, the plain mode option is not MPTCP-specific and is
> simple a signal that says “everything that follows is actually targeted
> for IP address a.b.c.d” - this is entirely transport-agnostic.

[Med] The plain mode allows for example to distinguish between native and proxied MPTCP connection. 
I'm puzzled here since MPTCP allows to inform a remote peer about an IP address while this is not TCP-specific. Isn't that information transport-agnostic as per you argument? (not mine).

 If the HAG
> could know where to find a proxy (e.g. a well-known anycast address) then
> addresses could be rewritten and packets forwarded, with no need for any
> MPTCP protocol changes.

[Med] You need the information about the ultimate destination IP address...and other information such as the source IP address for cases such as IPv4 bonding over IPv6 networks (IPv6-only networks is now a reality in mobile networks).

> 
> However, I fear I may be misunderstanding some of the elements here, so I
> look forward to a consolidated draft where it should hopefully be much
> clearer what the proposal is.
> 
> Regards,
> Alan
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp