From marcelo@it.uc3m.es Wed Apr 1 11:47:30 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39DEC3A6DF4 for ; Wed, 1 Apr 2009 11:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YB7K7vkSfjIA for ; Wed, 1 Apr 2009 11:47:29 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 1662A3A6E15 for ; Wed, 1 Apr 2009 11:47:28 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [163.117.203.185]) by smtp01.uc3m.es (Postfix) with ESMTP id D6A58B4D4C8; Wed, 1 Apr 2009 20:48:26 +0200 (CEST) Message-ID: <49D3B6FA.4090504@it.uc3m.es> Date: Wed, 01 Apr 2009 20:48:26 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: multipathtcp@ietf.org, Joe Touch Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16556.000 Subject: [multipathtcp] [Fwd: Re: multipath tcp disucssion] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 18:47:30 -0000 forwarding on behalf of Joe Touch -------- Mensaje original -------- Asunto: Re: multipath tcp disucssion Fecha: Wed, 01 Apr 2009 11:42:58 -0700 De: Joe Touch Para: marcelo bagnulo braun Referencias: <49CA932B.9050903@it.uc3m.es> <49D28A1F.7010409@isi.edu> <49D31237.6070102@it.uc3m.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here's one to forward: I am concerned about introducing a different model of a TCP connection than the "socket pair" (srcIP, dstIP, srcport, dstport), on which many other aspects of the Internet depend. This includes anything that depends on a connection as being atomic: NATs IPsec TCP MD5 / TCP-AO load balancers user applications that listen on given socket pairs ICMP handling TCP 'signal' packet handling The question is whether multipath TCP is consistent with those other systems, and the impact of using multiple TCP connections to emulate a single socket pair. E.g., when a single connection changes state, is protected/blocked, etc., what happens to the other connections in the set, and are they interrelated. The problem appears to be that the desired behavior might be different, depending on the system, e.g.: IPsec, TCP MD5, TCP-AO could be: one blocked -> all blocked one protected -> all protected where do the extra keys come from? who establishes them, esp. if manual? how do you ensure that all socket pairs have the same protection? load balancers: how do you ensure that different socket pairs end up at the same server? ICMP, TCP 'signal' (RST, SYN, FIN): does a hard error / shutdown / reset on one socket pair affect all socket pairs, or only the one signalled? when does it make sense to have fate sharing, and when does it make sense to decouple, and how do both ends know when to apply which? Overall, the question is: TCP currently presents a model of "one socket pair = one byte stream" to both the network and to the application. What model does multipath TCP present to the network and to the application, and how is it enforced? Is that model compatible with the current model (can the use of multiple socket pairs be hidden from either the network or the application)? - ---- From iljitsch@muada.com Thu Apr 2 10:28:15 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6B4828C16C for ; Thu, 2 Apr 2009 10:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lz0YlZ2Ca9jU for ; Thu, 2 Apr 2009 10:28:14 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 381C83A6E17 for ; Thu, 2 Apr 2009 10:27:55 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.54]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n32HRaqd070031 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Apr 2009 19:27:36 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com> From: Iljitsch van Beijnum To: Joe Touch In-Reply-To: <49D3B6FA.4090504@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 19:28:08 +0200 References: <49D3B6FA.4090504@it.uc3m.es> X-Mailer: Apple Mail (2.930.3) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] [Fwd: Re: multipath tcp disucssion] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 17:28:15 -0000 Hi Joe, On 1 apr 2009, at 20:48, marcelo bagnulo braun wrote: > I am concerned about introducing a different model of a TCP connection > than the "socket pair" (srcIP, dstIP, srcport, dstport), on which many > other aspects of the Internet depend. > This includes anything that depends on a connection as being atomic: > NATs > IPsec > TCP MD5 / TCP-AO > load balancers > user applications that listen on given socket pairs > ICMP handling > TCP 'signal' packet handling > The question is whether multipath TCP is consistent with those other > systems, and the impact of using multiple TCP connections to emulate a > single socket pair. First: there are different ways to do multipath TCP. The one you're addressing here is where TCP manages multiple addresses, just like SCTP does. Two other models are the one where TCP conforms to the current protocol specifications (the "one ended" multipath TCP with only changes to the sender) or a multipath TCP that runs on top of an existing multi-address system like shim6. Continuing the discussion about the multiaddress managing multipath TCP: > IPsec, TCP MD5, TCP-AO could be: I think you have a good point with regard to IPsec. We spent quite a bit of time on that with shim6, but those results aren't immediately applicable to an MAmTCP because shim6 can have IPsec both below or above it, with TCP it's only below. My initial thinking is that if the initial/main address pair is IPsec protected then it should be enforced that additional ones are also IPsec protected. By the way, how is this solved in SCTP? As for TCP MD5: first of all, I don't think this is an issue in practice because people won't run their BGP sessions over multipath TCP. Second, the MD5 protection is agnostic towards the addresses. I don't know if the addresses are part of the MD5 calculation, but if they are, the other side will see the same addresses and calculate the same MD5. If they're not, it's even simpler. I don't know what AO stands for. > load balancers: > how do you ensure that different socket pairs > end up at the same server? Probably with some kind of connection identifier cookie in the initial exchange. > ICMP, TCP 'signal' (RST, SYN, FIN): > does a hard error / shutdown / reset on > one socket pair affect all socket pairs, > or only the one signalled? This is an interesting issue, which sould be solved when the MAmTCP is designed. There are different ways to do this with different strengths and weaknesses. > Overall, the question is: > TCP currently presents a model of "one socket pair = one byte > stream" to > both the network and to the application. > What model does multipath TCP present to the network and to the > application, and how is it enforced? Is that model compatible with the > current model (can the use of multiple socket pairs be hidden from > either the network or the application)? Shim6 manages to hide the extra addresses from the application, so I'd say "yes" on that part. Not sure what you mean by hiding addresses from the network. There are of course applications that attach a lot of significance to the addresses they run over. It can be argued that this is not the best possible design, but something needs to be in place to make sure nothing really bad happens in these cases. Maybe just telling people to not configure multiple addresses is enough here, or maybe we need an API so applications can signal their needs. Or something else. Iljitsch From touch@ISI.EDU Thu Apr 2 10:46:18 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DF6E3A6988 for ; Thu, 2 Apr 2009 10:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJefVv9Da2Ij for ; Thu, 2 Apr 2009 10:46:16 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 756513A69EB for ; Thu, 2 Apr 2009 10:46:16 -0700 (PDT) Received: from [75.217.146.45] (45.sub-75-217-146.myvzw.com [75.217.146.45]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n32HjT9U010739; Thu, 2 Apr 2009 10:45:33 -0700 (PDT) Message-ID: <49D4F9B7.40309@isi.edu> Date: Thu, 02 Apr 2009 10:45:27 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <49D3B6FA.4090504@it.uc3m.es> <6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com> In-Reply-To: <6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] [Fwd: Re: multipath tcp disucssion] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 17:46:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Iljitsch, Iljitsch van Beijnum wrote: > Hi Joe, > > On 1 apr 2009, at 20:48, marcelo bagnulo braun wrote: > >> I am concerned about introducing a different model of a TCP connection >> than the "socket pair" (srcIP, dstIP, srcport, dstport), on which many >> other aspects of the Internet depend. > >> This includes anything that depends on a connection as being atomic: >> NATs >> IPsec >> TCP MD5 / TCP-AO >> load balancers >> user applications that listen on given socket pairs >> ICMP handling >> TCP 'signal' packet handling > >> The question is whether multipath TCP is consistent with those other >> systems, and the impact of using multiple TCP connections to emulate a >> single socket pair. > > First: there are different ways to do multipath TCP. The one you're > addressing here is where TCP manages multiple addresses, just like SCTP > does. Two other models are the one where TCP conforms to the current > protocol specifications (the "one ended" multipath TCP with only changes > to the sender) or a multipath TCP that runs on top of an existing > multi-address system like shim6. I'm not really focusing on the way multipath is done; I'm saying that all solutions that claim to be "TCP" need to address compatibility with the application-layer semantics of a single TCP connection. If multiple TCP connections are presented to the application as separate channels, then you're just talking about coordinating separate TCP connections, which was addressed in RFC2140, e.g. > Continuing the discussion about the multiaddress managing multipath TCP: > >> IPsec, TCP MD5, TCP-AO could be: > > I think you have a good point with regard to IPsec. We spent quite a bit > of time on that with shim6, but those results aren't immediately > applicable to an MAmTCP because shim6 can have IPsec both below or above > it, with TCP it's only below. My initial thinking is that if the > initial/main address pair is IPsec protected then it should be enforced > that additional ones are also IPsec protected. Yes, but the questions are: - how is that enforcement provided - is it provided only for IKE'd sessions, or for manual keying as well? - how does TCP know that IPsec is doing the right thing? That last one is the killer, IMO. > By the way, how is this solved in SCTP? I don't know whether it is. SCTP, however, doesn't intend to present a single socket pair as a connection to the application, AFAICT, so there's no expectation of the kind of security fate-sharing I'm concerned about. > As for TCP MD5: first of all, I don't think this is an issue in practice > because people won't run their BGP sessions over multipath TCP. TCP MD5 can be used for more than BGP, and TCP-AO (its replacement) can as well. I would think that running BGP over multipath would have uses, though - e.g., to allow BGP to remain stable when parallel links are provided for fault tolerance. > Second, > the MD5 protection is agnostic towards the addresses. I don't know if > the addresses are part of the MD5 calculation, but if they are, the > other side will see the same addresses and calculate the same MD5. If > they're not, it's even simpler. TCP MD5 and TCP-AO both include the IP pseudoheader in the MAC calculation. The problem is the same as for IPsec - fate sharing, knowing that all TCPs are similarly protected. > I don't know what AO stands for. Authentication Option: http://www.rfc-editor.org/cgi-bin/iddoctype.pl?letsgo=draft-ietf-tcpm-tcp-auth-opt-04 >> load balancers: >> how do you ensure that different socket pairs >> end up at the same server? > > Probably with some kind of connection identifier cookie in the initial > exchange. That seems to force application participation, at which point the app can/should be doing the multiplexing onto the different TCP streams. That works, but needs zero support from TCP (except, as noted above, RFC2140-style coordination). >> ICMP, TCP 'signal' (RST, SYN, FIN): >> does a hard error / shutdown / reset on >> one socket pair affect all socket pairs, >> or only the one signalled? > > This is an interesting issue, which sould be solved when the MAmTCP is > designed. There are different ways to do this with different strengths > and weaknesses. IMO this is a protocol specification issue, not an implementation issue. >> Overall, the question is: > >> TCP currently presents a model of "one socket pair = one byte stream" to >> both the network and to the application. > >> What model does multipath TCP present to the network and to the >> application, and how is it enforced? Is that model compatible with the >> current model (can the use of multiple socket pairs be hidden from >> either the network or the application)? > > Shim6 manages to hide the extra addresses from the application, so I'd > say "yes" on that part. Not sure what you mean by hiding addresses from > the network. Same kind of thing w.r.t. ICMP errors, ECN, or flow-based drops. Does the network know these connections are related? > There are of course applications that attach a lot of significance to > the addresses they run over. It can be argued that this is not the best > possible design, but something needs to be in place to make sure nothing > really bad happens in these cases. Maybe just telling people to not > configure multiple addresses is enough here, or maybe we need an API so > applications can signal their needs. Or something else.\ My basic point is that applications think that a single byte-stream is associated with a single socket pair because that's the model TCP presents to them. It's not a design issue; it's architectural - the definition of the endpoints of a bytestream is the socketpair. Changing that changes the application semantics - i.e., requires a major change to the API in RFC793... Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknU+bcACgkQE5f5cImnZrtcpgCgw02cZrNdhCk6gowYRg8UyTLk jvwAn3DqH0SK09M3K0QmBgGPGg/Xa3UZ =xiYc -----END PGP SIGNATURE----- From iljitsch@muada.com Thu Apr 2 13:08:54 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4C4E3A672F for ; Thu, 2 Apr 2009 13:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.549 X-Spam-Level: X-Spam-Status: No, score=-4.549 tagged_above=-999 required=5 tests=[AWL=2.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oyp4XLHNozAd for ; Thu, 2 Apr 2009 13:08:53 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 231A23A69E9 for ; Thu, 2 Apr 2009 13:08:52 -0700 (PDT) Received: from [192.168.0.192] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n32K89YR078804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Apr 2009 22:08:59 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Joe Touch In-Reply-To: <49D4F9B7.40309@isi.edu> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-14-550187811" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 22:08:29 +0200 References: <49D3B6FA.4090504@it.uc3m.es> <6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com> <49D4F9B7.40309@isi.edu> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.930.3) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] [Fwd: Re: multipath tcp disucssion] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 20:08:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-14-550187811 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2 apr 2009, at 19:45, Joe Touch wrote: > I'm saying that > all solutions that claim to be "TCP" need to address compatibility > with > the application-layer semantics of a single TCP connection. If > multiple > TCP connections are presented to the application as separate channels, > then you're just talking about coordinating separate TCP connections, Right. This is certainly NOT what we're talking about here. Today, TCP is a single funnel into the network. Anything that you pour into it at one end comes out in the same order at funnel at the other end. This isn't going to change in a multipath enabled TCP. What the multipath does is connect more than a single tube to the ends of the funnels. An important aspect of that is that if one of the paths breaks or clogs up, the packets are subsequently sent over (one of) the remaining working path(s). And the lost packets must also be retransmitted over a working path, probably before a normal RTO would expire in order to avoid the receive buffer from filling up because of lost packets, making the working path stall. >> My initial thinking is that if the >> initial/main address pair is IPsec protected then it should be >> enforced >> that additional ones are also IPsec protected. > Yes, but the questions are: > - how is that enforcement provided > - is it provided only for IKE'd sessions, or for manual > keying as well? > - how does TCP know that IPsec is doing the right thing? If IPsec implementations running on multipath TCP hosts already support the right API the multipath TCP could instruct the IPsec to do this. If not, the IPsec would have to be modified. >> As for TCP MD5: first of all, I don't think this is an issue in >> practice >> because people won't run their BGP sessions over multipath TCP. > TCP MD5 can be used for more than BGP, and TCP-AO (its replacement) > can > as well. That doesn't make sense, both TLS and IPsec are superior. > I would think that running BGP over multipath would have uses, > though - e.g., to allow BGP to remain stable when parallel links are > provided for fault tolerance. Well that kind of happens today when you use a single TCP session on multiple links between two routers. You do this by setting up the session between addresses tied to stable virtual addresses, which are statically routed over all of the links. So the packets are load balanced over the full set of links (although the load balancing could end up being that all the BGP packets only use one link, but in this case that doesn't matter). >> the MD5 protection is agnostic towards the addresses. I don't know if >> the addresses are part of the MD5 calculation, but if they are, the >> other side will see the same addresses and calculate the same MD5. > TCP MD5 and TCP-AO both include the IP pseudoheader in the MAC > calculation. The problem is the same as for IPsec - fate sharing, > knowing that all TCPs are similarly protected. There is no "all TCPs". It's one TCP session, it's just split into multiple subflows. So from above (the application layer) it's still one session so everything that you attach from above, like MD5 protection, applies to the entire session. Only from below you _may_ see the different subflows. >>> load balancers: >>> how do you ensure that different socket pairs >>> end up at the same server? >> Probably with some kind of connection identifier cookie in the >> initial >> exchange. > That seems to force application participation, I don't see that. TCP could simply negotiate additional subflows transparently to the application. The negotiation then fails if some subflows end up at another instance of a clustered service. > at which point the app > can/should be doing the multiplexing onto the different TCP streams. > That works, but needs zero support from TCP The trouble here is that the application must now split the data into multiple byte streams. For some stuff that's not a huge problem (file transfer like BitTorrent) but even in those cases it's not very flexible: once a piece of data is commited to a path, only an application level timeout or a failure allows for it to be rerouted over a different path. The transport layer can do this at RTT timescales without much extra overhead. >>> ICMP, TCP 'signal' (RST, SYN, FIN): >>> does a hard error / shutdown / reset on >>> one socket pair affect all socket pairs, >>> or only the one signalled? >> This is an interesting issue, which sould be solved when the MAmTCP >> is >> designed. There are different ways to do this with different >> strengths >> and weaknesses. > IMO this is a protocol specification issue, not an implementation > issue. Absolutely, this can only work well if both ends agree on how to do it. > Does the network know these connections are related? Does the network have a notion of connections in the first place? > My basic point is that applications think that a single byte-stream is > associated with a single socket pair because that's the model TCP > presents to them. It's not a design issue; it's architectural - the > definition of the endpoints of a bytestream is the socketpair. > Changing > that changes the application semantics - i.e., requires a major change > to the API in RFC793... Disagree. Per RFC 793, it's completely normal behavior for the network to send some packets over one path and some over another path. Having the TCP sender tell the network which packets to send over which path is an important optimization because now it's possible to run congestion control instances for each path, so TCP can adapt to the path properties. This is all firmly within the bounds of layers 3 and 4 and outside the scope of higher layers. Once additional addresses enter the picture, this is arguably no longer the case, but NATs, different types of tunnels, MIP, shim6 etc set precedents here long ago: applications can't expect to know all the details of the addresses used in their communication. --Apple-Mail-14-550187811 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFJ1Rs9N+eEORsfxOYRAhZ5AJ9jLgiZi8U0gwLQtTLuCwdn3Of/MgCgxXaP /WDc8uRNPEOBmYQpISGttG0= =Vt41 -----END PGP SIGNATURE----- --Apple-Mail-14-550187811-- From touch@ISI.EDU Thu Apr 2 13:28:25 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 439AF3A695F for ; Thu, 2 Apr 2009 13:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i74nDB69B9vG for ; Thu, 2 Apr 2009 13:28:23 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E3A3B3A68F5 for ; Thu, 2 Apr 2009 13:28:23 -0700 (PDT) Received: from [75.217.146.45] (45.sub-75-217-146.myvzw.com [75.217.146.45]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n32KSWIS026230; Thu, 2 Apr 2009 13:28:34 -0700 (PDT) Message-ID: <49D51FF0.8010600@isi.edu> Date: Thu, 02 Apr 2009 13:28:32 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <49D3B6FA.4090504@it.uc3m.es> <6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com> <49D4F9B7.40309@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] [Fwd: Re: multipath tcp disucssion] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 20:28:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Iljitsch van Beijnum wrote: > On 2 apr 2009, at 19:45, Joe Touch wrote: .. >>> My initial thinking is that if the >>> initial/main address pair is IPsec protected then it should be enforced >>> that additional ones are also IPsec protected. > >> Yes, but the questions are: >> - how is that enforcement provided >> - is it provided only for IKE'd sessions, or for manual >> keying as well? >> - how does TCP know that IPsec is doing the right thing? > > If IPsec implementations running on multipath TCP hosts already support > the right API the multipath TCP could instruct the IPsec to do this. If > not, the IPsec would have to be modified. Agreed. I just wonder whether it's even possible to modify IPsec to do this. I.e., IPsec (and IKE) needs to know about 'groups of transport connections that need to be treated the same'. That can be achieved in the configuration (i.e., using wildcards in port fields, or using identical configurations for different connection specifications), but there's nothing in IPsec that flags that inside IPsec. >>> As for TCP MD5: first of all, I don't think this is an issue in practice >>> because people won't run their BGP sessions over multipath TCP. > >> TCP MD5 can be used for more than BGP, and TCP-AO (its replacement) can >> as well. > > That doesn't make sense, both TLS and IPsec are superior. Please check our doc. TLS does not protect a TCP connection from TCP-level attacks, e.g., RSTs. IPsec cannot be forced to use new keys on new connections (i.e., upon receipt of a RST, destroy the SA). TCP-AO does both of these (TCP MD5 only the former), and is much simpler than IPsec (which is why it is preferred for BGP). >> I would think that running BGP over multipath would have uses, >> though - e.g., to allow BGP to remain stable when parallel links are >> provided for fault tolerance. > > Well that kind of happens today when you use a single TCP session on > multiple links between two routers. You do this by setting up the > session between addresses tied to stable virtual addresses, which are > statically routed over all of the links. So the packets are load > balanced over the full set of links (although the load balancing could > end up being that all the BGP packets only use one link, but in this > case that doesn't matter). Agreed. The current solution requires that the single IP address is routed over multiple link-layer paths; I'm suggesting utility to a solution that does not have that constraint. I don't know if there's a particular reason to encourage this using multiTCP, vs., e.g., single TCP over a virtual link tunnel (e.g., GRE). However, that begs the question of whether that technique would be useful elsewhere - i.e., a multipath TCP solution that deploys its own 'virtual diversification layer' underneath... >>> the MD5 protection is agnostic towards the addresses. I don't know if >>> the addresses are part of the MD5 calculation, but if they are, the >>> other side will see the same addresses and calculate the same MD5. > >> TCP MD5 and TCP-AO both include the IP pseudoheader in the MAC >> calculation. The problem is the same as for IPsec - fate sharing, >> knowing that all TCPs are similarly protected. > > There is no "all TCPs". It's one TCP session, it's just split into > multiple subflows. So from above (the application layer) it's still one > session so everything that you attach from above, like MD5 protection, > applies to the entire session. Only from below you _may_ see the > different subflows. If they subflows use different ports, then TCP MD5 would think they are different connections. So the answer depends on what the lower layer sees. >>>> load balancers: >>>> how do you ensure that different socket pairs >>>> end up at the same server? > >>> Probably with some kind of connection identifier cookie in the initial >>> exchange. > >> That seems to force application participation, > > I don't see that. TCP could simply negotiate additional subflows > transparently to the application. The negotiation then fails if some > subflows end up at another instance of a clustered service. Oh - yes, I see that now. It requires modification of the endpoints, but not necessarily at the application layer. >> at which point the app >> can/should be doing the multiplexing onto the different TCP streams. >> That works, but needs zero support from TCP > > The trouble here is that the application must now split the data into > multiple byte streams. For some stuff that's not a huge problem (file > transfer like BitTorrent) but even in those cases it's not very > flexible: once a piece of data is commited to a path, only an > application level timeout or a failure allows for it to be rerouted over > a different path. The transport layer can do this at RTT timescales > without much extra overhead. It can be done inbetween the app and transport, i.e., inside the socket buffers too. I.e., it can be done in a layer above TCP but below the app, if isolation from the app is needed. That's partly done by things like HTTP persistent connections with chunked responses. >>>> ICMP, TCP 'signal' (RST, SYN, FIN): >>>> does a hard error / shutdown / reset on >>>> one socket pair affect all socket pairs, >>>> or only the one signalled? > >>> This is an interesting issue, which sould be solved when the MAmTCP is >>> designed. There are different ways to do this with different strengths >>> and weaknesses. > >> IMO this is a protocol specification issue, not an implementation issue. > > Absolutely, this can only work well if both ends agree on how to do it. > >> Does the network know these connections are related? > > Does the network have a notion of connections in the first place? Yes. In places I've noted, at least: network layer in the end host or BITW: IPsec NATs multipath routing based on flow preservation firewall filtering when ICMPs are issued (in the network or at the dest host) >> My basic point is that applications think that a single byte-stream is >> associated with a single socket pair because that's the model TCP >> presents to them. It's not a design issue; it's architectural - the >> definition of the endpoints of a bytestream is the socketpair. Changing >> that changes the application semantics - i.e., requires a major change >> to the API in RFC793... > > Disagree. Per RFC 793, it's completely normal behavior for the network > to send some packets over one path and some over another path. Having > the TCP sender tell the network which packets to send over which path is > an important optimization because now it's possible to run congestion > control instances for each path, so TCP can adapt to the path > properties. This is all firmly within the bounds of layers 3 and 4 and > outside the scope of higher layers. I said socket pair, not path. If you keep the socket pair the same (srcIP, dstIP, srcPort, dstPort), it all works consistent with RFC793. If you have more than one socket pair in the network supporting a single socket pair at the endpoints, then you have changed the RFC793 model. > Once additional addresses enter the picture, this is arguably no longer > the case, but NATs, different types of tunnels, MIP, shim6 etc set > precedents here long ago: applications can't expect to know all the > details of the addresses used in their communication. They do expect that a single socket pair corresponds to a single connection - no more, no less. NATs, etc. preserve this. Anything that violates this breaks TCP. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknVH/AACgkQE5f5cImnZrv5HQCggbrzlXFTsKSMCV1K/Oe1sPSR RWYAniA7okOL5Ygv5CLU3JaAVclZAe6U =3Dse -----END PGP SIGNATURE----- From Michael.Tuexen@lurchi.franken.de Thu Apr 2 13:54:52 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9C213A6A6E for ; Thu, 2 Apr 2009 13:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMpoCUZCzauQ for ; Thu, 2 Apr 2009 13:54:42 -0700 (PDT) Received: from mail-n.franken.de (mail-n.franken.de [193.175.24.27]) by core3.amsl.com (Postfix) with ESMTP id 08A5E3A6898 for ; Thu, 2 Apr 2009 13:54:42 -0700 (PDT) Received: from [IPv6:2002:508f:f736::224:36ff:feef:67d1] (unknown [IPv6:2002:508f:f736:0:224:36ff:feef:67d1]) by mail-n.franken.de (Postfix) with ESMTP id 46D561C0AC4F2; Thu, 2 Apr 2009 22:55:11 +0200 (CEST) Message-Id: <5C08261D-86BD-48EC-8D36-FD17FE09F883@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Iljitsch van Beijnum In-Reply-To: <6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Thu, 2 Apr 2009 22:55:09 +0200 References: <49D3B6FA.4090504@it.uc3m.es> <6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com> X-Mailer: Apple Mail (2.930.4) Cc: multipathtcp@ietf.org, Joe Touch Subject: Re: [multipathtcp] [Fwd: Re: multipath tcp disucssion] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 20:54:52 -0000 Hi Iljitsch, a comment in-line. Best regards Michael On Apr 2, 2009, at 7:28 PM, Iljitsch van Beijnum wrote: > Hi Joe, > > On 1 apr 2009, at 20:48, marcelo bagnulo braun wrote: > >> I am concerned about introducing a different model of a TCP >> connection >> than the "socket pair" (srcIP, dstIP, srcport, dstport), on which >> many >> other aspects of the Internet depend. > >> This includes anything that depends on a connection as being atomic: >> NATs >> IPsec >> TCP MD5 / TCP-AO >> load balancers >> user applications that listen on given socket pairs >> ICMP handling >> TCP 'signal' packet handling > >> The question is whether multipath TCP is consistent with those other >> systems, and the impact of using multiple TCP connections to >> emulate a >> single socket pair. > > First: there are different ways to do multipath TCP. The one you're > addressing here is where TCP manages multiple addresses, just like > SCTP does. Two other models are the one where TCP conforms to the > current protocol specifications (the "one ended" multipath TCP with > only changes to the sender) or a multipath TCP that runs on top of > an existing multi-address system like shim6. > > Continuing the discussion about the multiaddress managing multipath > TCP: > >> IPsec, TCP MD5, TCP-AO could be: > > I think you have a good point with regard to IPsec. We spent quite a > bit of time on that with shim6, but those results aren't immediately > applicable to an MAmTCP because shim6 can have IPsec both below or > above it, with TCP it's only below. My initial thinking is that if > the initial/main address pair is IPsec protected then it should be > enforced that additional ones are also IPsec protected. > > By the way, how is this solved in SCTP? Have a look at http://www.ietf.org/rfc/rfc3554.txt but it is (up to my knowledge) not implemented yet. > > > As for TCP MD5: first of all, I don't think this is an issue in > practice because people won't run their BGP sessions over multipath > TCP. Second, the MD5 protection is agnostic towards the addresses. I > don't know if the addresses are part of the MD5 calculation, but if > they are, the other side will see the same addresses and calculate > the same MD5. If they're not, it's even simpler. > > I don't know what AO stands for. > >> load balancers: >> how do you ensure that different socket pairs >> end up at the same server? > > Probably with some kind of connection identifier cookie in the > initial exchange. > >> ICMP, TCP 'signal' (RST, SYN, FIN): >> does a hard error / shutdown / reset on >> one socket pair affect all socket pairs, >> or only the one signalled? > > This is an interesting issue, which sould be solved when the MAmTCP > is designed. There are different ways to do this with different > strengths and weaknesses. > >> Overall, the question is: > >> TCP currently presents a model of "one socket pair = one byte >> stream" to >> both the network and to the application. > >> What model does multipath TCP present to the network and to the >> application, and how is it enforced? Is that model compatible with >> the >> current model (can the use of multiple socket pairs be hidden from >> either the network or the application)? > > Shim6 manages to hide the extra addresses from the application, so > I'd say "yes" on that part. Not sure what you mean by hiding > addresses from the network. > > There are of course applications that attach a lot of significance > to the addresses they run over. It can be argued that this is not > the best possible design, but something needs to be in place to make > sure nothing really bad happens in these cases. Maybe just telling > people to not configure multiple addresses is enough here, or maybe > we need an API so applications can signal their needs. Or something > else. > > Iljitsch > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From Michael.Tuexen@lurchi.franken.de Thu Apr 2 13:58:17 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B80443A6898 for ; Thu, 2 Apr 2009 13:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QFbhUOcGqRz for ; Thu, 2 Apr 2009 13:58:16 -0700 (PDT) Received: from mail-n.franken.de (mail-n.franken.de [193.175.24.27]) by core3.amsl.com (Postfix) with ESMTP id B4CA028C26F for ; Thu, 2 Apr 2009 13:58:11 -0700 (PDT) Received: from [IPv6:2002:508f:f736::224:36ff:feef:67d1] (unknown [IPv6:2002:508f:f736:0:224:36ff:feef:67d1]) by mail-n.franken.de (Postfix) with ESMTP id BA33B1C0AC4B1; Thu, 2 Apr 2009 22:58:41 +0200 (CEST) Message-Id: <72F57532-6047-4AD1-A381-2C48D945C9EE@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Joe Touch In-Reply-To: <49D4F9B7.40309@isi.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Thu, 2 Apr 2009 22:58:40 +0200 References: <49D3B6FA.4090504@it.uc3m.es> <6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com> <49D4F9B7.40309@isi.edu> X-Mailer: Apple Mail (2.930.4) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] [Fwd: Re: multipath tcp disucssion] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 20:58:17 -0000 On Apr 2, 2009, at 7:45 PM, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Iljitsch, > > Iljitsch van Beijnum wrote: >> Hi Joe, >> >> On 1 apr 2009, at 20:48, marcelo bagnulo braun wrote: >> >>> I am concerned about introducing a different model of a TCP >>> connection >>> than the "socket pair" (srcIP, dstIP, srcport, dstport), on which >>> many >>> other aspects of the Internet depend. >> >>> This includes anything that depends on a connection as being atomic: >>> NATs >>> IPsec >>> TCP MD5 / TCP-AO >>> load balancers >>> user applications that listen on given socket pairs >>> ICMP handling >>> TCP 'signal' packet handling >> >>> The question is whether multipath TCP is consistent with those other >>> systems, and the impact of using multiple TCP connections to >>> emulate a >>> single socket pair. >> >> First: there are different ways to do multipath TCP. The one you're >> addressing here is where TCP manages multiple addresses, just like >> SCTP >> does. Two other models are the one where TCP conforms to the current >> protocol specifications (the "one ended" multipath TCP with only >> changes >> to the sender) or a multipath TCP that runs on top of an existing >> multi-address system like shim6. > > I'm not really focusing on the way multipath is done; I'm saying that > all solutions that claim to be "TCP" need to address compatibility > with > the application-layer semantics of a single TCP connection. If > multiple > TCP connections are presented to the application as separate channels, > then you're just talking about coordinating separate TCP connections, > which was addressed in RFC2140, e.g. > >> Continuing the discussion about the multiaddress managing multipath >> TCP: >> >>> IPsec, TCP MD5, TCP-AO could be: >> >> I think you have a good point with regard to IPsec. We spent quite >> a bit >> of time on that with shim6, but those results aren't immediately >> applicable to an MAmTCP because shim6 can have IPsec both below or >> above >> it, with TCP it's only below. My initial thinking is that if the >> initial/main address pair is IPsec protected then it should be >> enforced >> that additional ones are also IPsec protected. > > Yes, but the questions are: > - how is that enforcement provided > - is it provided only for IKE'd sessions, or for manual > keying as well? > - how does TCP know that IPsec is doing the right thing? > > That last one is the killer, IMO. > >> By the way, how is this solved in SCTP? > > I don't know whether it is. SCTP, however, doesn't intend to present a > single socket pair as a connection to the application, AFAICT, so > there's no expectation of the kind of security fate-sharing I'm > concerned about. SCTP supports two types of sockets: One-to-One: This is the same as TCP. A socket is either a listener or represents one end of an SCTP association. One-to-Many: This is simular to non-connected UDP sockets. A socket can handle multiple SCTP associations. The API provides an association ID, which can be used to identify the association. > > >> As for TCP MD5: first of all, I don't think this is an issue in >> practice >> because people won't run their BGP sessions over multipath TCP. > > TCP MD5 can be used for more than BGP, and TCP-AO (its replacement) > can > as well. I would think that running BGP over multipath would have > uses, > though - e.g., to allow BGP to remain stable when parallel links are > provided for fault tolerance. > >> Second, >> the MD5 protection is agnostic towards the addresses. I don't know if >> the addresses are part of the MD5 calculation, but if they are, the >> other side will see the same addresses and calculate the same MD5. If >> they're not, it's even simpler. > > TCP MD5 and TCP-AO both include the IP pseudoheader in the MAC > calculation. The problem is the same as for IPsec - fate sharing, > knowing that all TCPs are similarly protected. > >> I don't know what AO stands for. > > Authentication Option: > > http://www.rfc-editor.org/cgi-bin/iddoctype.pl?letsgo=draft-ietf-tcpm-tcp-auth-opt-04 > >>> load balancers: >>> how do you ensure that different socket pairs >>> end up at the same server? >> >> Probably with some kind of connection identifier cookie in the >> initial >> exchange. > > That seems to force application participation, at which point the app > can/should be doing the multiplexing onto the different TCP streams. > That works, but needs zero support from TCP (except, as noted above, > RFC2140-style coordination). > >>> ICMP, TCP 'signal' (RST, SYN, FIN): >>> does a hard error / shutdown / reset on >>> one socket pair affect all socket pairs, >>> or only the one signalled? >> >> This is an interesting issue, which sould be solved when the MAmTCP >> is >> designed. There are different ways to do this with different >> strengths >> and weaknesses. > > IMO this is a protocol specification issue, not an implementation > issue. > >>> Overall, the question is: >> >>> TCP currently presents a model of "one socket pair = one byte >>> stream" to >>> both the network and to the application. >> >>> What model does multipath TCP present to the network and to the >>> application, and how is it enforced? Is that model compatible with >>> the >>> current model (can the use of multiple socket pairs be hidden from >>> either the network or the application)? >> >> Shim6 manages to hide the extra addresses from the application, so >> I'd >> say "yes" on that part. Not sure what you mean by hiding addresses >> from >> the network. > > Same kind of thing w.r.t. ICMP errors, ECN, or flow-based drops. Does > the network know these connections are related? > >> There are of course applications that attach a lot of significance to >> the addresses they run over. It can be argued that this is not the >> best >> possible design, but something needs to be in place to make sure >> nothing >> really bad happens in these cases. Maybe just telling people to not >> configure multiple addresses is enough here, or maybe we need an >> API so >> applications can signal their needs. Or something else.\ > > My basic point is that applications think that a single byte-stream is > associated with a single socket pair because that's the model TCP > presents to them. It's not a design issue; it's architectural - the > definition of the endpoints of a bytestream is the socketpair. > Changing > that changes the application semantics - i.e., requires a major change > to the API in RFC793... > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAknU+bcACgkQE5f5cImnZrtcpgCgw02cZrNdhCk6gowYRg8UyTLk > jvwAn3DqH0SK09M3K0QmBgGPGg/Xa3UZ > =xiYc > -----END PGP SIGNATURE----- > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From rrs@lakerest.net Thu Apr 2 14:05:50 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14BE63A6A5D for ; Thu, 2 Apr 2009 14:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFBB-hPB2WSk for ; Thu, 2 Apr 2009 14:05:49 -0700 (PDT) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 7F3013A6A47 for ; Thu, 2 Apr 2009 14:05:48 -0700 (PDT) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n32L6r0t020637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 2 Apr 2009 17:06:53 -0400 (EDT) (envelope-from rrs@lakerest.net) Message-Id: <72170424-8E1B-4D41-AA93-CBBF210EEDCB@lakerest.net> From: Randall Stewart To: =?ISO-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <72F57532-6047-4AD1-A381-2C48D945C9EE@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 17:06:45 -0400 References: <49D3B6FA.4090504@it.uc3m.es> <6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com> <49D4F9B7.40309@isi.edu> <72F57532-6047-4AD1-A381-2C48D945C9EE@lurchi.franken.de> X-Mailer: Apple Mail (2.930.3) Cc: multipathtcp@ietf.org, Joe Touch Subject: Re: [multipathtcp] [Fwd: Re: multipath tcp disucssion] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 21:05:50 -0000 One other little comment for Joe... On Apr 2, 2009, at 4:58 PM, Michael T=FCxen wrote: > On Apr 2, 2009, at 7:45 PM, Joe Touch wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi, Iljitsch, >> >> Iljitsch van Beijnum wrote: >>> Hi Joe, >>> >>> On 1 apr 2009, at 20:48, marcelo bagnulo braun wrote: >>> >>>> I am concerned about introducing a different model of a TCP =20 >>>> connection >>>> than the "socket pair" (srcIP, dstIP, srcport, dstport), on which =20= >>>> many >>>> other aspects of the Internet depend. >>> >>>> This includes anything that depends on a connection as being =20 >>>> atomic: >>>> NATs >>>> IPsec >>>> TCP MD5 / TCP-AO >>>> load balancers >>>> user applications that listen on given socket pairs >>>> ICMP handling >>>> TCP 'signal' packet handling >>> >>>> The question is whether multipath TCP is consistent with those =20 >>>> other >>>> systems, and the impact of using multiple TCP connections to =20 >>>> emulate a >>>> single socket pair. >>> >>> First: there are different ways to do multipath TCP. The one you're >>> addressing here is where TCP manages multiple addresses, just like =20= >>> SCTP >>> does. Two other models are the one where TCP conforms to the current >>> protocol specifications (the "one ended" multipath TCP with only =20 >>> changes >>> to the sender) or a multipath TCP that runs on top of an existing >>> multi-address system like shim6. >> >> I'm not really focusing on the way multipath is done; I'm saying that >> all solutions that claim to be "TCP" need to address compatibility =20= >> with >> the application-layer semantics of a single TCP connection. If =20 >> multiple >> TCP connections are presented to the application as separate =20 >> channels, >> then you're just talking about coordinating separate TCP connections, >> which was addressed in RFC2140, e.g. >> >>> Continuing the discussion about the multiaddress managing =20 >>> multipath TCP: >>> >>>> IPsec, TCP MD5, TCP-AO could be: >>> >>> I think you have a good point with regard to IPsec. We spent quite =20= >>> a bit >>> of time on that with shim6, but those results aren't immediately >>> applicable to an MAmTCP because shim6 can have IPsec both below or =20= >>> above >>> it, with TCP it's only below. My initial thinking is that if the >>> initial/main address pair is IPsec protected then it should be =20 >>> enforced >>> that additional ones are also IPsec protected. >> >> Yes, but the questions are: >> - how is that enforcement provided >> - is it provided only for IKE'd sessions, or for manual >> keying as well? >> - how does TCP know that IPsec is doing the right thing? >> >> That last one is the killer, IMO. >> >>> By the way, how is this solved in SCTP? >> >> I don't know whether it is. SCTP, however, doesn't intend to =20 >> present a >> single socket pair as a connection to the application, AFAICT, so >> there's no expectation of the kind of security fate-sharing I'm >> concerned about. > SCTP supports two types of sockets: > One-to-One: This is the same as TCP. A socket is either a listener > or represents one end of an SCTP association. > One-to-Many: This is simular to non-connected UDP sockets. A socket > can handle multiple SCTP associations. The API provides > an association ID, which can be used to identify the > association. >> The above is all true.. but there is one other fundamental assumption in SCTP. An SCTP association (no matter which socket model) always assumes the possibility of the endpoints having multiple addresses. This means applications developed for SCTP should be aware of the fact that the fate sharing implied by an SCTP association is a combination of all of the addresses involved in the association. As long as a workable communication pair exists between two endpoints the association may continue to exist. R ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From touch@ISI.EDU Thu Apr 2 15:50:16 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96B73A6D63 for ; Thu, 2 Apr 2009 15:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.559 X-Spam-Level: X-Spam-Status: No, score=-1.559 tagged_above=-999 required=5 tests=[AWL=1.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnOvqivdriKj for ; Thu, 2 Apr 2009 15:50:16 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 2B3623A6824 for ; Thu, 2 Apr 2009 15:50:16 -0700 (PDT) Received: from [128.9.184.224] ([128.9.184.224]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n32MoO7K015243; Thu, 2 Apr 2009 15:50:25 -0700 (PDT) Message-ID: <49D5412F.4010400@isi.edu> Date: Thu, 02 Apr 2009 15:50:23 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Randall Stewart References: <49D3B6FA.4090504@it.uc3m.es> <6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com> <49D4F9B7.40309@isi.edu> <72F57532-6047-4AD1-A381-2C48D945C9EE@lurchi.franken.de> <72170424-8E1B-4D41-AA93-CBBF210EEDCB@lakerest.net> In-Reply-To: <72170424-8E1B-4D41-AA93-CBBF210EEDCB@lakerest.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] [Fwd: Re: multipath tcp disucssion] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 22:50:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Randall Stewart wrote: > One other little comment for Joe... ... > The above is all true.. but there is one other fundamental assumption in > SCTP. An SCTP association (no matter which socket model) always assumes > the possibility of the endpoints having multiple addresses. This means > applications developed for SCTP should be aware of the fact that the > fate sharing implied by an SCTP association is a combination of > all of the addresses involved in the association. As long as a > workable communication pair exists between two endpoints the association > may continue to exist. Right - and this assumption is NOT true for TCP applications. This means that SCTP applications would assume they would need to manage IPsec / TCP MD5 / TCP-AO etc., and NAT boxes may need to do special things to track groups of endpoint addresses associated with a single SCTP association, whereas that's not true for TCP. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknVQS8ACgkQE5f5cImnZrv7pQCggDLawADdlt39ltbGv1njeK8a lgAAoOcJZjB89g5A8ve+ISvgOa1nkU9y =EPSM -----END PGP SIGNATURE----- From rrs@lakerest.net Thu Apr 2 18:03:42 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D48B3A6D5D for ; Thu, 2 Apr 2009 18:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4fOS1bKJ40s for ; Thu, 2 Apr 2009 18:03:41 -0700 (PDT) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id BF6D83A6B81 for ; Thu, 2 Apr 2009 18:03:40 -0700 (PDT) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n3314dmk018900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 2 Apr 2009 21:04:40 -0400 (EDT) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1238720680; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=Ld0tmbw7WYtyaDWulvMSkJLlptQOyr2ficlK2BjUs8I76s4244jkepA 09BpPkH6cEkh3gb73shkWAtogFztEkg== Message-Id: <9F33D3A5-773A-4FD1-8363-DB725E69132C@lakerest.net> From: Randall Stewart To: Joe Touch In-Reply-To: <49D5412F.4010400@isi.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 21:04:39 -0400 References: <49D3B6FA.4090504@it.uc3m.es> <6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com> <49D4F9B7.40309@isi.edu> <72F57532-6047-4AD1-A381-2C48D945C9EE@lurchi.franken.de> <72170424-8E1B-4D41-AA93-CBBF210EEDCB@lakerest.net> <49D5412F.4010400@isi.edu> X-Mailer: Apple Mail (2.930.3) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] [Fwd: Re: multipath tcp disucssion] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 01:03:42 -0000 I would agree with that ;-) R On Apr 2, 2009, at 6:50 PM, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Randall Stewart wrote: >> One other little comment for Joe... > ... >> The above is all true.. but there is one other fundamental >> assumption in >> SCTP. An SCTP association (no matter which socket model) always >> assumes >> the possibility of the endpoints having multiple addresses. This >> means >> applications developed for SCTP should be aware of the fact that the >> fate sharing implied by an SCTP association is a combination of >> all of the addresses involved in the association. As long as a >> workable communication pair exists between two endpoints the >> association >> may continue to exist. > > Right - and this assumption is NOT true for TCP applications. This > means > that SCTP applications would assume they would need to manage IPsec / > TCP MD5 / TCP-AO etc., and NAT boxes may need to do special things to > track groups of endpoint addresses associated with a single SCTP > association, whereas that's not true for TCP. > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAknVQS8ACgkQE5f5cImnZrv7pQCggDLawADdlt39ltbGv1njeK8a > lgAAoOcJZjB89g5A8ve+ISvgOa1nkU9y > =EPSM > -----END PGP SIGNATURE----- > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From jta@fe.up.pt Fri Apr 3 04:02:43 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C179B3A68DE for ; Fri, 3 Apr 2009 04:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCWbnVj17XIp for ; Fri, 3 Apr 2009 04:02:43 -0700 (PDT) Received: from dax.ee.ucl.ac.uk (dax.ee.ucl.ac.uk [128.40.42.12]) by core3.amsl.com (Postfix) with ESMTP id B3E593A6782 for ; Fri, 3 Apr 2009 04:02:42 -0700 (PDT) Received: from [144.82.250.244] (dhcp-250-244.eduroam.ucl.ac.uk [144.82.250.244]) (authenticated bits=0) by dax.ee.ucl.ac.uk (8.13.8/8.13.8) with ESMTP id n33B30QW028238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 12:03:13 +0100 (BST) Message-ID: <49D5ECA2.9010703@fe.up.pt> Date: Fri, 03 Apr 2009 12:01:54 +0100 From: =?ISO-8859-1?Q?Jo=E3o_Taveira_Ara=FAjo?= User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <49D3B6FA.4090504@it.uc3m.es> <6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com> <49D4F9B7.40309@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UCL_EE-MailScanner-Information: Please contact mailhelp@ee.ucl.ac.uk for more information X-MailScanner-ID: n33B30QW028238 X-UCL_EE-MailScanner: Found to be clean X-UCL_EE-MailScanner-From: jta@fe.up.pt Cc: multipathtcp@ietf.org, Joe Touch Subject: Re: [multipathtcp] [Fwd: Re: multipath tcp disucssion] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 11:02:43 -0000 Hi, Just picking up on two of Iljitsch's comments: Iljitsch van Beijnum wrote: > First: there are different ways to do multipath TCP. The one you're > addressing here is where TCP manages multiple addresses, just like > SCTP does. Two other models are the one where TCP conforms to the > current protocol specifications (the "one ended" multipath TCP with > only changes to the sender) or a multipath TCP that runs on top of an > existing multi-address system like shim6. (...) > An important aspect of that is that if one of the paths breaks or > clogs up, the packets are subsequently sent over (one of) the > remaining working path(s). And the lost packets must also be > retransmitted over a working path, probably before a normal RTO would > expire in order to avoid the receive buffer from filling up because of > lost packets, making the working path stall. It would be convenient to start defining what the limitations of each model is, and not make overarching statements that may not apply to all variants. I briefly asked this during the IETF presentation via jabber, but here goes: in the "one ended" multipath TCP, how do you retransmit lost segments over different paths without confusing the legacy receiver, who has one of his connections stalled? Mark's proposal solves this by adding subflow sequence numbers alongside data sequence numbers, at the expense of requiring a compatible receiver. In the legacy case, it doesn't seem quite as simple. Cheers, Joao. From iljitsch@muada.com Fri Apr 3 04:19:40 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6E6F3A698F for ; Fri, 3 Apr 2009 04:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7f7SXCdfBf4 for ; Fri, 3 Apr 2009 04:19:40 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id BEA693A68DE for ; Fri, 3 Apr 2009 04:19:39 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.54]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n33BJdAI018145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 3 Apr 2009 13:19:39 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: =?ISO-8859-1?Q?Jo=E3o_Taveira_Ara=FAjo?= In-Reply-To: <49D5ECA2.9010703@fe.up.pt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 3 Apr 2009 13:20:11 +0200 References: <49D3B6FA.4090504@it.uc3m.es> <6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com> <49D4F9B7.40309@isi.edu> <49D5ECA2.9010703@fe.up.pt> X-Mailer: Apple Mail (2.930.3) Cc: multipathtcp@ietf.org, Joe Touch Subject: Re: [multipathtcp] [Fwd: Re: multipath tcp disucssion] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 11:19:40 -0000 On 3 apr 2009, at 13:01, Jo=E3o Taveira Ara=FAjo wrote: > It would be convenient to start defining what the limitations of =20 > each model is, and not make overarching statements that may not =20 > apply to all variants. I briefly asked this during the IETF =20 > presentation via jabber, but here goes: in the "one ended" multipath =20= > TCP, how do you retransmit lost segments over different paths =20 > without confusing the legacy receiver, who has one of his =20 > connections stalled? The legacy receiver is blissfully unaware of all of this. Assuming some mechanism for the sender to make packets flow over =20 different paths (yes, some handwaving here, for now assume the sender =20= has multiple NICs that connect to the network in multiple places, but =20= the multiple NICs all use the same address), the sender can simply =20 send normal TCP packets over different paths that will be processed =20 normally by an existing receiver. The receiver will of course see some =20= reordering, but otherwise it just sees regular TCP. As long as the sender is aware of which path is progressing the sender =20= can do what's necessary to make this work. The normal cumulative ACK =20 isn't all that helpful here because with the expected reordering, =20 feeback about packets received out of order will be delayed until the =20= holes in the seqnum space are filled in, slowing everything down. =20 Fortunately, SACK is widely deployed these days so SACK can be used to =20= determine which packets were received, so the sender can progress the =20= appropriate path. The single ended model does have the limitation that it can't =20 conclusively correlate an ACK with the path taken by the ACKed packet =20= if there was a retransmission.= From jta@fe.up.pt Fri Apr 3 04:42:32 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B7673A6C12 for ; Fri, 3 Apr 2009 04:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9r8BX0ozwf31 for ; Fri, 3 Apr 2009 04:42:31 -0700 (PDT) Received: from dax.ee.ucl.ac.uk (dax.ee.ucl.ac.uk [128.40.42.12]) by core3.amsl.com (Postfix) with ESMTP id 7CC933A6AC8 for ; Fri, 3 Apr 2009 04:42:31 -0700 (PDT) Received: from [144.82.250.244] (dhcp-250-244.eduroam.ucl.ac.uk [144.82.250.244]) (authenticated bits=0) by dax.ee.ucl.ac.uk (8.13.8/8.13.8) with ESMTP id n33BhSLp029295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 12:43:28 +0100 (BST) Message-ID: <49D5F61E.1010805@fe.up.pt> Date: Fri, 03 Apr 2009 12:42:22 +0100 From: =?ISO-8859-1?Q?Jo=E3o_Taveira_Ara=FAjo?= User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <49D3B6FA.4090504@it.uc3m.es> <6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com> <49D4F9B7.40309@isi.edu> <49D5ECA2.9010703@fe.up.pt> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-UCL_EE-MailScanner-Information: Please contact mailhelp@ee.ucl.ac.uk for more information X-MailScanner-ID: n33BhSLp029295 X-UCL_EE-MailScanner: Found to be clean X-UCL_EE-MailScanner-From: jta@fe.up.pt Cc: multipathtcp@ietf.org, Joe Touch Subject: Re: [multipathtcp] [Fwd: Re: multipath tcp disucssion] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 11:42:32 -0000 Iljitsch van Beijnum wrote: > On 3 apr 2009, at 13:01, João Taveira Araújo wrote: > >> It would be convenient to start defining what the limitations of each >> model is, and not make overarching statements that may not apply to >> all variants. I briefly asked this during the IETF presentation via >> jabber, but here goes: in the "one ended" multipath TCP, how do you >> retransmit lost segments over different paths without confusing the >> legacy receiver, who has one of his connections stalled? > > The legacy receiver is blissfully unaware of all of this. > > Assuming some mechanism for the sender to make packets flow over > different paths (yes, some handwaving here, for now assume the sender > has multiple NICs that connect to the network in multiple places, but > the multiple NICs all use the same address), the sender can simply > send normal TCP packets over different paths that will be processed > normally by an existing receiver. The receiver will of course see some > reordering, but otherwise it just sees regular TCP. Ok, so the assumption here is that the socket pair must remain consistent. You could use multiple interfaces / some form of tagging / tunneling. Putting quibbles from a CC perspective aside for now, how does this conform with the semantics of TCP as Joe was describing them? Example off the top of my head: you get a NAT on any of the concurrent paths, all of the sudden your consistent socket pair appears as something entirely different on the other side. > The single ended model does have the limitation that it can't > conclusively correlate an ACK with the path taken by the ACKed packet > if there was a retransmission. TBH, I don't think the single ended model has much merit, in considering that endpoints benefit the most from multipath, so the incentive to upgrade would be there, and fallback to legacy TCP would always be in place. The question is whether it makes architectural sense to design multipath as an extension of TCP or whether we're doing that because it seems to be the only deployment model available, and we may end up with an ugly hack which breaks stuff. I'm all for it btw, just playing devil's advocate. Joao From marcelo@it.uc3m.es Fri Apr 3 05:18:25 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FF073A6C08 for ; Fri, 3 Apr 2009 05:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.267 X-Spam-Level: X-Spam-Status: No, score=-6.267 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dULvNsyCw7sK for ; Fri, 3 Apr 2009 05:18:24 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id F2D553A6C81 for ; Fri, 3 Apr 2009 05:18:23 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (174.pool85-53-130.dynamic.orange.es [85.53.130.174]) by smtp01.uc3m.es (Postfix) with ESMTP id F39D1B4D395; Fri, 3 Apr 2009 14:19:22 +0200 (CEST) Message-ID: <49D5FECA.6090709@it.uc3m.es> Date: Fri, 03 Apr 2009 14:19:22 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Jo=E3o_Taveira_Ara=FAjo?= References: <49D3B6FA.4090504@it.uc3m.es> <6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com> <49D4F9B7.40309@isi.edu> <49D5ECA2.9010703@fe.up.pt> <49D5F61E.1010805@fe.up.pt> In-Reply-To: <49D5F61E.1010805@fe.up.pt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16558.007 Cc: multipathtcp@ietf.org, Joe Touch Subject: Re: [multipathtcp] [Fwd: Re: multipath tcp disucssion] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 12:18:25 -0000 João Taveira Araújo escribió: > Iljitsch van Beijnum wrote: >> On 3 apr 2009, at 13:01, João Taveira Araújo wrote: >> >>> It would be convenient to start defining what the limitations of >>> each model is, and not make overarching statements that may not >>> apply to all variants. I briefly asked this during the IETF >>> presentation via jabber, but here goes: in the "one ended" multipath >>> TCP, how do you retransmit lost segments over different paths >>> without confusing the legacy receiver, who has one of his >>> connections stalled? >> >> The legacy receiver is blissfully unaware of all of this. >> >> Assuming some mechanism for the sender to make packets flow over >> different paths (yes, some handwaving here, for now assume the sender >> has multiple NICs that connect to the network in multiple places, but >> the multiple NICs all use the same address), the sender can simply >> send normal TCP packets over different paths that will be processed >> normally by an existing receiver. The receiver will of course see >> some reordering, but otherwise it just sees regular TCP. > > Ok, so the assumption here is that the socket pair must remain > consistent. You could use multiple interfaces / some form of tagging / > tunneling. Putting quibbles from a CC perspective aside for now, how > does this conform with the semantics of TCP as Joe was describing them? in the case of the one ended multipaht tcp, what happens is that differnent packets are routed over different paths by the routing system. This is not very different with what happens today in the case that there is a failure and that the routing system decides to use an alternative path for the following packets. > Example off the top of my head: you get a NAT on any of the concurrent > paths, all of the sudden your consistent socket pair appears as > something entirely different on the other side. that would depend on where the nat is located, right? > >> The single ended model does have the limitation that it can't >> conclusively correlate an ACK with the path taken by the ACKed packet >> if there was a retransmission. > > TBH, I don't think the single ended model has much merit, in > considering that endpoints benefit the most from multipath, so the > incentive to upgrade would be there, interesting... the same comment would apply to widely deployed protocols such as HIP, shim6, sctp.... :-) In other words, there seems to be a significant deployment vector advantage if the end that deploys the new mechanism obtain benefits, irrespectively whether the other end supports it or not imho Clearly, both flavours (one ended and two ended) should play well toghether in the sense that if both ends support it, then most of the advantages should be realized, but it would improve significantly the deployment model if when one ends supports it, then it actually obtains benefits. the use case for one ended multipath tcp is the case of a multihomed content provider, which by using multipaht tcp, if can improve the performnce perceived by the clients. I think this is a significant benefit and i think it can be realized wihtou need for the client to be updated. > and fallback to legacy TCP would always be in place. The question is > whether it makes architectural sense to design multipath as an > extension of TCP or whether we're doing that because it seems to be > the only deployment model available, and we may end up with an ugly > hack which breaks stuff. > it is interesting that you qualify it as an ugly hack and that break stuff wihtout actually seeing any form of proposal of how this could be done. On your perspective, what actually breaks? > I'm all for it btw, just playing devil's advocate. > > Joao > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From iljitsch@muada.com Fri Apr 3 05:32:36 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7808B28C20B for ; Fri, 3 Apr 2009 05:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.907 X-Spam-Level: X-Spam-Status: No, score=-5.907 tagged_above=-999 required=5 tests=[AWL=0.692, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cqEZrMe8fpY for ; Fri, 3 Apr 2009 05:32:35 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id D270928C26E for ; Fri, 3 Apr 2009 05:32:34 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.54]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n33CWZCo019187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 3 Apr 2009 14:32:36 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Joe Touch In-Reply-To: <49D51FF0.8010600@isi.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 3 Apr 2009 14:33:08 +0200 References: <49D3B6FA.4090504@it.uc3m.es> <6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com> <49D4F9B7.40309@isi.edu> <49D51FF0.8010600@isi.edu> X-Mailer: Apple Mail (2.930.3) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] [Fwd: Re: multipath tcp disucssion] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 12:32:36 -0000 On 2 apr 2009, at 22:28, Joe Touch wrote: >> If IPsec implementations running on multipath TCP hosts already >> support >> the right API the multipath TCP could instruct the IPsec to do >> this. If >> not, the IPsec would have to be modified. > Agreed. I just wonder whether it's even possible to modify IPsec to do > this. I.e., IPsec (and IKE) needs to know about 'groups of transport > connections that need to be treated the same'. That can be achieved in > the configuration (i.e., using wildcards in port fields, or using > identical configurations for different connection specifications), but > there's nothing in IPsec that flags that inside IPsec. I'm not sure what kind of APIs exist to make applications control IPsec behavior. If those exist, it would of course be doable for multipath TCP to simply make sure IPsec behavior conforms to what the application specified for each subflow. If the desired IPsec behavior is specified in a racoon config file or the like this would be significantly more complex, and probably not possible the way things are today. If the IPsec is implemented in the same stack as the multipath TCP the two can coordinate the IPsec behavior on the subflows, but in the case of an external system applying IPsec tunneling that isn't really possible. I guess this is a limitation that must be carefully documented. >>> TCP MD5 can be used for more than BGP, and TCP-AO (its >>> replacement) can >>> as well. >> That doesn't make sense, both TLS and IPsec are superior. > Please check our doc. TLS does not protect a TCP connection from > TCP-level attacks, e.g., RSTs. IPsec cannot be forced to use new > keys on > new connections (i.e., upon receipt of a RST, destroy the SA). TCP-AO > does both of these (TCP MD5 only the former), and is much simpler than > IPsec (which is why it is preferred for BGP). I would have preferred to see the effort in this area spent on making IPsec more usable in this scenario. IPsec has an anti-replay counter that is sorely missed in the TCP MD5 scenario. [BGP over multiple paths] > The current solution requires that the single IP address is > routed over multiple link-layer paths; I'm suggesting utility to a > solution that does not have that constraint. I don't know if there's a > particular reason to encourage this using multiTCP, vs., e.g., single > TCP over a virtual link tunnel (e.g., GRE). The problem with this way of running BGP is that it only works between two hosts connected to the same set of links. In the case of eBGP this is already a requirement for other reasons so it's not a limitation, but it does make this type of use less useful for other purposes. I also don't think that using multipath TCP for BGP adds much, so I doubt it will be used for that in practice. > If they subflows use different ports, then TCP MD5 would think they > are > different connections. So the answer depends on what the lower layer > sees. I would assume that TCP MD5 is enabled in the TCP control block, not on an address/port number basis. So any segment that is part of the session will have the MD5 applied, regardless of the addresses that are in the packet. >>> at which point the app >>> can/should be doing the multiplexing onto the different TCP streams. >>> That works, but needs zero support from TCP >> The trouble here is that the application must now split the data into >> multiple byte streams. For some stuff that's not a huge problem (file >> transfer like BitTorrent) but even in those cases it's not very >> flexible: once a piece of data is commited to a path, only an >> application level timeout or a failure allows for it to be rerouted >> over >> a different path. The transport layer can do this at RTT timescales >> without much extra overhead. > It can be done inbetween the app and transport, i.e., inside the > socket > buffers too. I.e., it can be done in a layer above TCP but below the > app, if isolation from the app is needed. That's partly done by things > like HTTP persistent connections with chunked responses. You would need to add sequence numbers so the data can be put back in the right order at the receiving end. >>> Does the network know these connections are related? >> Does the network have a notion of connections in the first place? > Yes. In places I've noted, at least: > network layer in the end host or BITW: IPsec > NATs > multipath routing based on flow preservation > firewall filtering > when ICMPs are issued (in the network or at the dest host) Today a single session is a single flow. If a session has multiple flows, does this mean that middleboxes etc recognize those (sub)flows as belonging to the same session, or can they simply treat them as different flows? The latter is easier to support and would be sufficient in most cases, IMO. The IPsec case is an example of where we'd want to be able to recognize sessions rather than subflows, though. >> Disagree. Per RFC 793, it's completely normal behavior for the >> network >> to send some packets over one path and some over another path. Having >> the TCP sender tell the network which packets to send over which >> path is >> an important optimization because now it's possible to run congestion >> control instances for each path, so TCP can adapt to the path >> properties. This is all firmly within the bounds of layers 3 and 4 >> and >> outside the scope of higher layers. > I said socket pair, not path. Ok, I missed that. Do you have a pointer to something that explains what those are and how they're used? As far as I know, hosts work with sockets and control blocks. Those obviously relate to the addresses and port numbers, but within a host it's the socket or TCP control block that identifies a session. >> Once additional addresses enter the picture, this is arguably no >> longer >> the case, but NATs, different types of tunnels, MIP, shim6 etc set >> precedents here long ago: applications can't expect to know all the >> details of the addresses used in their communication. > They do expect that a single socket pair corresponds to a single > connection - no more, no less. NATs, etc. preserve this. Anything > that > violates this breaks TCP. A multiaddress multipath TCP would certainly extend the existing TCP model, yes. From jta@fe.up.pt Fri Apr 3 06:47:17 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CBBD3A6DE0 for ; Fri, 3 Apr 2009 06:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5NyXbT6jW1O for ; Fri, 3 Apr 2009 06:47:16 -0700 (PDT) Received: from dax.ee.ucl.ac.uk (dax.ee.ucl.ac.uk [128.40.42.12]) by core3.amsl.com (Postfix) with ESMTP id 4F5673A6CCB for ; Fri, 3 Apr 2009 06:47:16 -0700 (PDT) Received: from [144.82.250.244] (dhcp-250-244.eduroam.ucl.ac.uk [144.82.250.244]) (authenticated bits=0) by dax.ee.ucl.ac.uk (8.13.8/8.13.8) with ESMTP id n33Dm9l9004051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 14:48:09 +0100 (BST) Message-ID: <49D61357.1000401@fe.up.pt> Date: Fri, 03 Apr 2009 14:47:03 +0100 From: =?ISO-8859-1?Q?Jo=E3o_Taveira_Ara=FAjo?= User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: marcelo bagnulo braun References: <49D3B6FA.4090504@it.uc3m.es> <6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com> <49D4F9B7.40309@isi.edu> <49D5ECA2.9010703@fe.up.pt> <49D5F61E.1010805@fe.up.pt> <49D5FECA.6090709@it.uc3m.es> In-Reply-To: <49D5FECA.6090709@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UCL_EE-MailScanner-Information: Please contact mailhelp@ee.ucl.ac.uk for more information X-MailScanner-ID: n33Dm9l9004051 X-UCL_EE-MailScanner: Found to be clean X-UCL_EE-MailScanner-From: jta@fe.up.pt Cc: multipathtcp@ietf.org, Joe Touch Subject: Re: [multipathtcp] [Fwd: Re: multipath tcp disucssion] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 13:47:17 -0000 marcelo bagnulo braun wrote: > > in the case of the one ended multipaht tcp, what happens is that > differnent packets are routed over different paths by the routing > system. This is not very different with what happens today in the case > that there is a failure and that the routing system decides to use an > alternative path for the following packets. > >> Example off the top of my head: you get a NAT on any of the >> concurrent paths, all of the sudden your consistent socket pair >> appears as something entirely different on the other side. > > that would depend on where the nat is located, right? Right. >>> The single ended model does have the limitation that it can't >>> conclusively correlate an ACK with the path taken by the ACKed >>> packet if there was a retransmission. >> >> TBH, I don't think the single ended model has much merit, in >> considering that endpoints benefit the most from multipath, so the >> incentive to upgrade would be there, > interesting... the same comment would apply to widely deployed > protocols such as HIP, shim6, sctp.... :-) > > In other words, there seems to be a significant deployment vector > advantage if the end that deploys the new mechanism obtain benefits, > irrespectively whether the other end supports it or not imho > Clearly, both flavours (one ended and two ended) should play well > toghether in the sense that if both ends support it, then most of the > advantages should be realized, but it would improve significantly the > deployment model if when one ends supports it, then it actually > obtains benefits. > > the use case for one ended multipath tcp is the case of a multihomed > content provider, which by using multipaht tcp, if can improve the > performnce perceived by the clients. I think this is a significant > benefit and i think it can be realized wihtou need for the client to > be updated. > The problem here is you seem to imply that both "flavours" can coexist, so the two ended multipath can be seen as an extension of the one ended model and would bring even more benefits. My concern would be that by supporting one ended multipath you might concede to design limitations which then unnecessarily hinder the two ended model. If we come up with a technically superior two ended multipath proposal which can't readily be translated to a sender-only configuration, should we abandon it in favour of a proposal which manages to do both? My hunch is that in this case, the effort required in upgrading is small compared to the profits you reap. The protocols you used as examples (I wouldn't call them widely deployed just yet) have slightly different obstacles to deployment. Multipath TCP plays nice with the current architecture and just changes how you deal with some semantics, so I'd liken it more to an extension of TCP's CC than a full blown protocol (not quite correct I know). What Joe brought up was that doing this could prove disruptive in some respects due to the underlying assumptions the TCP model has. > >> and fallback to legacy TCP would always be in place. The question is >> whether it makes architectural sense to design multipath as an >> extension of TCP or whether we're doing that because it seems to be >> the only deployment model available, and we may end up with an ugly >> hack which breaks stuff. >> > it is interesting that you qualify it as an ugly hack and that break > stuff wihtout actually seeing any form of proposal of how this could > be done. On your perspective, what actually breaks? > I didn't classify it as an ugly hack, I said we MAY end up with an ugly hack, and I have seen a proposal on how this could be done. For a list of what could break Joe's list is a good start. From touch@ISI.EDU Fri Apr 3 11:07:04 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AC1928C14C for ; Fri, 3 Apr 2009 11:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOaBdTmYwtj1 for ; Fri, 3 Apr 2009 11:07:02 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 814E13A6358 for ; Fri, 3 Apr 2009 11:07:02 -0700 (PDT) Received: from [128.9.176.212] (c2-vpn03.isi.edu [128.9.176.212]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n33I72Sk024307; Fri, 3 Apr 2009 11:07:04 -0700 (PDT) Message-ID: <49D65046.7030004@isi.edu> Date: Fri, 03 Apr 2009 11:07:02 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <49D3B6FA.4090504@it.uc3m.es> <6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com> <49D4F9B7.40309@isi.edu> <49D51FF0.8010600@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] [Fwd: Re: multipath tcp disucssion] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 18:07:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Iljitsch van Beijnum wrote: > On 2 apr 2009, at 22:28, Joe Touch wrote: > ... >>>> TCP MD5 can be used for more than BGP, and TCP-AO (its replacement) can >>>> as well. > >>> That doesn't make sense, both TLS and IPsec are superior. > >> Please check our doc. TLS does not protect a TCP connection from >> TCP-level attacks, e.g., RSTs. IPsec cannot be forced to use new keys on >> new connections (i.e., upon receipt of a RST, destroy the SA). TCP-AO >> does both of these (TCP MD5 only the former), and is much simpler than >> IPsec (which is why it is preferred for BGP). > > I would have preferred to see the effort in this area spent on making > IPsec more usable in this scenario. IPsec has an anti-replay counter > that is sorely missed in the TCP MD5 scenario. It would be useful to look at TCP-AO, which deprecates TCP MD5. TCP-AO includes a sequence number extension to protect against replay attacks. >> If they subflows use different ports, then TCP MD5 would think they are >> different connections. So the answer depends on what the lower layer >> sees. > > I would assume that TCP MD5 is enabled in the TCP control block, not on > an address/port number basis. So any segment that is part of the session > will have the MD5 applied, regardless of the addresses that are in the > packet. TCP MD5 does not specify how it is enabled. TCP-AO addresses this by specifying protection on a socket pair basis - exactly because that is what uniquely defines a TCP connection. The TCB is an implementation suggestion in RFC793, not a protocol requirement. >>>> at which point the app >>>> can/should be doing the multiplexing onto the different TCP streams. >>>> That works, but needs zero support from TCP > >>> The trouble here is that the application must now split the data into >>> multiple byte streams. For some stuff that's not a huge problem (file >>> transfer like BitTorrent) but even in those cases it's not very >>> flexible: once a piece of data is commited to a path, only an >>> application level timeout or a failure allows for it to be rerouted over >>> a different path. The transport layer can do this at RTT timescales >>> without much extra overhead. > >> It can be done inbetween the app and transport, i.e., inside the socket >> buffers too. I.e., it can be done in a layer above TCP but below the >> app, if isolation from the app is needed. That's partly done by things >> like HTTP persistent connections with chunked responses. > > You would need to add sequence numbers so the data can be put back in > the right order at the receiving end. Agreed. Seems like that's required anyway, though - once you spread a single stream's data over multiple connections. >>>> Does the network know these connections are related? > >>> Does the network have a notion of connections in the first place? > >> Yes. In places I've noted, at least: > >> network layer in the end host or BITW: IPsec >> NATs >> multipath routing based on flow preservation >> firewall filtering >> when ICMPs are issued (in the network or at the dest host) > > Today a single session is a single flow. If a session has multiple > flows, does this mean that middleboxes etc recognize those (sub)flows as > belonging to the same session, or can they simply treat them as > different flows? That depends on the fate sharing you require between the flows. Do you expect them to go to the same place? Have a set of ports/addresses that both sides know are related? All get through or none? Any fate sharing is impacted by these boxes. > The latter is easier to support and would be sufficient > in most cases, IMO. The IPsec case is an example of where we'd want to > be able to recognize sessions rather than subflows, though. Load balancers that send flows to different servers too. Firewalls that permit some and deny others maybe as well. This all needs to be worked out - and I'm not sure there *is* a solution to most of it... >>> Disagree. Per RFC 793, it's completely normal behavior for the network >>> to send some packets over one path and some over another path. Having >>> the TCP sender tell the network which packets to send over which path is >>> an important optimization because now it's possible to run congestion >>> control instances for each path, so TCP can adapt to the path >>> properties. This is all firmly within the bounds of layers 3 and 4 and >>> outside the scope of higher layers. > >> I said socket pair, not path. > > Ok, I missed that. Do you have a pointer to something that explains what > those are and how they're used? RFC793, page 5: To allow for many processes within a single Host to use TCP communication facilities simultaneously, the TCP provides a set of addresses or ports within each host. Concatenated with the network and host addresses from the internet communication layer, this forms a socket. A pair of sockets uniquely identifies each connection. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ That is, a socket may be simultaneously used in multiple connections. > As far as I know, hosts work with sockets and control blocks. Those > obviously relate to the addresses and port numbers, but within a host > it's the socket or TCP control block that identifies a session. A socket is defined in RFC793 as an address/port pair. That's not necessarily how people use the term in implementations. The TCB is introduced in RFC793 as an implementation term. You need to work with the semantics of a *connection*, which is what TCP is all about. >>> Once additional addresses enter the picture, this is arguably no longer >>> the case, but NATs, different types of tunnels, MIP, shim6 etc set >>> precedents here long ago: applications can't expect to know all the >>> details of the addresses used in their communication. > >> They do expect that a single socket pair corresponds to a single >> connection - no more, no less. NATs, etc. preserve this. Anything that >> violates this breaks TCP. > > A multiaddress multipath TCP would certainly extend the existing TCP > model, yes. It is that which, AFAICT, needs development, and explanation as to whether it is, or even can be, backwards compatible. IMO, if you end up with something that isn't, you probably need to show benefit over SCTP (which already exists). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknWRqcACgkQE5f5cImnZrs6WACg7ZLMoO0f2iTC4kWq/K4QQiRz +BwAnj9a3cCMvhkiNy8dDJCOlb1mRc6a =3UAA -----END PGP SIGNATURE----- From dwing@cisco.com Fri Apr 3 11:23:47 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B94293A6939 for ; Fri, 3 Apr 2009 11:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.297 X-Spam-Level: X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DDnCwsFeotk for ; Fri, 3 Apr 2009 11:23:46 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 800AB3A6407 for ; Fri, 3 Apr 2009 11:23:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,320,1235952000"; d="scan'208";a="166369425" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 03 Apr 2009 18:24:49 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n33IOnT5026461 for ; Fri, 3 Apr 2009 11:24:49 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n33IOnI0026696 for ; Fri, 3 Apr 2009 18:24:49 GMT From: "Dan Wing" To: References: <49D3B6FA.4090504@it.uc3m.es><6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com><49D4F9B7.40309@isi.edu><49D51FF0.8010600@isi.edu> <49D65046.7030004@isi.edu> Date: Fri, 3 Apr 2009 11:24:49 -0700 Message-ID: <0c5101c9b489$79397e20$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <49D65046.7030004@isi.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm0hyTvCyAPryc9QDOa59gEm/H8gAAAfzmw DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8167; t=1238783089; x=1239647089; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20TCP-AO=20with=20NAT=20[was=20RE=3A=20[multipath tcp]=20[Fwd=3A=20Re=3A=20multipath=20tcp=20disucssion]] |Sender:=20; bh=0pjxOP2EDP1MCde8Py1kgzpOQcgW4NXe+OLrwS1/008=; b=JOEjDaoG01fq9LW5ynNPePpwfXThCBol6C0zjynrr1RFYUEvpVpQTxt9Tn YVN4jtNVbUvP9WMAzKw95mdTsEcwMgpjPQe8Cl8dO7c9gN6dv54PZhPDqQ+G h3B6DGoMSe; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [multipathtcp] TCP-AO with NAT [was RE: [Fwd: Re: multipath tcp disucssion]] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 18:23:47 -0000 Un-mentioned in this thread is that TCP-AO does not work across a NAT. Reviewing Iljitsch's slides they don't show a NAT or NAT64 so maybe this isn't a concern to anyone but me. http://www.ietf.org/mail-archive/web/tcpm/current/msg04001.html http://tools.ietf.org/html/draft-ietf-tcpm-tcp-auth-opt-04#section-11.2 We could create TCP-AObis, I suppose, which works over NAT and NAPT. -d > -----Original Message----- > From: multipathtcp-bounces@ietf.org > [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Joe Touch > Sent: Friday, April 03, 2009 11:07 AM > To: Iljitsch van Beijnum > Cc: multipathtcp@ietf.org > Subject: Re: [multipathtcp] [Fwd: Re: multipath tcp disucssion] > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Iljitsch van Beijnum wrote: > > On 2 apr 2009, at 22:28, Joe Touch wrote: > > > ... > >>>> TCP MD5 can be used for more than BGP, and TCP-AO (its > replacement) can > >>>> as well. > > > >>> That doesn't make sense, both TLS and IPsec are superior. > > > >> Please check our doc. TLS does not protect a TCP connection from > >> TCP-level attacks, e.g., RSTs. IPsec cannot be forced to > use new keys on > >> new connections (i.e., upon receipt of a RST, destroy the > SA). TCP-AO > >> does both of these (TCP MD5 only the former), and is much > simpler than > >> IPsec (which is why it is preferred for BGP). > > > > I would have preferred to see the effort in this area spent > on making > > IPsec more usable in this scenario. IPsec has an anti-replay counter > > that is sorely missed in the TCP MD5 scenario. > > It would be useful to look at TCP-AO, which deprecates TCP MD5. TCP-AO > includes a sequence number extension to protect against > replay attacks. > > >> If they subflows use different ports, then TCP MD5 would > think they are > >> different connections. So the answer depends on what the > lower layer > >> sees. > > > > I would assume that TCP MD5 is enabled in the TCP control > block, not on > > an address/port number basis. So any segment that is part > of the session > > will have the MD5 applied, regardless of the addresses that > are in the > > packet. > > TCP MD5 does not specify how it is enabled. TCP-AO addresses this by > specifying protection on a socket pair basis - exactly because that is > what uniquely defines a TCP connection. > > The TCB is an implementation suggestion in RFC793, not a protocol > requirement. > > >>>> at which point the app > >>>> can/should be doing the multiplexing onto the different > TCP streams. > >>>> That works, but needs zero support from TCP > > > >>> The trouble here is that the application must now split > the data into > >>> multiple byte streams. For some stuff that's not a huge > problem (file > >>> transfer like BitTorrent) but even in those cases it's not very > >>> flexible: once a piece of data is commited to a path, only an > >>> application level timeout or a failure allows for it to > be rerouted over > >>> a different path. The transport layer can do this at RTT > timescales > >>> without much extra overhead. > > > >> It can be done inbetween the app and transport, i.e., > inside the socket > >> buffers too. I.e., it can be done in a layer above TCP but > below the > >> app, if isolation from the app is needed. That's partly > done by things > >> like HTTP persistent connections with chunked responses. > > > > You would need to add sequence numbers so the data can be > put back in > > the right order at the receiving end. > > Agreed. Seems like that's required anyway, though - once you spread a > single stream's data over multiple connections. > > >>>> Does the network know these connections are related? > > > >>> Does the network have a notion of connections in the first place? > > > >> Yes. In places I've noted, at least: > > > >> network layer in the end host or BITW: IPsec > >> NATs > >> multipath routing based on flow preservation > >> firewall filtering > >> when ICMPs are issued (in the network or at the dest host) > > > > Today a single session is a single flow. If a session has multiple > > flows, does this mean that middleboxes etc recognize those > (sub)flows as > > belonging to the same session, or can they simply treat them as > > different flows? > > That depends on the fate sharing you require between the flows. Do you > expect them to go to the same place? Have a set of > ports/addresses that > both sides know are related? All get through or none? Any fate sharing > is impacted by these boxes. > > > The latter is easier to support and would be sufficient > > in most cases, IMO. The IPsec case is an example of where > we'd want to > > be able to recognize sessions rather than subflows, though. > > Load balancers that send flows to different servers too. > Firewalls that > permit some and deny others maybe as well. This all needs to be worked > out - and I'm not sure there *is* a solution to most of it... > > >>> Disagree. Per RFC 793, it's completely normal behavior > for the network > >>> to send some packets over one path and some over another > path. Having > >>> the TCP sender tell the network which packets to send > over which path is > >>> an important optimization because now it's possible to > run congestion > >>> control instances for each path, so TCP can adapt to the path > >>> properties. This is all firmly within the bounds of > layers 3 and 4 and > >>> outside the scope of higher layers. > > > >> I said socket pair, not path. > > > > Ok, I missed that. Do you have a pointer to something that > explains what > > those are and how they're used? > > RFC793, page 5: > To allow for many processes within a single Host to use TCP > communication facilities simultaneously, the TCP provides a set of > addresses or ports within each host. Concatenated with > the network > and host addresses from the internet communication layer, > this forms > a socket. A pair of sockets uniquely identifies each connection. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > That is, a socket may be simultaneously used in multiple > connections. > > > As far as I know, hosts work with sockets and control blocks. Those > > obviously relate to the addresses and port numbers, but > within a host > > it's the socket or TCP control block that identifies a session. > > A socket is defined in RFC793 as an address/port pair. That's not > necessarily how people use the term in implementations. The TCB is > introduced in RFC793 as an implementation term. You need to work with > the semantics of a *connection*, which is what TCP is all about. > > >>> Once additional addresses enter the picture, this is > arguably no longer > >>> the case, but NATs, different types of tunnels, MIP, shim6 etc set > >>> precedents here long ago: applications can't expect to > know all the > >>> details of the addresses used in their communication. > > > >> They do expect that a single socket pair corresponds to a single > >> connection - no more, no less. NATs, etc. preserve this. > Anything that > >> violates this breaks TCP. > > > > A multiaddress multipath TCP would certainly extend the existing TCP > > model, yes. > > It is that which, AFAICT, needs development, and explanation as to > whether it is, or even can be, backwards compatible. > > IMO, if you end up with something that isn't, you probably > need to show > benefit over SCTP (which already exists). > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAknWRqcACgkQE5f5cImnZrs6WACg7ZLMoO0f2iTC4kWq/K4QQiRz > +BwAnj9a3cCMvhkiNy8dDJCOlb1mRc6a > =3UAA > -----END PGP SIGNATURE----- > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From touch@ISI.EDU Fri Apr 3 11:58:21 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40A23A67FF for ; Fri, 3 Apr 2009 11:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[AWL=0.809, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twh58bARhtTK for ; Fri, 3 Apr 2009 11:58:20 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6FD743A67D1 for ; Fri, 3 Apr 2009 11:58:20 -0700 (PDT) Received: from [128.9.176.212] (c2-vpn03.isi.edu [128.9.176.212]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n33Iwdtb005974; Fri, 3 Apr 2009 11:58:41 -0700 (PDT) Message-ID: <49D65C5F.5050908@isi.edu> Date: Fri, 03 Apr 2009 11:58:39 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dan Wing References: <49D3B6FA.4090504@it.uc3m.es><6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com><49D4F9B7.40309@isi.edu><49D51FF0.8010600@isi.edu> <49D65046.7030004@isi.edu> <0c5101c9b489$79397e20$c4f0200a@cisco.com> In-Reply-To: <0c5101c9b489$79397e20$c4f0200a@cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] TCP-AO with NAT [was RE: [Fwd: Re: multipath tcp disucssion]] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 18:58:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Wing wrote: > Un-mentioned in this thread is that TCP-AO does not work across > a NAT. Reviewing Iljitsch's slides they don't show a NAT or > NAT64 so maybe this isn't a concern to anyone but me. > > http://www.ietf.org/mail-archive/web/tcpm/current/msg04001.html > http://tools.ietf.org/html/draft-ietf-tcpm-tcp-auth-opt-04#section-11.2 > > We could create TCP-AObis, I suppose, which works over NAT > and NAPT. NAT traversal is addressed in the document. Direct support was rejected because the functions of a NAT are the kind of attack TCP-AO, like IPsec, is designed to detect. I want to stress that once TCP-AO is complete, there are NO plans for a - -bis. This is intended to be an upgrade to TCP MD5, used largely where TCP MD5 is used. Protection across NATs is already supportable using UDP tunnels, as is done with IPsec. However, note that UDP tunnels through a NAT still force a single IPsec association to be treated as a unit. Multiple TCP connections treated differently wouldn't work with existing UDP tunneling solutions, e.g., for IPsec. Joe >> -----Original Message----- >> From: multipathtcp-bounces@ietf.org >> [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Joe Touch >> Sent: Friday, April 03, 2009 11:07 AM >> To: Iljitsch van Beijnum >> Cc: multipathtcp@ietf.org >> Subject: Re: [multipathtcp] [Fwd: Re: multipath tcp disucssion] >> > > > Iljitsch van Beijnum wrote: >>>> On 2 apr 2009, at 22:28, Joe Touch wrote: >>>> > ... >>>>>>> TCP MD5 can be used for more than BGP, and TCP-AO (its > replacement) can >>>>>>> as well. >>>>>> That doesn't make sense, both TLS and IPsec are superior. >>>>> Please check our doc. TLS does not protect a TCP connection from >>>>> TCP-level attacks, e.g., RSTs. IPsec cannot be forced to > use new keys on >>>>> new connections (i.e., upon receipt of a RST, destroy the > SA). TCP-AO >>>>> does both of these (TCP MD5 only the former), and is much > simpler than >>>>> IPsec (which is why it is preferred for BGP). >>>> I would have preferred to see the effort in this area spent > on making >>>> IPsec more usable in this scenario. IPsec has an anti-replay counter >>>> that is sorely missed in the TCP MD5 scenario. > It would be useful to look at TCP-AO, which deprecates TCP MD5. TCP-AO > includes a sequence number extension to protect against > replay attacks. > >>>>> If they subflows use different ports, then TCP MD5 would > think they are >>>>> different connections. So the answer depends on what the > lower layer >>>>> sees. >>>> I would assume that TCP MD5 is enabled in the TCP control > block, not on >>>> an address/port number basis. So any segment that is part > of the session >>>> will have the MD5 applied, regardless of the addresses that > are in the >>>> packet. > TCP MD5 does not specify how it is enabled. TCP-AO addresses this by > specifying protection on a socket pair basis - exactly because that is > what uniquely defines a TCP connection. > > The TCB is an implementation suggestion in RFC793, not a protocol > requirement. > >>>>>>> at which point the app >>>>>>> can/should be doing the multiplexing onto the different > TCP streams. >>>>>>> That works, but needs zero support from TCP >>>>>> The trouble here is that the application must now split > the data into >>>>>> multiple byte streams. For some stuff that's not a huge > problem (file >>>>>> transfer like BitTorrent) but even in those cases it's not very >>>>>> flexible: once a piece of data is commited to a path, only an >>>>>> application level timeout or a failure allows for it to > be rerouted over >>>>>> a different path. The transport layer can do this at RTT > timescales >>>>>> without much extra overhead. >>>>> It can be done inbetween the app and transport, i.e., > inside the socket >>>>> buffers too. I.e., it can be done in a layer above TCP but > below the >>>>> app, if isolation from the app is needed. That's partly > done by things >>>>> like HTTP persistent connections with chunked responses. >>>> You would need to add sequence numbers so the data can be > put back in >>>> the right order at the receiving end. > Agreed. Seems like that's required anyway, though - once you spread a > single stream's data over multiple connections. > >>>>>>> Does the network know these connections are related? >>>>>> Does the network have a notion of connections in the first place? >>>>> Yes. In places I've noted, at least: >>>>> network layer in the end host or BITW: IPsec >>>>> NATs >>>>> multipath routing based on flow preservation >>>>> firewall filtering >>>>> when ICMPs are issued (in the network or at the dest host) >>>> Today a single session is a single flow. If a session has multiple >>>> flows, does this mean that middleboxes etc recognize those > (sub)flows as >>>> belonging to the same session, or can they simply treat them as >>>> different flows? > That depends on the fate sharing you require between the flows. Do you > expect them to go to the same place? Have a set of > ports/addresses that > both sides know are related? All get through or none? Any fate sharing > is impacted by these boxes. > >>>> The latter is easier to support and would be sufficient >>>> in most cases, IMO. The IPsec case is an example of where > we'd want to >>>> be able to recognize sessions rather than subflows, though. > Load balancers that send flows to different servers too. > Firewalls that > permit some and deny others maybe as well. This all needs to be worked > out - and I'm not sure there *is* a solution to most of it... > >>>>>> Disagree. Per RFC 793, it's completely normal behavior > for the network >>>>>> to send some packets over one path and some over another > path. Having >>>>>> the TCP sender tell the network which packets to send > over which path is >>>>>> an important optimization because now it's possible to > run congestion >>>>>> control instances for each path, so TCP can adapt to the path >>>>>> properties. This is all firmly within the bounds of > layers 3 and 4 and >>>>>> outside the scope of higher layers. >>>>> I said socket pair, not path. >>>> Ok, I missed that. Do you have a pointer to something that > explains what >>>> those are and how they're used? > RFC793, page 5: > To allow for many processes within a single Host to use TCP > communication facilities simultaneously, the TCP provides a set of > addresses or ports within each host. Concatenated with > the network > and host addresses from the internet communication layer, > this forms > a socket. A pair of sockets uniquely identifies each connection. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > That is, a socket may be simultaneously used in multiple > connections. > >>>> As far as I know, hosts work with sockets and control blocks. Those >>>> obviously relate to the addresses and port numbers, but > within a host >>>> it's the socket or TCP control block that identifies a session. > A socket is defined in RFC793 as an address/port pair. That's not > necessarily how people use the term in implementations. The TCB is > introduced in RFC793 as an implementation term. You need to work with > the semantics of a *connection*, which is what TCP is all about. > >>>>>> Once additional addresses enter the picture, this is > arguably no longer >>>>>> the case, but NATs, different types of tunnels, MIP, shim6 etc set >>>>>> precedents here long ago: applications can't expect to > know all the >>>>>> details of the addresses used in their communication. >>>>> They do expect that a single socket pair corresponds to a single >>>>> connection - no more, no less. NATs, etc. preserve this. > Anything that >>>>> violates this breaks TCP. >>>> A multiaddress multipath TCP would certainly extend the existing TCP >>>> model, yes. > It is that which, AFAICT, needs development, and explanation as to > whether it is, or even can be, backwards compatible. > > IMO, if you end up with something that isn't, you probably > need to show > benefit over SCTP (which already exists). > > Joe _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp >> > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknWXF8ACgkQE5f5cImnZrt5NACgjZt1NzSANTyEUl1M/xzwLaPW OKQAoN2kqUelqEIGdE1+tigyn4htXuvz =wAXf -----END PGP SIGNATURE----- From dwing@cisco.com Fri Apr 3 12:21:58 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E6C13A686D for ; Fri, 3 Apr 2009 12:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.301 X-Spam-Level: X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+iqjJZa6Lia for ; Fri, 3 Apr 2009 12:21:57 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3D0BE3A67FF for ; Fri, 3 Apr 2009 12:21:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,320,1235952000"; d="scan'208";a="166400657" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 03 Apr 2009 19:23:00 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n33JN0O4009092; Fri, 3 Apr 2009 12:23:00 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n33JN0pO013902; Fri, 3 Apr 2009 19:23:00 GMT From: "Dan Wing" To: "'Joe Touch'" References: <49D3B6FA.4090504@it.uc3m.es><6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com><49D4F9B7.40309@isi.edu><49D51FF0.8010600@isi.edu> <49D65046.7030004@isi.edu> <0c5101c9b489$79397e20$c4f0200a@cisco.com> <49D65C5F.5050908@isi.edu> Date: Fri, 3 Apr 2009 12:22:59 -0700 Message-ID: <0c9e01c9b491$99dc9ec0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <49D65C5F.5050908@isi.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm0jla3YWC/CbLXTEyz3q+hcxigIgAAwYXA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9988; t=1238786580; x=1239650580; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[multipathtcp]=20TCP-AO=20with=20NAT=20 [was=20RE=3A=20[Fwd=3A=20Re=3A=20multipath=20tcp=20disucssio n]] |Sender:=20; bh=8zQ/wqrQr/7gE20m0X7m0u2UbLAOAjW5zjHHbWPEj4E=; b=a7lztA49TGmPUdwAkw1OZI1oMUGUP3ssUm8EBwFdA551qKCMbyWzbOC+f2 8vH86pmzbJaWDUuUktcbXOr0VdmXOUNgCw+vwSsB/n47lgPHOICVq/AK6cLU xW2vWUCTEI; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] TCP-AO with NAT [was RE: [Fwd: Re: multipath tcp disucssion]] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 19:21:58 -0000 > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Friday, April 03, 2009 11:59 AM > To: Dan Wing > Cc: multipathtcp@ietf.org > Subject: Re: [multipathtcp] TCP-AO with NAT [was RE: [Fwd: > Re: multipath tcp disucssion]] > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Dan Wing wrote: > > Un-mentioned in this thread is that TCP-AO does not work across > > a NAT. Reviewing Iljitsch's slides they don't show a NAT or > > NAT64 so maybe this isn't a concern to anyone but me. > > > > http://www.ietf.org/mail-archive/web/tcpm/current/msg04001.html > > > http://tools.ietf.org/html/draft-ietf-tcpm-tcp-auth-opt-04#sec > tion-11.2 > > > > We could create TCP-AObis, I suppose, which works over NAT > > and NAPT. > > NAT traversal is addressed in the document. Direct support > was rejected > because the functions of a NAT are the kind of attack TCP-AO, like > IPsec, is designed to detect. > > I want to stress that once TCP-AO is complete, there are NO > plans for a > - -bis. This is intended to be an upgrade to TCP MD5, used > largely where > TCP MD5 is used. Protection across NATs is already > supportable using UDP tunnels, as is done with IPsec. Yes, that is well explained in Section 11.2 of the document which I cited in my email. I didn't intend to ruffle feathers but rather intended to make sure everyone is well aware that TCP-AO cannot natively survive across a NAT. > However, note that UDP tunnels through a NAT still force a > single IPsec association to be treated as a unit. Multiple TCP > connections treated differently wouldn't work with existing UDP > tunneling solutions, e.g., for IPsec. I don't follow your last paragraph. -d > Joe > > > > >> -----Original Message----- > >> From: multipathtcp-bounces@ietf.org > >> [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Joe Touch > >> Sent: Friday, April 03, 2009 11:07 AM > >> To: Iljitsch van Beijnum > >> Cc: multipathtcp@ietf.org > >> Subject: Re: [multipathtcp] [Fwd: Re: multipath tcp disucssion] > >> > > > > > > Iljitsch van Beijnum wrote: > >>>> On 2 apr 2009, at 22:28, Joe Touch wrote: > >>>> > > ... > >>>>>>> TCP MD5 can be used for more than BGP, and TCP-AO (its > > replacement) can > >>>>>>> as well. > >>>>>> That doesn't make sense, both TLS and IPsec are superior. > >>>>> Please check our doc. TLS does not protect a TCP connection from > >>>>> TCP-level attacks, e.g., RSTs. IPsec cannot be forced to > > use new keys on > >>>>> new connections (i.e., upon receipt of a RST, destroy the > > SA). TCP-AO > >>>>> does both of these (TCP MD5 only the former), and is much > > simpler than > >>>>> IPsec (which is why it is preferred for BGP). > >>>> I would have preferred to see the effort in this area spent > > on making > >>>> IPsec more usable in this scenario. IPsec has an > anti-replay counter > >>>> that is sorely missed in the TCP MD5 scenario. > > It would be useful to look at TCP-AO, which deprecates TCP > MD5. TCP-AO > > includes a sequence number extension to protect against > > replay attacks. > > > >>>>> If they subflows use different ports, then TCP MD5 would > > think they are > >>>>> different connections. So the answer depends on what the > > lower layer > >>>>> sees. > >>>> I would assume that TCP MD5 is enabled in the TCP control > > block, not on > >>>> an address/port number basis. So any segment that is part > > of the session > >>>> will have the MD5 applied, regardless of the addresses that > > are in the > >>>> packet. > > TCP MD5 does not specify how it is enabled. TCP-AO addresses this by > > specifying protection on a socket pair basis - exactly > because that is > > what uniquely defines a TCP connection. > > > > The TCB is an implementation suggestion in RFC793, not a protocol > > requirement. > > > >>>>>>> at which point the app > >>>>>>> can/should be doing the multiplexing onto the different > > TCP streams. > >>>>>>> That works, but needs zero support from TCP > >>>>>> The trouble here is that the application must now split > > the data into > >>>>>> multiple byte streams. For some stuff that's not a huge > > problem (file > >>>>>> transfer like BitTorrent) but even in those cases it's not very > >>>>>> flexible: once a piece of data is commited to a path, only an > >>>>>> application level timeout or a failure allows for it to > > be rerouted over > >>>>>> a different path. The transport layer can do this at RTT > > timescales > >>>>>> without much extra overhead. > >>>>> It can be done inbetween the app and transport, i.e., > > inside the socket > >>>>> buffers too. I.e., it can be done in a layer above TCP but > > below the > >>>>> app, if isolation from the app is needed. That's partly > > done by things > >>>>> like HTTP persistent connections with chunked responses. > >>>> You would need to add sequence numbers so the data can be > > put back in > >>>> the right order at the receiving end. > > Agreed. Seems like that's required anyway, though - once > you spread a > > single stream's data over multiple connections. > > > >>>>>>> Does the network know these connections are related? > >>>>>> Does the network have a notion of connections in the > first place? > >>>>> Yes. In places I've noted, at least: > >>>>> network layer in the end host or BITW: IPsec > >>>>> NATs > >>>>> multipath routing based on flow preservation > >>>>> firewall filtering > >>>>> when ICMPs are issued (in the network or at the dest host) > >>>> Today a single session is a single flow. If a session > has multiple > >>>> flows, does this mean that middleboxes etc recognize those > > (sub)flows as > >>>> belonging to the same session, or can they simply treat them as > >>>> different flows? > > That depends on the fate sharing you require between the > flows. Do you > > expect them to go to the same place? Have a set of > > ports/addresses that > > both sides know are related? All get through or none? Any > fate sharing > > is impacted by these boxes. > > > >>>> The latter is easier to support and would be sufficient > >>>> in most cases, IMO. The IPsec case is an example of where > > we'd want to > >>>> be able to recognize sessions rather than subflows, though. > > Load balancers that send flows to different servers too. > > Firewalls that > > permit some and deny others maybe as well. This all needs > to be worked > > out - and I'm not sure there *is* a solution to most of it... > > > >>>>>> Disagree. Per RFC 793, it's completely normal behavior > > for the network > >>>>>> to send some packets over one path and some over another > > path. Having > >>>>>> the TCP sender tell the network which packets to send > > over which path is > >>>>>> an important optimization because now it's possible to > > run congestion > >>>>>> control instances for each path, so TCP can adapt to the path > >>>>>> properties. This is all firmly within the bounds of > > layers 3 and 4 and > >>>>>> outside the scope of higher layers. > >>>>> I said socket pair, not path. > >>>> Ok, I missed that. Do you have a pointer to something that > > explains what > >>>> those are and how they're used? > > RFC793, page 5: > > To allow for many processes within a single Host to use TCP > > communication facilities simultaneously, the TCP > provides a set of > > addresses or ports within each host. Concatenated with > > the network > > and host addresses from the internet communication layer, > > this forms > > a socket. A pair of sockets uniquely identifies each > connection. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > That is, a socket may be simultaneously used in multiple > > connections. > > > >>>> As far as I know, hosts work with sockets and control > blocks. Those > >>>> obviously relate to the addresses and port numbers, but > > within a host > >>>> it's the socket or TCP control block that identifies a session. > > A socket is defined in RFC793 as an address/port pair. That's not > > necessarily how people use the term in implementations. The TCB is > > introduced in RFC793 as an implementation term. You need to > work with > > the semantics of a *connection*, which is what TCP is all about. > > > >>>>>> Once additional addresses enter the picture, this is > > arguably no longer > >>>>>> the case, but NATs, different types of tunnels, MIP, > shim6 etc set > >>>>>> precedents here long ago: applications can't expect to > > know all the > >>>>>> details of the addresses used in their communication. > >>>>> They do expect that a single socket pair corresponds to a single > >>>>> connection - no more, no less. NATs, etc. preserve this. > > Anything that > >>>>> violates this breaks TCP. > >>>> A multiaddress multipath TCP would certainly extend the > existing TCP > >>>> model, yes. > > It is that which, AFAICT, needs development, and explanation as to > > whether it is, or even can be, backwards compatible. > > > > IMO, if you end up with something that isn't, you probably > > need to show > > benefit over SCTP (which already exists). > > > > Joe > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > >> > > > _______________________________________________ > > multipathtcp mailing list > > multipathtcp@ietf.org > > https://www.ietf.org/mailman/listinfo/multipathtcp > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAknWXF8ACgkQE5f5cImnZrt5NACgjZt1NzSANTyEUl1M/xzwLaPW > OKQAoN2kqUelqEIGdE1+tigyn4htXuvz > =wAXf > -----END PGP SIGNATURE----- From touch@ISI.EDU Fri Apr 3 15:40:31 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D9C53A657C for ; Fri, 3 Apr 2009 15:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQS5UW4xZrlE for ; Fri, 3 Apr 2009 15:40:30 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 549BE3A67EC for ; Fri, 3 Apr 2009 15:40:30 -0700 (PDT) Received: from [192.168.1.44] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n33MfFIW022644; Fri, 3 Apr 2009 15:41:20 -0700 (PDT) Message-ID: <49D6908A.5040500@isi.edu> Date: Fri, 03 Apr 2009 15:41:14 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dan Wing References: <49D3B6FA.4090504@it.uc3m.es><6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com><49D4F9B7.40309@isi.edu><49D51FF0.8010600@isi.edu> <49D65046.7030004@isi.edu> <0c5101c9b489$79397e20$c4f0200a@cisco.com> <49D65C5F.5050908@isi.edu> <0c9e01c9b491$99dc9ec0$c4f0200a@cisco.com> In-Reply-To: <0c9e01c9b491$99dc9ec0$c4f0200a@cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] TCP-AO with NAT [was RE: [Fwd: Re: multipath tcp disucssion]] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 22:40:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Wing wrote: >> I didn't intend to ruffle feathers but rather intended to make sure >> everyone is well aware that TCP-AO cannot natively survive across a NAT. TCPM discussed whether we wanted to support NAT traversal inside TCP-AO, or whether we would assume a UDP tunnel would be needed as is done with IPsec. We chose the latter exactly because we wanted to retain the correlation between the socket pair understood by the endpoints and the TCP connection - i.e., one of the points of concern I've raised with multi-TCP. In TCP-AO, the session protection information (i.e., keying material, protection parameters) is determined by the socket pair, where one of multiple keys/algorithms is selected by the keyID field. To support NAT traversal, we realized we would need to have the endpoints establish separate unique connection identifiers, and that would exceed TCP semantics. TCP-AO is intended to protect TCP connections, not to redefine them. That's why we decided as we did regarding NAT traversal. > However, note that UDP tunnels through a NAT still force a > single IPsec association to be treated as a unit. Multiple TCP > connections treated differently wouldn't work with existing UDP > tunneling solutions, e.g., for IPsec. > >> I don't follow your last paragraph. Running a single TCP connection through a single UDP tunnel results in a 1:1 correspondence between the connection and the tunnel. If multiple TCP connections are intended to behave as a unit, they would need to sent through a single UDP tunnel to have a similar effect - otherwise, a NAT could end up causing the different TCP connections to be handled differently at the receiving side - e.g., at a load balancer, they might be directed different places. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknWkIoACgkQE5f5cImnZrsYNACgtF/DVChiVxgVynrpAamgz8SM wB0An1zdYk7pB0MDxs78LPQHNiEWs5aO =D9zx -----END PGP SIGNATURE----- From dwing@cisco.com Fri Apr 3 15:48:14 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 503283A6912 for ; Fri, 3 Apr 2009 15:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.313 X-Spam-Level: X-Spam-Status: No, score=-6.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1OCfekwIIZr for ; Fri, 3 Apr 2009 15:48:13 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4A8AB3A67EC for ; Fri, 3 Apr 2009 15:47:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,321,1235952000"; d="scan'208";a="166500823" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 03 Apr 2009 22:48:59 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n33MmxQO018903; Fri, 3 Apr 2009 15:48:59 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n33Mmx1b018594; Fri, 3 Apr 2009 22:48:59 GMT From: "Dan Wing" To: "'Joe Touch'" References: <49D3B6FA.4090504@it.uc3m.es><6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com><49D4F9B7.40309@isi.edu><49D51FF0.8010600@isi.edu> <49D65046.7030004@isi.edu> <0c5101c9b489$79397e20$c4f0200a@cisco.com> <49D65C5F.5050908@isi.edu> <0c9e01c9b491$99dc9ec0$c4f0200a@cisco.com> <49D6908A.5040500@isi.edu> Date: Fri, 3 Apr 2009 15:48:59 -0700 Message-ID: <0d8401c9b4ae$60997a30$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <49D6908A.5040500@isi.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm0rVZ6dKcYajVJRzqdt9ctkKpYcwAAEvQQ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2610; t=1238798939; x=1239662939; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[multipathtcp]=20TCP-AO=20with=20NAT=20 [was=20RE=3A=20[Fwd=3A=20Re=3A=20multipath=20tcp=20disucssio n]] |Sender:=20; bh=EV3iOE7fUQ5wFWU96mHY26nlfbHkiwmCPgAqe2pO1vs=; b=Ha6u5rZVcqgMpMCvEDNmxjdA398HRcROHDqmxY/h1yFJp6O6tEMd+/FuF6 yTjPSB2k+43X7ja4fINpehQNX+ew0HJKd+kFPOslboHHD9k99/y5K4yuGV6i Kbmv61e22B; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] TCP-AO with NAT [was RE: [Fwd: Re: multipath tcp disucssion]] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 22:48:14 -0000 > Dan Wing wrote: > >> I didn't intend to ruffle feathers but rather intended to make sure > >> everyone is well aware that TCP-AO cannot natively survive > >> across a NAT. > > TCPM discussed whether we wanted to support NAT traversal > inside TCP-AO, > or whether we would assume a UDP tunnel would be needed as is > done with > IPsec. We chose the latter exactly because we wanted to retain the > correlation between the socket pair understood by the > endpoints and the > TCP connection - i.e., one of the points of concern I've raised with > multi-TCP. > > In TCP-AO, the session protection information (i.e., keying material, > protection parameters) is determined by the socket pair, where one of > multiple keys/algorithms is selected by the keyID field. To > support NAT > traversal, we realized we would need to have the endpoints establish > separate unique connection identifiers, and that would exceed TCP > semantics. TCP-AO is intended to protect TCP connections, not to > redefine them. That's why we decided as we did regarding NAT > traversal. Yes. I was involved with those threads. I remember. I am not attempting to revisit that decision. > > However, note that UDP tunnels through a NAT still force a > > single IPsec association to be treated as a unit. Multiple TCP > > connections treated differently wouldn't work with existing UDP > > tunneling solutions, e.g., for IPsec. > > > >> I don't follow your last paragraph. > > Running a single TCP connection through a single UDP tunnel > results in a 1:1 correspondence between the connection and the > tunnel. > > If multiple TCP connections are intended to behave as a unit, > they would > need to sent through a single UDP tunnel to have a similar effect - > otherwise, a NAT could end up causing the different TCP connections to > be handled differently at the receiving side - e.g., at a > load balancer, > they might be directed different places. Thanks for explaining. If I undestand correctly, you're saying that if TCP multipath wanted to traverse a NAT and TCP multipath used TCP-AO, then TCP multipath would need to use the same UDP tunnel for both of the TCP paths. If my understanding is correct, then that means the same NAT would have to be traversed for both TCP paths. -d > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAknWkIoACgkQE5f5cImnZrsYNACgtF/DVChiVxgVynrpAamgz8SM > wB0An1zdYk7pB0MDxs78LPQHNiEWs5aO > =D9zx > -----END PGP SIGNATURE----- From touch@ISI.EDU Fri Apr 3 15:54:43 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B05DA3A684B for ; Fri, 3 Apr 2009 15:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaeP39vNlV0K for ; Fri, 3 Apr 2009 15:54:42 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id BFA7D3A6810 for ; Fri, 3 Apr 2009 15:54:42 -0700 (PDT) Received: from [192.168.1.44] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n33Mt2Xa025261; Fri, 3 Apr 2009 15:55:08 -0700 (PDT) Message-ID: <49D693C6.20705@isi.edu> Date: Fri, 03 Apr 2009 15:55:02 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dan Wing References: <49D3B6FA.4090504@it.uc3m.es><6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com><49D4F9B7.40309@isi.edu><49D51FF0.8010600@isi.edu> <49D65046.7030004@isi.edu> <0c5101c9b489$79397e20$c4f0200a@cisco.com> <49D65C5F.5050908@isi.edu> <0c9e01c9b491$99dc9ec0$c4f0200a@cisco.com> <49D6908A.5040500@isi.edu> <0d8401c9b4ae$60997a30$c4f0200a@cisco.com> In-Reply-To: <0d8401c9b4ae$60997a30$c4f0200a@cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] TCP-AO with NAT [was RE: [Fwd: Re: multipath tcp disucssion]] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 22:54:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Wing wrote: >> Dan Wing wrote: >>>> I didn't intend to ruffle feathers but rather intended to make sure >>>> everyone is well aware that TCP-AO cannot natively survive >>>> across a NAT. >> TCPM discussed whether we wanted to support NAT traversal >> inside TCP-AO, >> or whether we would assume a UDP tunnel would be needed as is >> done with >> IPsec. We chose the latter exactly because we wanted to retain the >> correlation between the socket pair understood by the >> endpoints and the >> TCP connection - i.e., one of the points of concern I've raised with >> multi-TCP. >> >> In TCP-AO, the session protection information (i.e., keying material, >> protection parameters) is determined by the socket pair, where one of >> multiple keys/algorithms is selected by the keyID field. To >> support NAT >> traversal, we realized we would need to have the endpoints establish >> separate unique connection identifiers, and that would exceed TCP >> semantics. TCP-AO is intended to protect TCP connections, not to >> redefine them. That's why we decided as we did regarding NAT >> traversal. > > Yes. I was involved with those threads. I remember. > > I am not attempting to revisit that decision. > >>> However, note that UDP tunnels through a NAT still force a >>> single IPsec association to be treated as a unit. Multiple TCP >>> connections treated differently wouldn't work with existing UDP >>> tunneling solutions, e.g., for IPsec. >>> >>>> I don't follow your last paragraph. >> Running a single TCP connection through a single UDP tunnel >> results in a 1:1 correspondence between the connection and the >> tunnel. >> >> If multiple TCP connections are intended to behave as a unit, >> they would >> need to sent through a single UDP tunnel to have a similar effect - >> otherwise, a NAT could end up causing the different TCP connections to >> be handled differently at the receiving side - e.g., at a >> load balancer, >> they might be directed different places. > > Thanks for explaining. > > If I undestand correctly, you're saying that if TCP multipath wanted to > traverse a NAT and TCP multipath used TCP-AO, then TCP multipath would need to > use the same UDP tunnel for both of the TCP paths. If TCP multipath wanted to traverse a NAT and used TCP-AO, then each TCP-AO connection would be UDP tunneled. Whether that implies a single TCP-AO or not depends on how TCP multipath works. Note that I raised numerous issues: NAT, security, firewalls, etc. It'd be useful to address how TCP multipath interacts with each. Some combinations are also useful to address, but not necessarily all. > If my understanding is > correct, then that means the same NAT would have to be traversed for both TCP > paths. That's a question for TCP multipath to answer - is that what you expect, or not? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknWk8YACgkQE5f5cImnZrvW/QCeO53HTg76b1K5d0Iun3aGPQ+/ ZJQAoNDuED6bzzAH8BxxEsT1yx62QON+ =BhVW -----END PGP SIGNATURE----- From dwing@cisco.com Fri Apr 3 16:08:52 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3ED83A6A7C for ; Fri, 3 Apr 2009 16:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.316 X-Spam-Level: X-Spam-Status: No, score=-6.316 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTBE+kWheqmo for ; Fri, 3 Apr 2009 16:08:52 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id EC00B3A6912 for ; Fri, 3 Apr 2009 16:08:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,321,1235952000"; d="scan'208";a="150228360" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 03 Apr 2009 23:09:55 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n33N9tCu026637; Fri, 3 Apr 2009 16:09:55 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n33N9paA010520; Fri, 3 Apr 2009 23:09:52 GMT From: "Dan Wing" To: "'Joe Touch'" References: <49D3B6FA.4090504@it.uc3m.es><6D146EDE-8E35-4E1A-A213-CB5B8807CA97@muada.com><49D4F9B7.40309@isi.edu><49D51FF0.8010600@isi.edu> <49D65046.7030004@isi.edu> <0c5101c9b489$79397e20$c4f0200a@cisco.com> <49D65C5F.5050908@isi.edu> <0c9e01c9b491$99dc9ec0$c4f0200a@cisco.com> <49D6908A.5040500@isi.edu> <0d8401c9b4ae$60997a30$c4f0200a@cisco.com> <49D693C6.20705@isi.edu> Date: Fri, 3 Apr 2009 16:09:51 -0700 Message-ID: <0da001c9b4b1$4b2f9370$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <49D693C6.20705@isi.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm0r1Lo4BCkkN8lQva8SHgSRlG+qQAARshw DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3662; t=1238800195; x=1239664195; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[multipathtcp]=20TCP-AO=20with=20NAT=20 [was=20RE=3A=20[Fwd=3A=20Re=3A=20multipath=20tcp=20disucssio n]] |Sender:=20; bh=v+Kz1uidCyQyIRZhkhhII8g1N82f2HQl8h5Md+WueQA=; b=IMaEI5Jd9CEC+Q6rknRLAG+dP1x8geUBhiNHzBKzzPWym7MC0ADap1dzC5 x99V76bKWeHBmTxcXyWPXXNLbi7UzQViyP8DrzjoBdeP3OuKEUhw2KHuR4Ku O8a68RYtUA; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] TCP-AO with NAT [was RE: [Fwd: Re: multipath tcp disucssion]] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 23:08:52 -0000 > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Friday, April 03, 2009 3:55 PM > To: Dan Wing > Cc: multipathtcp@ietf.org > Subject: Re: [multipathtcp] TCP-AO with NAT [was RE: [Fwd: > Re: multipath tcp disucssion]] > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Dan Wing wrote: > >> Dan Wing wrote: > >>>> I didn't intend to ruffle feathers but rather intended > to make sure > >>>> everyone is well aware that TCP-AO cannot natively survive > >>>> across a NAT. > >> TCPM discussed whether we wanted to support NAT traversal > >> inside TCP-AO, > >> or whether we would assume a UDP tunnel would be needed as is > >> done with > >> IPsec. We chose the latter exactly because we wanted to retain the > >> correlation between the socket pair understood by the > >> endpoints and the > >> TCP connection - i.e., one of the points of concern I've > raised with > >> multi-TCP. > >> > >> In TCP-AO, the session protection information (i.e., > keying material, > >> protection parameters) is determined by the socket pair, > where one of > >> multiple keys/algorithms is selected by the keyID field. To > >> support NAT > >> traversal, we realized we would need to have the endpoints > establish > >> separate unique connection identifiers, and that would exceed TCP > >> semantics. TCP-AO is intended to protect TCP connections, not to > >> redefine them. That's why we decided as we did regarding NAT > >> traversal. > > > > Yes. I was involved with those threads. I remember. > > > > I am not attempting to revisit that decision. > > > >>> However, note that UDP tunnels through a NAT still force a > >>> single IPsec association to be treated as a unit. Multiple TCP > >>> connections treated differently wouldn't work with existing UDP > >>> tunneling solutions, e.g., for IPsec. > >>> > >>>> I don't follow your last paragraph. > >> Running a single TCP connection through a single UDP tunnel > >> results in a 1:1 correspondence between the connection and the > >> tunnel. > >> > >> If multiple TCP connections are intended to behave as a unit, > >> they would > >> need to sent through a single UDP tunnel to have a similar effect - > >> otherwise, a NAT could end up causing the different TCP > connections to > >> be handled differently at the receiving side - e.g., at a > >> load balancer, > >> they might be directed different places. > > > > Thanks for explaining. > > > > If I undestand correctly, you're saying that if TCP > multipath wanted to > > traverse a NAT and TCP multipath used TCP-AO, then TCP > multipath would need to > > use the same UDP tunnel for both of the TCP paths. > > If TCP multipath wanted to traverse a NAT and used TCP-AO, then each > TCP-AO connection would be UDP tunneled. Whether that implies a single > TCP-AO or not depends on how TCP multipath works. > > Note that I raised numerous issues: NAT, security, firewalls, > etc. It'd > be useful to address how TCP multipath interacts with each. Some > combinations are also useful to address, but not necessarily all. > > > If my understanding is > > correct, then that means the same NAT would have to be > traversed for both TCP > > paths. > > That's a question for TCP multipath to answer - is that what > you expect, or not? I expect each TCP multipath could go over a different NAT, as that would allow a host to connect to a WiFi access point (e.g., at a Starbucks) and an IPv6-only "4G"/"LTE" cellular connection that may traverse a NAT64 to connect to an IPv4 server. -d