mptcpd and (default) routes

mptcpd and (default) routes

[Paolo Abeni]

Hello,

I'm still experimenting with mptcpd. It looks like the current
'addr_adv' could be improved.

Currently it creates endpoints as soon as new non-link-local addresses
are available in the host, and that in turn causes new subflow creation
using such IP as source.

In a client system, usually we have this sequence of events:

1) <interface X goes up>
2) <dhcp start>
3) <interface X get new ip>
4) <new [default] route is added to X>

Just after 3) mptcpd creates the new endpoint and the kernel tries to
create the new subflows. The kernel can try to create the subflows
before the route (required to reach the server from the relevant
interface) is available.

A possible solution would be let mptcp listen even for route-related NL
events and let the 'addr_adv' plugin create the endpoint only when
there is a new address and a default route using such address/the
underlaying interface.

There are a couple of downside:
- the above condition is quite restrictive - e.g. a network specific
route could be enough, but we can't do a generic check for that. Adding
a configuration flag to enable the above check should suffice/cover
this point
- will be quite invasive for mptcpd

Are there any other options?

Apropos, I don't see any routing related code in mptcpd, so I guess
even the out-of-tree kernel could be subject to some similar
race/critical scenario?!?

Thanks,

Paolo

Re: mptcpd and (default) routes

[Matthieu Baerts]

Hi Paolo,

On 26/10/2021 18:49, Paolo Abeni wrote:
> Hello,
> 
> I'm still experimenting with mptcpd. It looks like the current
> 'addr_adv' could be improved.
> 
> Currently it creates endpoints as soon as new non-link-local addresses
> are available in the host, and that in turn causes new subflow creation
> using such IP as source.
> 
> In a client system, usually we have this sequence of events:
> 
> 1) <interface X goes up>
> 2) <dhcp start>
> 3) <interface X get new ip>
> 4) <new [default] route is added to X>
> 
> Just after 3) mptcpd creates the new endpoint and the kernel tries to
> create the new subflows. The kernel can try to create the subflows
> before the route (required to reach the server from the relevant
> interface) is available.
> 
> A possible solution would be let mptcp listen even for route-related NL
> events and let the 'addr_adv' plugin create the endpoint only when
> there is a new address and a default route using such address/the
> underlaying interface.
> 
> There are a couple of downside:
> - the above condition is quite restrictive - e.g. a network specific
> route could be enough, but we can't do a generic check for that. Adding
> a configuration flag to enable the above check should suffice/cover
> this point
> - will be quite invasive for mptcpd
> 
> Are there any other options?

Could it be enough to do a route validation after 3) until 4) is done?

I mean: if I understood your problem correctly, what is important is to
make sure that if you send something from the new IP of one interface,
it will go through this interface. Routes are then certainly OK for
MPTCP's PM to create new subflows using this IP. In other words, we
validate the user has configured routes like:

 $ ip rule add from <IP> table <X>
 $ ip route add default via <NEXT HOP> dev <DEV> table <X>

This check can be done with NL.

> Apropos, I don't see any routing related code in mptcpd, so I guess
> even the out-of-tree kernel could be subject to some similar
> race/critical scenario?!?

It would make sense if it is.

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

RE: mptcpd and (default) routes

[Othman, Ossama]

Hi Paolo,

> A possible solution would be let mptcp listen even for route-related NL
> events and let the 'addr_adv' plugin create the endpoint only when
> there is a new address and a default route using such address/the
> underlaying interface.
> 
> There are a couple of downside:
> - the above condition is quite restrictive - e.g. a network specific
> route could be enough, but we can't do a generic check for that. Adding
> a configuration flag to enable the above check should suffice/cover
> this point
> - will be quite invasive for mptcpd
> 
> Are there any other options?

I don't yet have any other options.  Your proposed solution works for me.  I'll add it to the TODO list.

> Apropos, I don't see any routing related code in mptcpd, so I guess
> even the out-of-tree kernel could be subject to some similar
> race/critical scenario?!?

Yes, that's correct.

Thanks,
-Ossama