Hi Michael, see below.
> Am 01.02.2018 um 16:31 schrieb Michael Richardson <[email protected]>: > > > Mirja Kuehlewind (IETF) <[email protected]> wrote: >> Why does your case 2 need an MPTCP connection instead of just opening a >> second separate TCP data plan connection (that of course fails when it >> fails..)? > > I think the idea is that there is some long running connection; for instance > a log flow or a mirror port flow. Or maybe even an SDN control connection. > The case 2 I’ve been referring to is that: "2) Connections for non-urgent bulk transers (for example most routine firmware updates or cached log collection) may use a policy where the connection is made to fail when the data-plane fails or have transfers suspend until another data-plane subflow can successfully be built. This avoids over-taxing the ACP when the data plane fails.“ I think for non-urgent bulk transfers it would be no problem to open a new TCP connection, send the data, and close it again. > I believe (but I could be wrong) that MPTCP would allow a router that has > multiple data-plane circuits to (pre-)establish those flows and then quickly > switch to them. You can also pre-establish normal non-MPTCP connections (and send keep-alives); there is no difference or advantage when using MPTCP. However, I don’t think you need that for non-urgent bulk transfers. > If all data-plane flows fail, then it might suspend > traffic. That will not happen with MPTCP; it will fail back to use the ACP connection (if there is a subflow for it). > > I think that there is some advantage to starting the connection on the ACP, > because: > a) no TCP SYN listener on the data-plane interface(s) reduces attack > surface (assuming NOC->router initialized connections, but the same > argument applies to keeping the NOC devices isolated) Also with MPTCP you need a TCP SYN lister on the remote data-plane interface because creating a MPTCP subflow means sending a TCP SYN with an MPTCP option. > > b) the IP addresses of the router on the data-plane might be hard to know > in advance, being subject to routing algorithms and address assignment > ASAs. Also some interfaces might exist only with LL addresses until the > need to grow a GUA occurs. > > The ACP addresses are essentially locked down by being embedded in > certificate DNs. (see the ACP draft). That also means that a TLS > connection to the router will be validatable by the router's domain > certificate, while the (stable? temporary?) address assigned on the > dataplane > interfaces will not. What I’m basically proposing is that you use MPTCP for case 1 (data that needs a fallback to the ACP connection) but for all other transmission (that should be done only over one of the paths, either data plane or ACP), you have additional plain TCP connections to use. You can still add an interface to MPTCP to extract the IP address information you need to start these additional connections. Mirja > > So that's what MPTCP gets us: the ability to start on the ACP, do security, > and then move the bulk traffic to another place. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] [email protected] http://www.sandelman.ca/ | ruby on rails > [ > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
