Mirja Kuehlewind (IETF) <i...@kuehlewind.net> wrote:
> see below.
>> Am 01.02.2018 um 16:31 schrieb Michael Richardson <m...@sandelman.ca>:
>>
>>
>> Mirja Kuehlewind (IETF) <i...@kuehlewind.net> 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.
Yes, but to what address does one open the new TCP connection?
The dataplane addresses are potentially ephemeral, and don't have any
TLS certificates bound to them.
>> 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).
okay.
>> 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.
okay, I'm honestly ignorant of such things.
But the address of the data-plane interface doesn't have to be known.
> 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.
so, you start TCP on the ACP, do security.
Then you add the data-plane interface to get the addresses.
Then you close it all and continue using the plain data-plane TCP?
Did I understand this correctly?
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
