From olivier.bonaventure@uclouvain.be Tue Jan 3 04:05:20 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AB021F850F for ; Tue, 3 Jan 2012 04:05:20 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-7v3lB0qgWb for ; Tue, 3 Jan 2012 04:05:20 -0800 (PST) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id E895A21F84D2 for ; Tue, 3 Jan 2012 04:05:19 -0800 (PST) Received: from mbpobo.dhcp.info.ucl.ac.be (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id B2A4811E675; Tue, 3 Jan 2012 13:05:13 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be B2A4811E675 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1325592313; bh=j7JmGXlmuRpuMPvJ3NC91ul8l0ADTVmI4OQ6s0Pf7Js=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=W5XZFP1tAwvlKPknifLME0p55aswbpeMq48lmRn9mrZQO6DYaXtfJqi+QKqnAZ9I4 GxGSwJIZDK+VnGaG6DMJBYxweEWgmlmgkP9OHbP7ilRwdh1tfXJ1B/k+V1lseJDCad kKRWDnvEnXzX+NGVc0NQ/kFTUhLO26hdJwcJskbg= Message-ID: <4F02EEDE.10000@uclouvain.be> Date: Tue, 03 Jan 2012 13:04:46 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Alan Ford References: <4EAE70AF.6030702@uclouvain.be> <4ED382C7.70900@gmail.com> <154773479ED2314980CB638A48FC443487F3FB9B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487F40031@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487FFD94F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC44348881C665@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE2C49.9060401@uclouvain.be> <154773479ED2314980CB638A48FC44348881CB8C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE7638.40300@uclouvain.be> <154773479ED2314980CB638A48FC44348881CBD8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <"4EDE80CD.5090 008"@uclouvain.be> <154773479ED2314980CB638A48FC44348881D368@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9C7E111C-40A1-4E24-B166-759A2A30D2A2@gmail.com> In-Reply-To: <9C7E111C-40A1-4E24-B166-759A2A30D2A2@gmail.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: B2A4811E675.A22D5 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 12:05:21 -0000 Alan, > > Apologies for the delay in catching up with these recent developments... > > A few thoughts: > > I don't particularly like the term MPTCP_RST or DATA_RST, since this is not a direct analogy to the TCP RST; rather, it is almost new functionality - a "fast close" mechanism, so it may be better termed DATA_CLOSE or similar. The name can be changed, no problem for me. > What is the reason for the reuse of the key in this context? Is there significant additional security? It shows that the segment containing the CLOSE option was generated by one of the endpoints (or at worse someone that saw the initial SYN exchange). Without this information, an attacker who sees segments on a WiFi interface could replay a modified segment to cause the entire MPTCP connection to be reset (and not only the WiFi segment). I think that adding some information to the segment that causes an entire MPTCP connection to be reset is important to avoid DoS attacks. > Do we really need it as a new option? Could we not just do it as an extra flag in the DSS? I thought that was the original proposal and I didn't see a rationale for a change. This would have the benefit that it requires no additional options, and could be included with data (it would seem unlikely to be able to fit an option with a key as well as a DSS option on a data packet). No, an extra flag in the DSS is not sufficient because an attacker could replay a DSS that it sees and change this bit to cause the entire MPTCP connection to be reset. We could reuse the MP_CAPABLE option with a reserved bit, but then firewalls would have to process this option in any segment. > In summary: I think the proposed mechanism below will cover most standard needs for this option, and any corner cases will be handled by normal session expiry. I think, however, that it should be implemented simply as a flag on the DSS option. Using the DSS introduces a risk of DoS attack. Consider a smartphone that uses 3G and WiFi and perhaps open MPTCP connections over 3G due to security. If DSS is used to close the MPTCP connection, then an attacker can observe a DSS on the WiFi interface and replay this DSS option to close the entire MPTCP connection. We should not allow this kind of attack with MPTCP. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From georg.hampel@alcatel-lucent.com Tue Jan 3 10:20:18 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51F05E800A for ; Tue, 3 Jan 2012 10:20:18 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUEarMarR8HP for ; Tue, 3 Jan 2012 10:20:17 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 0D09C5E8008 for ; Tue, 3 Jan 2012 10:20:13 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q03IJkdk004597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Jan 2012 12:20:07 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q03IJkLt010407 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 3 Jan 2012 12:19:46 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Tue, 3 Jan 2012 12:19:46 -0600 From: "Hampel, K Georg (K Georg)" To: "Olivier.Bonaventure@uclouvain.be" , Alan Ford Date: Tue, 3 Jan 2012 12:19:44 -0600 Thread-Topic: [multipathtcp] MPTCP connection termination Thread-Index: AczKD/dZYA2EWMkzTTirhSw4LVpZMAAMkJhA Message-ID: <154773479ED2314980CB638A48FC443488BC8EE6@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <4EAE70AF.6030702@uclouvain.be> <4ED382C7.70900@gmail.com> <154773479ED2314980CB638A48FC443487F3FB9B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487F40031@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487FFD94F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC44348881C665@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE2C49.9060401@uclouvain.be> <154773479ED2314980CB638A48FC44348881CB8C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE7638.40300@uclouvain.be> <154773479ED2314980CB638A48FC44348881CBD8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <"4EDE80CD.5090 008"@uclouvain.be> <154773479ED2314980CB638A48FC44348881D368@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9C7E111C-40A1-4E24-B166-759A2A30D2A2@gmail.com> <4F02EEDE.10000@uclouvain.be> In-Reply-To: <4F02EEDE.10000@uclouvain.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 18:20:18 -0000 Alan, To add to Olivier's DoS argument: MPTCP should not be more vulnerable to DoS than TCP. For TCP, a DoS princip= ally requires an on-path attacker. If multiple paths are supported (as in M= PTCP), the likelihood for an attacker to be on at least one of these paths = grows with the number of independent paths. The DoS therefore becomes easie= r unless you require that information pertaining to one specific path is in= serted into the RST message. Obviously, the initial key does this job since= it was exchanged on the initial path only. Happy New Year! Georg -----Original Message----- From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]=20 Sent: Tuesday, January 03, 2012 7:05 AM To: Alan Ford Cc: Hampel, K Georg (K Georg); multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination Alan, >=20 > Apologies for the delay in catching up with these recent developments... >=20 > A few thoughts: >=20 > I don't particularly like the term MPTCP_RST or DATA_RST, since this is n= ot a direct analogy to the TCP RST; rather, it is almost new functionality = - a "fast close" mechanism, so it may be better termed DATA_CLOSE or simila= r. The name can be changed, no problem for me. > What is the reason for the reuse of the key in this context? Is there sig= nificant additional security? It shows that the segment containing the CLOSE option was generated by one of the endpoints (or at worse someone that saw the initial SYN exchange). Without this information, an attacker who sees segments on a WiFi interface could replay a modified segment to cause the entire MPTCP connection to be reset (and not only the WiFi segment). I think that adding some information to the segment that causes an entire MPTCP connection to be reset is important to avoid DoS attacks. > Do we really need it as a new option? Could we not just do it as an extra= flag in the DSS? I thought that was the original proposal and I didn't see= a rationale for a change. This would have the benefit that it requires no = additional options, and could be included with data (it would seem unlikely= to be able to fit an option with a key as well as a DSS option on a data p= acket). No, an extra flag in the DSS is not sufficient because an attacker could replay a DSS that it sees and change this bit to cause the entire MPTCP connection to be reset. We could reuse the MP_CAPABLE option with a reserved bit, but then firewalls would have to process this option in any segment. > In summary: I think the proposed mechanism below will cover most standard= needs for this option, and any corner cases will be handled by normal sess= ion expiry. I think, however, that it should be implemented simply as a fla= g on the DSS option. Using the DSS introduces a risk of DoS attack. Consider a smartphone that uses 3G and WiFi and perhaps open MPTCP connections over 3G due to security. If DSS is used to close the MPTCP connection, then an attacker can observe a DSS on the WiFi interface and replay this DSS option to close the entire MPTCP connection. We should not allow this kind of attack with MPTCP. Olivier --=20 INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From internet-drafts@ietf.org Thu Jan 12 03:32:54 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A82A21F84DC; Thu, 12 Jan 2012 03:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8fABzsVkmYO; Thu, 12 Jan 2012 03:32:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3169021F84BF; Thu, 12 Jan 2012 03:32:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120112113236.14083.53103.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2012 03:32:36 -0800 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-05.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 11:32:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multipath TCP Working Group of the IE= TF. Title : TCP Extensions for Multipath Operation with Multiple Add= resses Author(s) : Alan Ford Costin Raiciu Mark Handley Olivier Bonaventure Filename : draft-ietf-mptcp-multiaddressed-05.txt Pages : 59 Date : 2012-01-12 TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network, and thus improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e. reliable bytestream), and provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-05.txt From c.raiciu@cs.ucl.ac.uk Thu Jan 12 03:39:30 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE5221F85D4 for ; Thu, 12 Jan 2012 03:39:30 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VMVsYqz3z5r for ; Thu, 12 Jan 2012 03:39:30 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by ietfa.amsl.com (Postfix) with ESMTP id E7D6921F85DB for ; Thu, 12 Jan 2012 03:39:29 -0800 (PST) Received: from [92.80.88.88] (helo=[192.168.1.8]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1RlIzS-000JWz-NJ for multipathtcp@ietf.org; Thu, 12 Jan 2012 11:38:42 +0000 From: Costin Raiciu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Jan 2012 13:39:21 +0200 Message-Id: <8DEDD48B-AA7B-4A90-99CE-1394B915621D@cs.ucl.ac.uk> To: "multipathtcp@ietf.org List" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [multipathtcp] MPTCP protocol draft revised X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 11:39:30 -0000 Hi all, We have revised the MPTCP protocol draft to include all the outstanding = issues that were ironed out during the MPTCP interim meeting. We have added nothing to the -05 draft regarding the intensely discussed = MPTCP RST functionality. We plan to do so until the Paris IETF cut-off.. Cheers, Costin From nishida@sfc.wide.ad.jp Tue Jan 17 03:31:23 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6611721F84BD for ; Tue, 17 Jan 2012 03:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.842 X-Spam-Level: X-Spam-Status: No, score=-97.842 tagged_above=-999 required=5 tests=[AWL=-2.381, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_51=0.6, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iJKlpTC6K9R for ; Tue, 17 Jan 2012 03:31:19 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 4E81D21F849B for ; Tue, 17 Jan 2012 03:31:19 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id F21B5278124 for ; Tue, 17 Jan 2012 20:31:15 +0900 (JST) Received: by lagv3 with SMTP id v3so2527758lag.31 for ; Tue, 17 Jan 2012 03:31:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.101.163 with SMTP id fh3mr3952134lbb.97.1326799871250; Tue, 17 Jan 2012 03:31:11 -0800 (PST) Received: by 10.112.84.10 with HTTP; Tue, 17 Jan 2012 03:31:11 -0800 (PST) Date: Tue, 17 Jan 2012 03:31:11 -0800 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] MPTCP abrupt connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 11:31:23 -0000 Hi folks, Although it's a bit quite these days, I personally believe we are getting close to finish this feature. I'm trying to create a simple summary of the current discussion items. please feel free to add and modify it. Also, I personally think the status of these items are followings 1: reach consensus 2: since procedure is fixed, we can just procced to create this 3: no disagreement (if we use option) 4: rather minor topic so easy to fix 5: let's decide quickly if there's no blocker 1: bacis procedure - Host A sends a regular TCP segment containing MPTCP_RST(B's key) on one subflow. It sends TCP RST segments on all other subflows and tears them down. - Upon reception of a regular TCP segment containing MPTCP_RST and its key, a host responds by sending a TCP RST segment on the same subflow and releases the entire MPTCP connection. - Host A tears down the MPTCP connection as soon as it receives a TCP segment containing MPTCP(A's key) or a RST segment on the remaining subflow. note 1: need to add retransmission timeout for MPTCP_RST 2: new state diagram for this 3: option format for MPTCP_RST http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01623.html 4: name for the option MPTCP_RST or DATA_RST might not be good? DATA_CLOSE? 5: using flag in DSS insted of option in case of DSS, we won't use KEY. Isn't it vulnerable? Thanks, -- Yoshifumi From georg.hampel@alcatel-lucent.com Tue Jan 17 11:40:43 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E0E11E809B for ; Tue, 17 Jan 2012 11:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.299 X-Spam-Level: X-Spam-Status: No, score=-8.299 tagged_above=-999 required=5 tests=[AWL=1.700, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVnJMUNYcsoE for ; Tue, 17 Jan 2012 11:40:42 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id E396E11E807F for ; Tue, 17 Jan 2012 11:40:41 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q0HJedCS022620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Jan 2012 13:40:39 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q0HJeX4t029705 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 17 Jan 2012 13:40:39 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 17 Jan 2012 13:40:33 -0600 From: "Hampel, K Georg (K Georg)" To: Yoshifumi Nishida , multipathtcp Date: Tue, 17 Jan 2012 13:40:32 -0600 Thread-Topic: [multipathtcp] MPTCP abrupt connection termination Thread-Index: AczVC4yNSH4YubFJSAuyFJlnMgPBRAAQYiTg Message-ID: <154773479ED2314980CB638A48FC443488CD455C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [multipathtcp] MPTCP abrupt connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 19:40:43 -0000 Hi Yoshifumi, On your points: 1. I'm fine with the basic procedure. The third bullet should perhaps menti= on that host A has to send a TCP RST in case it receives a MPTCP_RST. This = makes the third bullet compliant with the second bullet. 2. State diagram: I think we haven't converged on this issue yet. I once pr= oposed to introduce the RST_WAIT state.=20 - Host A transitions to RST_WAIT from any other state when it sends MPTCP_R= ST.=20 - Host B transitions to CLOSED from any other state when it receives MPTCP_= WAIT.=20 - Host A transitions to CLOSED from RST_WAIT when it receives TCP RST or MP= TCP_RST. The RST_WAIT state has a retransmission time out. If MPTCP_RST retransmissi= ons don't succeed within this time out, host A transitions to CLOSED. 3. I'm fine with Olivier's proposal on the MPTCP_RST packet format. 4. I don't have specific name preferences. However, I think it makes sense = to keep the term "RST" in the name since it builds on TCP RST and since it = doesn't represent a "proper" handshake. 5. I agree that just having DSS + flag is too vulnerable. I'd prefer the so= lution proposed under 3. Thanks. Georg -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Yoshifumi Nishida Sent: Tuesday, January 17, 2012 6:31 AM To: multipathtcp Subject: [multipathtcp] MPTCP abrupt connection termination Hi folks, Although it's a bit quite these days, I personally believe we are getting close to finish this feature. I'm trying to create a simple summary of the current discussion items. please feel free to add and modify it. Also, I personally think the status of these items are followings 1: reach consensus 2: since procedure is fixed, we can just procced to create this 3: no disagreement (if we use option) 4: rather minor topic so easy to fix 5: let's decide quickly if there's no blocker 1: bacis procedure - Host A sends a regular TCP segment containing MPTCP_RST(B's key) on one subflow. It sends TCP RST segments on all other subflows and tears them down. - Upon reception of a regular TCP segment containing MPTCP_RST and its key, a host responds by sending a TCP RST segment on the same subflow and releases the entire MPTCP connection. - Host A tears down the MPTCP connection as soon as it receives a TCP segment containing MPTCP(A's key) or a RST segment on the remaining subflow. note 1: need to add retransmission timeout for MPTCP_RST 2: new state diagram for this 3: option format for MPTCP_RST http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01623.html 4: name for the option MPTCP_RST or DATA_RST might not be good? DATA_CLOSE? 5: using flag in DSS insted of option in case of DSS, we won't use KEY. Isn't it vulnerable? Thanks, -- Yoshifumi _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From philip.eardley@bt.com Fri Jan 20 10:54:53 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52A221F8646 for ; Fri, 20 Jan 2012 10:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.793 X-Spam-Level: X-Spam-Status: No, score=-102.793 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpXh6iDY86xy for ; Fri, 20 Jan 2012 10:54:53 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id CE00221F8648 for ; Fri, 20 Jan 2012 10:54:52 -0800 (PST) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 20 Jan 2012 18:54:52 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.111]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Fri, 20 Jan 2012 18:54:51 +0000 From: To: , , Date: Fri, 20 Jan 2012 18:54:50 +0000 Thread-Topic: [multipathtcp] MPTCP abrupt connection termination Thread-Index: AczVC4yNSH4YubFJSAuyFJlnMgPBRAAQYiTgAJUzjvA= Message-ID: <9510D26531EF184D9017DF24659BB87F3316231BC5@EMV65-UKRD.domain1.systemhost.net> References: <154773479ED2314980CB638A48FC443488CD455C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC443488CD455C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [multipathtcp] MPTCP abrupt connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 18:54:54 -0000 Let me just clarify I understand. <<1: bacis procedure - Host A sends a regular TCP segment containing MPTCP_RST(B's key) on one subflow. It sends TCP RST segments on all other subflows and tears them down. - Upon reception of a regular TCP segment containing MPTCP_RST and its key, a host responds by sending a TCP RST segment on the same subflow and releases the entire MPTCP connection. >> [phil] TCP RST is an ordinary RST (at some earlier point there was discussi= on about this including the MPTCP-RST(A'skey) ; but this is not the proposa= l) [phil] is it required /recommended that A sends MPTCP_RST on exactly one su= bflow or can it send it on several? << - Host A tears down the MPTCP connection as soon as it receives a TCP segment containing MPTCP(A's key) or a RST segment on the remaining subflow. >> [phil] the second case is the normal one. the first case could occur if bot= h ends simulataneously send MPTCP-RST, is that right? Re 4, I think it would be good if the name included MPTCP, as there are ord= inary TCP msgs involved as well. The summarised position seems good to me - is everyone ok with it? then we = could finish this in the next couple of weeks? Thanks phil -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Hampel, K Georg (K Georg) Sent: 17 January 2012 19:41 To: Yoshifumi Nishida; multipathtcp Subject: Re: [multipathtcp] MPTCP abrupt connection termination Hi Yoshifumi, On your points: 1. I'm fine with the basic procedure. The third bullet should perhaps menti= on that host A has to send a TCP RST in case it receives a MPTCP_RST. This = makes the third bullet compliant with the second bullet. 2. State diagram: I think we haven't converged on this issue yet. I once pr= oposed to introduce the RST_WAIT state.=20 - Host A transitions to RST_WAIT from any other state when it sends MPTCP_R= ST.=20 - Host B transitions to CLOSED from any other state when it receives MPTCP_= WAIT.=20 - Host A transitions to CLOSED from RST_WAIT when it receives TCP RST or MP= TCP_RST. The RST_WAIT state has a retransmission time out. If MPTCP_RST retransmissi= ons don't succeed within this time out, host A transitions to CLOSED. 3. I'm fine with Olivier's proposal on the MPTCP_RST packet format. 4. I don't have specific name preferences. However, I think it makes sense = to keep the term "RST" in the name since it builds on TCP RST and since it = doesn't represent a "proper" handshake. 5. I agree that just having DSS + flag is too vulnerable. I'd prefer the so= lution proposed under 3. Thanks. Georg -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Yoshifumi Nishida Sent: Tuesday, January 17, 2012 6:31 AM To: multipathtcp Subject: [multipathtcp] MPTCP abrupt connection termination Hi folks, Although it's a bit quite these days, I personally believe we are getting close to finish this feature. I'm trying to create a simple summary of the current discussion items. please feel free to add and modify it. Also, I personally think the status of these items are followings 1: reach consensus 2: since procedure is fixed, we can just procced to create this 3: no disagreement (if we use option) 4: rather minor topic so easy to fix 5: let's decide quickly if there's no blocker 1: bacis procedure - Host A sends a regular TCP segment containing MPTCP_RST(B's key) on one subflow. It sends TCP RST segments on all other subflows and tears them down. - Upon reception of a regular TCP segment containing MPTCP_RST and its key, a host responds by sending a TCP RST segment on the same subflow and releases the entire MPTCP connection. - Host A tears down the MPTCP connection as soon as it receives a TCP segment containing MPTCP(A's key) or a RST segment on the remaining subflow. note 1: need to add retransmission timeout for MPTCP_RST 2: new state diagram for this 3: option format for MPTCP_RST http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01623.html 4: name for the option MPTCP_RST or DATA_RST might not be good? DATA_CLOSE? 5: using flag in DSS insted of option in case of DSS, we won't use KEY. Isn't it vulnerable? Thanks, -- Yoshifumi _______________________________________________ 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 From georg.hampel@alcatel-lucent.com Mon Jan 23 12:40:55 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9804821F8677 for ; Mon, 23 Jan 2012 12:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.149 X-Spam-Level: X-Spam-Status: No, score=-9.149 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgvL0T2F9TfY for ; Mon, 23 Jan 2012 12:40:54 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id C706921F8670 for ; Mon, 23 Jan 2012 12:40:54 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q0NKelwq021420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Jan 2012 14:40:47 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q0NKcKx5027146 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 23 Jan 2012 14:40:30 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Mon, 23 Jan 2012 14:39:50 -0600 From: "Hampel, K Georg (K Georg)" To: "philip.eardley@bt.com" , "nishida@sfc.wide.ad.jp" , "multipathtcp@ietf.org" Date: Mon, 23 Jan 2012 14:39:49 -0600 Thread-Topic: [multipathtcp] MPTCP abrupt connection termination Thread-Index: AczVC4yNSH4YubFJSAuyFJlnMgPBRAAQYiTgAJUzjvAAmsNhsA== Message-ID: <154773479ED2314980CB638A48FC443488D5289B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443488CD455C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F3316231BC5@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F3316231BC5@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [multipathtcp] MPTCP abrupt connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 20:40:55 -0000 Hi Phil, Comments inserted. Thanks. Georg -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Friday, January 20, 2012 1:55 PM To: Hampel, K Georg (K Georg); nishida@sfc.wide.ad.jp; multipathtcp@ietf.or= g Subject: RE: [multipathtcp] MPTCP abrupt connection termination Let me just clarify I understand. <<1: bacis procedure - Host A sends a regular TCP segment containing MPTCP_RST(B's key) on one subflow. It sends TCP RST segments on all other subflows and tears them down. - Upon reception of a regular TCP segment containing MPTCP_RST and its key, a host responds by sending a TCP RST segment on the same subflow and releases the entire MPTCP connection. >> [phil] TCP RST is an ordinary RST (at some earlier point there was discussi= on about this including the MPTCP-RST(A'skey) ; but this is not the proposa= l) [georg] Correct. TCP RST is an ordinary RST. [phil] is it required /recommended that A sends MPTCP_RST on exactly one su= bflow or can it send it on several? [georg] I originally proposed an extended version where A can send MPTCP_RS= T on any subset of subflows. That is possible but it makes the tear-down pr= ocedure a little more complicated.=20 - A sends MPTCP_RST on some subflows and TCP RST on all others. - B, upon reception of the first MPTCP_RST, sends TCP RSTs on all subflows = and shuts down. - A, upon arrival of at least one MPTCP_RST or TCP RSTs on all remaining su= bflows shuts down. Reliability: When no MPTCP_RST arrives, A retransmits MPTCP_RST on at least= one subflow and TCP RSTs on all remaining subflows. ML discussions with Olivier converged to the present simpler solution. << - Host A tears down the MPTCP connection as soon as it receives a TCP segment containing MPTCP(A's key) or a RST segment on the remaining subflow. >> [phil] the second case is the normal one. the first case could occur if bot= h ends simulataneously send MPTCP-RST, is that right? [georg] yes. Re 4, I think it would be good if the name included MPTCP, as there are ord= inary TCP msgs involved as well. The summarised position seems good to me - is everyone ok with it? then we = could finish this in the next couple of weeks? Thanks phil -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Hampel, K Georg (K Georg) Sent: 17 January 2012 19:41 To: Yoshifumi Nishida; multipathtcp Subject: Re: [multipathtcp] MPTCP abrupt connection termination Hi Yoshifumi, On your points: 1. I'm fine with the basic procedure. The third bullet should perhaps menti= on that host A has to send a TCP RST in case it receives a MPTCP_RST. This = makes the third bullet compliant with the second bullet. 2. State diagram: I think we haven't converged on this issue yet. I once pr= oposed to introduce the RST_WAIT state.=20 - Host A transitions to RST_WAIT from any other state when it sends MPTCP_R= ST.=20 - Host B transitions to CLOSED from any other state when it receives MPTCP_= WAIT.=20 - Host A transitions to CLOSED from RST_WAIT when it receives TCP RST or MP= TCP_RST. The RST_WAIT state has a retransmission time out. If MPTCP_RST retransmissi= ons don't succeed within this time out, host A transitions to CLOSED. 3. I'm fine with Olivier's proposal on the MPTCP_RST packet format. 4. I don't have specific name preferences. However, I think it makes sense = to keep the term "RST" in the name since it builds on TCP RST and since it = doesn't represent a "proper" handshake. 5. I agree that just having DSS + flag is too vulnerable. I'd prefer the so= lution proposed under 3. Thanks. Georg -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Yoshifumi Nishida Sent: Tuesday, January 17, 2012 6:31 AM To: multipathtcp Subject: [multipathtcp] MPTCP abrupt connection termination Hi folks, Although it's a bit quite these days, I personally believe we are getting close to finish this feature. I'm trying to create a simple summary of the current discussion items. please feel free to add and modify it. Also, I personally think the status of these items are followings 1: reach consensus 2: since procedure is fixed, we can just procced to create this 3: no disagreement (if we use option) 4: rather minor topic so easy to fix 5: let's decide quickly if there's no blocker 1: bacis procedure - Host A sends a regular TCP segment containing MPTCP_RST(B's key) on one subflow. It sends TCP RST segments on all other subflows and tears them down. - Upon reception of a regular TCP segment containing MPTCP_RST and its key, a host responds by sending a TCP RST segment on the same subflow and releases the entire MPTCP connection. - Host A tears down the MPTCP connection as soon as it receives a TCP segment containing MPTCP(A's key) or a RST segment on the remaining subflow. note 1: need to add retransmission timeout for MPTCP_RST 2: new state diagram for this 3: option format for MPTCP_RST http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01623.html 4: name for the option MPTCP_RST or DATA_RST might not be good? DATA_CLOSE? 5: using flag in DSS insted of option in case of DSS, we won't use KEY. Isn't it vulnerable? Thanks, -- Yoshifumi _______________________________________________ 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 From alan.ford@gmail.com Mon Jan 30 06:26:34 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F6221F8591 for ; Mon, 30 Jan 2012 06:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ehlPd9swlcK for ; Mon, 30 Jan 2012 06:26:33 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 51D3E21F858B for ; Mon, 30 Jan 2012 06:26:33 -0800 (PST) Received: by obbwc12 with SMTP id wc12so4851362obb.31 for ; Mon, 30 Jan 2012 06:26:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ceeni+8t8nrSyNtgk6i0285Rrm3HyAKlEi1owTSvITY=; b=KIXn3xSU3j/jeca5iVHS+g2phnEVbRk9gKyBkycahlRT1uOXQp3G1xQzX5SA9+mrSn lydEDMxb/xaMEFl1JjsmldD9goSC3M8Vwbx5BGzn/LkzMEfO8NH/8YUDhl9LdnjIEfq6 kuVaTRo44DHnipL7pz78aXvCoPTid0IAzcC8A= MIME-Version: 1.0 Received: by 10.182.41.36 with SMTP id c4mr7815494obl.21.1327933592894; Mon, 30 Jan 2012 06:26:32 -0800 (PST) Received: by 10.182.111.69 with HTTP; Mon, 30 Jan 2012 06:26:32 -0800 (PST) In-Reply-To: <154773479ED2314980CB638A48FC443488CD455C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443488CD455C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Date: Mon, 30 Jan 2012 14:26:32 +0000 Message-ID: From: Alan Ford To: "Hampel, K Georg (K Georg)" Content-Type: multipart/alternative; boundary=f46d0444ea1916fdb604b7bfa238 Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP abrupt connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 14:26:34 -0000 --f46d0444ea1916fdb604b7bfa238 Content-Type: text/plain; charset=ISO-8859-1 Hi Georg, all, My thoughts on this: 1. The procedure seems ok. I don't see much benefit/difference between this and doing the multiple-MPTCP_RST option that you mention in a later mail, so this is fine. The timeout should ensure a relatively clean finish. However, shouldn't B also send TCP RST on all other subflows on receipt of MPTCP_RST? 2. Your state machine description below seems fine (although require notes on transmitted packets on the transitions, too). 4. The name - I prefer "DATA_CLOSE" or "MPTCP_CLOSE" since I do not see this analogous to a TCP RST and instead see it as presenting a subset of TCP RST's (ab)uses. 3 and 5. Note that the use of the key makes the MPTCP_RST option up to 12 bytes long. This means we are unlikely to be able to fit a DSS option and the MPTCP_RST in the same packet. This is fine if the data in the last packet is already covered by a DSS option, but if not it would require a second packet just carrying MPTCP_RST. Although doing it by flag is open to replay attacks, is this really any worse than regular TCP? Regards, Alan On 17 January 2012 19:40, Hampel, K Georg (K Georg) < georg.hampel@alcatel-lucent.com> wrote: > Hi Yoshifumi, > > On your points: > > 1. I'm fine with the basic procedure. The third bullet should perhaps > mention that host A has to send a TCP RST in case it receives a MPTCP_RST. > This makes the third bullet compliant with the second bullet. > > 2. State diagram: I think we haven't converged on this issue yet. I once > proposed to introduce the RST_WAIT state. > - Host A transitions to RST_WAIT from any other state when it sends > MPTCP_RST. > - Host B transitions to CLOSED from any other state when it receives > MPTCP_WAIT. > - Host A transitions to CLOSED from RST_WAIT when it receives TCP RST or > MPTCP_RST. > > The RST_WAIT state has a retransmission time out. If MPTCP_RST > retransmissions don't succeed within this time out, host A transitions to > CLOSED. > > 3. I'm fine with Olivier's proposal on the MPTCP_RST packet format. > > 4. I don't have specific name preferences. However, I think it makes sense > to keep the term "RST" in the name since it builds on TCP RST and since it > doesn't represent a "proper" handshake. > > 5. I agree that just having DSS + flag is too vulnerable. I'd prefer the > solution proposed under 3. > > Thanks. > > Georg > > > > -----Original Message----- > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] > On Behalf Of Yoshifumi Nishida > Sent: Tuesday, January 17, 2012 6:31 AM > To: multipathtcp > Subject: [multipathtcp] MPTCP abrupt connection termination > > Hi folks, > Although it's a bit quite these days, I personally believe we are > getting close to finish this feature. > I'm trying to create a simple summary of the current discussion items. > please feel free to add and modify it. > > Also, I personally think the status of these items are followings > 1: reach consensus > 2: since procedure is fixed, we can just procced to create this > 3: no disagreement (if we use option) > 4: rather minor topic so easy to fix > 5: let's decide quickly if there's no blocker > > 1: bacis procedure > > - Host A sends a regular TCP segment containing MPTCP_RST(B's key) > on one subflow. It sends TCP RST segments on all other subflows and > tears them down. > > - Upon reception of a regular TCP segment containing MPTCP_RST and > its key, a host responds by sending a TCP RST segment on the same > subflow and releases the entire MPTCP connection. > > - Host A tears down the MPTCP connection as soon as it receives a > TCP segment containing MPTCP(A's key) or a RST segment on the > remaining subflow. > > note 1: need to add retransmission timeout for MPTCP_RST > > 2: new state diagram for this > > 3: option format for MPTCP_RST > http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01623.html > > 4: name for the option > MPTCP_RST or DATA_RST might not be good? > DATA_CLOSE? > > 5: using flag in DSS insted of option > in case of DSS, we won't use KEY. Isn't it vulnerable? > > > Thanks, > -- > Yoshifumi > _______________________________________________ > 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 > --f46d0444ea1916fdb604b7bfa238 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Georg, all,

My thoughts on this:

=
1. The procedure seems ok. I don't see much benefit/difference bet= ween this and doing the multiple-MPTCP_RST option that you mention in a lat= er mail, so this is fine. The timeout should ensure a relatively clean fini= sh.=A0

However, shouldn't B also send TCP RST on all other= subflows on receipt of MPTCP_RST?

2. Your state m= achine description below seems fine (although require notes on transmitted = packets on the transitions, too).

4. The name - I prefer "DATA_CLOSE" or "= MPTCP_CLOSE" since I do not see this analogous to a TCP RST and instea= d see it as presenting a subset of TCP RST's (ab)uses.

3 and 5. Note that the use of the key makes the MPTCP_RST option= up to 12 bytes long. This means we are unlikely to be able to fit a DSS op= tion and the MPTCP_RST in the same packet. This is fine if the data in the = last packet is already covered by a DSS option, but if not it would require= a second packet just carrying MPTCP_RST.

Although doing it by flag is open to replay attacks, is= this really any worse than regular TCP?

Regards,<= /div>
Alan


On 17 January 2= 012 19:40, Hampel, K Georg (K Georg) <georg.hampel@alcatel-lucent.com><= /span> wrote:
Hi Yoshifumi,

On your points:

1. I'm fine with the basic procedure. The third bullet should perhaps m= ention that host A has to send a TCP RST in case it receives a MPTCP_RST. T= his makes the third bullet compliant with the second bullet.

2. State diagram: I think we haven't converged on this issue yet. I onc= e proposed to introduce the RST_WAIT state.
- Host A transitions to RST_WAIT from any other state when it sends MPTCP_R= ST.
- Host B transitions to CLOSED from any other state when it receives MPTCP_= WAIT.
- Host A transitions to CLOSED from RST_WAIT when it receives TCP RST or MP= TCP_RST.

The RST_WAIT state has a retransmission time out. If MPTCP_RST retransmissi= ons don't succeed within this time out, host A transitions to CLOSED.
3. I'm fine with Olivier's proposal on the MPTCP_RST packet format.=

4. I don't have specific name preferences. However, I think it makes se= nse to keep the term "RST" in the name since it builds on TCP RST= and since it doesn't represent a "proper" handshake.

5. I agree that just having DSS + flag is too vulnerable. I'd prefer th= e solution proposed under 3.

Thanks.

Georg



-----Original Message-----
From: multipathtcp-bounces= @ietf.org [mailto:mult= ipathtcp-bounces@ietf.org] On Behalf Of Yoshifumi Nishida
Sent: Tuesday, January 17, 2012 6:31 AM
To: multipathtcp
Subject: [multipathtcp] MPTCP abrupt connection termination

Hi folks,
Although it's a bit quite these days, I personally believe we are
getting close to finish this feature.
I'm trying to create a simple summary of the current discussion items.<= br> please feel free to add and modify it.

Also, I personally think the status of these items are followings
=A0 1: reach consensus
=A0 2: since procedure is fixed, we can just procced to create this
=A0 3: no disagreement (if we use option)
=A0 4: rather minor topic so easy to fix
=A0 5: let's decide quickly if there's no blocker

1: bacis procedure

=A0 - Host A sends a regular TCP segment containing MPTCP_RST(B's key)=
on one subflow. It sends TCP RST segments on all other subflows and
tears them down.

=A0 - Upon reception of a regular TCP segment containing MPTCP_RST and
its key, a host responds by sending a TCP RST segment on the same
subflow and releases the entire MPTCP connection.

=A0 - Host A tears down the MPTCP connection as soon as it receives a
TCP segment containing MPTCP(A's key) or a RST segment on the
remaining subflow.

=A0 note 1: need to add retransmission timeout for MPTCP_RST

2: new state diagram for this

3: option format for MPTCP_RST
=A0 =A0http://www.ietf.org/mail-archive/web/mul= tipathtcp/current/msg01623.html

4: name for the option
=A0 =A0MPTCP_RST or DATA_RST might not be good?
=A0 =A0DATA_CLOSE?

5: using flag in DSS insted of option
=A0 =A0in case of DSS, we won't use KEY. Isn't it vulnerable?


Thanks,
--
Yoshifumi
_______________________________________________
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

--f46d0444ea1916fdb604b7bfa238-- From touch@isi.edu Mon Jan 30 07:51:07 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0288821F85E5 for ; Mon, 30 Jan 2012 07:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXU9AM29l9OJ for ; Mon, 30 Jan 2012 07:51:06 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 5946621F85E4 for ; Mon, 30 Jan 2012 07:51:06 -0800 (PST) Received: from [192.168.1.100] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q0UFoTX3023190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Jan 2012 07:50:32 -0800 (PST) Message-ID: <4F26BC45.4010408@isi.edu> Date: Mon, 30 Jan 2012 07:50:29 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: philip.eardley@bt.com References: <154773479ED2314980CB638A48FC443488CD455C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F3316231BC5@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F3316231BC5@EMV65-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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] MPTCP abrupt connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 15:51:07 -0000 On 1/20/2012 10:54 AM, philip.eardley@bt.com wrote: > Let me just clarify I understand. > > <<1: bacis procedure > > - Host A sends a regular TCP segment containing MPTCP_RST(B's key) > on one subflow. It sends TCP RST segments on all other subflows and > tears them down. > > - Upon reception of a regular TCP segment containing MPTCP_RST and > its key, a host responds by sending a TCP RST segment on the same > subflow and releases the entire MPTCP connection. >>> > > [phil] TCP RST is an ordinary RST (at some earlier point there was discussion about this including the MPTCP-RST(A'skey) ; but this is not the proposal) FWIW, I never liked any TCP mod in which a RST generates a response. I think it's counter to the point of the message; IMO, if you need further action, you should create a different message. Two other points: - RSTs (as all signals) can be lost; what happens to your system when they are? - if you use existing TCP RSTs, what happens to other TCP interactions? (e.g., a middlebox tends to tear things down on receiving a RST; they also sometimes send RSTs - will that create problems?) Joe From christoph.paasch@uclouvain.be Mon Jan 30 08:51:43 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35F321F861B for ; Mon, 30 Jan 2012 08:51:42 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jT9vZLagczCx for ; Mon, 30 Jan 2012 08:51:41 -0800 (PST) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id A371E21F8619 for ; Mon, 30 Jan 2012 08:51:40 -0800 (PST) Received: from [IPv6:2001:6a8:3080:2:6ab5:99ff:feea:c2fa] (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id CE32111E7AA; Mon, 30 Jan 2012 17:51:35 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be CE32111E7AA DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1327942295; bh=W1PTI/zMyUcCOagv1Bs5fYUPJB1tl77M+gv/f1hw6Hk=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=qlRXUNuU/5+NGX2pqGOyQ1ZDmt5Ys6s7UUepwaaXymQV5aJkI4BLe07eXxzahf6Yf jBSSZ2XonqcHzaskFvyyefPTewS+zSR215n6aCAXusqpHTe8HcQJ/bwuQ8IUMuDWlG 1lycnKTux+b3ef8Krdxa8kRDcqKz3DycuFnxxOBI= Message-ID: <4F26CA97.8070508@uclouvain.be> Date: Mon, 30 Jan 2012 17:51:35 +0100 From: Christoph Paasch Organization: =?ISO-8859-1?Q?Universit=E9_Catholique_de_Louvain?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Alan Ford References: <154773479ED2314980CB638A48FC443488CD455C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: X-TagToolbar-Keys: D20120130175135720 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: CE32111E7AA.A1870 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP abrupt connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: christoph.paasch@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 16:51:43 -0000 Hi Alan, On 01/30/2012 03:26 PM, Alan Ford wrote: > 3 and 5. Note that the use of the key makes the MPTCP_RST option up to > 12 bytes long. This means we are unlikely to be able to fit a DSS option > and the MPTCP_RST in the same packet. This is fine if the data in the > last packet is already covered by a DSS option, but if not it would > require a second packet just carrying MPTCP_RST. The DSS-option does not really matter, and can be ommitted on a packet containing the MPTCP_RST. Because, upon reception of the MPTCP_RST, the application will anyway receive an "ECONNRESET" on the socket and the data won't get delivered anymore. Cheers, Christoph -- Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be Université Catholique de Louvain -- From georg.hampel@alcatel-lucent.com Mon Jan 30 09:23:29 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD3621F8576 for ; Mon, 30 Jan 2012 09:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.432 X-Spam-Level: X-Spam-Status: No, score=-9.432 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rY5a5sDmKsOX for ; Mon, 30 Jan 2012 09:23:25 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id EBD6621F8568 for ; Mon, 30 Jan 2012 09:23:17 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q0UHNF1v005945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Jan 2012 11:23:15 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q0UHNEtd014954 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Jan 2012 11:23:14 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 30 Jan 2012 11:23:14 -0600 From: "Hampel, K Georg (K Georg)" To: Alan Ford Date: Mon, 30 Jan 2012 11:23:12 -0600 Thread-Topic: [multipathtcp] MPTCP abrupt connection termination Thread-Index: AczfWy9zuySml/guR/Go3VIf8vK7BwAE6K/g Message-ID: <154773479ED2314980CB638A48FC443488DD08F1@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443488CD455C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_154773479ED2314980CB638A48FC443488DD08F1USNAVSXCHMBSA2n_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP abrupt connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 17:23:29 -0000 --_000_154773479ED2314980CB638A48FC443488DD08F1USNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alan, I've inserted comments below. Thanks. Georg ________________________________ Hi Georg, all, My thoughts on this: 1. The procedure seems ok. I don't see much benefit/difference between this= and doing the multiple-MPTCP_RST option that you mention in a later mail, = so this is fine. The timeout should ensure a relatively clean finish. However, shouldn't B also send TCP RST on all other subflows on receipt of = MPTCP_RST? [gh] The philosophy is to keep the number of messages small and to have the= connection-disrupting host pay the price rather than the "innocent" peer. = Since host A (initially) sends TCP RSTs on all but one subflow, the corresp= onding on-path middleboxes should be properly closed down. Host B's subflow= s also properly close down either through these TCP RSTs or due to the (rel= iably transmitted) MPTCP_RST. The only problem I see exists for middle boxe= s in case one of these TCP RST gets lost. We could improve this situation b= y having host B also sent TCP RST on each path, but this doesn't make this = solution reliable. 2. Your state machine description below seems fine (although require notes = on transmitted packets on the transitions, too). 4. The name - I prefer "DATA_CLOSE" or "MPTCP_CLOSE" since I do not see thi= s analogous to a TCP RST and instead see it as presenting a subset of TCP R= ST's (ab)uses. [gh] I don't really agree on the term "TCP RST abuse". RFC 1122 simply forg= ot to provide a mechanism which allows an application to forcefully close d= own. I assume there was no need to fix this at a later point in time since = TCP RST had already been adopted for this purpose. Instead of TCP FIN =3D c= lean and TCP RST =3D dirty, I would rather say TCP FIN =3D close-down w/o d= ata loss and TCP RST =3D close-down with data loss. The same applies to MPT= CP FIN and MPTCP RST. Otherwise I would ask: Why do we need a MPTCP CLOSE h= andshake if we already have a MPTCP FIN handshake. 3 and 5. Note that the use of the key makes the MPTCP_RST option up to 12 b= ytes long. This means we are unlikely to be able to fit a DSS option and th= e MPTCP_RST in the same packet. This is fine if the data in the last packet= is already covered by a DSS option, but if not it would require a second p= acket just carrying MPTCP_RST. [gh] Since we assume connection abortion with data loss the DSS should not = be necessary anymore. Although doing it by flag is open to replay attacks, is this really any wor= se than regular TCP? [gh] Do you mean DoS attacks? What would you accomplish with a replay attac= k? Regards, Alan On 17 January 2012 19:40, Hampel, K Georg (K Georg) > wrote: Hi Yoshifumi, On your points: 1. I'm fine with the basic procedure. The third bullet should perhaps menti= on that host A has to send a TCP RST in case it receives a MPTCP_RST. This = makes the third bullet compliant with the second bullet. 2. State diagram: I think we haven't converged on this issue yet. I once pr= oposed to introduce the RST_WAIT state. - Host A transitions to RST_WAIT from any other state when it sends MPTCP_R= ST. - Host B transitions to CLOSED from any other state when it receives MPTCP_= WAIT. - Host A transitions to CLOSED from RST_WAIT when it receives TCP RST or MP= TCP_RST. The RST_WAIT state has a retransmission time out. If MPTCP_RST retransmissi= ons don't succeed within this time out, host A transitions to CLOSED. 3. I'm fine with Olivier's proposal on the MPTCP_RST packet format. 4. I don't have specific name preferences. However, I think it makes sense = to keep the term "RST" in the name since it builds on TCP RST and since it = doesn't represent a "proper" handshake. 5. I agree that just having DSS + flag is too vulnerable. I'd prefer the so= lution proposed under 3. Thanks. Georg -----Original Message----- From: multipathtcp-bounces@ietf.org [= mailto:multipathtcp-bounces@ietf.org]= On Behalf Of Yoshifumi Nishida Sent: Tuesday, January 17, 2012 6:31 AM To: multipathtcp Subject: [multipathtcp] MPTCP abrupt connection termination Hi folks, Although it's a bit quite these days, I personally believe we are getting close to finish this feature. I'm trying to create a simple summary of the current discussion items. please feel free to add and modify it. Also, I personally think the status of these items are followings 1: reach consensus 2: since procedure is fixed, we can just procced to create this 3: no disagreement (if we use option) 4: rather minor topic so easy to fix 5: let's decide quickly if there's no blocker 1: bacis procedure - Host A sends a regular TCP segment containing MPTCP_RST(B's key) on one subflow. It sends TCP RST segments on all other subflows and tears them down. - Upon reception of a regular TCP segment containing MPTCP_RST and its key, a host responds by sending a TCP RST segment on the same subflow and releases the entire MPTCP connection. - Host A tears down the MPTCP connection as soon as it receives a TCP segment containing MPTCP(A's key) or a RST segment on the remaining subflow. note 1: need to add retransmission timeout for MPTCP_RST 2: new state diagram for this 3: option format for MPTCP_RST http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01623.html 4: name for the option MPTCP_RST or DATA_RST might not be good? DATA_CLOSE? 5: using flag in DSS insted of option in case of DSS, we won't use KEY. Isn't it vulnerable? Thanks, -- Yoshifumi _______________________________________________ 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 --_000_154773479ED2314980CB638A48FC443488DD08F1USNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alan,

 

I’ve inserted comments below. Thanks.


Georg

 

 

Hi Georg, all,

 

My thoughts on this:

 

1. The procedure seems ok. I don't see much benefit/difference betw= een this and doing the multiple-MPTCP_RST option that you mention in a later ma= il, so this is fine. The timeout should ensure a relatively clean finish. =

 

However, shouldn't B also send TCP RST on all other subflows on rec= eipt of MPTCP_RST?

 

[gh] The philosophy is to keep the num= ber of messages small and to have the connection-disrupting host pay the price = rather than the “innocent” peer. Since host A (initially) sends TCP RS= Ts on all but one subflow, the corresponding on-path middleboxes should be properly closed down. Host B’s subflows also properly close down eith= er through these TCP RSTs or due to the (reliably transmitted) MPTCP_RST. The = only problem I see exists for middle boxes in case one of these TCP RST gets los= t. We could improve this situation by having host B also sent TCP RST on each pat= h, but this doesn’t make this solution reliable.

 

 

2. Your state machine description below seems fine (although requir= e notes on transmitted packets on the transitions, too).

 

4. The name - I prefer "DATA_CLOSE" or "MPTCP_CLOSE" since I do not see this analogous to a TCP RST and instead see it as presenting a subset of TCP RST's (ab)uses.

<= span style=3D'font-size:12.0pt;color:navy'> 

[gh] I don’t really agree on the term “TCP RST abuse”. RFC 1122 simply forgot to provide a mecha= nism which allows an application to forcefully close down. I assume there was no= need to fix this at a later point in time since TCP RST had already been adopted= for this purpose. Instead of TCP FIN =3D clean and TCP RST =3D dirty, I would r= ather say TCP FIN =3D close-down w/o data loss and TCP RST =3D close-down with da= ta loss. The same applies to MPTCP FIN and MPTCP RST. Otherwise I would ask: Why do = we need a MPTCP CLOSE handshake if we already have a MPTCP FIN handshake.=

 

 

3 and 5. Note that the use of the key makes the MPTCP_RST option up= to 12 bytes long. This means we are unlikely to be able to fit a DSS option an= d the MPTCP_RST in the same packet. This is fine if the data in the last pack= et is already covered by a DSS option, but if not it would require a second pa= cket just carrying MPTCP_RST.

 

[gh] Since we assume connection aborti= on with data loss the DSS should not be necessary anymore.

 

Although doing it by flag is open to replay attacks, is this really= any worse than regular TCP?

 

[gh] Do you mean DoS attacks? What wou= ld you accomplish with a replay attack?

 

Regards,

Alan

 =

On 17 January 2012 19:40, Hampel, K Georg (K Georg) <georg.hampel@alcatel-lucent= .com> wrote:

Hi Yoshifumi,

On your points:

1. I'm fine with the basic procedure. The third bullet should perhaps menti= on that host A has to send a TCP RST in case it receives a MPTCP_RST. This mak= es the third bullet compliant with the second bullet.

2. State diagram: I think we haven't converged on this issue yet. I once proposed to introduce the RST_WAIT state.
- Host A transitions to RST_WAIT from any other state when it sends MPTCP_R= ST.
- Host B transitions to CLOSED from any other state when it receives MPTCP_WAIT.
- Host A transitions to CLOSED from RST_WAIT when it receives TCP RST or MPTCP_RST.

The RST_WAIT state has a retransmission time out. If MPTCP_RST retransmissi= ons don't succeed within this time out, host A transitions to CLOSED.

3. I'm fine with Olivier's proposal on the MPTCP_RST packet format.

4. I don't have specific name preferences. However, I think it makes sense = to keep the term "RST" in the name since it builds on TCP RST and si= nce it doesn't represent a "proper" handshake.

5. I agree that just having DSS + flag is too vulnerable. I'd prefer the solution proposed under 3.

Thanks.

Georg




-----Original Message-----
From: multipathtcp-bounces= @ietf.org [mailto:multipathtcp-bounc= es@ietf.org] On Behalf Of Yoshifumi Nishida
Sent: Tuesday, January 17, 2012 6:31 AM
To: multipathtcp
Subject: [multipathtcp] MPTCP abrupt connection termination

Hi folks,
Although it's a bit quite these days, I personally believe we are
getting close to finish this feature.
I'm trying to create a simple summary of the current discussion items.
please feel free to add and modify it.

Also, I personally think the status of these items are followings
  1: reach consensus
  2: since procedure is fixed, we can just procced to create this
  3: no disagreement (if we use option)
  4: rather minor topic so easy to fix
  5: let's decide quickly if there's no blocker

1: bacis procedure

  - Host A sends a regular TCP segment containing MPTCP_RST(B's key) on one subflow. It sends TCP RST segments on all other subflows and
tears them down.

  - Upon reception of a regular TCP segment containing MPTCP_RST and its key, a host responds by sending a TCP RST segment on the same
subflow and releases the entire MPTCP connection.

  - Host A tears down the MPTCP connection as soon as it receives a TCP segment containing MPTCP(A's key) or a RST segment on the
remaining subflow.

  note 1: need to add retransmission timeout for MPTCP_RST

2: new state diagram for this

3: option format for MPTCP_RST
   http://www.ietf.org/mail-archive/web/multipathtcp/current= /msg01623.html

4: name for the option
   MPTCP_RST or DATA_RST might not be good?
   DATA_CLOSE?

5: using flag in DSS insted of option
   in case of DSS, we won't use KEY. Isn't it vulnerable?


Thanks,
--
Yoshifumi
_______________________________________________
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

 

--_000_154773479ED2314980CB638A48FC443488DD08F1USNAVSXCHMBSA2n_-- From georg.hampel@alcatel-lucent.com Mon Jan 30 09:50:07 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2D721F84AA for ; Mon, 30 Jan 2012 09:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.874 X-Spam-Level: X-Spam-Status: No, score=-7.874 tagged_above=-999 required=5 tests=[AWL=-1.275, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiUUZj9aOT2a for ; Mon, 30 Jan 2012 09:50:05 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 706D521F85C7 for ; Mon, 30 Jan 2012 09:50:01 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q0UHntoA007742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Jan 2012 11:49:56 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q0UHnUVF032489 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Jan 2012 11:49:53 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Mon, 30 Jan 2012 11:49:48 -0600 From: "Hampel, K Georg (K Georg)" To: Joe Touch , "philip.eardley@bt.com" Date: Mon, 30 Jan 2012 11:49:47 -0600 Thread-Topic: [multipathtcp] MPTCP abrupt connection termination Thread-Index: AczfZvhZBlOSylsjRAy1ML0rXlvpxwADymvQ Message-ID: <154773479ED2314980CB638A48FC443488DD091B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443488CD455C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F3316231BC5@EMV65-UKRD.domain1.systemhost.net> <4F26BC45.4010408@isi.edu> In-Reply-To: <4F26BC45.4010408@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] MPTCP abrupt connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 17:50:08 -0000 Hi Joe, Comments inserted. Thanks. Georg On 1/20/2012 10:54 AM, philip.eardley@bt.com wrote: > Let me just clarify I understand. > > <<1: bacis procedure > > - Host A sends a regular TCP segment containing MPTCP_RST(B's key) > on one subflow. It sends TCP RST segments on all other subflows and > tears them down. > > - Upon reception of a regular TCP segment containing MPTCP_RST and > its key, a host responds by sending a TCP RST segment on the same > subflow and releases the entire MPTCP connection. >>> > > [phil] TCP RST is an ordinary RST (at some earlier point there was discus= sion about this including the MPTCP-RST(A'skey) ; but this is not the propo= sal) FWIW, I never liked any TCP mod in which a RST generates a response. I=20 think it's counter to the point of the message; IMO, if you need further=20 action, you should create a different message. [gh] We don't propose any TCP response to a TCP RST. We propose a TCP-RST r= esponse to a MPTCP_RST. MPTCP is seen as the "higher layer" whose RST creat= es a "lower layer" RST, in the same manner as an HTTP error message may cau= se a TCP RST response. Two other points: - RSTs (as all signals) can be lost; what happens to your system when=20 they are? [gh] Our system is fine since MPTCP_RST is sent reliably (i.e. retransmitte= d). Some middle boxes may keep hanging in. - if you use existing TCP RSTs, what happens to other TCP interactions?=20 (e.g., a middlebox tends to tear things down on receiving a RST; they=20 also sometimes send RSTs - will that create problems?) [gh] We are planning to use existing TCP RSTs. The main reason is to tear d= own middle-box state (courtesy procedure). To the best of my knowledge, RST= s sent by middle boxes shouldn't create any problem. Joe From touch@isi.edu Mon Jan 30 10:06:04 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E3511E808E for ; Mon, 30 Jan 2012 10:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.467 X-Spam-Level: X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[AWL=-0.868, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URUnUvbAqTiA for ; Mon, 30 Jan 2012 10:06:03 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id D963511E8081 for ; Mon, 30 Jan 2012 10:06:03 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q0UI5fcD003389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Jan 2012 10:05:41 -0800 (PST) Message-ID: <4F26DBF5.10009@isi.edu> Date: Mon, 30 Jan 2012 10:05:41 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Hampel, K Georg (K Georg)" References: <154773479ED2314980CB638A48FC443488CD455C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F3316231BC5@EMV65-UKRD.domain1.systemhost.net> <4F26BC45.4010408@isi.edu> <154773479ED2314980CB638A48FC443488DD091B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC443488DD091B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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] MPTCP abrupt connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 18:06:04 -0000 Hi, Georg, Thanks for the clarification. Joe On 1/30/2012 9:49 AM, Hampel, K Georg (K Georg) wrote: > Hi Joe, > > Comments inserted. Thanks. > > Georg > > > On 1/20/2012 10:54 AM, philip.eardley@bt.com wrote: >> Let me just clarify I understand. >> >> <<1: bacis procedure >> >> - Host A sends a regular TCP segment containing MPTCP_RST(B's key) >> on one subflow. It sends TCP RST segments on all other subflows and >> tears them down. >> >> - Upon reception of a regular TCP segment containing MPTCP_RST and >> its key, a host responds by sending a TCP RST segment on the same >> subflow and releases the entire MPTCP connection. >>>> >> >> [phil] TCP RST is an ordinary RST (at some earlier point there was discussion about this including the MPTCP-RST(A'skey) ; but this is not the proposal) > > FWIW, I never liked any TCP mod in which a RST generates a response. I > think it's counter to the point of the message; IMO, if you need further > action, you should create a different message. > > [gh] We don't propose any TCP response to a TCP RST. We propose a TCP-RST response to a MPTCP_RST. MPTCP is seen as the "higher layer" whose RST creates a "lower layer" RST, in the same manner as an HTTP error message may cause a TCP RST response. > > Two other points: > > - RSTs (as all signals) can be lost; what happens to your system when > they are? > > [gh] Our system is fine since MPTCP_RST is sent reliably (i.e. retransmitted). Some middle boxes may keep hanging in. > > - if you use existing TCP RSTs, what happens to other TCP interactions? > (e.g., a middlebox tends to tear things down on receiving a RST; they > also sometimes send RSTs - will that create problems?) > > [gh] We are planning to use existing TCP RSTs. The main reason is to tear down middle-box state (courtesy procedure). To the best of my knowledge, RSTs sent by middle boxes shouldn't create any problem. > > Joe > From alan.ford@gmail.com Mon Jan 30 11:35:39 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037EF21F865C for ; Mon, 30 Jan 2012 11:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBCszvyTySs8 for ; Mon, 30 Jan 2012 11:35:37 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1B721F85B4 for ; Mon, 30 Jan 2012 11:35:36 -0800 (PST) Received: by wgbgn7 with SMTP id gn7so4079881wgb.1 for ; Mon, 30 Jan 2012 11:35:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=UVJAFfWqhRnVoT+DOtfrwKC/ogRmuHF/x2t/R3AGrpE=; b=kuWs+8Ml1Ur14T+DPU5BAmXSGWwyS8BcAwJrcZH3M/55yX4AmJtoJ/Kep4uUf3OSsM oFAlTYxjqgCS2qED9vEtwm+EqefBkfUhbpZ4NUXVGIzUtZ3/qgrgyeN6WkIhvMxGyfvU oPyT8CclDnPbl89cDTE5HswxfHoB03SJ2VsKY= Received: by 10.180.93.132 with SMTP id cu4mr30230394wib.9.1327952132136; Mon, 30 Jan 2012 11:35:32 -0800 (PST) Received: from [10.0.0.15] (82-71-117-110.dsl.in-addr.zen.co.uk. [82.71.117.110]) by mx.google.com with ESMTPS id n5sm55417191wiw.7.2012.01.30.11.35.29 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Jan 2012 11:35:30 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_14A2FCAD-4BEA-44E4-AD4B-7A2E7C7BC63A" From: Alan Ford In-Reply-To: <154773479ED2314980CB638A48FC443488DD08F1@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Date: Mon, 30 Jan 2012 19:35:31 +0000 Message-Id: <4B19BEB5-185C-4B09-B283-7B4D0D57BBD9@gmail.com> References: <154773479ED2314980CB638A48FC443488CD455C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443488DD08F1@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> To: "Hampel, K Georg (K Georg)" X-Mailer: Apple Mail (2.1251.1) Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP abrupt connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 19:35:39 -0000 --Apple-Mail=_14A2FCAD-4BEA-44E4-AD4B-7A2E7C7BC63A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Georg, Thank you for the clarifications below. I think that's cleared up my = remaining issues/confusions (especially given Christoph's point that the = signal needs a packet of its own anyway, so we might as well make it a = semi-secure signal). We'll get an updated version of the draft out shortly. Cheers, Alan On 30 Jan 2012, at 17:23, Hampel, K Georg (K Georg) wrote: > Hi Alan, > =20 > I=92ve inserted comments below. Thanks. >=20 > Georg > =20 > =20 > Hi Georg, all, > =20 > My thoughts on this: > =20 > 1. The procedure seems ok. I don't see much benefit/difference between = this and doing the multiple-MPTCP_RST option that you mention in a later = mail, so this is fine. The timeout should ensure a relatively clean = finish.=20 > =20 > However, shouldn't B also send TCP RST on all other subflows on = receipt of MPTCP_RST? > =20 > [gh] The philosophy is to keep the number of messages small and to = have the connection-disrupting host pay the price rather than the = =93innocent=94 peer. Since host A (initially) sends TCP RSTs on all but = one subflow, the corresponding on-path middleboxes should be properly = closed down. Host B=92s subflows also properly close down either through = these TCP RSTs or due to the (reliably transmitted) MPTCP_RST. The only = problem I see exists for middle boxes in case one of these TCP RST gets = lost. We could improve this situation by having host B also sent TCP RST = on each path, but this doesn=92t make this solution reliable. > =20 > =20 > 2. Your state machine description below seems fine (although require = notes on transmitted packets on the transitions, too). > =20 > 4. The name - I prefer "DATA_CLOSE" or "MPTCP_CLOSE" since I do not = see this analogous to a TCP RST and instead see it as presenting a = subset of TCP RST's (ab)uses. > =20 > [gh] I don=92t really agree on the term =93TCP RST abuse=94. RFC 1122 = simply forgot to provide a mechanism which allows an application to = forcefully close down. I assume there was no need to fix this at a later = point in time since TCP RST had already been adopted for this purpose. = Instead of TCP FIN =3D clean and TCP RST =3D dirty, I would rather say = TCP FIN =3D close-down w/o data loss and TCP RST =3D close-down with = data loss. The same applies to MPTCP FIN and MPTCP RST. Otherwise I = would ask: Why do we need a MPTCP CLOSE handshake if we already have a = MPTCP FIN handshake. > =20 > =20 > 3 and 5. Note that the use of the key makes the MPTCP_RST option up to = 12 bytes long. This means we are unlikely to be able to fit a DSS option = and the MPTCP_RST in the same packet. This is fine if the data in the = last packet is already covered by a DSS option, but if not it would = require a second packet just carrying MPTCP_RST. > =20 > [gh] Since we assume connection abortion with data loss the DSS should = not be necessary anymore. > =20 > Although doing it by flag is open to replay attacks, is this really = any worse than regular TCP? > =20 > [gh] Do you mean DoS attacks? What would you accomplish with a replay = attack? > =20 > Regards, > Alan > =20 >=20 > On 17 January 2012 19:40, Hampel, K Georg (K Georg) = wrote: > Hi Yoshifumi, >=20 > On your points: >=20 > 1. I'm fine with the basic procedure. The third bullet should perhaps = mention that host A has to send a TCP RST in case it receives a = MPTCP_RST. This makes the third bullet compliant with the second bullet. >=20 > 2. State diagram: I think we haven't converged on this issue yet. I = once proposed to introduce the RST_WAIT state. > - Host A transitions to RST_WAIT from any other state when it sends = MPTCP_RST. > - Host B transitions to CLOSED from any other state when it receives = MPTCP_WAIT. > - Host A transitions to CLOSED from RST_WAIT when it receives TCP RST = or MPTCP_RST. >=20 > The RST_WAIT state has a retransmission time out. If MPTCP_RST = retransmissions don't succeed within this time out, host A transitions = to CLOSED. >=20 > 3. I'm fine with Olivier's proposal on the MPTCP_RST packet format. >=20 > 4. I don't have specific name preferences. However, I think it makes = sense to keep the term "RST" in the name since it builds on TCP RST and = since it doesn't represent a "proper" handshake. >=20 > 5. I agree that just having DSS + flag is too vulnerable. I'd prefer = the solution proposed under 3. >=20 > Thanks. >=20 > Georg >=20 >=20 >=20 > -----Original Message----- > From: multipathtcp-bounces@ietf.org = [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Yoshifumi Nishida > Sent: Tuesday, January 17, 2012 6:31 AM > To: multipathtcp > Subject: [multipathtcp] MPTCP abrupt connection termination >=20 > Hi folks, > Although it's a bit quite these days, I personally believe we are > getting close to finish this feature. > I'm trying to create a simple summary of the current discussion items. > please feel free to add and modify it. >=20 > Also, I personally think the status of these items are followings > 1: reach consensus > 2: since procedure is fixed, we can just procced to create this > 3: no disagreement (if we use option) > 4: rather minor topic so easy to fix > 5: let's decide quickly if there's no blocker >=20 > 1: bacis procedure >=20 > - Host A sends a regular TCP segment containing MPTCP_RST(B's key) > on one subflow. It sends TCP RST segments on all other subflows and > tears them down. >=20 > - Upon reception of a regular TCP segment containing MPTCP_RST and > its key, a host responds by sending a TCP RST segment on the same > subflow and releases the entire MPTCP connection. >=20 > - Host A tears down the MPTCP connection as soon as it receives a > TCP segment containing MPTCP(A's key) or a RST segment on the > remaining subflow. >=20 > note 1: need to add retransmission timeout for MPTCP_RST >=20 > 2: new state diagram for this >=20 > 3: option format for MPTCP_RST > = http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01623.html >=20 > 4: name for the option > MPTCP_RST or DATA_RST might not be good? > DATA_CLOSE? >=20 > 5: using flag in DSS insted of option > in case of DSS, we won't use KEY. Isn't it vulnerable? >=20 >=20 > Thanks, > -- > Yoshifumi > _______________________________________________ > 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 > =20 --Apple-Mail=_14A2FCAD-4BEA-44E4-AD4B-7A2E7C7BC63A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Georg,

Thank you for the = clarifications below. I think that's cleared up my remaining = issues/confusions (especially given Christoph's point that the signal = needs a packet of its own anyway, so we might as well make it a = semi-secure signal).

We'll get an updated = version of the draft out = shortly.

Cheers,
Alan

On 30 Jan 2012, at 17:23, Hampel, K Georg (K Georg) = wrote:

Hi Alan,
I=92ve inserted comments below. = Thanks.

Georg
 
Hi Georg, = all,
My thoughts on = this:
1. The procedure seems ok. I don't see much = benefit/difference between this and doing the multiple-MPTCP_RST option = that you mention in a later mail, so this is fine. The timeout should = ensure a relatively clean = finish. 
However, shouldn't B also send TCP RST on = all other subflows on receipt of = MPTCP_RST?
 
[gh] The = philosophy is to keep the number of messages small and to have the = connection-disrupting host pay the price rather than the =93innocent=94 = peer. Since host A (initially) sends TCP RSTs on all but one subflow, = the corresponding on-path middleboxes should be properly closed down. = Host B=92s subflows also properly close down either through these TCP = RSTs or due to the (reliably transmitted) MPTCP_RST. The only problem I = see exists for middle boxes in case one of these TCP RST gets lost. We = could improve this situation by having host B also sent TCP RST on each = path, but this doesn=92t make this solution = reliable.
 
2. Your state machine description below = seems fine (although require notes on transmitted packets on the = transitions, too).
4. The name - I prefer "DATA_CLOSE" or = "MPTCP_CLOSE" since I do not see this analogous to a TCP RST and instead = see it as presenting a subset of TCP RST's = (ab)uses.
[gh] I don=92t really agree on the term =93TCP RST = abuse=94. RFC 1122 simply forgot to provide a mechanism which allows an = application to forcefully close down. I assume there was no need to fix = this at a later point in time since TCP RST had already been adopted for = this purpose. Instead of TCP FIN =3D clean and TCP RST =3D dirty, I = would rather say TCP FIN =3D close-down w/o data loss and TCP RST =3D = close-down with data loss. The same applies to MPTCP FIN and MPTCP RST. = Otherwise I would ask: Why do we need a MPTCP CLOSE handshake if we = already have a MPTCP FIN handshake.
 
3 and 5. Note that the use of the key makes = the MPTCP_RST option up to 12 bytes long. This means we are unlikely to = be able to fit a DSS option and the MPTCP_RST in the same packet. This = is fine if the data in the last packet is already covered by a DSS = option, but if not it would require a second packet just carrying = MPTCP_RST.
 
[gh] Since = we assume connection abortion with data loss the DSS should not be = necessary anymore.
Although doing it by flag is open to replay = attacks, is this really any worse than regular = TCP?
 
[gh] Do you = mean DoS attacks? What would you accomplish with a replay = attack?
 

On 17 January = 2012 19:40, Hampel, K Georg (K Georg) <georg.hampel@alcatel-lucent.com> = wrote:
Hi Yoshifumi,

On = your points:

1. I'm fine with the basic procedure. The third = bullet should perhaps mention that host A has to send a TCP RST in case = it receives a MPTCP_RST. This makes the third bullet compliant with the = second bullet.

2. State diagram: I think we haven't converged on = this issue yet. I once proposed to introduce the RST_WAIT state.
- = Host A transitions to RST_WAIT from any other state when it sends = MPTCP_RST.
- Host B transitions to CLOSED from any other state when = it receives MPTCP_WAIT.
- Host A transitions to CLOSED from RST_WAIT = when it receives TCP RST or MPTCP_RST.

The RST_WAIT state has a = retransmission time out. If MPTCP_RST retransmissions don't succeed = within this time out, host A transitions to CLOSED.

3. I'm fine = with Olivier's proposal on the MPTCP_RST packet format.

4. I = don't have specific name preferences. However, I think it makes sense to = keep the term "RST" in the name since it builds on TCP RST and since it = doesn't represent a "proper" handshake.

5. I agree that just = having DSS + flag is too vulnerable. I'd prefer the solution proposed = under 3.

Thanks.

Georg
=



-----Original = Message-----
From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On = Behalf Of Yoshifumi Nishida
Sent: Tuesday, January 17, 2012 6:31 = AM
To: multipathtcp
Subject: [multipathtcp] MPTCP abrupt = connection termination

Hi folks,
Although it's a bit quite = these days, I personally believe we are
getting close to finish this = feature.
I'm trying to create a simple summary of the current = discussion items.
please feel free to add and modify it.

Also, = I personally think the status of these items are followings
  1: = reach consensus
  2: since procedure is fixed, we can just = procced to create this
  3: no disagreement (if we use = option)
  4: rather minor topic so easy to fix
  5: = let's decide quickly if there's no blocker

1: bacis = procedure

  - Host A sends a regular TCP segment containing = MPTCP_RST(B's key)
on one subflow. It sends TCP RST segments on all = other subflows and
tears them down.

  - Upon reception of = a regular TCP segment containing MPTCP_RST and
its key, a host = responds by sending a TCP RST segment on the same
subflow and = releases the entire MPTCP connection.

  - Host A tears down = the MPTCP connection as soon as it receives a
TCP segment containing = MPTCP(A's key) or a RST segment on the
remaining = subflow.

  note 1: need to add retransmission timeout for = MPTCP_RST

2: new state diagram for this

3: option format = for MPTCP_RST
   http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01623.html<= /a>

4: name for the option
   MPTCP_RST or DATA_RST = might not be good?
   DATA_CLOSE?

5: using flag in = DSS insted of option
   in case of DSS, we won't use KEY. = Isn't it = vulnerable?


Thanks,
--
Yoshifumi
_____________________= __________________________
multipathtcp mailing list
multipathtcp@ietf.org
multipathtcp@ietf.org
Date: Tue, 31 Jan 2012 09:58:04 -0800 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-06.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 17:58:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multipath TCP Working Group of the IE= TF. Title : TCP Extensions for Multipath Operation with Multiple Add= resses Author(s) : Alan Ford Costin Raiciu Mark Handley Olivier Bonaventure Filename : draft-ietf-mptcp-multiaddressed-06.txt Pages : 60 Date : 2012-01-31 TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network, and thus improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e. reliable bytestream), and provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-06.txt