Re: [multipathtcp] q about on-path proxy

[<[e-mail]>]

Re-,

Thank you for the clarification.

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Olivier Bonaventure [mailto:[e-mail]]
> Envoyé : mercredi 22 mars 2017 11:13
> À : BOUCADAIR Mohamed IMT/OLN; Yoshifumi Nishida; multipathtcp
> Objet : Re: [multipathtcp] q about on-path proxy
> 
> Med,
> 
> 
> >         +------- R4 ---- R5 --------+
> > C --- uMCP ---- R1 ---- R2 ------ dMCP ---- R6 --- R7 --- S
> 
> 
> 
> >>> Also, in the two proxy scenario, does the downstream MCP have to be
> >>> on-path?
> >>
> >> If the downstream MCP is on path, then it does not have to include any
> >> NAT function which is beneficial from an operational viewpoint.
> >>
> >>
> >
> > [Med] Perhaps I misunderstood your point but DNAT/SNAT are still needed
> for subsequent subflows even for the implicit case. Think about subflows
> that are placed with a destination address set to the one of the MCP and
> with a distinct source IP address than the one used to place the initial
> subflow.
> 
> By no NAT, I mean that all the packets between the client and the server
> that the operator would observe on the R1-R2 path or the R6-R7 path have

[Med] For the R6-R7 leg, this is valid for all MCP deployments with source address/prefix preservation. 

> C/S as source/destination addresses. This means that the existing
> techniques that are used for logging, traffic control or monitoring that
> depends on addresses can be reused without any modification.

[Med] Agree, if these functions are located in the R1-R2 leg. Some adjustments may be needed (Legal Intercept, for example), but that is out of scope. 

> 
> When the uMCP creates a subflow towards the dMCP, it uses other
> addresses than C and S, but these addresses are invisible to both the
> client and the final server.

[Med] Yes, this is the SNAT/DNAT I mentioned.

> 
> Olivier