> Am 01.02.2018 um 21:19 schrieb Michael Richardson <mcr+i...@sandelman.ca>:
> 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
>>> 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
>> 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,
>>> 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.
Of course you need an address.
>> 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?
No. you open the MPTCP connection, get the address and open the subflow. This
connection you can use for any transfer where you want to fallback to the ACP
connection. However, if you also have transfers where you don’t want to
fallback, you expose the address you learnt over the MPTCP connection and use
that to open a second (non-MPTCP) TCP connection to the same address (which
then has automatically the desired feature to fail when needed). Having
multiple TCP connection opens at once is the right solution here.
> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
Anima mailing list