Re: [multipathtcp] Multipath deployment and fate sharing

["Laganier, Julien" <[e-mail]>]

Hello Iljitsch,

Iljitsch van Beijnum wrote:
>
> Joe Touch wrote:
> >
> > However, anything that would cause the original subflow to fail even 
> > when tunneled over other interfaces still, IMO, needs to cause the 
> > whole set to go down. The key example is loss of the IP address 
> > associated with the original flow - either when the interface goes 
> > down, or when it's lost via failed DHCP renewals, or when it's 
> > otherwise explicitly reconfigured.
>
> There are several issues here. But before we delve in: why didn't we 
> have this discussion in shim6, where the exact same problem is present?

In the MPTCP fate sharing discussion there are two situations to consider:

1- a peer stop to use the original IP address but nobody else uses it
2- a peer stop to use the original IP address but somebody else starts to use it (e.g., address is re-allocated via DHCP)

In SHIM6 only the situation #1 is likely to occur, because as Marcelo pointed out earlier, SHIM6 security relies on the use of a specific type of addresses (Hash Based Addresses and Cryptographically Generated Addresses) whose size and random nature make them unlikely to ever collide, thus situation #2 cannot happen in SHIM6.

So SHIM6 decided that in situation #1 it was perfectly okay that a TCP connection continue to work even though the IPv6 address to which the TCP connection was originally bound (Upper Layer ID in SHIM6 terms) is no longer reachable/available. I tend to think that the same applies to MPTCP under situation #1. If we were to base MPTCP security over IPv6 on the use of HBA's and CGA's as well, we could guarantee that situation #2 doesn't occur, and thus be left to deal with situation #1 only and maintain same properties as SHIM6, i.e. no fate sharing for IPv6.

With IPv4 of course the situation would be different due to the IPv4 address space exhaustion, presence of NATs, and DHCP allocation with short term leases. So in IPv4 we can't rule out situation #2, and thus we want to make fate sharing the default IPv4. 

Not a perfect situation of course, but one in which at least we provide better functionality where possible (with IPv6, by leveraging on its IID addressing space size) and maintain existing functionality and semantic for the other situations (with IPv4, with NATs and DHCP)

--julien

PS: it also makes MPTCP over IPv6 more attractive than MPTCP over IPv4 and gives a good reason to migrate to IPv6 transports :)