Re: [multipathtcp] Multipath Address Family

[Michael Tüxen <[e-mail]>]

On Nov 30, 2009, at 4:59 PM, Bryan Ford wrote:

> On Nov 24, 2009, at 4:04 PM, Michael Tüxen wrote:
>> On Nov 23, 2009, at 10:40 PM, Pasi Sarolahti wrote:
>>> I wrote down some further thinking about the idea of multipath address family in the form of Internet-Draft, which I thought to be better than a long Email to the list. The draft is available at http://tools.ietf.org/html/draft-sarolahti-mptcp-af-multipath-00 and I'd be happy to hear further comments about it.
>>> 
>>> I think a new address family would be a minimal needed change to the current socket API, without extending the API with new operations, but yet provide an interface to handle multiple addresses in a socket. One potentially useful characteristic would be that this would allow name resolver to return multiple IPv4 and/or IPv6 addresses from the name server as a single sockaddr structure, that could be directly given as a parameter to a connect call, which would lead to trying which of the addresses are reachable for the MPTCP session. Traditionally this has been done in the applications, by cycling through the returned addresses from resolver one by one, until connect is successful. Especially dual-stack IPv6/IPv4 hosts should find such feature useful.
>> There is one thing that I do not understand. Currently there is no way a DNS
>> server resolves a name indicating that all addresses belong to the same host.
>> You just get a list of addresses. They might belong to one host or not.
> 
> You may not know whether all those addresses belong to the same host, but that doesn't necessarily mean they're not useful.  Just for other security reasons, MPTCP will have to have a fairly strong mechanism to verify that whoever is at a given alternate destination address(/port) really is the same host we hold the logical connection with, before starting to use a new subflow to that alternate address(/port).  This is especially true in today's heavily NATted world, where a huge number of endpoints all through the network have highly non-unique IP addresses like '10.1.1.x'; if one MPTCP endpoint says it has an alternate address 10.1.1.5 but is on a different private network from the other endpoint, it's VERY likely that the remote host's attempt to connect to 10.1.1.5 actually WILL reach some host, but the wrong host - even without any malicious attackers anywhere.
> 
> Thus, if we are given a bundle of DNS-resolved addresses, successfully open an initial MPTCP connection to one of them, and then want to try using those other addresses as alternate subflow targets, I don't see an inherent problem with just doing that as long as MPTCP's verification is working right, which it has to anyway.  If the bundle contains addresses of other hosts, those hosts will fail the verification check and subflow creation to them will fail - a few network and host resources get burned, but that can be limited with reasonable policies on attempting new subflows.
So when you connect to (IP1, ..., IPn) you want to connect to one of them. That is fine.
So if your server has n addresses but has no listening scoket, you will exchange n SYS/RST
pairs. (In SCTP we would use only one INIT/ABORT exchange and terminate the association).
> 
> A separate issue is HOW the application "names" a bundle of addresses to the OS.  One option is to add an AF_MULTI or somesuch that takes a bundle of already-resolved addresses, and have the application resolve the DNS name itself to a bundle of addresses and then pass the bundle to the sockets layer using the new AF.  Another option is just to add a new connect_by_name API, or alternately a new AF_NAME address family that embeds a name in its sockaddr struct, and transfer the job of name resolution into the sockets layer.  The latter seems like the cleaner approach to me: as Stuart Cheshire and Christian Vogt and others have pointed out, connect_by_name functions are already getting added to a lot of higher-level networking APIs and thus used by applications: this seems to be the way the industry is going, so all we really need to do is add a way to preserve the naming-based abstraction all the way down to the transport interface (i.e., through the Unix sockets API).
> 
> Cheers,
> Bryan
> 
>