From nobody Sun Jan 3 22:07:25 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 546241A03A6 for ; Sun, 3 Jan 2016 21:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.414 X-Spam-Level: *** X-Spam-Status: No, score=3.414 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pW3gGD-6saOQ for ; Sun, 3 Jan 2016 21:43:07 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF6551A03A3 for ; Sun, 3 Jan 2016 21:43:06 -0800 (PST) Received: from mail-yk0-f182.google.com (mail-yk0-f182.google.com [209.85.160.182]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id C95F7278171 for ; Mon, 4 Jan 2016 14:43:04 +0900 (JST) Received: by mail-yk0-f182.google.com with SMTP id k129so215743048yke.0 for ; Sun, 03 Jan 2016 21:43:04 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.129.155.204 with SMTP id s195mr62604427ywg.302.1451886183261; Sun, 03 Jan 2016 21:43:03 -0800 (PST) Received: by 10.129.147.5 with HTTP; Sun, 3 Jan 2016 21:43:03 -0800 (PST) In-Reply-To: <20151214154527.689FE180004@rfc-editor.org> References: <20151214154527.689FE180004@rfc-editor.org> Date: Sun, 3 Jan 2016 21:43:03 -0800 X-Gmail-Original-Message-ID: Message-ID: From: Yoshifumi Nishida To: RFC Errata System Content-Type: multipart/alternative; boundary=94eb2c05425435365b05287b98f4 Archived-At: X-Mailman-Approved-At: Sun, 03 Jan 2016 22:07:24 -0800 Cc: costin.raiciu@cs.pub.ro, Christoph Paasch , multipathtcp , Martin Stiemerling , fgont@si6networks.com Subject: Re: [multipathtcp] [Technical Errata Reported] RFC7430 (4565) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 05:43:09 -0000 --94eb2c05425435365b05287b98f4 Content-Type: text/plain; charset=UTF-8 Hi, This might already be taken care of, but just in case... I personally think this errata is correct (although it can look an editorial error) I think we will need confirmations from authors. Thanks, -- Yoshi On Mon, Dec 14, 2015 at 7:45 AM, RFC Errata System < rfc-editor@rfc-editor.org> wrote: > The following errata report has been submitted for RFC7430, > "Analysis of Residual Threats and Possible Fixes for Multipath TCP > (MPTCP)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=7430&eid=4565 > > -------------------------------------- > Type: Technical > Reported by: Fabrizio Demaria > > Section: 6 > > Original Text > ------------- > Summary of the attack: > > Type of attack: An attacker that can intercept the SYN/JOIN > message can alter the source address being added. > > Type of attacker: partial-time on-path eavesdropper > > Description: > > The attacker is present along the path when the SYN/JOIN exchange > takes place. This allows the attacker to add any new address it > wants to by simply substituting the source address of the SYN/JOIN > packet for one it chooses. This vulnerability was readily identified > when designing the MPTCP security solution [RFC6181], and the threat > was considered acceptable. > > Corrected Text > -------------- > Summary of the attack: > > Type of attack: An attacker that can intercept the SYN/JOIN > message can alter the source address being added. > > Type of attacker: partial-time on-path active attacker > > Description: > > The attacker is present along the path when the SYN/JOIN exchange > takes place. This allows the attacker to add any new address it > wants to by simply substituting the source address of the SYN/JOIN > packet for one it chooses. This vulnerability was readily identified > when designing the MPTCP security solution [RFC6181], and the threat > was considered acceptable. > > Notes > ----- > As noted in section 1, an active attacker is able to change, discard, or > delay some of the packets of the MPTCP session. This coincide with the > description of the SYN/JOIN attack in section 6. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7430 (draft-ietf-mptcp-attacks-04) > -------------------------------------- > Title : Analysis of Residual Threats and Possible Fixes for > Multipath TCP (MPTCP) > Publication Date : July 2015 > Author(s) : M. Bagnulo, C. Paasch, F. Gont, O. Bonaventure, C. > Raiciu > Category : INFORMATIONAL > Source : Multipath TCP > Area : Transport > Stream : IETF > Verifying Party : IESG > > --94eb2c05425435365b05287b98f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
This might already be taken care of, bu= t just in case...

I personally think this errata is cor= rect (although it can look an editorial error)
I think we will need con= firmations from authors.

Thanks,
--
<= div>Yoshi


On Mon, Dec 14, 2015= at 7:45 AM, RFC Errata System <rfc-editor@rfc-editor.org><= /span> wrote:
The following errata report has been subm= itted for RFC7430,
"Analysis of Residual Threats and Possible Fixes for Multipath TCP (MP= TCP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/err= ata_search.php?rfc=3D7430&eid=3D4565

--------------------------------------
Type: Technical
Reported by: Fabrizio Demaria <fabrizio.demaria@intel.com>

Section: 6

Original Text
-------------
=C2=A0 =C2=A0Summary of the attack:

=C2=A0 =C2=A0 =C2=A0 Type of attack: An attacker that can intercept the SYN= /JOIN
=C2=A0 =C2=A0 =C2=A0 message can alter the source address being added.

=C2=A0 =C2=A0 =C2=A0 Type of attacker: partial-time on-path eavesdropper
=C2=A0 =C2=A0Description:

=C2=A0 =C2=A0The attacker is present along the path when the SYN/JOIN excha= nge
=C2=A0 =C2=A0takes place.=C2=A0 This allows the attacker to add any new add= ress it
=C2=A0 =C2=A0wants to by simply substituting the source address of the SYN/= JOIN
=C2=A0 =C2=A0packet for one it chooses.=C2=A0 This vulnerability was readil= y identified
=C2=A0 =C2=A0when designing the MPTCP security solution [RFC6181], and the = threat
=C2=A0 =C2=A0was considered acceptable.

Corrected Text
--------------
=C2=A0 =C2=A0Summary of the attack:

=C2=A0 =C2=A0 =C2=A0 Type of attack: An attacker that can intercept the SYN= /JOIN
=C2=A0 =C2=A0 =C2=A0 message can alter the source address being added.

=C2=A0 =C2=A0 =C2=A0 Type of attacker: partial-time on-path active attacker=

=C2=A0 =C2=A0Description:

=C2=A0 =C2=A0The attacker is present along the path when the SYN/JOIN excha= nge
=C2=A0 =C2=A0takes place.=C2=A0 This allows the attacker to add any new add= ress it
=C2=A0 =C2=A0wants to by simply substituting the source address of the SYN/= JOIN
=C2=A0 =C2=A0packet for one it chooses.=C2=A0 This vulnerability was readil= y identified
=C2=A0 =C2=A0when designing the MPTCP security solution [RFC6181], and the = threat
=C2=A0 =C2=A0was considered acceptable.

Notes
-----
As noted in section 1, an active attacker is able to change, discard, or de= lay some of the packets of the MPTCP session. This coincide with the descri= ption of the SYN/JOIN attack in section 6.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7430 (draft-ietf-mptcp-attacks-04)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Analysis of R= esidual Threats and Possible Fixes for Multipath TCP (MPTCP)
Publication Date=C2=A0 =C2=A0 : July 2015
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: M. Bagnulo, C. Paasch, = F. Gont, O. Bonaventure, C. Raiciu
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : INFORMATIONAL
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Multipath TCP
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Transport
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG


--94eb2c05425435365b05287b98f4-- From nobody Mon Jan 4 07:48:46 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA331A87A8 for ; Mon, 4 Jan 2016 03:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.036 X-Spam-Level: X-Spam-Status: No, score=-0.036 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xr5apZnLyCr8 for ; Mon, 4 Jan 2016 03:07:01 -0800 (PST) Received: from s1.neomailbox.net (s1.neomailbox.net [5.148.176.57]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9271A87A6 for ; Mon, 4 Jan 2016 03:06:59 -0800 (PST) To: Yoshifumi Nishida , RFC Errata System References: <20151214154527.689FE180004@rfc-editor.org> From: marcelo bagnulo Message-ID: <568A523B.4030809@neomailbox.ch> Date: Mon, 4 Jan 2016 12:06:35 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Mon, 04 Jan 2016 07:48:45 -0800 Cc: costin.raiciu@cs.pub.ro, Christoph Paasch , multipathtcp , Martin Stiemerling , fgont@si6networks.com Subject: Re: [multipathtcp] [Technical Errata Reported] RFC7430 (4565) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 11:07:02 -0000 Hi, I understand the only change is to change the type of attacker from eavesdropper to active, correct? If so, I agree. Regards, marcelo El 04/01/16 a las 06:43, Yoshifumi Nishida escribió: > Hi, > This might already be taken care of, but just in case... > > I personally think this errata is correct (although it can look an > editorial error) > I think we will need confirmations from authors. > > Thanks, > -- > Yoshi > > > On Mon, Dec 14, 2015 at 7:45 AM, RFC Errata System > > wrote: > > The following errata report has been submitted for RFC7430, > "Analysis of Residual Threats and Possible Fixes for Multipath TCP > (MPTCP)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=7430&eid=4565 > > -------------------------------------- > Type: Technical > Reported by: Fabrizio Demaria > > > Section: 6 > > Original Text > ------------- > Summary of the attack: > > Type of attack: An attacker that can intercept the SYN/JOIN > message can alter the source address being added. > > Type of attacker: partial-time on-path eavesdropper > > Description: > > The attacker is present along the path when the SYN/JOIN exchange > takes place. This allows the attacker to add any new address it > wants to by simply substituting the source address of the SYN/JOIN > packet for one it chooses. This vulnerability was readily > identified > when designing the MPTCP security solution [RFC6181], and the > threat > was considered acceptable. > > Corrected Text > -------------- > Summary of the attack: > > Type of attack: An attacker that can intercept the SYN/JOIN > message can alter the source address being added. > > Type of attacker: partial-time on-path active attacker > > Description: > > The attacker is present along the path when the SYN/JOIN exchange > takes place. This allows the attacker to add any new address it > wants to by simply substituting the source address of the SYN/JOIN > packet for one it chooses. This vulnerability was readily > identified > when designing the MPTCP security solution [RFC6181], and the > threat > was considered acceptable. > > Notes > ----- > As noted in section 1, an active attacker is able to change, > discard, or delay some of the packets of the MPTCP session. This > coincide with the description of the SYN/JOIN attack in section 6. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7430 (draft-ietf-mptcp-attacks-04) > -------------------------------------- > Title : Analysis of Residual Threats and Possible > Fixes for Multipath TCP (MPTCP) > Publication Date : July 2015 > Author(s) : M. Bagnulo, C. Paasch, F. Gont, O. > Bonaventure, C. Raiciu > Category : INFORMATIONAL > Source : Multipath TCP > Area : Transport > Stream : IETF > Verifying Party : IESG > > From nobody Mon Jan 11 00:51:38 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6BE1A8829 for ; Mon, 11 Jan 2016 00:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSAVhrH3PvzW for ; Mon, 11 Jan 2016 00:51:33 -0800 (PST) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F0F41A8828 for ; Mon, 11 Jan 2016 00:51:33 -0800 (PST) Received: from E07HT04-UKBR.domain1.systemhost.net (193.113.197.162) by EVMED01-UKBR.bt.com (10.216.161.31) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 11 Jan 2016 08:51:28 +0000 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by E07HT04-UKBR.domain1.systemhost.net (193.113.197.162) with Microsoft SMTP Server (TLS) id 8.3.342.0; Mon, 11 Jan 2016 08:51:30 +0000 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 11 Jan 2016 08:51:30 +0000 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1104.000; Mon, 11 Jan 2016 08:51:30 +0000 From: To: Thread-Topic: [Recentattendees] IETF 95 Hackathon in Buenos Aires Thread-Index: AQHRPaGm7VyFYHBxg0Ol6ngq8zdHGJ72Hx7w Date: Mon, 11 Jan 2016 08:51:29 +0000 Message-ID: <5adeaf7d64244c47b2eb1654ce09b505@rew09926dag03b.domain1.systemhost.net> References: <20151223164729.13967.21303.idtracker@ietfa.amsl.com> In-Reply-To: <20151223164729.13967.21303.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.233] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] FW: [Recentattendees] IETF 95 Hackathon in Buenos Aires X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 08:51:36 -0000 SXMgdGhlcmUgaW50ZXJlc3QgaW4gam9pbmluZyB0aGUgaGFja2F0aG9uIHRoaXMgdGltZT8NCg0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSZWNlbnRhdHRlbmRlZXMgW21h aWx0bzpyZWNlbnRhdHRlbmRlZXMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElFVEYg U2VjcmV0YXJpYXQNClNlbnQ6IDIzIERlY2VtYmVyIDIwMTUgMTY6NDcNClRvOiBJRVRGIEFubm91 bmNlbWVudCBMaXN0IDxpZXRmLWFubm91bmNlQGlldGYub3JnPg0KQ2M6IHJlY2VudGF0dGVuZGVl c0BpZXRmLm9yZzsgOTVhbGxAaWV0Zi5vcmcNClN1YmplY3Q6IFtSZWNlbnRhdHRlbmRlZXNdIElF VEYgOTUgSGFja2F0aG9uIGluIEJ1ZW5vcyBBaXJlcw0KDQpUaGUgSW50ZXJuZXQgRW5naW5lZXJp bmcgVGFzayBGb3JjZSAoSUVURikgaXMgaG9sZGluZyBhIEhhY2thdGhvbiBhdCBJRVRGIDk1IHRv IGVuY291cmFnZSBkZXZlbG9wZXJzIHRvIGRpc2N1c3MsIGNvbGxhYm9yYXRlIGFuZCBkZXZlbG9w IHV0aWxpdGllcywgaWRlYXMsIHNhbXBsZSBjb2RlIGFuZCBzb2x1dGlvbnMgdGhhdCBzaG93IHBy YWN0aWNhbCBpbXBsZW1lbnRhdGlvbnMgb2YgSUVURiBzdGFuZGFyZHMuICANCg0KV2hlbjogU2F0 dXJkYXkgQXByaWwgMiBhbmQgU3VuZGF5IEFwcmlsIDMNCldoZXJlOiBIaWx0b24gQnVlbm9zIEFp cmVzLCBSb29tIFRCRA0KU2lnbnVwIGZvciB0aGUgSGFja2F0aG9uOiBodHRwczovL3d3dy5pZXRm Lm9yZy9yZWdpc3RyYXRpb24vaWV0Zjk1L2hhY2thdGhvbnJlZ2lzdHJhdGlvbi5weQ0KTW9yZSBp bmZvcm1hdGlvbiBjYW4gYmUgZm91bmQgaGVyZTogaHR0cDovL2lldGYub3JnL2hhY2thdGhvbi85 NS1oYWNrYXRob24uaHRtbA0KS2VlcCB1cCB0byBkYXRlIGJ5IHN1YnNjcmliaW5nIHRvOiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2hhY2thdGhvbg0KDQpUaGUgSGFja2F0 aG9uIGlzIGZyZWUgdG8gYXR0ZW5kIGFuZCBvcGVuIHRvIGFsbC4gRXh0ZW5kIHRoZSBpbnZpdGF0 aW9uIHRvIGNvbGxlYWd1ZXMgb3V0c2lkZSB0aGUgSUVURiENCg0KSGVyZeKAmXMgd2hhdCBoYXBw ZW5lZCBhdCB0aGUgSGFja2F0aG9uIGluIFlva29oYW1hIGF0IElFVEYgOTQgKGJsb2cgcG9zdCk6 ICANCmh0dHBzOi8vY29tbXVuaXRpZXMuY2lzY28uY29tL2NvbW11bml0eS9kZXZlbG9wZXIvb3Bl bnNvdXJjZS9ibG9nLzIwMTUvMTEvMTIvaWV0Zi05NC1oYWNrYXRob24tb3Blbi1zb3VyY2UtYW5k LW9wZW4tc3RhbmRhcmRzLWluLXlva29oYW1hDQoNClRoZXNlIGJyaWVmIHZpZGVvcyBmcm9tIHRo ZSBJRVRGIDkzIEhhY2thdGhvbiBpbiBQcmFndWUgZXhwbGFpbiBtb3JlIGFib3V0IGhvdyBJRVRG IEhhY2thdGhvbnMgd29yazogaHR0cHM6Ly95b3V0dS5iZS9lbVotcElKTERsZz9saXN0PVBMQzg2 VC02WlRQNWc4N2pkeE5xZFdWNTQ3NVUteUVFOE0NCg0KVG8gc2VlIHRoZSBjdXJyZW50IGxpc3Qg b2YgdGVjaG5vbG9naWVzIHBsYW5uZWQgZm9yIHRoZSBJRVRGIDk1IEhhY2thdGhvbiwgb3IgdG8g dm9sdW50ZWVyIHRvIGNoYW1waW9uIGFkZGl0aW9uYWwgdGVjaG5vbG9naWVzLCB2aXNpdCB0aGUg SUVURiA5NSBNZWV0aW5nIFdpa2k6IGh0dHBzOi8vd3d3LmlldGYub3JnL3JlZ2lzdHJhdGlvbi9N ZWV0aW5nV2lraS93aWtpLzk1aGFja2F0aG9uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpSZWNlbnRhdHRlbmRlZXMgbWFpbGluZyBsaXN0DQpSZWNl bnRhdHRlbmRlZXNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcmVjZW50YXR0ZW5kZWVzDQo= From nobody Mon Jan 11 05:59:57 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86791A00CF for ; Mon, 11 Jan 2016 05:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.202 X-Spam-Level: X-Spam-Status: No, score=-6.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCc9cU9LKj6d for ; Mon, 11 Jan 2016 05:59:54 -0800 (PST) Received: from ndjsvnpf103.ndc.nasa.gov (NDJSVNPF103.ndc.nasa.gov [198.117.1.153]) by ietfa.amsl.com (Postfix) with ESMTP id 447551A00D0 for ; Mon, 11 Jan 2016 05:59:54 -0800 (PST) Received: from ndjsppt105.ndc.nasa.gov (ndjsppt105.ndc.nasa.gov [198.117.1.199]) by ndjsvnpf103.ndc.nasa.gov (Postfix) with ESMTP id D6FD2400EE32; Mon, 11 Jan 2016 07:59:53 -0600 (CST) Received: from NDJSCHT103.ndc.nasa.gov (ndjscht103-pub.ndc.nasa.gov [198.117.1.203]) by ndjsppt105.ndc.nasa.gov (8.15.0.59/8.15.0.59) with ESMTP id u0BDxrYK001609; Mon, 11 Jan 2016 07:59:53 -0600 Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.136]) by NDJSCHT103.ndc.nasa.gov ([198.117.1.203]) with mapi id 14.03.0266.001; Mon, 11 Jan 2016 07:59:53 -0600 From: "Ivancic, William D. (GRC-LCA0)" To: "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] FW: [Recentattendees] IETF 95 Hackathon in Buenos Aires Thread-Index: AQHRTHhYHDyyaleM7kW1T/7dRnI1kg== Date: Mon, 11 Jan 2016 13:59:52 +0000 Message-ID: References: <20151223164729.13967.21303.idtracker@ietfa.amsl.com> <5adeaf7d64244c47b2eb1654ce09b505@rew09926dag03b.domain1.systemhost.net> In-Reply-To: <5adeaf7d64244c47b2eb1654ce09b505@rew09926dag03b.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-originating-ip: [184.56.61.175] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <959606DAAA05AC45B5B29AE4574F9FF6@mail.nasa.gov> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-01-11_09:, , signatures=0 Archived-At: Subject: Re: [multipathtcp] FW: [Recentattendees] IETF 95 Hackathon in Buenos Aires X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 13:59:55 -0000 I was wondering if a hackathon is planned. Although I am not a coder, I have someone I would like to bring and get involved. I am starting work my travel plans to the sooner I know the better. Thanks, Will Ivancic On 1/11/16 3:51 AM, "multipathtcp on behalf of philip.eardley@bt.com" wrote: >Is there interest in joining the hackathon this time? > > > >-----Original Message----- >From: Recentattendees [mailto:recentattendees-bounces@ietf.org] On Behalf >Of IETF Secretariat >Sent: 23 December 2015 16:47 >To: IETF Announcement List >Cc: recentattendees@ietf.org; 95all@ietf.org >Subject: [Recentattendees] IETF 95 Hackathon in Buenos Aires > >The Internet Engineering Task Force (IETF) is holding a Hackathon at IETF >95 to encourage developers to discuss, collaborate and develop utilities, >ideas, sample code and solutions that show practical implementations of >IETF standards. =20 > >When: Saturday April 2 and Sunday April 3 >Where: Hilton Buenos Aires, Room TBD >Signup for the Hackathon: >https://www.ietf.org/registration/ietf95/hackathonregistration.py >More information can be found here: >http://ietf.org/hackathon/95-hackathon.html >Keep up to date by subscribing to: >https://www.ietf.org/mailman/listinfo/hackathon > >The Hackathon is free to attend and open to all. Extend the invitation to >colleagues outside the IETF! > >Here=B9s what happened at the Hackathon in Yokohama at IETF 94 (blog post)= : >=20 >https://communities.cisco.com/community/developer/opensource/blog/2015/11/ >12/ietf-94-hackathon-open-source-and-open-standards-in-yokohama > >These brief videos from the IETF 93 Hackathon in Prague explain more >about how IETF Hackathons work: >https://youtu.be/emZ-pIJLDlg?list=3DPLC86T-6ZTP5g87jdxNqdWV5475U-yEE8M > >To see the current list of technologies planned for the IETF 95 >Hackathon, or to volunteer to champion additional technologies, visit the >IETF 95 Meeting Wiki: >https://www.ietf.org/registration/MeetingWiki/wiki/95hackathon > >_______________________________________________ >Recentattendees mailing list >Recentattendees@ietf.org >https://www.ietf.org/mailman/listinfo/recentattendees >_______________________________________________ >multipathtcp mailing list >multipathtcp@ietf.org >https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Mon Jan 11 08:37:02 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5721A876F for ; Mon, 11 Jan 2016 08:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.302 X-Spam-Level: X-Spam-Status: No, score=-6.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xh6cvFsUhf62 for ; Mon, 11 Jan 2016 08:36:58 -0800 (PST) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29E1E1A8A90 for ; Mon, 11 Jan 2016 08:36:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1452530215; x=2316443815; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dhWL/frJ0ZlMiqHUautDriT689AdfdQucjzw+m1jEfI=; b=q4I0tI7mAEqpLMui2EACE2nRl1byuAvq9tkVQgOV/ZWNPsK+bZosCevI3WMRRQ69 xwhl9hVVbQ+y1s1+tGos7JQxp9mjwsIFxpivukEQVsd6ESA9MTn5zOl0/Ijd9y6i Th1eGw9hFAjbj1VP9AkAquWnH3s+ePILnerUBccYykhaVA4KZTjay8zCLhCVpU01 OqBAaZnMKnVMIBDRdplYuhuNB3ZwSEwv8uS2kivBqBTK4+HB32riEZduRlI86YHH m3TTAZKKQ8rg8+h44KwupZP5qWEGQK33h4CC9L07XaRqYPHFLyFgpysxrrk5aTXH IH92EH3HLLnOa6ElV4Izlw==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id A3.C8.27232.72AD3965; Mon, 11 Jan 2016 08:36:55 -0800 (PST) X-AuditID: 11973e15-f79366d000006a60-97-5693da277c63 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 60.A4.29028.72AD3965; Mon, 11 Jan 2016 08:36:55 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-disposition: inline Content-type: text/plain; charset=iso-8859-1 Received: from localhost ([17.149.220.226]) by spicerack.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O0S00B4QRHJLG70@spicerack.apple.com> for multipathtcp@ietf.org; Mon, 11 Jan 2016 08:36:55 -0800 (PST) Sender: cpaasch@apple.com Date: Mon, 11 Jan 2016 08:36:55 -0800 From: Christoph Paasch To: "Ivancic, William D. (GRC-LCA0)" Message-id: <20160111163655.GL29760@Chimay.local> References: <20151223164729.13967.21303.idtracker@ietfa.amsl.com> <5adeaf7d64244c47b2eb1654ce09b505@rew09926dag03b.domain1.systemhost.net> In-reply-to: User-Agent: Mutt/1.5.24 (08e81162482f) (2015-08-30) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUi2FCYpqt+a3KYwbTPuhafV19nc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpRTy1gLfotVXH/TztLAuEq4i5GTQ0LAROLQ+8lMELaYxIV7 69m6GLk4hAT2MUqc2N3CCFN0s/07K0RiHpNE55+XzCAJXgFBiR+T77F0MXJwMAvISxy5lA0S ZhaQlnj0dwY7hK0j0fv9GzNE7wQmif5l88F6hQUkJbrv3AGzWQRUJZoOHgZrYBPQknh7u50V xBYRcJS4MeMPI8T8NImbx+0hWkMlzj+awAYS5hUwlLh5NAFi/C5GiaerFoGN4RSwkLg5cRPY Y6ICxhJNR+aA3SAhsIVNYtnFDUwTGEVnIXlhFsILs5C8MAvJCwsYWVYxCuUmZuboZuaZ6SUW FOSk6iXn525iBEXDdDvRHYxnVlkdYhTgYFTi4Z2xa1KYEGtiWXFl7iFGaQ4WJXHeQ2eAQgLp iSWp2ampBalF8UWlOanFhxiZODilGhgnyy5p81tUUf+30Xeh5O/Fjr+vvbQqPL9RulCrrcqD UyVXjf20waOlQnb529cV/1gSZ/GCxb6FUcwgp8hV492PmFXPlV7d/ZplVaL31KL1U9oe5mt3 t9/IV+H/zjubw8D+62KGY1Mup2yatHg/+4oj308/YXY8uutOQNDW/BdrfXQsmfMW3HdVYinO SDTUYi4qTgQAKx9FSWcCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42IRbCjW0FW/NTnMoPuItsXn1dfZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMeXUMtaC32IV19+0szQwrhLuYuTkkBAwkbjZ/p0VwhaTuHBv PVsXIxeHkMA8JonOPy+ZQRK8AoISPybfY+li5OBgFpCXOHIpGyTMLCAt8ejvDHYIW0ei9/s3 ZojeCUwS/cvmg/UKC0hKdN+5A2azCKhKNB08DNbAJqAl8fZ2O9hiEQFHiRsz/jBCzE+TuHnc HqI1VOL8owlsIGFeAUOJm0cTIMbvYpR4umoR2BhOAQuJmxM3MYHYogLGEk1H5jBPYBSaheTq WQhXz0Jy9SwkVy9gZFnFKFCUmpNYaaGXWFCQk6qXnJ+7iREcvIVpOxibllsdYhTgYFTi4Z2x a1KYEGtiWXFl7iFGCQ5mJRFete2Tw4R4UxIrq1KL8uOLSnNSiw8xJgO9O5FZSjQ5HxhZeSXx hiYmBibGxmbGxuYm5qQJK4nzHpPsCRMSSE8sSc1OTS1ILYLZwsTBKdXAqDTvwUbLTU2RpiY1 1rM0TlTsLQhIOqV1PXa7btMhgYOXOWYEPhSX8cl1t7p4rlPfufX52v1uTdMneHNvj/m0b8k9 j44ZodN5TjFN0mgUSenj1tu3yEBtUozeHCsPhfOL19+w+C7HLeXc+cJOO8/i4N2IR9cU6n3j 3vI3rDRX+5zDFOiruGezEktxRqKhFnNRcSIA2+m1vKICAAA= Archived-At: Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] FW: [Recentattendees] IETF 95 Hackathon in Buenos Aires X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 16:37:01 -0000 Hello, On 11/01/16 - 13:59:52, Ivancic, William D. (GRC-LCA0) wrote: > I was wondering if a hackathon is planned. Although I am not a coder, I > have someone I would like to bring and get involved. I am starting work > my travel plans to the sooner I know the better. I will be there (at least on Sunday). I can come to the Hackathon, if people want help,... for their Linux Kernel project. Christoph > > Thanks, > > Will Ivancic > > On 1/11/16 3:51 AM, "multipathtcp on behalf of philip.eardley@bt.com" > wrote: > > >Is there interest in joining the hackathon this time? > > > > > > > >-----Original Message----- > >From: Recentattendees [mailto:recentattendees-bounces@ietf.org] On Behalf > >Of IETF Secretariat > >Sent: 23 December 2015 16:47 > >To: IETF Announcement List > >Cc: recentattendees@ietf.org; 95all@ietf.org > >Subject: [Recentattendees] IETF 95 Hackathon in Buenos Aires > > > >The Internet Engineering Task Force (IETF) is holding a Hackathon at IETF > >95 to encourage developers to discuss, collaborate and develop utilities, > >ideas, sample code and solutions that show practical implementations of > >IETF standards. > > > >When: Saturday April 2 and Sunday April 3 > >Where: Hilton Buenos Aires, Room TBD > >Signup for the Hackathon: > >https://www.ietf.org/registration/ietf95/hackathonregistration.py > >More information can be found here: > >http://ietf.org/hackathon/95-hackathon.html > >Keep up to date by subscribing to: > >https://www.ietf.org/mailman/listinfo/hackathon > > > >The Hackathon is free to attend and open to all. Extend the invitation to > >colleagues outside the IETF! > > > >Here¹s what happened at the Hackathon in Yokohama at IETF 94 (blog post): > > > >https://communities.cisco.com/community/developer/opensource/blog/2015/11/ > >12/ietf-94-hackathon-open-source-and-open-standards-in-yokohama > > > >These brief videos from the IETF 93 Hackathon in Prague explain more > >about how IETF Hackathons work: > >https://youtu.be/emZ-pIJLDlg?list=PLC86T-6ZTP5g87jdxNqdWV5475U-yEE8M > > > >To see the current list of technologies planned for the IETF 95 > >Hackathon, or to volunteer to champion additional technologies, visit the > >IETF 95 Meeting Wiki: > >https://www.ietf.org/registration/MeetingWiki/wiki/95hackathon > > > >_______________________________________________ > >Recentattendees mailing list > >Recentattendees@ietf.org > >https://www.ietf.org/mailman/listinfo/recentattendees > >_______________________________________________ > >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 nobody Tue Jan 12 00:25:08 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37FB31A1C06 for ; Tue, 12 Jan 2016 00:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.224 X-Spam-Level: ** X-Spam-Status: No, score=2.224 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHpSaVtEPczV for ; Tue, 12 Jan 2016 00:25:05 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6262B1A1C00 for ; Tue, 12 Jan 2016 00:25:04 -0800 (PST) Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 2642227810B for ; Tue, 12 Jan 2016 17:25:03 +0900 (JST) Received: by mail-qk0-f172.google.com with SMTP id n135so241889447qka.2 for ; Tue, 12 Jan 2016 00:25:03 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.129.31.67 with SMTP id f64mr94216988ywf.94.1452587101604; Tue, 12 Jan 2016 00:25:01 -0800 (PST) Received: by 10.13.196.3 with HTTP; Tue, 12 Jan 2016 00:25:01 -0800 (PST) Date: Tue, 12 Jan 2016 00:25:01 -0800 X-Gmail-Original-Message-ID: Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: multipart/alternative; boundary=001a1141ed3c32587f05291eca3d Archived-At: Subject: [multipathtcp] several comments on draft-paasch-mptcp-syncookies-02 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 08:25:07 -0000 --001a1141ed3c32587f05291eca3d Content-Type: text/plain; charset=UTF-8 Hello, I've read syscoockies-02 draft. I think it looks good, but I would like to clarify the following points. 1: Page 7: An indication for the client that the server received the key is when the server issues a DATA_ACK... -> It seems that the server needs to send DATA_ACK if it receives MP_CAPABLE for this. However, in my understanding, RFC6824bis doesn't mandate to send DATA_ACK. If this is mandatory, I guess we'll need to mention it explicitly. 2: Page 7: This mechanism of sending the MP_CAPABLE with a DATA_ACK until the server acknowledge it.... -> Do you mean "This mechanism of sending MP_CAPABLE until the arrival of DATA_ACK from sender"? 3: Page 8: Section 3.1.2 However, the client receiving this data send by... -> Is there a case where we cannot put MP_CAPABLE and DATA_ACK together? 4: Page 8: Section 3.1.3 -> Don't we need to describe what we should do if the server doesn't this version? 5: Section 3.2 It should respond with a Data ACK set to... -> I think we should mention which tcp-ack num is used here. it'll be X? 6: Page 1: Title It seems to me that the title indicate that it is only for stateless webservers. If this draft will be merged into 6824bis, it might not be a problem. However, if this draft will be a separate draft and will be the standard mechanism for mptcp session establishment, I personally would like to think about changing the title. Thanks. -- Yoshi --001a1141ed3c32587f05291eca3d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I've read syscoockies-02 dra= ft. I think it looks good, but I would like to clarify the following points= .=C2=A0

1: Page 7:
=C2=A0 =C2=A0 =C2=A0A= n indication for the client that the server received the key is when the se= rver issues a DATA_ACK...
=C2=A0
=C2=A0 -> It seems = that the server needs to send DATA_ACK if it receives MP_CAPABLE for this. = However, in my understanding, RFC6824bis doesn't mandate to send DATA_A= CK. =C2=A0
=C2=A0 =C2=A0 =C2=A0 If this is mandatory, I guess= we'll need to mention it explicitly.

2: Page = 7:=C2=A0
=C2=A0 =C2=A0 This mechanism of sending the MP_CAPABLE w= ith a DATA_ACK until the server acknowledge it....
=C2=A0
=C2=A0 =C2=A0-> Do you mean "This mechanism of sending MP_CAPABL= E until the arrival of =C2=A0DATA_ACK from sender"?=C2=A0
3: Page 8: Section 3.1.2
=C2=A0 =C2=A0 However, the = client receiving this data send by...
=C2=A0
=C2=A0 =C2= =A0 -> Is there a case where we cannot put MP_CAPABLE and DATA_ACK toget= her?

4: Page 8: Section 3.1.3

=
=C2=A0 =C2=A0 -> Don't we need to describe what we should do if= the server doesn't this version?

5: Section 3= .2

=C2=A0 =C2=A0It should respond with a Data ACK = set to...
=C2=A0 =C2=A0 -> I think we should mention which tcp= -ack num is used here. it'll be X?

6: Page 1: = Title

=C2=A0 =C2=A0It seems to me that the title i= ndicate that it is only for stateless webservers.=C2=A0
=C2=A0 = =C2=A0If this draft will be merged into 6824bis, it might not be a problem.=
=C2=A0 =C2=A0However, if this draft will be a separate draft and= will be the standard mechanism for mptcp session establishment, I personal= ly would like to think about changing the title.=C2=A0

=
Thanks.
--
Yoshi
--001a1141ed3c32587f05291eca3d-- From nobody Tue Jan 12 08:23:30 2016 Return-Path: X-Original-To: multipathtcp@ietf.org Delivered-To: multipathtcp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9511B2B1F; Tue, 12 Jan 2016 08:23:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160112162327.17170.70483.idtracker@ietfa.amsl.com> Date: Tue, 12 Jan 2016 08:23:27 -0800 Archived-At: Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-05.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 16:23:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multipath TCP Working Group of the IETF. Title : TCP Extensions for Multipath Operation with Multiple Addresses Authors : Alan Ford Costin Raiciu Mark Handley Olivier Bonaventure Christoph Paasch Filename : draft-ietf-mptcp-rfc6824bis-05.txt Pages : 71 Date : 2016-01-12 Abstract: 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 it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC6824 [5] through clarifications and modifications primarily driven by deployment experience. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mptcp-rfc6824bis-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 12 08:26:58 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9221B2B2D for ; Tue, 12 Jan 2016 08:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAwckd9mA1MQ for ; Tue, 12 Jan 2016 08:26:54 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB9FB1A0419 for ; Tue, 12 Jan 2016 08:26:27 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id g73so193372043ioe.3 for ; Tue, 12 Jan 2016 08:26:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=HLcvI8G3pL+a3jF3d1fgzl7jACS7gZaKWkcdlgkHQMs=; b=ZbYZRyip7kBwJcNAzrh3CR0g5R5vyBpMYW6YNYojBEcZeadvg/BvPSLjCrByGiA66x FgIV9q3MTkzMci6FadOHqL2OkC6FTNh3rfz+ZX3fJhf4g6isrW36rXlVtNwL1b6MB7j3 vTmc8qnvJHXJcveMyULGLbpOQ0fRoKwZsQxQT2oJgTB3hEblv8YvDQP2bTO4DC8/sG9M e0fw15Lr8e1Dreq5o++sJs9cdoVahwq1I8P/4aaITP1GEamiGRyZZ8GeOiVDBCses7di yEJPU/B7GVWnVQy+1iEOnVPR/CqhWa5sNz+C6RwvmJY85tWvtTnRFjlHIPChVjKyLWMJ hedA== MIME-Version: 1.0 X-Received: by 10.107.43.138 with SMTP id r132mr133613409ior.7.1452615987245; Tue, 12 Jan 2016 08:26:27 -0800 (PST) Received: by 10.64.102.234 with HTTP; Tue, 12 Jan 2016 08:26:27 -0800 (PST) In-Reply-To: <20160112162327.17170.70483.idtracker@ietfa.amsl.com> References: <20160112162327.17170.70483.idtracker@ietfa.amsl.com> Date: Tue, 12 Jan 2016 16:26:27 +0000 Message-ID: From: Alan Ford To: "multipathtcp@ietf.org" Content-Type: multipart/alternative; boundary=001a1139793cea37230529258320 Archived-At: Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-05.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 16:26:57 -0000 --001a1139793cea37230529258320 Content-Type: text/plain; charset=UTF-8 Hi all, This long-awaited update to rfc6824bis draft contains - as agreed - new handshake as described in the syncookies draft, experimental option, renumbering of ADD_ADDR2 back to ADD_ADDR given it's a new version, and a number of clarifications and corrections based on comments. It is very likely that the handshake presented here will not be the final v1 handshake so please do not implement anything in production based on this. We as a group still need to decide what to do about the loadbalancers issue and potential separation of token and key. Regards, Alan On 12 January 2016 at 16:23, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multipath TCP Working Group of the IETF. > > Title : TCP Extensions for Multipath Operation with > Multiple Addresses > Authors : Alan Ford > Costin Raiciu > Mark Handley > Olivier Bonaventure > Christoph Paasch > Filename : draft-ietf-mptcp-rfc6824bis-05.txt > Pages : 71 > Date : 2016-01-12 > > Abstract: > 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 it provides the components necessary to establish > and use multiple TCP flows across potentially disjoint paths. > > This document specifies v1 of Multipath TCP, obsoleting v0 as > specified in RFC6824 [5] through clarifications and modifications > primarily driven by deployment experience. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-mptcp-rfc6824bis-05 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > --001a1139793cea37230529258320 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

This long-awaited update to rfc= 6824bis draft contains - as agreed - new handshake as described in the sync= ookies draft, experimental option, renumbering of ADD_ADDR2 back to ADD_ADD= R given it's a new version, and a number of clarifications and correcti= ons based on comments.

It is very likely that the = handshake presented here will not be the final v1 handshake so please do no= t implement anything in production based on this. We as a group still need = to decide what to do about the loadbalancers issue and potential separation= of token and key.

Regards,
Alan

On 12 January= 2016 at 16:23, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Multipath TCP Working Group of the I= ETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= TCP Extensions for Multipath Operation with Multiple Addresses
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Alan= Ford
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Costin Raiciu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Mark Handley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Olivier Bonaventure
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Christoph Paasch
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mptcp-rfc6824bis-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 71
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-01-12

Abstract:
=C2=A0 =C2=A0TCP/IP communication is currently restricted to a single path = per
=C2=A0 =C2=A0connection, yet multiple paths often exist between peers.=C2= =A0 The
=C2=A0 =C2=A0simultaneous use of these multiple paths for a TCP/IP session = would
=C2=A0 =C2=A0improve resource usage within the network and, thus, improve u= ser
=C2=A0 =C2=A0experience through higher throughput and improved resilience t= o
=C2=A0 =C2=A0network failure.

=C2=A0 =C2=A0Multipath TCP provides the ability to simultaneously use multi= ple
=C2=A0 =C2=A0paths between peers.=C2=A0 This document presents a set of ext= ensions to
=C2=A0 =C2=A0traditional TCP to support multipath operation.=C2=A0 The prot= ocol offers
=C2=A0 =C2=A0the same type of service to applications as TCP (i.e., reliabl= e
=C2=A0 =C2=A0bytestream), and it provides the components necessary to estab= lish
=C2=A0 =C2=A0and use multiple TCP flows across potentially disjoint paths.<= br>
=C2=A0 =C2=A0This document specifies v1 of Multipath TCP, obsoleting v0 as<= br> =C2=A0 =C2=A0specified in RFC6824 [5] through clarifications and modificati= ons
=C2=A0 =C2=A0primarily driven by deployment experience.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-= ietf-mptcp-rfc6824bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mp= tcp-rfc6824bis-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-mptcp-rfc6824bis-05


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp=

--001a1139793cea37230529258320-- From nobody Tue Jan 12 08:27:55 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4851B2B18 for ; Tue, 12 Jan 2016 08:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IY3GhF-4tAwc for ; Tue, 12 Jan 2016 08:27:52 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 797551B2B41 for ; Tue, 12 Jan 2016 08:27:29 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id q21so388869088iod.0 for ; Tue, 12 Jan 2016 08:27:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=H8zx+3HjAcqz2xrO3f1klEjcnWsfn+fDQgaWM8F1S5o=; b=BrXX2FvpmQRDvlqLXZPNsTYalGgQh+nWpiNFZuRCr/g97FZEFWB41CNVc/jODgp93z a3ok686jHo9ZJcpMvgRZwJJhCtp1jgoThd4vhZvT3rxkg5D5ZA6TFtIerjaIuvypHqYm gDUmTGP1QrjeSKWxLyhEuPYoDUtzl7R5QM9/95nUyf9ZGHYMBcYuYepRbceeT2y65Z0B 2fWVvoQ6FH8MfI1H4dXmIXtrZ4at/CzYLwQryRK5Kl6g1sDuJzjfDA5q44f10/ZIn7My T4+wMpBERjrLYyvwazPlOXH0ih8F9VhPdEJhYwAzZPOhDxJKayd5dYSxyxNv4vkhEXBR 8qDQ== MIME-Version: 1.0 X-Received: by 10.107.185.6 with SMTP id j6mr116857215iof.111.1452616048835; Tue, 12 Jan 2016 08:27:28 -0800 (PST) Received: by 10.64.102.234 with HTTP; Tue, 12 Jan 2016 08:27:28 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Jan 2016 16:27:28 +0000 Message-ID: From: Alan Ford To: "multipathtcp@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0866389600bc0529258782 Archived-At: Subject: Re: [multipathtcp] several comments on draft-paasch-mptcp-syncookies-02 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 16:27:54 -0000 --94eb2c0866389600bc0529258782 Content-Type: text/plain; charset=UTF-8 Hi Yoshi, I believe most of these points are addressed by the tailored wording now introduced in the latest 6824bis draft. If anything there does not make sense please let us know! Cheers, Alan On 12 January 2016 at 08:25, Yoshifumi Nishida wrote: > Hello, > > I've read syscoockies-02 draft. I think it looks good, but I would like to > clarify the following points. > > 1: Page 7: > An indication for the client that the server received the key is when > the server issues a DATA_ACK... > > -> It seems that the server needs to send DATA_ACK if it receives > MP_CAPABLE for this. However, in my understanding, RFC6824bis doesn't > mandate to send DATA_ACK. > If this is mandatory, I guess we'll need to mention it explicitly. > > 2: Page 7: > This mechanism of sending the MP_CAPABLE with a DATA_ACK until the > server acknowledge it.... > > -> Do you mean "This mechanism of sending MP_CAPABLE until the arrival > of DATA_ACK from sender"? > > 3: Page 8: Section 3.1.2 > However, the client receiving this data send by... > > -> Is there a case where we cannot put MP_CAPABLE and DATA_ACK > together? > > 4: Page 8: Section 3.1.3 > > -> Don't we need to describe what we should do if the server doesn't > this version? > > 5: Section 3.2 > > It should respond with a Data ACK set to... > -> I think we should mention which tcp-ack num is used here. it'll be > X? > > 6: Page 1: Title > > It seems to me that the title indicate that it is only for stateless > webservers. > If this draft will be merged into 6824bis, it might not be a problem. > However, if this draft will be a separate draft and will be the > standard mechanism for mptcp session establishment, I personally would like > to think about changing the title. > > Thanks. > -- > Yoshi > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > --94eb2c0866389600bc0529258782 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Yoshi,

I believe most of these point= s are addressed by the tailored wording now introduced in the latest 6824bi= s draft. If anything there does not make sense please let us know!

Cheers,
Alan

On 12 January 2016 at 08:25, Yoshifumi Ni= shida <nishida@sfc.wide.ad.jp> wrote:
Hello,

I've read s= yscoockies-02 draft. I think it looks good, but I would like to clarify the= following points.=C2=A0

1: Page 7:
=C2= =A0 =C2=A0 =C2=A0An indication for the client that the server received the = key is when the server issues a DATA_ACK...
=C2=A0
=C2= =A0 -> It seems that the server needs to send DATA_ACK if it receives MP= _CAPABLE for this. However, in my understanding, RFC6824bis doesn't man= date to send DATA_ACK. =C2=A0
=C2=A0 =C2=A0 =C2=A0 If this is= mandatory, I guess we'll need to mention it explicitly.

=
2: Page 7:=C2=A0
=C2=A0 =C2=A0 This mechanism of sendi= ng the MP_CAPABLE with a DATA_ACK until the server acknowledge it....
=
=C2=A0
=C2=A0 =C2=A0-> Do you mean "This mechanism o= f sending MP_CAPABLE until the arrival of =C2=A0DATA_ACK from sender"?= =C2=A0

3: Page 8: Section 3.1.2
=C2=A0 = =C2=A0 However, the client receiving this data send by...
=C2=A0<= /div>
=C2=A0 =C2=A0 -> Is there a case where we cannot put MP_CAPABL= E and DATA_ACK together?

4: Page 8: Section 3.1.3<= /div>

=C2=A0 =C2=A0 -> Don't we need to describe = what we should do if the server doesn't this version?

5: Section 3.2

=C2=A0 =C2=A0It should resp= ond with a Data ACK set to...
=C2=A0 =C2=A0 -> I think we shou= ld mention which tcp-ack num is used here. it'll be X?

6: Page 1: Title

=C2=A0 =C2=A0It seems to= me that the title indicate that it is only for stateless webservers.=C2=A0=
=C2=A0 =C2=A0If this draft will be merged into 6824bis, it might= not be a problem.
=C2=A0 =C2=A0However, if this draft will be a = separate draft and will be the standard mechanism for mptcp session establi= shment, I personally would like to think about changing the title.=C2=A0

Thanks.
--
Yoshi

_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp=


--94eb2c0866389600bc0529258782-- From nobody Tue Jan 12 13:11:17 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A612E1A039F; Tue, 12 Jan 2016 13:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.903 X-Spam-Level: X-Spam-Status: No, score=-101.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMv3rPMJhE3W; Tue, 12 Jan 2016 13:11:12 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id B40E51A8941; Tue, 12 Jan 2016 13:11:00 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id E778218000F; Tue, 12 Jan 2016 13:10:12 -0800 (PST) To: friedrich@haussmann.tel, alanford@cisco.com, costin.raiciu@cs.pub.ro, m.handley@cs.ucl.ac.uk, olivier.bonaventure@uclouvain.be X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160112211012.E778218000F@rfc-editor.org> Date: Tue, 12 Jan 2016 13:10:12 -0800 (PST) Archived-At: Cc: multipathtcp@ietf.org, mls.ietf@gmail.com, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [multipathtcp] [Errata Verified] RFC6824 (4129) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 21:11:13 -0000 The following errata report has been verified for RFC6824, "TCP Extensions for Multipath Operation with Multiple Addresses". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6824&eid=4129 -------------------------------------- Status: Verified Type: Technical Reported by: Friedrich Haussmann Date Reported: 2014-10-11 Verified by: Martin Stiemerling (IESG) Section: B.1.1. Original Text ------------- MPTCP.Checksum (flag): This flag is set to true if at least one of the hosts has set the C bit in the MP_CAPABLE options exchanged during connection establishment, and is set to false otherwise. If this flag is set, the checksum must be computed in all DSS options. Corrected Text -------------- MPTCP.Checksum (flag): This flag is set to true if at least one of the hosts has set the A bit in the MP_CAPABLE options exchanged during connection establishment, and is set to false otherwise. If this flag is set, the checksum must be computed in all DSS options. Notes ----- Checksum is not on bit "C", but instead on bit "A". There are no other instances of referring on bit "C" as the checksum. Bit "C" is unassigned in this version. Other instances of bit "A" as checksum: * Section 3.1. Connection Initiation, p. 16 f. * Section 8. IANA Considerations, Table 3: MPTCP Handshake Algorithms, p. 56 -------------------------------------- RFC6824 (draft-ietf-mptcp-multiaddressed-12) -------------------------------------- Title : TCP Extensions for Multipath Operation with Multiple Addresses Publication Date : January 2013 Author(s) : A. Ford, C. Raiciu, M. Handley, O. Bonaventure Category : EXPERIMENTAL Source : Multipath TCP Area : Transport Stream : IETF Verifying Party : IESG From nobody Tue Jan 12 15:06:52 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A281D1A8942; Tue, 12 Jan 2016 13:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.903 X-Spam-Level: X-Spam-Status: No, score=-101.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIDU4kugFy3O; Tue, 12 Jan 2016 13:13:02 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 396BC1A8941; Tue, 12 Jan 2016 13:13:02 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 74ACF18000F; Tue, 12 Jan 2016 13:12:13 -0800 (PST) To: fabrizio.demaria@intel.com, marcelo@it.uc3m.es, christoph.paasch@gmail.com, fgont@si6networks.com, Olivier.Bonaventure@uclouvain.be, costin.raiciu@cs.pub.ro X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160112211214.74ACF18000F@rfc-editor.org> Date: Tue, 12 Jan 2016 13:12:13 -0800 (PST) Archived-At: X-Mailman-Approved-At: Tue, 12 Jan 2016 15:06:49 -0800 Cc: multipathtcp@ietf.org, mls.ietf@gmail.com, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [multipathtcp] [Errata Verified] RFC7430 (4565) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 21:13:03 -0000 The following errata report has been verified for RFC7430, "Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7430&eid=4565 -------------------------------------- Status: Verified Type: Technical Reported by: Fabrizio Demaria Date Reported: 2015-12-14 Verified by: Martin Stiemerling (IESG) Section: 6 Original Text ------------- Summary of the attack: Type of attack: An attacker that can intercept the SYN/JOIN message can alter the source address being added. Type of attacker: partial-time on-path eavesdropper Description: The attacker is present along the path when the SYN/JOIN exchange takes place. This allows the attacker to add any new address it wants to by simply substituting the source address of the SYN/JOIN packet for one it chooses. This vulnerability was readily identified when designing the MPTCP security solution [RFC6181], and the threat was considered acceptable. Corrected Text -------------- Summary of the attack: Type of attack: An attacker that can intercept the SYN/JOIN message can alter the source address being added. Type of attacker: partial-time on-path active attacker Description: The attacker is present along the path when the SYN/JOIN exchange takes place. This allows the attacker to add any new address it wants to by simply substituting the source address of the SYN/JOIN packet for one it chooses. This vulnerability was readily identified when designing the MPTCP security solution [RFC6181], and the threat was considered acceptable. Notes ----- As noted in section 1, an active attacker is able to change, discard, or delay some of the packets of the MPTCP session. This coincide with the description of the SYN/JOIN attack in section 6. -------------------------------------- RFC7430 (draft-ietf-mptcp-attacks-04) -------------------------------------- Title : Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP) Publication Date : July 2015 Author(s) : M. Bagnulo, C. Paasch, F. Gont, O. Bonaventure, C. Raiciu Category : INFORMATIONAL Source : Multipath TCP Area : Transport Stream : IETF Verifying Party : IESG From nobody Wed Jan 13 00:29:12 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00EA1AC3D3 for ; Wed, 13 Jan 2016 00:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.23 X-Spam-Level: * X-Spam-Status: No, score=1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U52G1muM91fn for ; Wed, 13 Jan 2016 00:29:07 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 835A11AC3CF for ; Wed, 13 Jan 2016 00:29:07 -0800 (PST) Received: from mail-yk0-f173.google.com (mail-yk0-f173.google.com [209.85.160.173]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 6C5D7278134 for ; Wed, 13 Jan 2016 17:29:05 +0900 (JST) Received: by mail-yk0-f173.google.com with SMTP id k129so458129750yke.0 for ; Wed, 13 Jan 2016 00:29:05 -0800 (PST) X-Gm-Message-State: ALoCoQl1/ry7qMrev49hEDlZa1BfJQWrWcykPCFPDEWvSk38GwzITcAJVn/xXZZ1gtp6wN/jNR+qNTkOJqZriBCJW5PMhzXSPA== MIME-Version: 1.0 X-Received: by 10.129.31.67 with SMTP id f64mr98464627ywf.94.1452673743383; Wed, 13 Jan 2016 00:29:03 -0800 (PST) Received: by 10.13.196.3 with HTTP; Wed, 13 Jan 2016 00:29:03 -0800 (PST) In-Reply-To: References: Date: Wed, 13 Jan 2016 00:29:03 -0800 X-Gmail-Original-Message-ID: Message-ID: From: Yoshifumi Nishida To: Alan Ford Content-Type: multipart/alternative; boundary=001a1141ed3c72fe36052932f658 Archived-At: Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] several comments on draft-paasch-mptcp-syncookies-02 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 08:29:09 -0000 --001a1141ed3c72fe36052932f658 Content-Type: text/plain; charset=UTF-8 Hi Alan, I see. The new 6824bis has a similar handshake mechanism in syn cookie draft. I will check it later. Thanks for the updates. --- Yoshi On Tue, Jan 12, 2016 at 8:27 AM, Alan Ford wrote: > Hi Yoshi, > > I believe most of these points are addressed by the tailored wording now > introduced in the latest 6824bis draft. If anything there does not make > sense please let us know! > > Cheers, > Alan > > On 12 January 2016 at 08:25, Yoshifumi Nishida > wrote: > >> Hello, >> >> I've read syscoockies-02 draft. I think it looks good, but I would like >> to clarify the following points. >> >> 1: Page 7: >> An indication for the client that the server received the key is >> when the server issues a DATA_ACK... >> >> -> It seems that the server needs to send DATA_ACK if it receives >> MP_CAPABLE for this. However, in my understanding, RFC6824bis doesn't >> mandate to send DATA_ACK. >> If this is mandatory, I guess we'll need to mention it explicitly. >> >> 2: Page 7: >> This mechanism of sending the MP_CAPABLE with a DATA_ACK until the >> server acknowledge it.... >> >> -> Do you mean "This mechanism of sending MP_CAPABLE until the arrival >> of DATA_ACK from sender"? >> >> 3: Page 8: Section 3.1.2 >> However, the client receiving this data send by... >> >> -> Is there a case where we cannot put MP_CAPABLE and DATA_ACK >> together? >> >> 4: Page 8: Section 3.1.3 >> >> -> Don't we need to describe what we should do if the server doesn't >> this version? >> >> 5: Section 3.2 >> >> It should respond with a Data ACK set to... >> -> I think we should mention which tcp-ack num is used here. it'll be >> X? >> >> 6: Page 1: Title >> >> It seems to me that the title indicate that it is only for stateless >> webservers. >> If this draft will be merged into 6824bis, it might not be a problem. >> However, if this draft will be a separate draft and will be the >> standard mechanism for mptcp session establishment, I personally would like >> to think about changing the title. >> >> Thanks. >> -- >> Yoshi >> >> _______________________________________________ >> 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 > > --001a1141ed3c72fe36052932f658 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alan,

I see. The new 6824bis has a similar handshake mechanism= in syn cookie draft.
I will check it later= . Thanks for the updates.
---
Yoshi

On Tue, Jan 12, 2016 at 8:27 AM, Alan Ford <alan.ford@g= mail.com> wrote:
Hi Yoshi,

I believe most of these points are ad= dressed by the tailored wording now introduced in the latest 6824bis draft.= If anything there does not make sense please let us know!

Cheers,
Alan

<= div class=3D"gmail_quote">
On 12 January 2016 at 08:2= 5, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
Hello,

I've read syscoockies-02 draft. I th= ink it looks good, but I would like to clarify the following points.=C2=A0<= /div>

1: Page 7:
=C2=A0 =C2=A0 =C2=A0An indica= tion for the client that the server received the key is when the server iss= ues a DATA_ACK...
=C2=A0
=C2=A0 -> It seems that the= server needs to send DATA_ACK if it receives MP_CAPABLE for this. However,= in my understanding, RFC6824bis doesn't mandate to send DATA_ACK. =C2= =A0
=C2=A0 =C2=A0 =C2=A0 If this is mandatory, I guess we'= ;ll need to mention it explicitly.

2: Page 7:=C2= =A0
=C2=A0 =C2=A0 This mechanism of sending the MP_CAPABLE with a= DATA_ACK until the server acknowledge it....
=C2=A0
= =C2=A0 =C2=A0-> Do you mean "This mechanism of sending MP_CAPABLE u= ntil the arrival of =C2=A0DATA_ACK from sender"?=C2=A0

<= /div>
3: Page 8: Section 3.1.2
=C2=A0 =C2=A0 However, the cli= ent receiving this data send by...
=C2=A0
=C2=A0 =C2=A0= -> Is there a case where we cannot put MP_CAPABLE and DATA_ACK together= ?

4: Page 8: Section 3.1.3

=C2=A0 =C2=A0 -> Don't we need to describe what we should do if th= e server doesn't this version?

5: Section 3.2<= /div>

=C2=A0 =C2=A0It should respond with a Data ACK set= to...
=C2=A0 =C2=A0 -> I think we should mention which tcp-ac= k num is used here. it'll be X?

6: Page 1: Tit= le

=C2=A0 =C2=A0It seems to me that the title indi= cate that it is only for stateless webservers.=C2=A0
=C2=A0 =C2= =A0If this draft will be merged into 6824bis, it might not be a problem.
=C2=A0 =C2=A0However, if this draft will be a separate draft and wi= ll be the standard mechanism for mptcp session establishment, I personally = would like to think about changing the title.=C2=A0

Thanks.
--
Yoshi

_______________________________________________
multipathtcp mailing list
multipathtcp@iet= f.org
https://www.ietf.org/mailman/listinfo/multipathtcp=



_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp=


--001a1141ed3c72fe36052932f658-- From nobody Sun Jan 17 19:54:33 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE71F1AD065 for ; Sun, 17 Jan 2016 19:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.924 X-Spam-Level: **** X-Spam-Status: No, score=4.924 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHKe1rLJtTIF for ; Sun, 17 Jan 2016 19:54:30 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F0F1AD061 for ; Sun, 17 Jan 2016 19:54:29 -0800 (PST) Received: from mail-yk0-f172.google.com (mail-yk0-f172.google.com [209.85.160.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 992042781F2 for ; Mon, 18 Jan 2016 12:54:27 +0900 (JST) Received: by mail-yk0-f172.google.com with SMTP id k129so578090523yke.0 for ; Sun, 17 Jan 2016 19:54:27 -0800 (PST) X-Gm-Message-State: ALoCoQkTvPNg1OiH8pX6BhHQ4as3DpAqzAucmHdpg+pEf1EoOxGp1sIRMboGkEQlTkAaxuLxbxKOWS09JPZ/W/qOsOYs0v7Zig== MIME-Version: 1.0 X-Received: by 10.129.155.204 with SMTP id s195mr14315441ywg.302.1453089266140; Sun, 17 Jan 2016 19:54:26 -0800 (PST) Received: by 10.13.196.3 with HTTP; Sun, 17 Jan 2016 19:54:26 -0800 (PST) Date: Sun, 17 Jan 2016 19:54:26 -0800 X-Gmail-Original-Message-ID: Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: multipart/alternative; boundary=94eb2c054254891020052993b529 Archived-At: Subject: [multipathtcp] some comments on draft-ietf-mptcp-rfc6824bis-05 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 03:54:32 -0000 --94eb2c054254891020052993b529 Content-Type: text/plain; charset=UTF-8 Hi, I've read draft-ietf-mptcp-rfc6824bis-05. I think it nicely integrates previous discussions and it makes lots of senses, although I might want to clarify several points. I have listed my comments below. 1: We now have several types of MP_CAPABLE. 1) contains only first 4bytes 2) contains sender's key 3) contains sender and receiver's key 4) contains sender and receiver's key and data length (+checksum) It is a bit unclear to me that which types of MP_CABLE used in which packet. For example, 1) should be used for SYN, but it might be possible to use 3) for SYN as it is not prohibited in the draft. If an endpoint receives 2) in SYN, what it should respond? Or, what will happen if the 3rd ACK with data uses 3) instead of 4)? Also, I might want to clarify the only way to identify these types of MP_CAPABLE is to check the option length in the draft. 2: It might not be very clear when initiator can confirm whether the key's arrived at responder or not when it sends data at first. For example, after sending MP_CAPABLE with data, what if it receives normal TCP ACK? Should it fallback to normal TCP or continue MPTCP as it might receive DATA_ACK eventually? 3: The syn coolie draft proposed a recovery mechanism for the case where the first data packet is lost in stateless server. We don't consider this case in this draft? 4: What if there is not enough option space to put MP_CAPABLE in the first data? Do we fallback or continue MPTCP as the 3rd ACK may arrive? 5: I personally prefer to explain explicitly that we don't have to set MP_CAPABLE in the first data when it already received DSS from its peer. 6: "An implementation MUST be able to receive and process both 64-bit or 32-bit sequence number value..." -> Should it be "64-bit and 32-bit"? Thanks, -- Yoshi --94eb2c054254891020052993b529 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
I've read draft-ietf-mptcp-rfc6824bis-05.
I= think it nicely integrates previous discussions and it makes lots of sense= s, although I might want to clarify several points.
I have listed my com= ments below.

1: We now have several types of MP_CAPABLE.
=C2=A0 = =C2=A01) contains only first 4bytes
=C2=A0 =C2=A02) contains sender'= s key
=C2=A0 =C2=A03) contains sender and receiver's key
=C2=A0 = =C2=A04) contains sender and receiver's key and data length (+checksum)=

=C2=A0 =C2=A0It is a bit unclear to me that which types of MP_CABLE= used in which packet. For example, 1) should be used for SYN, but it might= be possible to use 3) for SYN as it is not prohibited in the draft. If an = endpoint receives 2) in SYN, what it should respond?
=C2=A0 =C2=A0Or, w= hat will happen if the 3rd ACK with data uses 3) instead of 4)?

=C2= =A0 Also, I might want to clarify the only way to identify these types of M= P_CAPABLE is to check the option length in the draft.

2: It might no= t be very clear when initiator can confirm whether the key's arrived at= responder or not when it sends data at first. =C2=A0

=C2=A0 =C2=A0F= or example, after sending MP_CAPABLE with data, what if it receives normal = TCP ACK?=C2=A0
=C2=A0 =C2=A0Should it fallback to normal TCP or c= ontinue MPTCP as it might receive DATA_ACK eventually?
=C2=A0 =C2= =A0
3: The syn coolie draft proposed a recovery mechanism for the= case where the first data packet is lost in stateless server.
= =C2=A0 =C2=A0 We don't consider this case in this draft?

=
4: What if there is not enough option space to put MP_CAPABLE in= the first data?=C2=A0
=C2=A0 =C2=A0 Do we fallback or continue M= PTCP as the 3rd ACK may arrive?

5: I personally pr= efer to explain explicitly that we don't have to set MP_CAPABLE in the = first data when it already received DSS from its peer.

=
6: "An implementation MUST be able to receive and process both 64= -bit or 32-bit sequence number value..."
=C2=A0 =C2=A0 ->= Should it be "64-bit and 32-bit"?=C2=A0

Thanks,
--
Yoshi
--94eb2c054254891020052993b529-- From nobody Mon Jan 18 20:59:23 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2077F1A9077 for ; Mon, 18 Jan 2016 20:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.692 X-Spam-Level: X-Spam-Status: No, score=-2.692 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsl0yv63nRwM for ; Mon, 18 Jan 2016 20:59:20 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD791A9076 for ; Mon, 18 Jan 2016 20:59:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1453179560; x=2317093160; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Bkfw78pUDCqGbIuI1uVqvvp7at8qFTZeZtiQNqLs3yo=; b=vGd3HKPYJ5oVA0EvPWUOj+YAHZTi5r6zGSemVaUbUwa1MQGmJepLUGpeh1moKOV6 Z4TgRUi8olMS1uLQ+/Fk9Bj+FVDbh3C5L6pMkRrhYYt/FDz/aUM1BSOBVfQLroqd Sw2C7eOUmcoBswDvhhKFq3dCjz0NQTqGocs0JxhTL+DFXEcGoNfpF5lYgr8S4ewg vQrqYooSRPYeFj8g3Ak1hZbIic35qSSx7Ka4in8IDk61L+3s6JyYujOMS9lXZVG5 ZB3kNK7WtyuU8zvKBOq9RU3ryklGaCjiG3j5oQJA6BTsLcnFqmxhagxxrsbzBs4t hZLolQSky3mzDnFebyfCNw==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id A7.0B.03960.8A2CD965; Mon, 18 Jan 2016 20:59:20 -0800 (PST) X-AuditID: 11973e12-f796d6d000000f78-c1-569dc2a83e0e Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id A7.F4.29392.7A2CD965; Mon, 18 Jan 2016 20:59:20 -0800 (PST) Received: from localhost ([17.149.220.163]) by chive.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O1600276OIVEF80@chive.apple.com> for multipathtcp@ietf.org; Mon, 18 Jan 2016 20:59:19 -0800 (PST) Sender: cpaasch@apple.com Date: Mon, 18 Jan 2016 20:59:19 -0800 From: Christoph Paasch To: Yoshifumi Nishida Message-id: <20160119045919.GC37186@Chimay.local> References: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: User-Agent: Mutt/1.5.24 (08e81162482f) (2015-08-30) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUi2FAYpbvi0Nwwg4a1nBafV19nc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsL5PxgLmiUqnn2YxtLA+ESoi5GTQ0LAROLwnh8sELaYxIV7 69lAbCGBvYwSn3vUYWrW7FkOVMMFFJ/GJPGlawMrRFEbk8S7NWC2sICkRPedO8wgNouAqsSy uYfYQWw2AS2Jt7fbwWpEBPQkPnz/yARiMwtoSFx/2MwG0estMalrH1icV8BQ4vut98wQ8wMk lt7axQoRF5T4MfkeC0SvlsT6nceh5khLPPo7A2wXp0CwxMV5HYwgtqiAsUTTkTnMIEdLCCxg k3h4cDLjBEaRWUhmzUIyaxaSWQsYmVcxCuUmZuboZuaZ6CUWFOSk6iXn525iBIX3dDuhHYyn VlkdYhTgYFTi4X3hODdMiDWxrLgy9xCjNAeLkjivQyBQSCA9sSQ1OzW1ILUovqg0J7X4ECMT B6dUA6PcJU6tXZyvn1Q+ZN3+rXNO96JniuafnsR2fl1YLn9HMIWzq/GQp03V/i1y3D5fVOMk BDJvyYitEto+46Ldlu29e+QTXp8OCppZsNv71oz/Uxhn1BrUSZbc6Jz7f4ergODbh5yypQWr VmgG2+9yk3Q13qDds3vBxEVnWzIuvPq4NTt64acO3VdKLMUZiYZazEXFiQBIKb1GUAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUi2FDMr7vi0NwwgzUn2Sw+r77O5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIXzfzAWNEtUPPswjaWB8YlQFyMnh4SAicSaPctZIGwxiQv3 1rN1MXJxCAlMY5L40rWBFSQhJNDGJPFuDZgtLCAp0X3nDjOIzSKgKrFs7iF2EJtNQEvi7e12 sBoRAT2JD98/MoHYzAIaEtcfNrNB9HpLTOraBxbnFTCU+H7rPTPE/ACJpbd2sULEBSV+TL7H AtGrJbF+53GoOdISj/7OANvFKRAscXFeByOILSpgLNF0ZA7zBEbBWUjaZyFpn4WkfQEj8ypG gaLUnMRKM73EgoKcVL3k/NxNjOCALIzawdiw3OoQowAHoxIP7wvHuWFCrIllxZW5hxglOJiV RHi5twOFeFMSK6tSi/Lji0pzUosPMSYDA2Iis5Rocj4wWvJK4g1NTAxMjI3NjI3NTcxJE1YS 512iMy1MSCA9sSQ1OzW1ILUIZgsTB6dUA2PDRL3jNlVZn9ZHzOqSlknJjpnKyT/X8d/CBQ+a Le8+mO9wWkZ8xYvFvP9LnKR70xl0blxvtE7leXv3hqcop67V1kPqpVZry80vVnc8aFY8N5nv QXxY8Jfr7w2OPHWO/W1VPmvB7awM2c3+kydtdvLZHGJ/5tSdc9I3BcKsHs6SXxdw66Hu/1dK LMUZiYZazEXFiQCSvaKKjAIAAA== Archived-At: Cc: multipathtcp Subject: Re: [multipathtcp] some comments on draft-ietf-mptcp-rfc6824bis-05 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 04:59:22 -0000 Hello Yoshifumi, On 17/01/16 - 19:54:26, Yoshifumi Nishida wrote: > I've read draft-ietf-mptcp-rfc6824bis-05. > I think it nicely integrates previous discussions and it makes lots of > senses, although I might want to clarify several points. > I have listed my comments below. > > 1: We now have several types of MP_CAPABLE. > 1) contains only first 4bytes > 2) contains sender's key > 3) contains sender and receiver's key > 4) contains sender and receiver's key and data length (+checksum) > > It is a bit unclear to me that which types of MP_CABLE used in which > packet. For example, 1) should be used for SYN, but it might be possible to > use 3) for SYN as it is not prohibited in the draft. If an endpoint > receives 2) in SYN, what it should respond? I think, we should prohibit this in the protocol a host should fallback to regular TCP when the peer uses the incorrect MP_CAPABLE message in a segment. > Or, what will happen if the 3rd ACK with data uses 3) instead of 4)? > > Also, I might want to clarify the only way to identify these types of > MP_CAPABLE is to check the option length in the draft. > > 2: It might not be very clear when initiator can confirm whether the key's > arrived at responder or not when it sends data at first. > > For example, after sending MP_CAPABLE with data, what if it receives > normal TCP ACK? > Should it fallback to normal TCP or continue MPTCP as it might receive > DATA_ACK eventually? If at the beginning of a session a host receives a TCP ACK that acknowledges data but does not include a DATA_ACK, the host will do a seamless fallback to regular TCP. It does so because from the host's point-of-view there is a middlebox that is removing MPTCP-options from non-SYN segments. > 3: The syn coolie draft proposed a recovery mechanism for the case where > the first data packet is lost in stateless server. > We don't consider this case in this draft? In SYN-cookie draft we considered this as a "bonus" for MPTCP as it allows to recover from packet-loss where TCP will fail when facing stateless webservers. I think we could include it in RFC6824bis, although it is more of an implementation choice to implement such an optimisation. > > 4: What if there is not enough option space to put MP_CAPABLE in the first > data? > Do we fallback or continue MPTCP as the 3rd ACK may arrive? Yes, continuing MPTCP might be a good approach here. > 5: I personally prefer to explain explicitly that we don't have to set > MP_CAPABLE in the first data when it already received DSS from its peer. Yes, I think we can do this. Thanks for your feedback, Christoph > > 6: "An implementation MUST be able to receive and process both 64-bit or > 32-bit sequence number value..." > -> Should it be "64-bit and 32-bit"? > > Thanks, > -- > Yoshi > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Tue Jan 19 07:45:15 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C471B30A0 for ; Tue, 19 Jan 2016 07:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbTrBUeC0_Ue for ; Tue, 19 Jan 2016 07:45:11 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D90761B2FF7 for ; Tue, 19 Jan 2016 07:45:10 -0800 (PST) Received: by mail-ig0-x22a.google.com with SMTP id ik10so79648310igb.1 for ; Tue, 19 Jan 2016 07:45:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UpGQmoddqr7Nl4Pr/Ura7/HmhZQTCyeDolM35W0loBE=; b=tuhKxwe9knoDVsqzuZ+9KOYV4XV7da7jGMtbcjj84KDLZq6hSms6L5GWdjIsJ+qc2Z m5zu+WVsMTD4iKPtWk/V3jf0oujV5+0EWUA5WIthZm/7kkKNDkd40f+sP3zin2xoe/xO Z/oLq7zyyB93028C8RbqLQZxaZteNfwwI5YieHCSyKzgr47sp++VpORDGRZlahQsllhK RsbhySIQoFAg/kTiPj901Scasz0oWGBjJcs7LaEAlTh/9gLDf5hVNB/pue46aygEUYQO 0q9N5gahjzejoYy7kQF28eWHAG2jqfwRuNkBDoG5cGz38LG2mbQ2FukNtP8Jhzi4FWXR F85g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UpGQmoddqr7Nl4Pr/Ura7/HmhZQTCyeDolM35W0loBE=; b=GKXrgQjgcCZPeNvBIy+gM+9VpgRJ7dP2WPCpsejRZFja6ZDJ67FQiZ2fwv8q2DY7XK R+OVf2S7AKNHPI0lNYgahRvMclBujJqvEGyGqYnfQObRyY4JSSniYWHllpXIC90mD1dy YNLPYvqJGBPh3t3BknhelwnZsi4A93GxTKMybHof0EKNvdspEHLI215DOBY5+z4LK0V4 W9C5ymXLI2GMzexIHHjuAdU99E+/drdEaNfpOxH+pKy0EOrog56yXF4zCJsyZgoEyWFL CL8hTffB81p/a1bj9va+Fppzep8lNnfCnrmIoccPxdZi2onLqwJ+AVBhjKLrrNC0t/Hy tb5A== X-Gm-Message-State: AG10YORGwb8c95XrHz4OqKMiACRdCK7AwBzLXsd2Eap5cDEDyHP6s/Cb8kZkjS5LwHjiueGI1Jr2tKoiQrCskQ== MIME-Version: 1.0 X-Received: by 10.50.122.100 with SMTP id lr4mr16894774igb.37.1453218310290; Tue, 19 Jan 2016 07:45:10 -0800 (PST) Received: by 10.64.102.234 with HTTP; Tue, 19 Jan 2016 07:45:10 -0800 (PST) In-Reply-To: <20160119045919.GC37186@Chimay.local> References: <20160119045919.GC37186@Chimay.local> Date: Tue, 19 Jan 2016 15:45:10 +0000 Message-ID: From: Alan Ford To: Christoph Paasch Content-Type: multipart/alternative; boundary=001a11c1f7a42a8b260529b1c1c6 Archived-At: Cc: multipathtcp Subject: Re: [multipathtcp] some comments on draft-ietf-mptcp-rfc6824bis-05 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 15:45:13 -0000 --001a11c1f7a42a8b260529b1c1c6 Content-Type: text/plain; charset=UTF-8 Hi, Thanks for your feedback! On 19 January 2016 at 04:59, Christoph Paasch wrote: > On 17/01/16 - 19:54:26, Yoshifumi Nishida wrote: > > I've read draft-ietf-mptcp-rfc6824bis-05. > > I think it nicely integrates previous discussions and it makes lots of > > senses, although I might want to clarify several points. > > I have listed my comments below. > > > > 1: We now have several types of MP_CAPABLE. > > 1) contains only first 4bytes > > 2) contains sender's key > > 3) contains sender and receiver's key > > 4) contains sender and receiver's key and data length (+checksum) > > > > It is a bit unclear to me that which types of MP_CABLE used in which > > packet. For example, 1) should be used for SYN, but it might be possible > to > > use 3) for SYN as it is not prohibited in the draft. If an endpoint > > receives 2) in SYN, what it should respond? > > I think, we should prohibit this in the protocol a host should fallback to > regular TCP when the peer uses the incorrect MP_CAPABLE message in a > segment. > It says in the draft: o SYN (A->B): only the first four octets (Length = 4). o SYN/ACK (B->A): B's Key for this connection (Length = 12). o ACK (no data) (A->B): A's Key followed by B's Key (Length = 20). o ACK (with first data) (A->B): A's Key followed by B's Key followed by Data-Level Length, and optional Checksum (Length = 22 or 24). The contents of the option is determined by the SYN and ACK flags of the packet, along with the option's length field. For the diagram shown in Figure 4, "sender" and "receiver" refer to the sender or receiver of the TCP packet (which can be either host). Which I thought was fairly clear on which options can be used on which packets, but I'll look at clarifying the text to put some MUSTs in there. > > 5: I personally prefer to explain explicitly that we don't have to set > > MP_CAPABLE in the first data when it already received DSS from its peer. > > Yes, I think we can do this. > The relevant text is: If B has data to send first, then the reliable delivery of the ACK can be inferred by the receipt of this data with an appropriate MPTCP Data Sequence Signal (DSS) option (Section 3.3). If, however, A wishes to send data first, it would not know whether the ACK has successfully been received, and thus whether the MPTCP is successfully established. Therefore, on the first data A has to send (if it has not received any data from B), it MUST also include a MP_CAPABLE option, with additional data parameters. This packet may be the third ACK if data is ready to be sent by the application, or may be a later packet if the application only later has data to send. But if this is not explicit enough, I will look to make it even clearer. Regards, Alan --001a11c1f7a42a8b260529b1c1c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thanks for =C2=A0your feedback!
=

On 19 January 201= 6 at 04:59, Christoph Paasch <cpaasch@apple.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">On 17/01/16 - 19:54:26, Yoshifumi Nishida = wrote:
> I've read draft-ietf-mptcp-rfc6824bis-05.
> I think it nicely integrates previous discussions and it makes lots of=
> senses, although I might want to clarify several points.
> I have listed my comments below.
>
> 1: We now have several types of MP_CAPABLE.
>=C2=A0 =C2=A0 1) contains only first 4bytes
>=C2=A0 =C2=A0 2) contains sender's key
>=C2=A0 =C2=A0 3) contains sender and receiver's key
>=C2=A0 =C2=A0 4) contains sender and receiver's key and data length= (+checksum)
>
>=C2=A0 =C2=A0 It is a bit unclear to me that which types of MP_CABLE us= ed in which
> packet. For example, 1) should be used for SYN, but it might be possib= le to
> use 3) for SYN as it is not prohibited in the draft. If an endpoint > receives 2) in SYN, what it should respond?

I think, we should prohibit this in the protocol a host should fallb= ack to
regular TCP when the peer uses the incorrect MP_CAPABLE message in a
segment.

It says in the draft:

   o  SYN (A->B): only the first four octets (Length =3D=
 4).

   o  SYN/ACK (B->A): B's Key for this connection (Length =3D 12).

   o  ACK (no data) (A->B): A's Key followed by B's Key (Length =
=3D 20).

   o  ACK (with first data) (A->B): A's Key followed by B's Key =
followed
      by Data-Level Length, and optional Checksum (Length =3D 22 or 24).

   The contents of the option is determined by the SYN and ACK flags of
   the packet, along with the option's length field.  For the diagram
   shown in Figure 4, "sender" and "receiver" refer to =
the sender or
   receiver of the TCP packet (which can be either host).

<= /div>
Which I thought was fairly clear on which options can be used on = which packets, but I'll look at clarifying the text to put some MUSTs i= n there.


> 5: I personally prefer to explain explicitly that we don't have to= set
> MP_CAPABLE in the first data when it already received DSS from its pee= r.

Yes, I think we can do this.

The= relevant text is:

   If B has data to send first, =
then the reliable delivery of the ACK
   can be inferred by the receipt of this data with an appropriate MPTCP
   Data Sequence Signal (DSS) option (Section 3.3).  If, however, A
   wishes to send data first, it would not know whether the ACK has
   successfully been received, and thus whether the MPTCP is
   successfully established.  Therefore, on the first data A has to send
   (if it has not received any data from B), it MUST also include a
   MP_CAPABLE option, with additional data parameters.  This packet may
   be the third ACK if data is ready to be sent by the application, or
   may be a later packet if the application only later has data to send.

But if this is not explicit enough, I will loo= k to make it even clearer.=C2=A0
=C2=A0
Regards,
<= div>Alan

--001a11c1f7a42a8b260529b1c1c6-- From nobody Thu Jan 21 00:55:49 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635131A1AA6 for ; Thu, 21 Jan 2016 00:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.224 X-Spam-Level: ** X-Spam-Status: No, score=2.224 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tDmrhcGbZsl for ; Thu, 21 Jan 2016 00:55:46 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 302471A1AB3 for ; Thu, 21 Jan 2016 00:55:45 -0800 (PST) Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com [209.85.160.174]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 91F32278106 for ; Thu, 21 Jan 2016 17:55:43 +0900 (JST) Received: by mail-yk0-f174.google.com with SMTP id a85so40842841ykb.1 for ; Thu, 21 Jan 2016 00:55:43 -0800 (PST) X-Gm-Message-State: AG10YOSYQ9Y29ztXj5G0BiHd9ZTI1ZcjnxEcAikaC1Y4y4PeECOZbdNssvvmqP589R3uxLszS0fO0tgcTrVaBw== MIME-Version: 1.0 X-Received: by 10.13.200.1 with SMTP id k1mr4196327ywd.141.1453366542123; Thu, 21 Jan 2016 00:55:42 -0800 (PST) Received: by 10.13.196.3 with HTTP; Thu, 21 Jan 2016 00:55:42 -0800 (PST) In-Reply-To: <20160119045919.GC37186@Chimay.local> References: <20160119045919.GC37186@Chimay.local> Date: Thu, 21 Jan 2016 00:55:42 -0800 X-Gmail-Original-Message-ID: Message-ID: From: Yoshifumi Nishida To: Christoph Paasch Content-Type: multipart/alternative; boundary=001a114e60fe78d25e0529d4446b Archived-At: Cc: multipathtcp Subject: Re: [multipathtcp] some comments on draft-ietf-mptcp-rfc6824bis-05 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 08:55:48 -0000 --001a114e60fe78d25e0529d4446b Content-Type: text/plain; charset=UTF-8 Hi Christoph, On Mon, Jan 18, 2016 at 8:59 PM, Christoph Paasch wrote: > Hello Yoshifumi, > > On 17/01/16 - 19:54:26, Yoshifumi Nishida wrote: > > I've read draft-ietf-mptcp-rfc6824bis-05. > > I think it nicely integrates previous discussions and it makes lots of > > senses, although I might want to clarify several points. > > I have listed my comments below. > > > > 1: We now have several types of MP_CAPABLE. > > 1) contains only first 4bytes > > 2) contains sender's key > > 3) contains sender and receiver's key > > 4) contains sender and receiver's key and data length (+checksum) > > > > It is a bit unclear to me that which types of MP_CABLE used in which > > packet. For example, 1) should be used for SYN, but it might be possible > to > > use 3) for SYN as it is not prohibited in the draft. If an endpoint > > receives 2) in SYN, what it should respond? > > I think, we should prohibit this in the protocol a host should fallback to > regular TCP when the peer uses the incorrect MP_CAPABLE message in a > segment. > > > Or, what will happen if the 3rd ACK with data uses 3) instead of 4)? > > > > Also, I might want to clarify the only way to identify these types of > > MP_CAPABLE is to check the option length in the draft. > > > > 2: It might not be very clear when initiator can confirm whether the > key's > > arrived at responder or not when it sends data at first. > > > > For example, after sending MP_CAPABLE with data, what if it receives > > normal TCP ACK? > > Should it fallback to normal TCP or continue MPTCP as it might receive > > DATA_ACK eventually? > > If at the beginning of a session a host receives a TCP ACK that > acknowledges > data but does not include a DATA_ACK, the host will do a seamless fallback > to regular TCP. It does so because from the host's point-of-view there is a > middlebox that is removing MPTCP-options from non-SYN segments. > I basically agree. But, I think it means if responder doesn't (or cannot) set DATA_ACK in the first ack for data packets, it will cause fallback. In my understanding, when to set DATA_ACK is a bit ambiguous, but I am thinking that we might need some rules here. > > 3: The syn coolie draft proposed a recovery mechanism for the case where > > the first data packet is lost in stateless server. > > We don't consider this case in this draft? > > In SYN-cookie draft we considered this as a "bonus" for MPTCP as it allows > to recover from packet-loss where TCP will fail when facing stateless > webservers. > I think we could include it in RFC6824bis, although it is more of an > implementation choice to implement such an optimisation. > I got it. I don't think this is an important item for the core spec. I just would like to clarify the intention behind it. > > > 4: What if there is not enough option space to put MP_CAPABLE in the > first > > data? > > Do we fallback or continue MPTCP as the 3rd ACK may arrive? > > Yes, continuing MPTCP might be a good approach here. > OK. I might prefer to clarify it in the draft. Thanks, -- Yoshi --001a114e60fe78d25e0529d4446b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Christoph,

On Mon, Jan 18, 2016 at 8:59 PM, Christoph Paasch <cpaasc= h@apple.com> wrote:
Hello Y= oshifumi,

On 17/01/16 - 19:54:26, Yoshifumi Nishida wrote:
> I've read draft-ietf-mptcp-rfc6824bis-05.
> I think it nicely integrates previous discussions and it makes lots of=
> senses, although I might want to clarify several points.
> I have listed my comments below.
>
> 1: We now have several types of MP_CAPABLE.
>=C2=A0 =C2=A0 1) contains only first 4bytes
>=C2=A0 =C2=A0 2) contains sender's key
>=C2=A0 =C2=A0 3) contains sender and receiver's key
>=C2=A0 =C2=A0 4) contains sender and receiver's key and data length= (+checksum)
>
>=C2=A0 =C2=A0 It is a bit unclear to me that which types of MP_CABLE us= ed in which
> packet. For example, 1) should be used for SYN, but it might be possib= le to
> use 3) for SYN as it is not prohibited in the draft. If an endpoint > receives 2) in SYN, what it should respond?

I think, we should prohibit this in the protocol a host should fallb= ack to
regular TCP when the peer uses the incorrect MP_CAPABLE message in a
segment.

>=C2=A0 =C2=A0 Or, what will happen if the 3rd ACK with data uses 3) ins= tead of 4)?
>
>=C2=A0 =C2=A0Also, I might want to clarify the only way to identify the= se types of
> MP_CAPABLE is to check the option length in the draft.
>
> 2: It might not be very clear when initiator can confirm whether the k= ey's
> arrived at responder or not when it sends data at first.
>
>=C2=A0 =C2=A0 For example, after sending MP_CAPABLE with data, what if = it receives
> normal TCP ACK?
>=C2=A0 =C2=A0 Should it fallback to normal TCP or continue MPTCP as it = might receive
> DATA_ACK eventually?

If at the beginning of a session a host receives a TCP ACK that ackn= owledges
data but does not include a DATA_ACK, the host will do a seamless fallback<= br> to regular TCP. It does so because from the host's point-of-view there = is a
middlebox that is removing MPTCP-options from non-SYN segments.

I basically agree. But, I think it means if respon= der doesn't (or cannot) set DATA_ACK in the first ack for data packets,= it will cause fallback. In my understanding, when to set DATA_ACK is a bit= ambiguous, but I am thinking that we might need some rules here.
=C2=A0=C2=A0
> 3: The syn coolie draft proposed a recovery mechanism for the case whe= re
> the first data packet is lost in stateless server.
>=C2=A0 =C2=A0 =C2=A0We don't consider this case in this draft?

In SYN-cookie draft we considered this as a "bonus" for MP= TCP as it allows
to recover from packet-loss where TCP will fail when facing stateless
webservers.
I think we could include it in RFC6824bis, although it is more of an
implementation choice to implement such an optimisation.

I got it. I don't think this is an important item for= the core spec.
I just would like to clarify the intention behind= it.

>
> 4: What if there is not enough option space to put MP_CAPABLE in the f= irst
> data?
>=C2=A0 =C2=A0 =C2=A0Do we fallback or continue MPTCP as the 3rd ACK may= arrive?

Yes, continuing MPTCP might be a good approach here.

OK. I might prefer to clarify it in the draft.

Thanks,
--
Yoshi
--001a114e60fe78d25e0529d4446b-- From nobody Thu Jan 21 09:24:35 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CDA1B333D for ; Thu, 21 Jan 2016 09:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjUrIZ6H0QNj for ; Thu, 21 Jan 2016 09:24:33 -0800 (PST) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B8E11B333A for ; Thu, 21 Jan 2016 09:24:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1453397073; x=2317310673; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=faEQTundUVead9TJxbJIvsXqKSf9amacIcR+FIL/9sQ=; b=MqznhSUVT14Wy63dq9/rdi+TnRIdLJHwbFHZykSh+K6M/RxcaITw51glnBRHEcuf fzZqdhNNW/NblOphsCVRFO3GolZQVE/oZJH9EsHDvLIbNPfa8V+iE/KFMg1lyVXj N4tJ4zzDUq92cAtTWq95nixMKjHjwsDxCqnGP9IWQoHcvSUFsWMimdrDdvb2N0dW lgNjRqzVtwGt1T6jk/y1TwSFa/BC+RwqF2L04BXUHnZFwnGqy42weIT7cw6QNxNr gcTYH4yvxyCWRW4baqMZ1rkqZ6IkbcVfq0pxJhLBo7iQmQk/BRh7OzOwSTNTErrn jJh+MxW0fQF9U+e0lfiQ9g==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 35.55.27232.15411A65; Thu, 21 Jan 2016 09:24:33 -0800 (PST) X-AuditID: 11973e15-f79366d000006a60-e4-56a114512456 Received: from chicory.apple.com (chicory.apple.com [17.128.115.99]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 38.B4.29392.05411A65; Thu, 21 Jan 2016 09:24:32 -0800 (PST) Received: from localhost ([17.149.220.161]) by chicory.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O1B00DT3CCW4W00@chicory.apple.com> for multipathtcp@ietf.org; Thu, 21 Jan 2016 09:24:32 -0800 (PST) Sender: cpaasch@apple.com Date: Thu, 21 Jan 2016 09:24:32 -0800 From: Christoph Paasch To: Yoshifumi Nishida Message-id: <20160121172432.GI48144@Chimay.local> References: <20160119045919.GC37186@Chimay.local> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: User-Agent: Mutt/1.5.24 (08e81162482f) (2015-08-30) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUi2FAYpRsosjDM4PNiJovPq6+zOTB6LFny kymAMYrLJiU1J7MstUjfLoEro+3TXLaCHTIVL5t+MDUwXhbtYuTkkBAwkfjych0ThC0mceHe erYuRi4OIYG9jBKtKxawwBQdevGPGSIxi0ni0adudgini0li36sF7CBVwgKSEt137jCD2CwC qhI3Di1hBbHZBLQk3t5uB7NFBPQkPnz/CLaOWUBD4vrDZjaIXm+JSV37wOK8AoYSMzY2sEIs OMgo0fVqDitEQlDix+R7LBDNWhLrdx6HGiQt8ejvDKAjODg4BYIljq91AAmLChhLNB2ZA3a1 hMBPVonbXw6zTmAUmYVk1Cwko2YhGbWAkXkVo1BuYmaObmaemV5iQUFOql5yfu4mRlCIT7cT 3cF4ZpXVIUYBDkYlHt4b1+aHCbEmlhVX5h5ilOZgURLnfSu8MExIID2xJDU7NbUgtSi+qDQn tfgQIxMHp1QDY3fVC+Nvnp8cD0xcuY117rme88XpV720n7PG35myd7uktb/ditkK/QUd5v3s tjuP3a3bqCt1/E7x+ZieGY/uhNxZ+CH82qyVe8OMTi/aqFq8cM/t2QUqrRMDtG+9fD35g9/9 PbJJ4qIvS12MOG7X6GstsD0XcGEXV4JQ1qELry8lm5++dzZ3sqgSS3FGoqEWc1FxIgAp9wcq UgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUi2FCcrBsgsjDM4PpzG4vPq6+zOTB6LFny kymAMYrLJiU1J7MstUjfLoEro+3TXLaCHTIVL5t+MDUwXhbtYuTkkBAwkTj04h8zhC0mceHe erYuRi4OIYFZTBKPPnWzQzhdTBL7Xi1gB6kSFpCU6L5zB6yDRUBV4sahJawgNpuAlsTb2+1g toiAnsSH7x+ZQGxmAQ2J6w+b2SB6vSUmde0Di/MKGErM2NjACrHgIKNE16s5rBAJQYkfk++x QDRrSazfeRxqkLTEo78zgI7g4OAUCJY4vtYBJCwqYCzRdGQO8wRGwVlIumch6Z6FpHsBI/Mq RoGi1JzESjO9xIKCnFS95PzcTYzgkCyM2sHYsNzqEKMAB6MSD6/BzflhQqyJZcWVuYcYJTiY lUR4e/kXhgnxpiRWVqUW5ccXleakFh9ilOZgURLn3TJxQZiQQHpiSWp2ampBahFMlomDU6qB Uady6nLDP9Vcd6OuT/X7zvvlcMZd/2u9AbcVri4oOSQ8fdPjmWcMuLYn6lW1ONe6rttTetfO WsVLd2vjTgOHDWI+Xb+XRe78ybtX85jepoqlNvO/XTjrwPBeebUAz/33snPf3gw/uKT/iAD7 xaXCOnVrlzXnxhrppAtw/ag2fiR13bvvjpr2RCWW4oxEQy3mouJEAPu3BpRFAgAA Archived-At: Cc: multipathtcp Subject: Re: [multipathtcp] some comments on draft-ietf-mptcp-rfc6824bis-05 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 17:24:35 -0000 On 21/01/16 - 00:55:42, Yoshifumi Nishida wrote: > On Mon, Jan 18, 2016 at 8:59 PM, Christoph Paasch wrote: > > On 17/01/16 - 19:54:26, Yoshifumi Nishida wrote: > > > I've read draft-ietf-mptcp-rfc6824bis-05. > > > I think it nicely integrates previous discussions and it makes lots of > > > senses, although I might want to clarify several points. > > > I have listed my comments below. > > > > > > 1: We now have several types of MP_CAPABLE. > > > 1) contains only first 4bytes > > > 2) contains sender's key > > > 3) contains sender and receiver's key > > > 4) contains sender and receiver's key and data length (+checksum) > > > > > > It is a bit unclear to me that which types of MP_CABLE used in which > > > packet. For example, 1) should be used for SYN, but it might be possible > > to > > > use 3) for SYN as it is not prohibited in the draft. If an endpoint > > > receives 2) in SYN, what it should respond? > > > > I think, we should prohibit this in the protocol a host should fallback to > > regular TCP when the peer uses the incorrect MP_CAPABLE message in a > > segment. > > > > > Or, what will happen if the 3rd ACK with data uses 3) instead of 4)? > > > > > > Also, I might want to clarify the only way to identify these types of > > > MP_CAPABLE is to check the option length in the draft. > > > > > > 2: It might not be very clear when initiator can confirm whether the > > key's > > > arrived at responder or not when it sends data at first. > > > > > > For example, after sending MP_CAPABLE with data, what if it receives > > > normal TCP ACK? > > > Should it fallback to normal TCP or continue MPTCP as it might receive > > > DATA_ACK eventually? > > > > If at the beginning of a session a host receives a TCP ACK that > > acknowledges > > data but does not include a DATA_ACK, the host will do a seamless fallback > > to regular TCP. It does so because from the host's point-of-view there is a > > middlebox that is removing MPTCP-options from non-SYN segments. > > > > I basically agree. But, I think it means if responder doesn't (or cannot) > set DATA_ACK in the first ack for data packets, it will cause fallback. In > my understanding, when to set DATA_ACK is a bit ambiguous, but I am > thinking that we might need some rules here. I agree it is a bit ambiguous. Currently, this fallback at the beginning of a subflow is documented only in Section 3.8. It might be good to explain it in Section 3.3.1 and 3.3.2, to make clear that at the beginning of a subflow segments must contain a DSS and DATA_ACK. Cheers, Christoph > > > 3: The syn coolie draft proposed a recovery mechanism for the case where > > > the first data packet is lost in stateless server. > > > We don't consider this case in this draft? > > > > In SYN-cookie draft we considered this as a "bonus" for MPTCP as it allows > > to recover from packet-loss where TCP will fail when facing stateless > > webservers. > > I think we could include it in RFC6824bis, although it is more of an > > implementation choice to implement such an optimisation. > > > > I got it. I don't think this is an important item for the core spec. > I just would like to clarify the intention behind it. > > > > > > 4: What if there is not enough option space to put MP_CAPABLE in the > > first > > > data? > > > Do we fallback or continue MPTCP as the 3rd ACK may arrive? > > > > Yes, continuing MPTCP might be a good approach here. > > > > OK. I might prefer to clarify it in the draft. > > Thanks, > -- > Yoshi From nobody Fri Jan 22 09:01:46 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098121B2A0C for ; Fri, 22 Jan 2016 09:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.123 X-Spam-Level: **** X-Spam-Status: No, score=4.123 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rseJYyRC36B for ; Fri, 22 Jan 2016 09:01:43 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 141191B2A01 for ; Fri, 22 Jan 2016 09:01:42 -0800 (PST) Received: from mail-yk0-f172.google.com (mail-yk0-f172.google.com [209.85.160.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id E44AE2782AE for ; Sat, 23 Jan 2016 02:01:40 +0900 (JST) Received: by mail-yk0-f172.google.com with SMTP id k129so93920249yke.0 for ; Fri, 22 Jan 2016 09:01:40 -0800 (PST) X-Gm-Message-State: AG10YORphv6y4uT8WZeQYbdPgV7irMtrOjnSOViZeZxMwzYJNLVSSuA2YRp/B/6P4EBi5Pw9zPJ2uHL/Ime12w== MIME-Version: 1.0 X-Received: by 10.129.102.6 with SMTP id a6mr2073385ywc.7.1453482099406; Fri, 22 Jan 2016 09:01:39 -0800 (PST) Received: by 10.13.196.3 with HTTP; Fri, 22 Jan 2016 09:01:39 -0800 (PST) Date: Fri, 22 Jan 2016 09:01:39 -0800 X-Gmail-Original-Message-ID: Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: multipart/alternative; boundary=001a114901a438fefe0529ef2cd1 Archived-At: Subject: [multipathtcp] IPR related to draft-ietf-mptcp-rfc6824bis-05 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 17:01:45 -0000 --001a114901a438fefe0529ef2cd1 Content-Type: text/plain; charset=UTF-8 Hi folks, We have a short announcement for IPR related to the 6824bis draft that might need your attentions. Apple has submitted IPR info related to draft-paash-mptcp-syncookies some time ago. Please check the following link for the detailed info. https://datatracker.ietf.org/ipr/2678/ We have asked Christoph to check with their lawyer if this affects 6824bis. He has received a response that Apple is willing to apply the same IPR statement to the new 6824bis. We are not sure if this affects the WG's decision, but we want to share this to make sure people aware it. If you have any questions, opinions, etc, please share so that we can discuss how to proceed. Regards, -- Yoshi and Phil --001a114901a438fefe0529ef2cd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi folks,

We have a short announcement = for IPR related to the 6824bis draft that might need your attentions.
=

Apple has submitted IPR info related to draft-paas= h-mptcp-syncookies some time ago. Please check the following link for the d= etailed info.


We have asked Christop= h to check with their lawyer if this affects 6824bis.
He has rece= ived a response that Apple is willing to apply the same IPR statement to th= e new 6824bis.=C2=A0
We are not sure if this affects the WG&#= 39;s decision, but we want to share this to make sure people aware it.=C2= =A0
If you have any questions, opinions, etc, please share so tha= t we can discuss how to proceed.=C2=A0

Regards,
--
Yoshi and Phil
--001a114901a438fefe0529ef2cd1-- From nobody Wed Jan 27 02:43:47 2016 Return-Path: X-Original-To: multipathtcp@ietf.org Delivered-To: multipathtcp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E0B1B3693; Wed, 27 Jan 2016 00:42:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160127084226.16807.95941.idtracker@ietfa.amsl.com> Date: Wed, 27 Jan 2016 00:42:26 -0800 Archived-At: X-Mailman-Approved-At: Wed, 27 Jan 2016 02:43:45 -0800 Cc: multipathtcp@ietf.org, mls.ietf@gmail.com, mptcp-chairs@ietf.org Subject: [multipathtcp] mptcp - New Meeting Session Request for IETF 95 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 08:42:26 -0000 A new meeting session request has just been submitted by Philip Eardley, a Chair of the mptcp working group. --------------------------------------------------------- Working Group Name: Multipath TCP Area Name: Transport Area Session Requester: Philip Eardley Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: ippm tcpinc tcpm tsvarea tsvwg lmap tls saag Second Priority: taps netext mif iccrg rtcweb cdni Special Requests: ---------------------------------------------------------