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.
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. If all data-plane flows fail, then it might suspend
traffic.
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)
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.
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 [
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
