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

[<[e-mail]>]

Dear Bart, 

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : PEIRENS Bart (TSI/MST) [mailto:[e-mail]]
> Envoyé : jeudi 14 juillet 2016 19:05
> À : BOUCADAIR Mohamed IMT/OLN; [e-mail]
> Objet : Re: [multipathtcp] TR: I-D Action: draft-boucadair-mptcp-plain-
> mode-08.txt
> 
> 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)

[Med] Yes, that's one of the objectives. No constraint on the location of the concentrators + minimal traffic steering policies at the network side. This model inherits BCPs from existing deployments such as Session Border Controllers, in particular.

>      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.

[Med] Yes. Each operator is free to enforce its local policies, e.g.,: 
* IPv4 address sharing N:1
* IPv4 address rewriting 1:1
* IPv6 address preservation
* NPTv6
And:
* TCP-only
* TCP and UDP
* Etc.

> 
> 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?

[Med] As mentioned in the draft: "In order to
      intercept incoming traffic, specific IPv6 routes are injected so
      that traffic is redirected towards the concentrator"

That's part of the "minimal" configuration I mentioned above.

 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.

[Med] I'm not sure how an on-path model can preserve the IPv6 address of the terminal located behind the CPE if no tunnels are put in place.

> 
> * 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.

[Med] Good point. The attack vector would be a misbehaving CPE that injects an IP address that is not used locally.  

We have a catch up sentence that covers this case:

"Nevertheless, attacks from
   within the network between a host and a concentrator instance are yet
   another actual threat."

The text can be elaborated further to describe the point you mentioned. 

 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).

[Med] Anti-spoofing filters are still needed to make sure that each CPE is using a valid (source) IP address.

 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?

[Med] The concentrator may enforce some validation checks without such knowledge, e.g.:
* Check that the source IPv6 address in the PM option and an address of the CPE used to place the session belong to a same prefix, e.g. /56 or /64.

 This would
> likely require some extra out of band synchronisation and complexity in
> the overall solution.

[Med] See my previous comment. Local validation checks may be sufficient.

> 
> * 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.

[Med] I don't understand the point. A source IP address used by a CPE is assumed to be always validated by the access network. I don't see a problem there.

> 
> * 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.

[Med] The CPE must follow BCPs for these matters: only trust a list of concentrators that are provisioned. Think about SBCs/PCSFs/etc. 

 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?

[Med] MPTCP with PM is only enabled with concentrators that are provisioned to the CPE. The document says: "secure means to discover a concentrator should
   be enabled."

> 
> 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.

[Med] FWIW, SFC requires two encapsulation schemes: the transport encapsulation and the service encapsulation.

 We would welcome discussion on this topic and benefits of either
> deployment model and will present the draft in the Wednesday slot next
> week.

[Med] My personal view is that both implicit and explicit modes may have proponents. I won't personally object to a specification that targets the implicit mode in addition to an explicit mode specification. FWIW, below are listed some of the reasons why I'm for an explicit mode:

   o  It does not impose any specific constraint on the location of the
      concentrator.  For example, the concentrator can be located in any
      access network, located upstream in the core network, or located
      in a data canter facility.

   o  Tasks required for activating the explicit mode are minimal.  In
      particular, this mode does not require any specific routing and/or
      forwarding policies for handling outbound packets other than
      ensuring that a concentrator is reachable from a CPE, and vice
      versa (which is straightforward IP routing policy operation).

   o  The engineering effort to change the location of a concentrator
      for some reason (e.g., to better accommodate dimensioning
      constraints, to move the concentrator to a data canter, to enable
      additional concentrator instances closer to the customer premises,
      etc.) is minimal

   o  An operator can easily enforce strategies for differentiating the
      treatment of MPTCP connections that are directly initiated by an
      MPTCP-enabled host connected to a concentrator if the explicit
      mode is enabled.  Typically, an operator may decide to offload
      MPTCP connections originated by an MPTCP-enabled terminal from
      being forwarded through a specific concentrator, or decide to
      relay them via a specific concentrator.  Such policies can be
      instructed to the concentrator.  Implementing such differentiating
      behavior if the implicit mode is in use may be complex to achieve.

   o  Multiple concentrators can be supported to service the same CPE,
      e.g., a concentrator can be enabled for internal services (to
      optimize the delivery of some operator-specific services) while
      another concentrator may be solicited for external services (e.g.,
      access to the Internet).  The explicit mode allows the deployment
      of such scenario owing to the provisioning of a concentrator
      selection policy table that relies upon the destination IP
      prefixes to select the concentrator to involve for an ongoing
      MPTCP connection, for instance.

   o  Because the concentrator's reachability information is explicitly
      configured on the CPE, means to guarantee successful inbound
      connections can be enabled in the CPE to dynamically discover the
      external IP address that has been assigned for communicating with
      remote servers, instruct the concentrator to maintain active
      bindings so that incoming packets can be successfully redirected
      towards the appropriate CPE, etc.

   o  Troubleshooting and root cause analysis may be facilitated in the
      explicit mode since faulty key nodes that may have caused a
      service degradation are known.  Because of the loose adherence to
      the traffic forwarding and routing polices, troubleshooting a
      service degradation that is specific to multi-access serviced
      customers should first investigate the behavior of the involved
      concentrator. 

Etc.

> 
> 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