Re: [multipathtcp] TR: I-D Action: draft-boucadair-mptcp-plain-mode-08.txt

["PEIRENS Bart (TSI/MST)" <[e-mail]>]

Dear Med,

Thanks for the update of this draft

My understanding is that the plain-mode draft is:
     It's inspired to have a deployment model that allows an 'off-path' concentrator/mptcp-proxy in the backbone network without requiring additional traffic steering techniques or tunnelling done in the network towards it.
        (E.g. it's 'network assisted mptcp deployment, within an operator controlled environment, but avoiding impact/configuration changes on other existing network elements in the operator network)
     It allows either implicit or explicit deployment modes (using e.g. I-D.boucadair-mptcp-dhc for discovery of the concentrator nodes)

    Furthermore it allows different modes in which the original CPE WAN or Host LAN (IPv6) address is either preserved or mapped to the local pool on the proxy node.

Some questions arise while reviewing the draft:

* Is the option preservation or the original source address on the concentrator not in direct contradiction with the goals of the draft, as the network in such mode will have to implement traffic steering policies for Internet originated or return packets back to the concentrator, even more problematic if only selected flows/protocols originating from the CPE should benefit from the network assisted mptcp? An 'on-path' model of the mptcp proxy in the forwarding path in the network could resolve this, but then rewriting the addresses and embedding original ones in the PM option would no longer be a requirement as well for deployment.

* The draft does not seem to address the requirement for validation of the embedded address in the PM option by the concentrator, especially with the D bit set. The updated -08 version addresses the concern with multicast/broadcast/host loopback addresses however. Such validation for packets with the D-bit set should be done to implement BCP 38 on the concentrator. The network elements of an operator at the network boundary can no longer do this now the address is embedded (we consider the CPE function outside of the network boundary and untrusted). When the PM option with D bit set to preserve original LAN address (e.g. IPv6 default case) the concentrator in addition needs to have knowledge of the delegated addresses behind the CPE and keep state of this? This would likely require some extra out of band synchronisation and complexity in the overall solution.

* Even without source address preservation at the concentrator node, the lack of validation of an embedded address in a PM option with D bit set by the CPE is problematic. As mentioned in section 7.3 such a deployment that involves global (ipv4) address mapping/sharing will typically require a logging function for the operator for traceback of abuse or lawful purposes. Such logging can only be relied on if the embedded source address received by the CPE has been validated by some means to be effectively being assigned to it.

* The effects of a rogue 'on-path' concentrator are described and illegitimate access to a concentrator node is described in section 7.1. My understanding of the workings of plain-mode is however that if any (e.g. including illegitimate off-path) concentrator can direct traffic to the CPE WAN address it allows source address spoofing for incoming connections towards the customer LAN or CPE itself. I believe restricting the sources that a CPE does accept packets with PM option set would be a requirement to resolve this and as such ruling out the option of an implicit configuration model currently left open in the draft?

I believe if the above points are left unaddressed the benefits of the 'off-path' deployment model do not outweighs the new issues it creates for an operator and doubt if addressing them will not bring the solution to at least the same or even higher complexity than an on-path model for an operator.

In response we submitted a new ID (draft-peirens-mptcp-transparent-00) where a more 'transparent' mode deployment is documented, preserving original customer addressing without embedding those within a new option field, as an alternate deployment model. It would however require placing the concentrator 'on-path', or using network assisted steering of the traffic towards the concentrator/proxy. Today an operator has already has multiple options available today to archive this, not necessary requiring encapsulation, and a more generic framework is being addresses as well in sfc wg. We would welcome discussion on this topic and benefits of either deployment model and will present the draft in the Wednesday slot next week.

While in favour of a MPTCP proxy model for accelerated deployment and resource pooling between access networks, I'm currently not convinced that embedding a specific traffic steering using a new MPTCP option is the best approach forward.

Regards
Bart

> Dear all,
>
> A new version that integrates the comments received from the list is available online:
> * clarify that the solution applies for both CPEs and hosts directly connected to operator networks.
> * clarify how fragmentation is managed for UDP.
> * clarify that one MPTCP connection is bound to one UDP flow
> * precise the behavior when a plain mode option includes multicast and broadcast addresses
> * call out that CGN optimization are inherited (e.g., optimize logging files, address pooling, port randomization, port set assuagement, etc.).
> * add a new section to explicit the target deployment and middlebox interference
> * add some text about checksum adjustment
>
> Reviews are more than welcome.
>
> Cheers,
> Med


________________________________

***** Disclaimer *****
http://www.proximus.be/maildisclaimer