From nobody Mon Jul 2 00:14:17 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9CA8130E17 for ; Mon, 2 Jul 2018 00:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 CDCxwl5oSq9j for ; Mon, 2 Jul 2018 00:14:13 -0700 (PDT) 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 5083F130DF4 for ; Mon, 2 Jul 2018 00:14:12 -0700 (PDT) Received: from mail-it0-f53.google.com (mail-it0-f53.google.com [209.85.214.53]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 627682783BE for ; Mon, 2 Jul 2018 16:14:10 +0900 (JST) Received: by mail-it0-f53.google.com with SMTP id 188-v6so10685306ita.5 for ; Mon, 02 Jul 2018 00:14:10 -0700 (PDT) X-Gm-Message-State: APt69E2ig9QkQzMsDWviWKYxp3HI2z1evb11+UWF7mE368J2s4JlzruY zAROBZkB+U535IxraGHkgRjwiUkxSE8KuYR5HC8= X-Google-Smtp-Source: AAOMgpe2lRogGcfn0qRxdRDnqq9W8lToS4n3T/rs2OKvZhHQVasDujRaibJl7kH3L9qUp0h0fqvQOe/27Zub5Y0d9xg= X-Received: by 2002:a02:98e2:: with SMTP id c31-v6mr8493687jak.47.1530515649253; Mon, 02 Jul 2018 00:14:09 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:7599:0:0:0:0:0 with HTTP; Mon, 2 Jul 2018 00:14:08 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Mon, 2 Jul 2018 00:14:08 -0700 X-Gmail-Original-Message-ID: Message-ID: To: multipathtcp Content-Type: multipart/alternative; boundary="00000000000098d637056ffef1c7" Archived-At: Subject: Re: [multipathtcp] Call for agenda items for MPTCP WG meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 07:14:16 -0000 --00000000000098d637056ffef1c7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, Just in case, we accept remote presentations as usual in case you cannot be there. If you're interested, please let us know. Thanks, -- Yoshi & Phil On Tue, Jun 19, 2018 at 12:55 AM, wrote: > Hi, > > Please send requests for anything you want to present or discuss in > Montreal. Our timeslot is on Monday at 1550-1750 (on the preliminary agen= da > =E2=80=93 so may change). > > Please let us know topic /title, presenter & requested length of time. > > Thanks > > Phil & Yoshi > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > --00000000000098d637056ffef1c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Just in case, we accept remote p= resentations as usual in case you cannot be there.
If you're = interested, please let us know.

Thanks,
= --
Yoshi & Phil=C2=A0
On Tue, Jun 19, 2018 at 12:55 AM, <phi= lip.eardley@bt.com> wrote:

Hi,

Please send requests for anything you want to presen= t or discuss in Montreal. Our timeslot is on Monday at 1550-1750 (on the pr= eliminary agenda =E2=80=93 so may change).

Please let us know topic /title, presenter & req= uested length of time.

Thanks

Phil & Yoshi

=C2=A0


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


--00000000000098d637056ffef1c7-- From nobody Tue Jul 3 09:05:00 2018 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 DD68B131004; Tue, 3 Jul 2018 09:00:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: multipathtcp@ietf.org, ietf@kuehlewind.net X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153063362190.4893.12973451012294341052.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 09:00:21 -0700 Archived-At: Subject: [multipathtcp] mptcp - Requested session has been scheduled for IETF 102 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:00:32 -0000 Dear Yoshifumi Nishida, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. mptcp Session 1 (1:30 requested) Monday, 16 July 2018, Afternoon Session II 1550-1750 Room Name: Saint-Paul/Sainte-Catherine size: 100 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/102/sessions/mptcp.ics Request Information: --------------------------------------------------------- Working Group Name: Multipath TCP Area Name: Transport Area Session Requester: Yoshifumi Nishida Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: ippm tcpinc tcpm tsvarea tsvwg tls Second Priority: taps iccrg rtcweb manet dmm Third Priority: nfvrg quic maprg People who must be present: Yoshifumi Nishida Philip Eardley Mirja Kuehlewind Resources Requested: Special Requests: please avoid any transport area BoFs --------------------------------------------------------- From nobody Wed Jul 4 00:30:43 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C78130E28 for ; Wed, 4 Jul 2018 00:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 9w-G_f4HCXlg for ; Wed, 4 Jul 2018 00:30:38 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D772130EC1 for ; Wed, 4 Jul 2018 00:30:38 -0700 (PDT) Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by EVMED02-UKBR.bt.com (10.216.161.32) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 4 Jul 2018 08:30:32 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03c.domain1.systemhost.net (10.55.202.26) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 4 Jul 2018 08:30:34 +0100 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.1293.004; Wed, 4 Jul 2018 08:30:33 +0100 From: To: Thread-Topic: WG Last Call for draft-ietf-mptcp-rfc6824bis Thread-Index: AdP8pPjqwq5n45WRS2ywhz4YK91ZcQAGiU/gBBgqcVABkj0esA== Date: Wed, 4 Jul 2018 07:30:33 +0000 Message-ID: <419c12ae34ec45bd9ba3a0e5c8310624@rew09926dag03b.domain1.systemhost.net> References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> <39fbc9f18384473398fca38670c73cf6@rew09926dag03b.domain1.systemhost.net> 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.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 07:30:42 -0000 We urgently need your comments about this document.=20 It's been in WG last call for just on 4 weeks, but I think the only comment= s so far are from the WG chairs - clearly we need more comments before the = document can advance. We'd like to discuss and close issues before or durin= g the IETF. So please can you dedicate some time to checking the document. Thanks, Phil & Yoshi -----Original Message----- From: Eardley,PL,Philip,TUD1 R=20 Sent: 26 June 2018 08:33 To: multipathtcp@ietf.org Subject: RE: WG Last Call for draft-ietf-mptcp-rfc6824bis Hi, Just a reminder about the WGLC for the protocol bis. Please send comments, = Thanks! Phil & Yoshi -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 05 June 2018 12:21 To: multipathtcp@ietf.org Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis As a reminder, this document Obsoletes: 6824 (if approved) and its Intended= status is Standards Track. As well as suggested changes or edits, positive review comments ("It's read= y") are also very valuable.=20 -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 05 June 2018 09:14 To: multipathtcp@ietf.org Subject: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis This starts a WG Last Call for draft-ietf-mptcp-rfc6824bis. Please send com= ments by the end of June.=20 Please note there are three IPR disclosures (we're working on getting them = added to the rfc6824bis page):=20 * two are inherited from RFC6824 https://datatracker.ietf.org/ipr/search/?= submit=3Ddraft&id=3Ddraft-ietf-mptcp-multiaddressed =20 * one is inherited from draft-paasch-mptcp-syncookies (which got include in= rfc6824bis) https://datatracker.ietf.org/ipr/2678/=20 Thanks, Phil & 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 From nobody Wed Jul 4 02:11:01 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC3E130E24 for ; Wed, 4 Jul 2018 02:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 aq_VyTiXnuia for ; Wed, 4 Jul 2018 02:10:55 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76050130DC1 for ; Wed, 4 Jul 2018 02:10:55 -0700 (PDT) Received: from mail-it0-f50.google.com (mail-it0-f50.google.com [209.85.214.50]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id B095C278487 for ; Wed, 4 Jul 2018 18:10:53 +0900 (JST) Received: by mail-it0-f50.google.com with SMTP id j185-v6so6763219ite.1 for ; Wed, 04 Jul 2018 02:10:53 -0700 (PDT) X-Gm-Message-State: APt69E28OSfCLCMjE68F+scUqJVDOpOqadyX3iK0zFWlkd8cIbrFWN4s JH2tgQr1ds+amJcojqeGAoEonj9oxpbBhbilVFg= X-Google-Smtp-Source: AAOMgpdOMU+s2oupgwinlKx5EEjRxS3Oto6cpwcbT2MZaOcxmfYl7o+S7YHXthJ4h2QgvZdKrqGSmoQXRQkGfGVmB2Y= X-Received: by 2002:a02:2505:: with SMTP id g5-v6mr942049jag.130.1530695452374; Wed, 04 Jul 2018 02:10:52 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:7599:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 02:10:51 -0700 (PDT) In-Reply-To: <419c12ae34ec45bd9ba3a0e5c8310624@rew09926dag03b.domain1.systemhost.net> References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> <39fbc9f18384473398fca38670c73cf6@rew09926dag03b.domain1.systemhost.net> <419c12ae34ec45bd9ba3a0e5c8310624@rew09926dag03b.domain1.systemhost.net> From: Yoshifumi Nishida Date: Wed, 4 Jul 2018 02:10:51 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "philip.eardley" Cc: multipathtcp Content-Type: multipart/alternative; boundary="000000000000b2bb11057028ce03" Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 09:10:59 -0000 --000000000000b2bb11057028ce03 Content-Type: text/plain; charset="UTF-8" We also expect the authors to respond the comments sent during WGLC as it can trigger other comments. Thanks, -- Yoshi On Wed, Jul 4, 2018 at 12:30 AM, wrote: > We urgently need your comments about this document. > > It's been in WG last call for just on 4 weeks, but I think the only > comments so far are from the WG chairs - clearly we need more comments > before the document can advance. We'd like to discuss and close issues > before or during the IETF. > > So please can you dedicate some time to checking the document. > > Thanks, > Phil & Yoshi > > -----Original Message----- > From: Eardley,PL,Philip,TUD1 R > Sent: 26 June 2018 08:33 > To: multipathtcp@ietf.org > Subject: RE: WG Last Call for draft-ietf-mptcp-rfc6824bis > > Hi, > Just a reminder about the WGLC for the protocol bis. Please send comments, > Thanks! > Phil & Yoshi > > -----Original Message----- > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: 05 June 2018 12:21 > To: multipathtcp@ietf.org > Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis > > As a reminder, this document Obsoletes: 6824 (if approved) and its > Intended status is Standards Track. > > As well as suggested changes or edits, positive review comments ("It's > ready") are also very valuable. > > -----Original Message----- > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: 05 June 2018 09:14 > To: multipathtcp@ietf.org > Subject: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis > > This starts a WG Last Call for draft-ietf-mptcp-rfc6824bis. Please send > comments by the end of June. > > Please note there are three IPR disclosures (we're working on getting them > added to the rfc6824bis page): > > * two are inherited from RFC6824 https://datatracker.ietf.org/i > pr/search/?submit=draft&id=draft-ietf-mptcp-multiaddressed > * one is inherited from draft-paasch-mptcp-syncookies (which got include > in rfc6824bis) https://datatracker.ietf.org/ipr/2678/ > > Thanks, > Phil & 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 > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > --000000000000b2bb11057028ce03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We also expect the authors to respond the comments sent du= ring WGLC as it can trigger other comments.

Thanks,
--
Yoshi

<= div class=3D"gmail_quote">On Wed, Jul 4, 2018 at 12:30 AM, <philip.ea= rdley@bt.com> wrote:
= We urgently need your comments about this document.

It's been in WG last call for just on 4 weeks, but I think the only com= ments so far are from the WG chairs - clearly we need more comments before = the document can advance. We'd like to discuss and close issues before = or during the IETF.

So please can you dedicate some time to checking the document.

Thanks,
Phil & Yoshi

-----Original Message-----
multipathtcp= @ietf.org
multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.c= om
multipathtcp= @ietf.org
Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mpt= cp-rfc6824bis

As a reminder, this document Obsoletes: 6824 (if approved) and its Intended= status is Standards Track.

As well as suggested changes or edits, positive review comments ("It&#= 39;s ready") are also very valuable.

-----Original Message-----
From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.c= om
Sent: 05 June 2018 09:14
To: multipathtcp= @ietf.org
Subject: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis

This starts a WG Last Call for draft-ietf-mptcp-rfc6824bis. Please send com= ments by the end of June.

Please note there are three IPR disclosures (we're working on getting t= hem added to the rfc6824bis page):

* two are inherited from RFC6824=C2=A0 https://datatracker.ietf.org/ipr/se= arch/?submit=3Ddraft&id=3Ddraft-ietf-mptcp-multiaddressed=C2= =A0 =C2=A0
* one is inherited from draft-paasch-mptcp-syncookies (which got include in= rfc6824bis) https://datatracker.ietf.org/ipr/2678/ <= br>
Thanks,
Phil & Yoshi
_______________________________________________
multipathtcp mailing list
multipathtcp@iet= f.org
https://www.ietf.org/mailman/listinfo/multipa= thtcp

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

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

--000000000000b2bb11057028ce03-- From nobody Wed Jul 4 07:42:37 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E0613101F for ; Wed, 4 Jul 2018 07:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 vanTjWLGtmt7 for ; Wed, 4 Jul 2018 07:42:20 -0700 (PDT) Received: from vesa.cs.pub.ro (vesa.cs.pub.ro [141.85.227.187]) by ietfa.amsl.com (Postfix) with ESMTP id D88CB131065 for ; Wed, 4 Jul 2018 07:42:19 -0700 (PDT) IronPort-PHdr: =?us-ascii?q?9a23=3AhdhK8BwRe3BvlcvXCy+O+j09IxM/srCxBDY+r6?= =?us-ascii?q?Qd2+4SIJqq85mqBkHD//Il1AaPAd2Fraocw8Pt8InYEVQa5piAtH1QOLdtbD?= =?us-ascii?q?Qizfssogo7HcSeAlf6JvO5JwYzHcBFSUM3tyrjaRsdF8nxfUDdrWOv5jAOBB?= =?us-ascii?q?r/KRB1JuPoEYLOksi7ze+/94HSbglSmDaxfa55IQmrownWqsQYm5ZpJLwryh?= =?us-ascii?q?vOrHtIeuBWyn1tKFmOgRvy5dq+8YB6/ShItP0v68BPUaPhf6QlVrNYFygpM3?= =?us-ascii?q?o05MLwqxbOSxaE62YGXWUXlhpIBBXF7A3/U5zsvCb2qvZx1S+HNsDwULs6Wy?= =?us-ascii?q?mt771zRRH1hicJKT43/mLZhMN+g61Uog6uqgdlzILIeoyYLuZyc63fcN4cWG?= =?us-ascii?q?FPXtxRVytEAo6kYIQPC/AOMvtZr4n4plsOtwa1CxCoBOPz1DBHnHn23bAn2O?= =?us-ascii?q?kmDwHG2BYvEM8PsHTRrdX1Lr0eUeexzKnU0zrMdfVW2Srm5YfUaRAtu+mMXa?= =?us-ascii?q?9rfsbL00kvEBrIg1ONooLrODOV0/4Cs2md7+d4WuKvinInqwFsoje03Msjlo?= =?us-ascii?q?7JhocNxlDF6yp53Ig1Kce/SE5hbt6pFoZbuSKCN4ZuX88vTHxktDw5x7AGo5?= =?us-ascii?q?K3YjYGxZY9yxPRc/CLboeF7g/5WOuSITp0nmxpdbyxihqo7EStxfPwW8+p21?= =?us-ascii?q?hQtCVFiMPDtnUV2hzW7ciIV+Vy81+62TaKywDT8uZEIV0olabDK54u3Lowlp?= =?us-ascii?q?0LvETdGy/5gkT2jKuMeko44eik8fznYqj9qZOGLY90jRnyMqUomsOhHeQ1Kh?= =?us-ascii?q?UCUmeG9eim17Du/Vf1TKtUgvA0iKXUvojWJcEBqa64Bw9V3Jwj6xG6Dzq+zt?= =?us-ascii?q?QYmWMII09EeBKCjojpIUvCIPf8DfejnVujijFrx+3dM7L9GZXBNGDDkKr6cr?= =?us-ascii?q?pn8U5czxI/zcpD6JJMFrEBPPXzV1f0tNzFCh85Lw20w/79B9Vh1oMeRX6AAr?= =?us-ascii?q?eCPaPTr1CI+uwvL/OLZI8PtzauY8QisvvziWM4gVYBfbWixdNDbW28AvV+Kl?= =?us-ascii?q?mZfXH0qtYMDWlMuRAxGr/EklqHBABXbnqzWqMmrhY/FI+vC5qLEp6pibCA2S?= =?us-ascii?q?ahWJpSem1PDE2kGmyub5iOHe0LPnHBavR9myAJAODyA7Qq0guj4Vf3?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2CHBgBI3Dxb/wPjVY1cHQEBBQELAYQ?= =?us-ascii?q?rA2oSKIN6iGONNCqXJzAGAYRAAoJFNxUBAgEBAgEBAgFsHAyCNSKCXwEDAyN?= =?us-ascii?q?UEhwDAQIrAgJNAggGDQYCAQGDHAGCAwuoXoIcH4Q8g3aBOopDP4E2gmiDGAE?= =?us-ascii?q?BAgEBFoEwNoJhglUCjFE8K4wUBwKBboQYiRSBRkODSYJGhUWKNYh3NCImgSw?= =?us-ascii?q?zGlKDCgmCGxeDRYUUhUFsAXkBAZBmAQE?= X-IPAS-Result: =?us-ascii?q?A2CHBgBI3Dxb/wPjVY1cHQEBBQELAYQrA2oSKIN6iGONN?= =?us-ascii?q?CqXJzAGAYRAAoJFNxUBAgEBAgEBAgFsHAyCNSKCXwEDAyNUEhwDAQIrAgJNA?= =?us-ascii?q?ggGDQYCAQGDHAGCAwuoXoIcH4Q8g3aBOopDP4E2gmiDGAEBAgEBFoEwNoJhg?= =?us-ascii?q?lUCjFE8K4wUBwKBboQYiRSBRkODSYJGhUWKNYh3NCImgSwzGlKDCgmCGxeDR?= =?us-ascii?q?YUUhUFsAXkBAZBmAQE?= X-IronPort-AV: E=Sophos;i="5.51,306,1526331600"; d="scan'208,217";a="2701561" Received: from mail.cs.pub.ro (HELO vmail.cs.pub.ro) ([141.85.227.3]) by vesa.cs.pub.ro with ESMTP; 04 Jul 2018 17:42:03 +0300 Received: from localhost (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTP id 6FB091A601B0 for ; Wed, 4 Jul 2018 17:42:03 +0300 (EEST) Received: from vmail.cs.pub.ro ([127.0.0.1]) by localhost (vmail.cs.pub.ro [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Pz1ghbhN_eHr for ; Wed, 4 Jul 2018 17:42:03 +0300 (EEST) Received: from vmail.cs.pub.ro (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTPS id 4CEC21A601B1 for ; Wed, 4 Jul 2018 17:42:03 +0300 (EEST) Received: from [172.19.2.139] (unknown [141.85.233.142]) by vmail.cs.pub.ro (Postfix) with ESMTPSA id 4803E1A601B0 for ; Wed, 4 Jul 2018 17:42:03 +0300 (EEST) References: <153057505413.16040.3777506946393415591.idtracker@ietfa.amsl.com> To: multipathtcp From: Vladimir Olteanu X-Forwarded-Message-Id: <153057505413.16040.3777506946393415591.idtracker@ietfa.amsl.com> Message-ID: <35e29059-de82-7c6a-69cb-9130b338e4e3@cs.pub.ro> Date: Wed, 4 Jul 2018 17:42:02 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <153057505413.16040.3777506946393415591.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------53D13300CC4443684A3740C5" Content-Language: en-US Archived-At: Subject: [multipathtcp] Fwd: New Version Notification for draft-olteanu-intarea-socks-6-03.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 14:42:36 -0000 This is a multi-part message in MIME format. --------------53D13300CC4443684A3740C5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, We've submitted a new version of the SOCKS v6 draft. We've made multiple changes to the protocol based on our experience implementing it. It is now easier to pick and choose which parts of SOCKS v6 to implement: all option kinds are now optional (no pun intended), and no longer have any inter-dependencies or overlap in functionality. It basically can be stripped down all the way to SOCKS v4 functionality. We've also moved token window advertisements to the Authentication Reply, so that the proxy-server RTT has no influence on their timeliness. You can find a feature-complete message library here: https://github.com/45G/libsocks6msg . We've also used said library to implement a (not feature-complete) prototype based on Shadowsocks: https://github.com/45G/shadowsocks-libev . A full-blown implementation is in the works. You can find more SOCKS6-related stuff on the 45G page on Github. Cheers, Vlad -------- Forwarded Message -------- Subject: New Version Notification for draft-olteanu-intarea-socks-6-03.txt Date: Mon, 02 Jul 2018 16:44:14 -0700 From: internet-drafts@ietf.org To: Vladimir Olteanu , Dragos Niculescu A new version of I-D, draft-olteanu-intarea-socks-6-03.txt has been successfully submitted by Vladimir Olteanu and posted to the IETF repository. Name: draft-olteanu-intarea-socks-6 Revision: 03 Title: SOCKS Protocol Version 6 Document date: 2018-07-02 Group: Individual Submission Pages: 24 URL: https://www.ietf.org/internet-drafts/draft-olteanu-intarea-socks-6-03.txt Status: https://datatracker.ietf.org/doc/draft-olteanu-intarea-socks-6/ Htmlized: https://tools.ietf.org/html/draft-olteanu-intarea-socks-6-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-olteanu-intarea-socks-6 Diff: https://www.ietf.org/rfcdiff?url2=draft-olteanu-intarea-socks-6-03 Abstract: The SOCKS protocol is used primarily to proxy TCP connections to arbitrary destinations via the use of a proxy server. Under the latest version of the protocol (version 5), it takes 2 RTTs (or 3, if authentication is used) before data can flow between the client and the server. This memo proposes SOCKS version 6, which reduces the number of RTTs used, takes full advantage of TCP Fast Open, and adds support for 0-RTT authentication. 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. The IETF Secretariat --------------53D13300CC4443684A3740C5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi,

We've submitted a new version of the SOCKS v6 draft.

We've made multiple changes to the protocol based on our experience implementing it. It is now easier to pick and choose which parts of SOCKS v6 to implement: all option kinds are now optional (no pun intended), and no longer have any inter-dependencies or overlap in functionality. It basically can be stripped down all the way to SOCKS v4 functionality.

We've also moved token window advertisements to the Authentication Reply, so that the proxy-server RTT has no influence on their timeliness.

You can find a feature-complete message library here: https://github.com/45G/libsocks6msg . We've also used said library to implement a (not feature-complete) prototype based on Shadowsocks: https://github.com/45G/shadowsocks-libev . A full-blown implementation is in the works.

You can find more SOCKS6-related stuff on the 45G page on Github.

Cheers,

Vlad


-------- Forwarded Message --------
Subject: New Version Notification for draft-olteanu-intarea-socks-6-03.txt
Date: Mon, 02 Jul 2018 16:44:14 -0700
From: internet-drafts@ietf.org
To: Vladimir Olteanu <vladimir.olteanu@cs.pub.ro>, Dragos Niculescu <dragos.niculescu@cs.pub.ro> 


A new version of I-D, draft-olteanu-intarea-socks-6-03.txt
has been successfully submitted by Vladimir Olteanu and posted to the
IETF repository.

Name:		draft-olteanu-intarea-socks-6
Revision:	03
Title:		SOCKS Protocol Version 6
Document date:	2018-07-02
Group:		Individual Submission
Pages:		24
URL:            https://www.ietf.org/internet-drafts/draft-olteanu-intarea-socks-6-03.txt
Status:         https://datatracker.ietf.org/doc/draft-olteanu-intarea-socks-6/
Htmlized:       https://tools.ietf.org/html/draft-olteanu-intarea-socks-6-03
Htmlized:       https://datatracker.ietf.org/doc/html/draft-olteanu-intarea-socks-6
Diff:           https://www.ietf.org/rfcdiff?url2=draft-olteanu-intarea-socks-6-03

Abstract:
   The SOCKS protocol is used primarily to proxy TCP connections to
   arbitrary destinations via the use of a proxy server.  Under the
   latest version of the protocol (version 5), it takes 2 RTTs (or 3, if
   authentication is used) before data can flow between the client and
   the server.

   This memo proposes SOCKS version 6, which reduces the number of RTTs
   used, takes full advantage of TCP Fast Open, and adds support for
   0-RTT authentication.

                                                                                  


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.

The IETF Secretariat
--------------53D13300CC4443684A3740C5-- From nobody Wed Jul 4 08:22:40 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14710130FE1; Wed, 4 Jul 2018 08:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hxUA7eeNw-V3; Wed, 4 Jul 2018 08:22:35 -0700 (PDT) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (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 69376130F05; Wed, 4 Jul 2018 08:22:35 -0700 (PDT) Received: by mail-qk0-x244.google.com with SMTP id c131-v6so3026502qkb.0; Wed, 04 Jul 2018 08:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=1SsbT0wkKH3FtbTY6nqn9Y+y20GFdyLVC/NNGvkP+Ls=; b=u6L6JtMZaTkcAm3l/BdwXdqInhIVUQCaCkFx+6bUtwAos6HNeTKCWYsQcAZ5VWJYuL /5hlNEVV0PymTFrfuwvQ/C5UJHp+m+N6lkgmq8Ar3fSCz+JwKHcVHE2sYzlguEOWLeFU VWzcofZ5Mfm4u4Dacge+gKWhrvDICPBhps5jVLErmn1eIivYgK02YlsSmSGZs+qaPbwc 4tlstF3tDhVlsvttGirvfXIVw6yDGvZ0UaMsaHg2K6zGX1mSKq8VQmwHG32SXYM16VcC /Njyam/wEwbbz/nBszV3oxhxDw/Cmm4/PXz78StH9Fk1SBxy0txC52BS25+xvd827Yyz ELSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=1SsbT0wkKH3FtbTY6nqn9Y+y20GFdyLVC/NNGvkP+Ls=; b=QOT8ySrJH56+xvcCbA1QeFmnJ8wpTZ0oZy+/NJ4Wi5OEaN8Org5hUrWARQMvdUT5T0 /9j4fE5v7JA+2FYpUzryLyYpIfxJKFA3AFjbeVt/5t9FfbDNGex5VldaJHrXI16BLccH r/UFQ9xm8Iir4n5xyOw62RxHCczABGygT8rAqmhqAvg5mk8biaolAlA2xyRVwwBwQ08x Ux5hUEyIiEn/tYgc/qeoTfhE/d2rMM+SEWvAXXDyNki7t7h9W1fHIwobgzQj1K06JNMM vzIMv1VsMuerIoxDxHBYu2NEcPUpSWTl4DYQDwDoKR8lx58Ydd8IF0lBnJuSsc1hyAS1 MRtw== X-Gm-Message-State: APt69E3swlGX60ZgkTHUSrGfhf6lYojakPBNf032OZnrMdsoTpPYiIS+ oJAMuZirMwBrjFPGaZ9FsOr4DZuDMok+sr/zrP3bJw== X-Google-Smtp-Source: AAOMgpctA3hbUK+WJsGoZolO3KeKvvbm77zY2BLnR0Yul7pM1/FbJtB6Xl1vEDJYOhLTZo3zcYMZ0M032beGpuHlC5Y= X-Received: by 2002:a37:bb43:: with SMTP id l64-v6mr1991139qkf.414.1530717754120; Wed, 04 Jul 2018 08:22:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:185a:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 08:22:33 -0700 (PDT) In-Reply-To: References: <152967671506.3644.8668562709318978649.idtracker@ietfa.amsl.com> From: Xavier de Foy Date: Wed, 4 Jul 2018 11:22:33 -0400 Message-ID: To: dmm , multipathtcp Content-Type: multipart/alternative; boundary="000000000000fc5ee205702dff99" Archived-At: Subject: [multipathtcp] Fwd: FW: New Version Notification for draft-defoy-mptcp-considerations-for-5g-01.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 15:22:38 -0000 --000000000000fc5ee205702dff99 Content-Type: text/plain; charset="UTF-8" This update to "Considerations for MPTCP operation in 5G" proposes to make use of the session continuity type defined in ietf-dmm-ondemand-mobility, as input for decisions in the MPTCP stack. (Adding DMM list as recipient. Your feedback would be appreciated.) Best Regards, Xavier. ---------- Forwarded message ---------- From: Xavier de Foy Date: Fri, Jun 22, 2018 at 11:03 AM Subject: Fwd: FW: New Version Notification for draft-defoy-mptcp-considerations-for-5g-01.txt To: multipathtcp Hi, We have submitted a new version of "Considerations for MPTCP operation in 5G". Following comments at the last IETF meeting, we used the session continuity type defined in ietf-dmm-ondemand-mobility as primary input for local decisions in MPTCP stack. Session continuity type can also be associated with IP addresses in MPTCP signalling. More minor updates were made to the dual connectivity related topic (work is ongoing, there may be a more significant update later). Best Regards, Xavier. ---------- A new version of I-D, draft-defoy-mptcp-considerations-for-5g-01.txt has been successfully submitted by Xavier de Foy and posted to the IETF repository. Name:draft-defoy-mptcp-considerations-for-5g Revision:01 Title:Considerations for MPTCP operation in 5G Document date:2018-06-22 Group:Individual Submission Pages:13 URL: https://www.ietf.org/internet-drafts/draft-defoy-mptcp-consi derations-for-5g-01.txt Status: https://datatracker.ietf.org/doc/draft-defoy-mptcp-consider ations-for-5g/ Htmlized: https://tools.ietf.org/html/draft-defoy-mptcp-consideration s-for-5g-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-defoy-mptcp-con siderations-for-5g Diff: https://www.ietf.org/rfcdiff?url2=draft-defoy-mptcp-conside rations-for-5g-01 Abstract: This document describes scenarios where the behavior of the 5G mobility management framework is different from earlier cellular generations, and describes how it may benefit from some form of adaptation of MPTCP implementations and protocol aspects in the 5G system. This document also describes how MPTCP may be leveraged in 5G system specifications. 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. The IETF Secretariat [Banner] This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature. --000000000000fc5ee205702dff99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This update to=20 "Considerations for MPTCP operation in 5G" proposes to make use o= f=20 the session continuity type defined in ietf-dmm-ondemand-mobility,=20 as input for decisions in the MPTCP stack.

(Adding = DMM list as recipient. Your feedback would be appreciated.)
<= br>
Best Regards,
Xavier.
=C2=A0
---------- Forwarded message ----= ------
From: Xavier de Foy <x.defoy.ietf@gmail.c= om>
Date: Fri, Jun 22, 2018 at 11:03 AM
Subject: Fwd: F= W: New Version Notification for draft-defoy-mptcp-considerations-for-5g-01.= txt
To: multipathtcp <multip= athtcp@ietf.org>


Hi,

=
=C2=A0 We have submitted a new version of "Considerations f= or MPTCP operation in 5G".

=C2=A0 Following c= omments at the last IETF meeting, we used the session continuity type defin= ed in ietf-dmm-ondemand-mobility as primary input for local decisions in MP= TCP stack. Session continuity type can also be associated with IP addresses= in MPTCP signalling. More minor updates were made to the dual connectivity= related topic (work is ongoing, there may be a more significant update lat= er).

=C2=A0Best Regards,=
Xavier.
----------

A new version of I-D, draft-defoy-mptcp-considerations-for-5g-01.txt has been successfully submitted by Xavier de Foy and posted to the IETF rep= ository.

Name:draft-defoy-mptcp-considerations-for-5g
Revision:01
Title:Considerations for MPTCP operation in 5G
Document date:2018-06-22
Group:Individual Submission
Pages:13
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draf= t-defoy-mptcp-considerations-for-5g-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-defoy-mptcp-consi= derations-for-5g/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-defoy-mptcp-consideration= s-for-5g-01
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-defoy-mptcp-c= onsiderations-for-5g
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-defo= y-mptcp-considerations-for-5g-01

Abstract:
=C2=A0 =C2=A0This document describes scenarios where the behavior of the 5G=
=C2=A0 =C2=A0mobility management framework is different from earlier cellul= ar
=C2=A0 =C2=A0generations, and describes how it may benefit from some form o= f
=C2=A0 =C2=A0adaptation of MPTCP implementations and protocol aspects in th= e 5G
=C2=A0 =C2=A0system.=C2=A0 This document also describes how MPTCP may be le= veraged in
=C2=A0 =C2=A05G system specifications.




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.

The IETF Secretariat

[Banner]
This e-mail is intended only for the use of the individual or entity to whi= ch it is addressed, and may contain information that is privileged, confide= ntial and/or otherwise protected from disclosure to anyone other than its i= ntended recipient. Unintended transmission shall not constitute waiver of a= ny privilege or confidentiality obligation. If you received this communicat= ion in error, please do not review, copy or distribute it, notify me immedi= ately by email, and delete the original message and any attachments. Unless= expressly stated in this e-mail, nothing in this message or any attachment= should be construed as a digital or electronic signature.



--000000000000fc5ee205702dff99-- From nobody Thu Jul 5 01:11:50 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96411130E44 for ; Thu, 5 Jul 2018 01:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 4YgW9nujNC5k for ; Thu, 5 Jul 2018 01:11:46 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8DAD130E03 for ; Thu, 5 Jul 2018 01:11:45 -0700 (PDT) Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by EVMED02-UKBR.bt.com (10.216.161.32) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 5 Jul 2018 09:11:43 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03c.domain1.systemhost.net (10.55.202.26) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Thu, 5 Jul 2018 09:11:41 +0100 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.1293.004; Thu, 5 Jul 2018 09:11:41 +0100 From: To: Thread-Topic: mptcp - Requested session has been scheduled for IETF 102 Thread-Index: AQHUEub6eALNfiYXMUqvAQvG9UtPj6SASK5A Date: Thu, 5 Jul 2018 08:11:40 +0000 Message-ID: <38030110367d4490b91097e59fb52cd7@rew09926dag03b.domain1.systemhost.net> References: <153063362190.4893.12973451012294341052.idtracker@ietfa.amsl.com> In-Reply-To: <153063362190.4893.12973451012294341052.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.242] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] FW: mptcp - Requested session has been scheduled for IETF 102 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 08:11:49 -0000 SGksDQpBYm91dCB0aGUgYWdlbmRhIGZvciBvdXIgbWVldGluZy4gQSBwcmVsaW1pbmFyeSBhZ2Vu ZGEgaXMgdXBsb2FkZWQuIA0KDQotIHdoaWNoIG9mIHRoZSBhdXRob3JzIG9mIHJmYzY4MjRiaXMg d2lsbCBsZWFkIHRoYXQgZGlzY3Vzc2lvbj8NCi0gb2YgY291cnNlIHdlIChzdGlsbCkgbmVlZCBj b21tZW50cyBvbiB0aGUgZG9jLCBhbmQgcmVzcG9uc2VzIHRvIHRoZSBjb21tZW50cyBzbyBmYXIN Ci0gYXJlIHRoZXJlIG90aGVyIHBlb3BsZSB3aG8gd2FudCB0byBwcmVzZW50IHNvbWV0aGluZz8N Ci0gd2Ugd2lsbCBhbHNvIHRyeSB0byBoYXZlIGEgZGlzY3Vzc2lvbiBhYm91dCB0aGUgZnV0dXJl IG9mIHRoZSBXRyAoc29tZSBlYXJsaWVyIG1haWxzIGFib3V0IHBvdGVudGlhbCBmdXR1cmUgdG9w aWNzKQ0KDQp0aGFua3MNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206ICJJRVRG IFNlY3JldGFyaWF0IiBbbWFpbHRvOmFnZW5kYUBpZXRmLm9yZ10gDQpTZW50OiAwMyBKdWx5IDIw MTggMTc6MDANClRvOiBuaXNoaWRhQHNmYy53aWRlLmFkLmpwOyBtcHRjcC1jaGFpcnNAaWV0Zi5v cmcNCkNjOiBtdWx0aXBhdGh0Y3BAaWV0Zi5vcmc7IGlldGZAa3VlaGxld2luZC5uZXQNClN1Ympl Y3Q6IG1wdGNwIC0gUmVxdWVzdGVkIHNlc3Npb24gaGFzIGJlZW4gc2NoZWR1bGVkIGZvciBJRVRG IDEwMg0KDQpEZWFyIFlvc2hpZnVtaSBOaXNoaWRhLA0KDQpUaGUgc2Vzc2lvbihzKSB0aGF0IHlv dSBoYXZlIHJlcXVlc3RlZCBoYXZlIGJlZW4gc2NoZWR1bGVkLg0KQmVsb3cgaXMgdGhlIHNjaGVk dWxlZCBzZXNzaW9uIGluZm9ybWF0aW9uIGZvbGxvd2VkIGJ5IHRoZSBvcmlnaW5hbCByZXF1ZXN0 LiANCg0KDQogICAgbXB0Y3AgU2Vzc2lvbiAxICgxOjMwIHJlcXVlc3RlZCkNCiAgICBNb25kYXks IDE2IEp1bHkgMjAxOCwgQWZ0ZXJub29uIFNlc3Npb24gSUkgMTU1MC0xNzUwDQogICAgUm9vbSBO YW1lOiBTYWludC1QYXVsL1NhaW50ZS1DYXRoZXJpbmUgc2l6ZTogMTAwDQogICAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KaUNhbGVuZGFyOiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAyL3Nlc3Npb25zL21wdGNwLmljcw0K DQpSZXF1ZXN0IEluZm9ybWF0aW9uOg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KV29ya2luZyBHcm91cCBOYW1lOiBNdWx0aXBh dGggVENQDQpBcmVhIE5hbWU6IFRyYW5zcG9ydCBBcmVhDQpTZXNzaW9uIFJlcXVlc3RlcjogWW9z aGlmdW1pIE5pc2hpZGENCg0KTnVtYmVyIG9mIFNlc3Npb25zOiAxDQpMZW5ndGggb2YgU2Vzc2lv bihzKTogIDEuNSBIb3Vycw0KTnVtYmVyIG9mIEF0dGVuZGVlczogNTANCkNvbmZsaWN0cyB0byBB dm9pZDogDQogRmlyc3QgUHJpb3JpdHk6IGlwcG0gdGNwaW5jIHRjcG0gdHN2YXJlYSB0c3Z3ZyB0 bHMgIFNlY29uZCBQcmlvcml0eTogdGFwcyBpY2NyZyBydGN3ZWIgbWFuZXQgZG1tICBUaGlyZCBQ cmlvcml0eTogbmZ2cmcgcXVpYyBtYXByZw0KDQoNClBlb3BsZSB3aG8gbXVzdCBiZSBwcmVzZW50 Og0KICBZb3NoaWZ1bWkgTmlzaGlkYQ0KICBQaGlsaXAgRWFyZGxleQ0KICBNaXJqYSBLdWVobGV3 aW5kDQoNClJlc291cmNlcyBSZXF1ZXN0ZWQ6DQoNClNwZWNpYWwgUmVxdWVzdHM6DQogIHBsZWFz ZSBhdm9pZCBhbnkgdHJhbnNwb3J0IGFyZWEgQm9Gcw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== From nobody Thu Jul 5 01:21:00 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30D7130E03 for ; Thu, 5 Jul 2018 01:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Ijp0x20hV_T0 for ; Thu, 5 Jul 2018 01:20:55 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9646126CB6 for ; Thu, 5 Jul 2018 01:20:54 -0700 (PDT) Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by EVMED02-UKBR.bt.com (10.216.161.32) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 5 Jul 2018 09:20:52 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03c.domain1.systemhost.net (10.55.202.26) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Thu, 5 Jul 2018 09:20:51 +0100 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.1293.004; Thu, 5 Jul 2018 09:20:51 +0100 From: To: Thread-Topic: WG Last Call for draft-ietf-mptcp-rfc6824bis Thread-Index: AdP8pPjqwq5n45WRS2ywhz4YK91ZcQAGiU/gBBgqcVABkj0esAAzz6Fw Date: Thu, 5 Jul 2018 08:20:50 +0000 Message-ID: References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> <39fbc9f18384473398fca38670c73cf6@rew09926dag03b.domain1.systemhost.net> 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.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 08:20:58 -0000 Hi, Fyi I prepared some text describing the main differences between the bis an= d rfc6824, and the reasons for those changes. I wrote it in the context of = helping the IESG when they get to reviewing it - but I thought it might be = useful to helping prompt WG comments at this stage (which we urgently need)= . The text is draft. Best wishes, Phil -- This summarises the changes in draft-ietf-mptcp-rfc6824bis compared to the = RFC6824.=20 https://tools.ietf.org/rfcdiff?url1=3Dhttps://www.ietf.org/id/draft-ietf-mp= tcp-rfc6824bis-11.txt&url2=3Dhttps://www.rfc-editor.org/rfc/rfc6824.txt =20 1. It obsoletes RFC6824. This is considered a replacement for RFC6824, as i= t improves it in several ways. It is not backwards compatible with RFC6824 = (the protocol changes in #4 and #9 in particular).=20 2. Its Intended Status is Standards Track. RFC6824 is an Experimental Track= document. When it was completed, it was agreed to re-charter the WG with t= he primary goal to create a bis version of the protocol document on the Sta= ndards track.=20 a. The bis incorporates lessons learnt from the various implementations, de= ployments and experiments. RFC8041 discusses "Use Cases and Operational Exp= erience with Multipath TCP" https://tools.ietf.org/html/rfc8041 and an IETF= Journal article describes "Multipath TCP Deployments" https://www.ietfjour= nal.org/multipath-tcp-deployments/=20 b. In summary, MPTCP is extensively deployed, especially on smartphones (it= is in Apple's iOS and macOS operating systems and is in several models of = commercial Android smartphones), and is also deployed in some hybrid access= networks. =20 c. The 'reference', maintained Linux implementation of RFC6824 is available= at https://multipath-tcp.org/=20 d. RFC6824bis-11 has been implemented in Linux, but has not been released (= yet). 3. Christoph Paasch is added as an author, as he proposed several of the ne= w elements 4. Connection initiation, through the exchange of the MP-CAPABLE MPTCP opti= on, is different from RFC6824. Assuming that host A sends the SYN and ACK, = and host B sends the SYN-ACK:- a. Unlike RFC6824, the SYN doesn't include A's key (it is still sent in the= ACK). This change means that A's key, which is sent in the clear, is not s= ent until B is known to be MPTCP-enabled. b. The ACK can include data. This change means that A can send data without= having to wait for B to send it data, as only then can it be sure the ACK = has been received. To handle this case, the MP-CAPABLE option includes fiel= ds with the Data-Level Length and optionally a Checksum.=20 c. In the Flags field, C is now assigned to mean that the sender of this op= tion will not accept additional MPTCP subflows to the source address and po= rt. This is an efficiency improvement, for example where the sender is behi= nd a strict NAT. d. In the flags field, D now indicates the use of HMAC-SHA256 (rather than = HMAC-SHA1). 5. Connection initiation also defines the procedure for version negotiation= , for implementations that support both v0 (RFC6824) and v1 (RFC6824bis). T= he initiator indicates the highest version it supports, the responder indic= ates if it supports this version. To prevent a downgrade attack, the initia= tor SHOULD fall back to regular TCP, alternatively it MAY establish a new c= onnection with the lower version of MPTCP.=20 6. The HMAC-SHA256 (rather than HMAC-SHA1) algorithm is used, as the algori= thm provides better security. It is used to generate the token in the MP_JO= IN and ADD_ADDR messages, and to set the initial data sequence number. 7. As in RFC6824, a TCP RST for the subflow re-sets the subflow, or (in res= ponse to MP_JOIN) rejects an attempt to open a subflow. The change is that = the process is enhanced by adding a MP_TCPRST Option:- a. The new option includes a flag indicating whether the error condition is= permanent or temporary, and a field with the "MP_TCPRST Reason Code", whic= h indicates why the TCP RST is being sent.=20 b. The receiving host MAY use this information to decide, for example, whet= her it tries to re-establish the subflow immediately, later, or never. c. IANA is requested to create a further sub-registry with the "MP_TCPRST R= eason Codes".=20 8. The MP_PRIO option, which is used to signal a change of priority for a s= ubflow, no longer includes the AddrID field. Its purpose was to allow the c= hanged priority to be applied on a subflow other than the one it was sent = on. However, it has been realised that this could be used by a man-in-the-m= iddle to divert all traffic on to its own path, and this is an easy attack = since MP_PRIO does not include a token or other security mechanism. The iss= ue was discussed at IETF-99 and since no implementer was known to use the a= ddress identifier on MP-PRIO, it was agreed that the best approach was to r= emove it. 9. The ADD_ADDR option, which is used to inform the other host about anothe= r potential address, is different in several ways: a. It now includes an HMAC of the added address. This is for enhanced secur= ity. The RFC6824 procedure for adding an address is open to an attack where= an off-path attacker creates a spoofed ADD_ADDR that enables it to hijack = an MPTCP-enabled connection. Including an HMAC in the ADD_ADDR message make= s it as secure as MP_JOIN.=20 b. This was the primary driver for incrementing the version number. This wa= s first discussed at an interim meeting in 2015 and subsequently at IETF-96= . The WG consensus was that this approach was better than incorporating an = alternative add address mechanism within an enhanced version 0 of the proto= col. The problem and solution is discussed further in RFC7430. c. Reliability for the ADD_ADDR option. The IPVer field is replaced with a = flag field (the IP version field was not useful, since it is known anyway),= and one flag is assigned (E) which is used as an 'Echo' so a host can indi= cate that it has received the option. Hence this provides reliability for t= he ADD_ADDR option.=20 10. An additional way of performing a Fast Close is described. The host sen= ds a RST containing the MPT_FASTCLOSE option on all subflows. This allows t= he host to tear down the subflows and the connection immediately.=20 11. In the IANA registry a new MPTCP subtype option, MP_EXPERIMENTAL, is Re= served for private experiments. However, the document doesn't define how to= use the subtype option.=20 12. A new Appendix discusses the usage of both the MPTCP and TCP Fast Open = on the same packet. The two main issues are discussed:=20 a. The potential lack of enough option space in a TCP packet. This is more = likely to be an issue on the SYN+ACK packet, and the suggestion is to use a= shorter TFO cookie if necessary. b. A potential problem with data sequence mapping under some circumstances.= The suggestion is that the TFO data is not considered part of the Data Seq= uence Number space. -----Original Message----- From: Eardley,PL,Philip,TUD1 R=20 Sent: 04 July 2018 08:31 To: 'multipathtcp@ietf.org' Subject: RE: WG Last Call for draft-ietf-mptcp-rfc6824bis We urgently need your comments about this document.=20 It's been in WG last call for just on 4 weeks, but I think the only comment= s so far are from the WG chairs - clearly we need more comments before the = document can advance. We'd like to discuss and close issues before or durin= g the IETF. So please can you dedicate some time to checking the document. Thanks, Phil & Yoshi -----Original Message----- From: Eardley,PL,Philip,TUD1 R=20 Sent: 26 June 2018 08:33 To: multipathtcp@ietf.org Subject: RE: WG Last Call for draft-ietf-mptcp-rfc6824bis Hi, Just a reminder about the WGLC for the protocol bis. Please send comments, = Thanks! Phil & Yoshi -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 05 June 2018 12:21 To: multipathtcp@ietf.org Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis As a reminder, this document Obsoletes: 6824 (if approved) and its Intended= status is Standards Track. As well as suggested changes or edits, positive review comments ("It's read= y") are also very valuable.=20 -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 05 June 2018 09:14 To: multipathtcp@ietf.org Subject: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis This starts a WG Last Call for draft-ietf-mptcp-rfc6824bis. Please send com= ments by the end of June.=20 Please note there are three IPR disclosures (we're working on getting them = added to the rfc6824bis page):=20 * two are inherited from RFC6824 https://datatracker.ietf.org/ipr/search/?= submit=3Ddraft&id=3Ddraft-ietf-mptcp-multiaddressed =20 * one is inherited from draft-paasch-mptcp-syncookies (which got include in= rfc6824bis) https://datatracker.ietf.org/ipr/2678/=20 Thanks, Phil & 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 From nobody Sun Jul 8 11:33:45 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D9F1310D4; Sun, 8 Jul 2018 11:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 aTgGJDLfSvHw; Sun, 8 Jul 2018 11:33:41 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68CF1310CC; Sun, 8 Jul 2018 11:33:40 -0700 (PDT) Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A46E92783BC; Mon, 9 Jul 2018 03:33:38 +0900 (JST) Received: by mail-io0-f178.google.com with SMTP id z19-v6so15130939ioh.4; Sun, 08 Jul 2018 11:33:38 -0700 (PDT) X-Gm-Message-State: AOUpUlH7SByxzLxcTwzkPZTCisCz+flBicYjqAUfWnMylEdW+6H3BKWy wnfkBbewa28M50rENASbEwgErIyBNoabwqmBvkY= X-Google-Smtp-Source: AAOMgpdPWN+dm/eUjv4OVJj5dlXsgQP6NUKHXZUhcE7sozm3xL1JW2LCYx4RCo0MmK292pbl/ZbfozOdi170wr47Jsw= X-Received: by 2002:a6b:5903:: with SMTP id n3-v6mr14634526iob.7.1531074817525; Sun, 08 Jul 2018 11:33:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:7599:0:0:0:0:0 with HTTP; Sun, 8 Jul 2018 11:33:37 -0700 (PDT) In-Reply-To: References: <152967671506.3644.8668562709318978649.idtracker@ietfa.amsl.com> From: Yoshifumi Nishida Date: Sun, 8 Jul 2018 11:33:37 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Xavier de Foy Cc: dmm , multipathtcp Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [multipathtcp] Fwd: FW: New Version Notification for draft-defoy-mptcp-considerations-for-5g-01.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2018 18:33:44 -0000 Hi Xavier, Thanks for the draft. I have a question about dual connectivity. "Therefore, in a first case, DC can be made visible to applications through different IP addresses, while in a second case, DC can be used by different flows terminated at the same IP address on the device." In the second case, is there any way for upper layer to know or specify which packets go through which radio links? -- Yoshi On Wed, Jul 4, 2018 at 8:22 AM, Xavier de Foy wrote: > This update to "Considerations for MPTCP operation in 5G" proposes to make > use of the session continuity type defined in ietf-dmm-ondemand-mobility, as > input for decisions in the MPTCP stack. > > (Adding DMM list as recipient. Your feedback would be appreciated.) > > Best Regards, > Xavier. > > ---------- Forwarded message ---------- > From: Xavier de Foy > Date: Fri, Jun 22, 2018 at 11:03 AM > Subject: Fwd: FW: New Version Notification for > draft-defoy-mptcp-considerations-for-5g-01.txt > To: multipathtcp > > > Hi, > > We have submitted a new version of "Considerations for MPTCP operation in > 5G". > > Following comments at the last IETF meeting, we used the session > continuity type defined in ietf-dmm-ondemand-mobility as primary input for > local decisions in MPTCP stack. Session continuity type can also be > associated with IP addresses in MPTCP signalling. More minor updates were > made to the dual connectivity related topic (work is ongoing, there may be a > more significant update later). > > Best Regards, > Xavier. > > ---------- > > A new version of I-D, draft-defoy-mptcp-considerations-for-5g-01.txt > has been successfully submitted by Xavier de Foy and posted to the IETF > repository. > > Name:draft-defoy-mptcp-considerations-for-5g > Revision:01 > Title:Considerations for MPTCP operation in 5G > Document date:2018-06-22 > Group:Individual Submission > Pages:13 > URL: > https://www.ietf.org/internet-drafts/draft-defoy-mptcp-considerations-for-5g-01.txt > Status: > https://datatracker.ietf.org/doc/draft-defoy-mptcp-considerations-for-5g/ > Htmlized: > https://tools.ietf.org/html/draft-defoy-mptcp-considerations-for-5g-01 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-defoy-mptcp-considerations-for-5g > Diff: > https://www.ietf.org/rfcdiff?url2=draft-defoy-mptcp-considerations-for-5g-01 > > Abstract: > This document describes scenarios where the behavior of the 5G > mobility management framework is different from earlier cellular > generations, and describes how it may benefit from some form of > adaptation of MPTCP implementations and protocol aspects in the 5G > system. This document also describes how MPTCP may be leveraged in > 5G system specifications. > > > > > 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. > > The IETF Secretariat > > [Banner] > This e-mail is intended only for the use of the individual or entity to > which it is addressed, and may contain information that is privileged, > confidential and/or otherwise protected from disclosure to anyone other than > its intended recipient. Unintended transmission shall not constitute waiver > of any privilege or confidentiality obligation. If you received this > communication in error, please do not review, copy or distribute it, notify > me immediately by email, and delete the original message and any > attachments. Unless expressly stated in this e-mail, nothing in this message > or any attachment should be construed as a digital or electronic signature. > > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From nobody Mon Jul 9 07:03:25 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E93130E79; Mon, 9 Jul 2018 07:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KGsdOdFOqWGT; Mon, 9 Jul 2018 07:03:14 -0700 (PDT) Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (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 1A322130DBE; Mon, 9 Jul 2018 07:03:14 -0700 (PDT) Received: by mail-qk0-x241.google.com with SMTP id y4-v6so9731433qka.5; Mon, 09 Jul 2018 07:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XFJIC+9ubkPEzLDhPPlMSyQhNr3pP1UNqmdRO8bmxvs=; b=dQV+QGh7KRHhFx4CmdlhcwR5BKjYUpyXxsEE/PK9Xn3oABRaEQbFp/Q2pFW3jbs+h5 rpBcdc6ATYNJHXjNPj6RPfIl4/FEXNuFiRZuLNCVhMGx104CmAFIraB5gWhKE+dRfbSG bcnKLKHTRZcs2vORyKXzK32rLkUS9xqy/wtPjomU7ADQfzXYWkntrkj5j/eUwhpW4gpH YFp7vHc9L+pO4BBHP4oOczVz4xLu+08oa4Oht6rcOtvsuCqXNlUepHlwk60wpsbNQ28r 87foxL1LAK+rMYh01kInjWJXVcW2MHNvlQoRMSluijpYE36QzRSElnwUeczgRY/fxny7 VJOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XFJIC+9ubkPEzLDhPPlMSyQhNr3pP1UNqmdRO8bmxvs=; b=SUTUO8k798qzzFvAbUeawZDW81okK/I+FnhfvcBqzcIB9vbtEAxRdbEzbLjDJiVfwH pYV1ubEMPTCENYg5dCkZ2mtHeawCXGnAu7yviWa3SCq9jYN4O02JPG1aq06vU5/EXK+H K+J8uT5VA1VsZbGm0zd6MpHLgo1zRtwCj8/oeQFEQ2/HDAQwtmkx36oeyoXp5WS0ioKj XKrhY1/AUKcPOPJd3xP7pFNyYAIgsAe5H7hxfJofpOPomCZMqp9pe/Py30+x4HF4RQp+ MGYimxBK3NhsmI2X55oB6ZZAhAs4TC+yuzni+sipO25vbCd+ULWqdYU72mlhlF0BlslS RTYA== X-Gm-Message-State: APt69E3YNN55teJqU9cGj9YAkheAECQxbak8YW0Gm7oD02R6ofiV2BBo HOyF+9+Sh54WPtVyknLc5bL9XhMfE8Nk3GhZ7McCmA== X-Google-Smtp-Source: AAOMgpeSQwYY3CWyI4erEkCd+nrtH4hGUfXmw7SCJT2aJ6lRkxdft9gNx+1jVdtH3/ds6RAcUz5EPz7xc8aEfAeQvEE= X-Received: by 2002:a37:4f10:: with SMTP id d16-v6mr17927993qkb.323.1531144993243; Mon, 09 Jul 2018 07:03:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:30f8:0:0:0:0:0 with HTTP; Mon, 9 Jul 2018 07:03:12 -0700 (PDT) In-Reply-To: References: <152967671506.3644.8668562709318978649.idtracker@ietfa.amsl.com> From: Xavier de Foy Date: Mon, 9 Jul 2018 10:03:12 -0400 Message-ID: To: Yoshifumi Nishida Cc: dmm , multipathtcp Content-Type: multipart/alternative; boundary="0000000000006c0a0505709179ec" Archived-At: Subject: Re: [multipathtcp] Fwd: FW: New Version Notification for draft-defoy-mptcp-considerations-for-5g-01.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 14:03:18 -0000 --0000000000006c0a0505709179ec Content-Type: text/plain; charset="UTF-8" Hi Yoshi, My guess would be through (possibly new) socket options, but maybe Kien will have a better answer, as the main contributor on this section. Best Regards, Xavier On Sun, Jul 8, 2018 at 2:33 PM, Yoshifumi Nishida wrote: > Hi Xavier, > > Thanks for the draft. I have a question about dual connectivity. > > "Therefore, in a first case, DC can be made visible to applications > through different IP addresses, while in a second case, DC can be used > by different flows terminated at the same IP address on the device." > > In the second case, is there any way for upper layer to know or > specify which packets go through which radio links? > -- > Yoshi > > On Wed, Jul 4, 2018 at 8:22 AM, Xavier de Foy > wrote: > > This update to "Considerations for MPTCP operation in 5G" proposes to > make > > use of the session continuity type defined in > ietf-dmm-ondemand-mobility, as > > input for decisions in the MPTCP stack. > > > > (Adding DMM list as recipient. Your feedback would be appreciated.) > > > > Best Regards, > > Xavier. > > > > ---------- Forwarded message ---------- > > From: Xavier de Foy > > Date: Fri, Jun 22, 2018 at 11:03 AM > > Subject: Fwd: FW: New Version Notification for > > draft-defoy-mptcp-considerations-for-5g-01.txt > > To: multipathtcp > > > > > > Hi, > > > > We have submitted a new version of "Considerations for MPTCP operation > in > > 5G". > > > > Following comments at the last IETF meeting, we used the session > > continuity type defined in ietf-dmm-ondemand-mobility as primary input > for > > local decisions in MPTCP stack. Session continuity type can also be > > associated with IP addresses in MPTCP signalling. More minor updates were > > made to the dual connectivity related topic (work is ongoing, there may > be a > > more significant update later). > > > > Best Regards, > > Xavier. > > > > ---------- > > > > A new version of I-D, draft-defoy-mptcp-considerations-for-5g-01.txt > > has been successfully submitted by Xavier de Foy and posted to the IETF > > repository. > > > > Name:draft-defoy-mptcp-considerations-for-5g > > Revision:01 > > Title:Considerations for MPTCP operation in 5G > > Document date:2018-06-22 > > Group:Individual Submission > > Pages:13 > > URL: > > https://www.ietf.org/internet-drafts/draft-defoy-mptcp- > considerations-for-5g-01.txt > > Status: > > https://datatracker.ietf.org/doc/draft-defoy-mptcp- > considerations-for-5g/ > > Htmlized: > > https://tools.ietf.org/html/draft-defoy-mptcp-considerations-for-5g-01 > > Htmlized: > > https://datatracker.ietf.org/doc/html/draft-defoy-mptcp- > considerations-for-5g > > Diff: > > https://www.ietf.org/rfcdiff?url2=draft-defoy-mptcp- > considerations-for-5g-01 > > > > Abstract: > > This document describes scenarios where the behavior of the 5G > > mobility management framework is different from earlier cellular > > generations, and describes how it may benefit from some form of > > adaptation of MPTCP implementations and protocol aspects in the 5G > > system. This document also describes how MPTCP may be leveraged in > > 5G system specifications. > > > > > > > > > > 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. > > > > The IETF Secretariat > > > > [Banner] > > This e-mail is intended only for the use of the individual or entity to > > which it is addressed, and may contain information that is privileged, > > confidential and/or otherwise protected from disclosure to anyone other > than > > its intended recipient. Unintended transmission shall not constitute > waiver > > of any privilege or confidentiality obligation. If you received this > > communication in error, please do not review, copy or distribute it, > notify > > me immediately by email, and delete the original message and any > > attachments. Unless expressly stated in this e-mail, nothing in this > message > > or any attachment should be construed as a digital or electronic > signature. > > > > > > > > > > _______________________________________________ > > multipathtcp mailing list > > multipathtcp@ietf.org > > https://www.ietf.org/mailman/listinfo/multipathtcp > > > --0000000000006c0a0505709179ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yoshi,

My guess woul= d be through (possibly new) socket options, but maybe Kien will have a bett= er answer, as the main contributor on this section.

Best Regards,
Xavier

On Sun, Jul 8, 2018 at 2:33= PM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:<= br>
Hi Xavier,

Thanks for the draft. I have a question about dual connectivity.

"Therefore, in a first case, DC can be made visible to applications through different IP addresses, while in a second case, DC can be used
by different flows terminated at the same IP address on the device."
In the second case, is there any way for upper layer to know or
specify which packets go through which radio links?
--
Yoshi

On Wed, Jul 4, 2018 at 8:22 AM, Xavier de Foy <x.defoy.ietf@gmail.com> wrote:
> This update to "Considerations for MPTCP operation in 5G" pr= oposes to make
> use of the session continuity type defined in ietf-dmm-ondemand-mobili= ty, as
> input for decisions in the MPTCP stack.
>
> (Adding DMM list as recipient. Your feedback would be appreciated.) >
> Best Regards,
> Xavier.
>
> ---------- Forwarded message ----------
> From: Xavier de Foy <x.de= foy.ietf@gmail.com>
> Date: Fri, Jun 22, 2018 at 11:03 AM
> Subject: Fwd: FW: New Version Notification for
> draft-defoy-mptcp-considerations-for-5g-01.txt
> To: multipathtcp <multipat= htcp@ietf.org>
>
>
> Hi,
>
>=C2=A0 =C2=A0We have submitted a new version of "Considerations fo= r MPTCP operation in
> 5G".
>
>=C2=A0 =C2=A0Following comments at the last IETF meeting, we used the s= ession
> continuity type defined in ietf-dmm-ondemand-mobility as primary input= for
> local decisions in MPTCP stack. Session continuity type can also be > associated with IP addresses in MPTCP signalling. More minor updates w= ere
> made to the dual connectivity related topic (work is ongoing, there ma= y be a
> more significant update later).
>
>=C2=A0 Best Regards,
> Xavier.
>
> ----------
>
> A new version of I-D, draft-defoy-mptcp-considerations-for-5g-01.= txt
> has been successfully submitted by Xavier de Foy and posted to the IET= F
> repository.
>
> Name:draft-defoy-mptcp-considerations-for-5g
> Revision:01
> Title:Considerations for MPTCP operation in 5G
> Document date:2018-06-22
> Group:Individual Submission
> Pages:13
> URL:
> https://www.= ietf.org/internet-drafts/draft-defoy-mptcp-considerations-for-5g-= 01.txt
> Status:
> https://datatracker.ie= tf.org/doc/draft-defoy-mptcp-considerations-for-5g/
> Htmlized:
> https://tools.ietf.org/ht= ml/draft-defoy-mptcp-considerations-for-5g-01
> Htmlized:
> https://datatracke= r.ietf.org/doc/html/draft-defoy-mptcp-considerations-for-5g > Diff:
> https://www.ietf.= org/rfcdiff?url2=3Ddraft-defoy-mptcp-considerations-for-5g-01=
>
> Abstract:
>=C2=A0 =C2=A0 This document describes scenarios where the behavior of t= he 5G
>=C2=A0 =C2=A0 mobility management framework is different from earlier c= ellular
>=C2=A0 =C2=A0 generations, and describes how it may benefit from some f= orm of
>=C2=A0 =C2=A0 adaptation of MPTCP implementations and protocol aspects = in the 5G
>=C2=A0 =C2=A0 system.=C2=A0 This document also describes how MPTCP may = be leveraged in
>=C2=A0 =C2=A0 5G system specifications.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> The IETF Secretariat
>
> [Banner]
> This e-mail is intended only for the use of the individual or entity t= o
> which it is addressed, and may contain information that is privileged,=
> confidential and/or otherwise protected from disclosure to anyone othe= r than
> its intended recipient. Unintended transmission shall not constitute w= aiver
> of any privilege or confidentiality obligation. If you received this > communication in error, please do not review, copy or distribute it, n= otify
> me immediately by email, and delete the original message and any
> attachments. Unless expressly stated in this e-mail, nothing in this m= essage
> or any attachment should be construed as a digital or electronic signa= ture.
>
>
>
>
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/mu= ltipathtcp
>

--0000000000006c0a0505709179ec-- From nobody Tue Jul 10 23:22:50 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6ED3130E0E for ; Tue, 10 Jul 2018 23:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5LanHrv_i8TR for ; Tue, 10 Jul 2018 23:22:45 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 88283130E13 for ; Tue, 10 Jul 2018 23:22:44 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id q127-v6so17882826ljq.11 for ; Tue, 10 Jul 2018 23:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lyTaWL1yBchTVJVT5yzLXq/kgjW0xRGjPQOiyCO+Lhk=; b=RAEefQobSYuEE8xk8tPbVe9bdpOYIQkZbLFrdXMPUy2jOnGbleP1G+2m+LbIBXR0+I 9WOMUtmbFXHTFgk1WB+uYULuu58wwzJENyPaG1yRLlEeniQOwcqINORF08O+WF9cdrnF +S4xw7qbifLV1Fq99tNwtuB+0UI5/UlmzZNdfA+P4TCDDQN+iCNXbgB+eWdowRoXgMGn DEt1lL9aYgCdSor9I+HIXU0KlVALsOfbShXXwGOVcJ7S96Hk1Ewe311p2j2mfQRe0XDN 4jyIFu5DjpQ1kA9mY1LVI08xjT29dG/zc/d7xz90oNviogcbgehh5w8+re4QNpixmFfg JyOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lyTaWL1yBchTVJVT5yzLXq/kgjW0xRGjPQOiyCO+Lhk=; b=CbwThi+c9y3wWKr4KjKH26fyRh6RNNxwYRgK5dhTuaPr0ISxp4mi+XRlGFQvcHMzaP +TZIEuc6g/SWxIVtii+BcZEOkwh2Sg9JpkYqrA1GQa14N+9J4O0MXkln/SkQ8N+GnvIK kybu1GTK7TxjEt0jzq+WMeHDH5mBk8MMWqDUfIQKO608UBmxYzgvijHVHcZVYEJANYIv w6CUUqhYhO6cJ9bxt7Nt/HI5y/AhESZC+5ZZnNuXFm6JpsWRZm7keEPFg+4nt/Y1UEPR 1OSaHapi0uJD29baLDIljj4R2CHpPpXrg4qoOb1lAQ9vqU1EJwFLhPXoo+GWdyrde9LI uArg== X-Gm-Message-State: APt69E0P7dPKvGiuYD4oUmS3vvfskwZpsrUwHLi8jxxogQWK9JVZEOP9 J9eTce7BX0//kanV4bimEl4= X-Google-Smtp-Source: AAOMgpe9A6qLy5KuVN11MpUR3iSoC/ty9gH5cMYEHwaF8MSjUrtT81hC1oijqHdIbW2yvEGHb5ccsQ== X-Received: by 2002:a2e:350b:: with SMTP id z11-v6mr16871943ljz.55.1531290162618; Tue, 10 Jul 2018 23:22:42 -0700 (PDT) Received: from [192.168.1.66] ([83.216.156.195]) by smtp.gmail.com with ESMTPSA id w14-v6sm2064959ljh.71.2018.07.10.23.22.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 10 Jul 2018 23:22:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan Ford In-Reply-To: Date: Wed, 11 Jul 2018 07:22:40 +0100 Cc: multipathtcp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> To: philip.eardley@bt.com X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 06:22:48 -0000 Thank you for your feedback, Phil. All proposed changes look good and we = will wrap these into the next version. @Everyone - we are however awaiting other WGLC feedback before doing a = new revision! Best regards, Alan > On 18 Jun 2018, at 14:59, philip.eardley@bt.com wrote: >=20 > More comments: > Section 3.5 -=20 > Option R (RST) - add (at the end of the bullet) "the Host A enters the = CLOSED state directly" (I think) >=20 > << If a host receives a packet with a valid MP_FASTCLOSE option, it > shall process it as follows :>> > I think the text that follows (apart from the last bullet) is only = relevant for Option A, where the MP_FASTCLOSE is sent on an ACK - it = doesn't apply for option R (where it's sent on a RST). Anyway, things = could be laid out slightly differently so the section is clearer.=20 >=20 > Section 3.6 > I wonder if it would be more logical for this section to be before = Fast close? >=20 > This section could do with a read through. A few things: > << As discussed in Section 3.5 above, the MP_FASTCLOSE option provides = a > connection-level reset roughly analagous to a TCP RST. Regular TCP > RST options remain used to at the subflow-level to indicate the > receiving host has no knowledge of the MPTCP subflow or TCP > connection to which the packet belongs.>> > Can this paragraph be deleted? at least I found it a bit confusing = that this text is not about this section.=20 >=20 > "remain used to at" is ugly >=20 > << However, in MPTCP, there may be many reasons for rejecting the > opening of a subflow, but these semantics cannot be carried in a > standard TCP RST. It would be beneficial for a host to the reasons > why its subflow has been closed with a RST, and thus whether it > should try to re-establish the subflow immediately, later, or never > again. These semantics are carried in the MP_TCPRST option that can > be included on a TCP RST packet.>> > I presume the new MP_TCPRST can be added to a RST, whenever it's = created - the sentence seems to imply it's only when it wants to reject = the opening of a subflow (ie in response to MP_JOIN).=20 > I assume inclusion of the MP_TCPRST option is optional? >=20 > potential better phrasing: > A host sends a TCP RST in order to close a subflow or reject an = attempt to open a subflow (MP_JOIN). In order to inform the receiving = host why a subflow is being closed or rejected, the TCP RST packet MAY = include the MP_TCPRST Option. The host MAY use this information to = decide, for example, whether it tries to re-establish the subflow = immediately, later, or never.=20 >=20 > << o Unspecified error (code 0x0). This is the default error = implying > the subflow is not longer available. The receiving host SHOULD > take account of the 'T' bit in deciding whether to re-estbalish > this subflow. The presence of this option shows that the RST was > generated by a MPTCP-aware device.>> >=20 > " The receiving host SHOULD take account of the 'T' bit in deciding = whether to re-estbalish this subflow." > Only this sub-bullet mentions the T bit, which may suggest that it = should not be taken account of with the other reason codes. I think the = sentence should be deleted (using the T flag is mentioned earlier).=20 >=20 > <> enough resources >=20 > Section 3.7 > I guess it's OK to refer to it as RST rather than TCP RST? >=20 > << The case described above is a specialized case of fallback, for = when > the lack of MPTCP support is detected before any data is = acknowledged > at the connection level on a subflow. >> > "The case above" - I'm not sure which of the previous paragraph or = paragraphs you're referring to. > "specialised" - maybe "specific" [is it really specialised?] > "for when" -> when >=20 > S3.9.2 > << If the two communicating hosts immediately try to set up subflows > from all available addresses to all available addresses on the other > host, this could end up creating two subflows per path. This is an > inefficient use of resources.>> > is two subflows correct? Multiple I think > " could end up creating two subflows per path" -> "could create = multiple subflows over the same path" >=20 > << If a host does not support TCP simultaneous open, it > is RECOMMENDED that some element of randomization is applied to the > time waited before opening new subflows, so that only one subflow > exists between a given address pair. If, however, hosts signal > additional ports to use (for example, for leveraging ECMP on-path), > this heuristic need not apply.>> > "time waited" - ugly phrase? > "exists" -> is created > "need not apply" -> is not appropriate >=20 > Section 5 - Security > This section needs updating to reflect the changes in the bis.: >=20 > Add mention of ADD_ADDR, now with HMAC and reliability, > Discuss the revised MP_CAPABLE > I'm not sure if the new fast close option (option R) has any security = impact? > Discuss the MP_PRIO change (no off path address indication) > Discuss downgrade attacks (to v0) during connection initiation >=20 > Section 8 IANA > << This document updates [RFC6824] and as such IANA is requested to > update the TCP option space registry to point to this document for > Multipath TCP>> > This document obsoletes rather than updates... I suspect this means = all the MPTCP options need to be included in this document, but we can = leave IANA to decide that.=20 >=20 > << | C | Do not attempt to connect to | This document, = | > | | source address | Section 3.1 = | >>>=20 > I don't think this is a good summary of flag C's meaning. >=20 > << The > contents of this sub-registry are to to this document, as follows: >>>=20 > Is this sentence needed? >=20 > Appendix B TCP Fast Open > Maybe rephrae the title as "TCP Fast Open and MPTCP" or = "Considerations about using TCP Fast Open and MPTCP"? >=20 > This section could do with a read through, it could do with a few = minor re-phrasings >=20 >=20 > << TCP Fast Open (TFO) is an experimental TCP extension, described = in > [RFC7413], which has been introduced with the objective of gaining > one RTT before transmitting data.>> > " gaining one RTT"? maybe: which allows data to be sent one RTT = earlier than with regular TCP.=20 > << It achieves this by sending the SYN- > segment together with data>> > re-phrase (I think data is referring ot the cookie - but you havent = yet mentioned it - rather than user data) >=20 > "resp." =3D ? >=20 > << TFO and MPTCP can be combined provided that the total length of = their > options does not exceed the maximum 40 bytes possible in TCP>> > "their" is wrong, as there may be other options. -> "all the" >=20 > << We also note that this does not entail a loss > of functionality, because TFO-data is always sent when only one path > is active.>> > -> "TFO-data is only ever sent when only a single path is active" > How do you guarantee this? Not sure I understand.=20 >=20 > << To solve this, the TFO data should not be considered part of the = Data > Sequence Number space:>> > Is this a SHOULD NOT? Does it imply a change to rfc7413 (the tfo = rfc)? I guess this is really a suggestion to the implementer? >=20 > Section B.3 > I assume this sub-section is an example (so no SHOULD or even MAY are = needed) >=20 > << client = server > | | > | S 0(0) , | > | -----------------------------------------------------------> | >>>=20 > Can you explain the S 0(0) nomenclature/ please. >=20 >=20 > Appendix D Finite state machine > I presume we don't need similar FSM for fastclose? >=20 >=20 > Section 2: > Need to add sub-sections on closing subflow & fast close & fallback >=20 > S2.7 - I think the third bullet about notable features could be = slightly altered, with enhanced security for ADD_ADDR and MP_CAPABLE. = You could also add a mention of rfc7430 >=20 >=20 > Section 2.1 & 3.1 - can you remind me why we changed MP_CAPABLE so = that Host A's key is sent only on the ACK (not on the SYN)? Is this so = it's only sent when we know host B is MPTCP capable, which is therefore = a slight security improvement? (Just send a link to earlier emails, if = that's easier) >=20 > Thanks > phil > -----Original Message----- > From: Eardley,PL,Philip,TUD1 R=20 > Sent: 14 June 2018 11:56 > To: 'philip.eardley@bt.com' ; = multipathtcp@ietf.org > Subject: RE: WG Last Call for draft-ietf-mptcp-rfc6824bis >=20 > A few comments as I work through the document, basically minor so far >=20 > Section 3.1 > << Given the SYN exchange is different between v1 and v0 > the exchange cannot be immediately downgraded, and therefore if the > far end has requested a lower version then the initiator SHOULD > respond with an ACK without any MP_CAPABLE option, to fall back to > regular TCP.>> > I think it should say "to ensure the exchange cannot..." >=20 >=20 > << The first 4 bits of the first octet in the MP_CAPABLE option > (Figure 4) define the MPTCP option subtype (see Section 8; for > MP_CAPABLE, this is 0), and the remaining 4 bits of this octet > specify the MPTCP version in use (for this specification, this is = 1). >>>=20 > "The first 4 bits of the first octet in the MP_CAPABLE option" Fig 4 = shows two earlier octets (Kind & Length) - I know these arent the = MP-CAPABLE option, but I think it might be worth spelling out what they = are.=20 >=20 > Would it be better strictly to have "0x0" rather than "0"? (ie match = the IANA registry) >=20 > Section 3.4.1 > < Address ID. Only the rightmost bit - labelled 'E' - is assinged > today. The other bits are currently unassigned and MUST be set to > zero by a sender and MUST be ignored by the receiver. >=20 > The 'E' bit exists to provide reliability for this option. Because > this option will often be sent on pure ACKs, there is no guarantee = of > reliability. Therefore, a receiver receiving a fresh ADD_ADDR = option > (where E=3D0), will send the same option back to the sender, but not > including the HMAC, and with E=3D1. The lack of this echo can be = used > by the initial ADD_ADDR sender to retransmit the ADD_ADDR according > to local policy. >>>=20 > 4 comments: > Assinged /assigned >=20 > The 'E' bit - better to say flag? >=20 > Section 2.3 needs to be amended to show the reply /echo message for = ADD-ADDR. I suggest the pic in S2.3 also shows the E value.=20 >=20 > Not sure - does this open security hole, where an attacker pretends an = ADD-ADDR has been received? (the Echo doesn't include an hmac, so is = easy to spoof) >=20 > And in Fig 12 > | Truncated HMAC (8 octets, if length > 10 octets) | >=20 > Could this be made more straightforward? Ie spell out when length is = >10 octets ie IPv6 (if I understand it). This also seems to mean that = IPv4 doesn't include the HMAC, is this right?? >=20 > Thanks > phil >=20 > -----Original Message----- > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of = philip.eardley@bt.com > Sent: 05 June 2018 09:14 > To: multipathtcp@ietf.org > Subject: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis >=20 > This starts a WG Last Call for draft-ietf-mptcp-rfc6824bis. Please = send comments by the end of June.=20 >=20 > Please note there are three IPR disclosures (we're working on getting = them added to the rfc6824bis page):=20 >=20 > * two are inherited from RFC6824 = https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf-mp= tcp-multiaddressed =20 > * one is inherited from draft-paasch-mptcp-syncookies (which got = include in rfc6824bis) https://datatracker.ietf.org/ipr/2678/=20 >=20 > Thanks, > Phil & Yoshi > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Wed Jul 11 20:39:41 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DA6130DCD for ; Wed, 11 Jul 2018 20:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 tGKGu8s08bsx for ; Wed, 11 Jul 2018 20:39:35 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556DD130EB1 for ; Wed, 11 Jul 2018 20:39:35 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 3568E57699C24 for ; Thu, 12 Jul 2018 04:39:31 +0100 (IST) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 12 Jul 2018 04:39:32 +0100 Received: from DGGEMM514-MBX.china.huawei.com ([169.254.2.187]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0382.000; Thu, 12 Jul 2018 11:39:27 +0800 From: Kangjiao To: Yoshifumi Nishida CC: multipathtcp Thread-Topic: [multipathtcp] Possible future items for mptcp WG Thread-Index: AQHUA6+0vapSxC934kaBBPCOPQrT36SLGjgg Date: Thu, 12 Jul 2018 03:39:26 +0000 Message-ID: <719A2C1D4AC73847B6E1BF21DF1545EAE43D5C8F@dggemm514-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.160.166] Content-Type: multipart/alternative; boundary="_000_719A2C1D4AC73847B6E1BF21DF1545EAE43D5C8Fdggemm514mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [multipathtcp] =?utf-8?b?562U5aSNOiAgUG9zc2libGUgZnV0dXJlIGl0?= =?utf-8?q?ems_for_mptcp_WG?= X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 03:39:40 -0000 --_000_719A2C1D4AC73847B6E1BF21DF1545EAE43D5C8Fdggemm514mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBjaGFpciBhbmQgYWxsLA0KDQpUaGUgc2NoZWR1bGluZyBhbGdvcml0aG0gcGxheXMgYW4g aW1wb3J0YW50IHJvbGUgZm9yIHRoZSBwZXJmb3JtYW5jZSBvZiBNUFRDUCBhbmQgaGFzIGFuIGlt cGFjdCB0byBpdHMgZGVwbG95bWVudCwgYW5kIGl0IGlzIGFuIGltcG9ydGFudCBwYXJ0IGluIHRo ZSBjb2RlIGJhc2UuICBCdXQgaXQgaGFzIG5vdCBiZWVuIHdlbGwgZG9jdW1lbnRlZCBpbiBJRVRG LiAgQWx0aG91Z2ggbW9zdCBzY2hlZHVsaW5nIGFsZ29yaXRobXMgZG8gbm90IHJlcXVpcmUgcHJv dG9jb2wgZXh0ZW5zaW9uLCBpdCBpcyB1c2VmdWwgdG8gZG9jdW1lbnQgc29tZSBvZiB0aGVtIGlu dG8gZXhwZXJpbWVudGFsIG9yIGluZm9ybWF0aW9uYWwgY2F0ZWdvcmllcy4NCg0KZHJhZnQtenVv LW1wdGNwLXNjaGVkdWxlci8gZHJhZnQtenVvLW1wdGNwLWRlZ3JhZGF0aW9uIC8gZHJhZnQtc29u Zy1tcHRjcC1vd2wgaGF2ZSBkaXNjdXNzZWQgc3VjaCBwcm9ibGVtLCBhbmQgSSBhbSBnbGFkIHRv IHNoYXJlIG1vcmUgb2Ygb3VyIGV4cGVyaWVuY2UgaW4gZnV0dXJlLg0KDQpCZXN0IHJlZ2FyZHMs DQpKaWFvDQoNCuWPkeS7tuS6ujogbXVsdGlwYXRodGNwIFttYWlsdG86bXVsdGlwYXRodGNwLWJv dW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBZb3NoaWZ1bWkgTmlzaGlkYQ0K5Y+R6YCB5pe26Ze0OiAy MDE45bm0NuaciDE05pelIDE1OjE3DQrmlLbku7bkuro6IG11bHRpcGF0aHRjcCA8bXVsdGlwYXRo dGNwQGlldGYub3JnPg0K5Li76aKYOiBbbXVsdGlwYXRodGNwXSBQb3NzaWJsZSBmdXR1cmUgaXRl bXMgZm9yIG1wdGNwIFdHDQoNCkhlbGxvIGV2ZXJ5b25lLA0KDQpQaGlsIGFuZCBJIGhhdmUgYmVl biBkaXNjdXNzaW5nIHRoZSBuZXh0IHN0ZXAgZm9yIHRoZSBXRy4NCkFmdGVyIHdlIGZpbmlzaCA2 ODI0YmlzLCB3ZSDvvZdvbid0IGhhdmUgYWN0aXZlIFdHIGl0ZW1zIGFzIHRoZSBwcm94eSB3b3Jr IHdpbGwgYmUgZGlzY3Vzc2VkIGF0IHRjcG0gV0cuDQpPbmUgc3VnZ2VzdGlvbiBtaWdodCBiZSB0 byBjbG9zZSB0aGUgV0cgb3IgdG8gcHV0IGl0IGluIGRvcm1hbnQgc3RhdGUsIGhvd2V2ZXIsIHdl IGFyZSB0aGlua2luZyB0aGVyZSBzdGlsbCBtaWdodCBiZSBzb21lIG1vcmUgd29ya2luZyBpdGVt cyBhcyB3ZSd2ZSBzZWVuIGludGVyZXN0aW5nIHByZXNlbnRhdGlvbnMgZm9yIG5ldyBpZGVhcywg ZXhwZXJpbWVudCByZXN1bHRzIGFuZCBzbyBvbiBhdCB0aGUgbWVldGluZ3MgYW5kIG9uIHRoZSBN TC4NCg0KQmVsb3cgaXMgdGhlIGxpc3Qgb2YgcG90ZW50aWFsIHdvcmtpbmcgaXRlbXMgZnJvbSB0 aGUgY2hhaXJzJyBwb2ludCBvZiB2aWV3Lg0KUGxlYXNlIGxldCB1cyBrbm93IGlmIHlvdSB0aGlu ayBzb21lIG9mIHRoZW0gYXJlIGltcG9ydGFudCBpdGVtcyBmb3IgdGhlIFdHIChhbmQgeW91ciB3 aWxsaW5nbmVzcyB0byBjb250cmlidXRlIGlmIHBvc3NpYmxlKSBvciB0aGVyZSBhcmUgc29tZSBt b3JlIGl0ZW1zLCBvciB0aGlzIGlzIG5vdCBzb21ldGhpbmcgd2Ugc2hvdWxkIHdvcmsgb24sIGV0 Yy4NCg0KQWxzbywgaWYgeW91IGhhdmUgc29tZSBvcGluaW9ucyBvbiB0aGUgc3RhdHVzIG9mIHRo ZSBXRyBvciBzdWdnZXN0aW9ucyB0byB0aGUgY2hhaXJzLCBwbGVhc2UgbGV0IHVzIGhlYXIhDQoN CldlIGFwcHJlY2lhdGUgeW91ciBmZWVkYmFjaw0KDQpUaGFua3MsDQotLQ0KWW9zaGkgJiBQaGls DQoNCg0KDQoNCjE6IEFQSSBleHRlbnNpb25zIChUaGlzIGlzIGFscmVhZHkgaW4gb3VyIGNoYXJ0 ZXIpDQogICAgZHJhZnQtaGVzbWFucy1tcHRjcC1zb2NrZXQNCiAgICBkcmFmdC1zYW1hci1tcHRj cC1zb2NrZXRhcGkNCg0KMjogRmVhdHVyZSBleHRlbnNpb25zDQogICAgYSkgcm9idXN0IGluaXRp YWwgc2V0dXANCiAgICAgICAgcHJvcG9zZWQgYnkgTWFya3VzLCBhbHNvIEtpZW4gcHJlc2VudGVk IGEgc2ltaWxhciBpZGVhDQoNCiAgICBiKSBmYXN0IHN1YmZsb3cgc2V0dXANCiAgICAgICAgcHJv cG9zZWQgYnkgUXVlbnRpbg0KDQogICAgYykgc2VjdXJpdHkgZW5oYW5jZW1lbnQNCiAgICAgICAg MSkgVExTDQogICAgICAgICAgICBkcmFmdC1ib25hdmVudHVyZS1tcHRjcC10bHMtMDANCiAgICAg ICAgICAgIGRyYWZ0LXBhYXNjaC1tcHRjcC10bHMtYXV0aGVudGljYXRpb24tMDANCg0KICAgICAg ICAyKSBVdGlsaXplIHByb3Bvc2FscyBmcm9tIHRjcGluYz8NCg0KICAgICAgICAzKSBFbGxpcHRp YyBDdXJ2ZSBDcnlwdG9ncmFwaHkNCiAgICAgICAgICAgIGRyYWZ0LWtpbS1tcHRjcC1zZW1wdGNw LTAwDQoNCiAgICBkKSBTb2x1dGlvbnMgZm9yIG9wZXJhdGlvbmFsIGlzc3Vlcw0KICAgICAgICAg MSkgaG93IHRvIGhhbmRsZSBuYXQ2NCBpc3N1ZSBwcm9wb3NlZCBieSBRdWVudGluDQogICAgICAg ICAyKSBob3cgdG8gaGFuZGxlIGxvYWQgYmFsYW5jZXIgcHJvcG9zZWQgYnkgRmFiaWVuLCBDaHJp c3RvcGgsIENvc3Rpbg0KDQozOiBDb25nZXN0aW9uIENvbnRyb2wgKFRoaXMgdG9waWMgaXRzZWxm IHNob3VsZCBwcm9iYWJseSBiZSBkaXNjdXNzZWQgYXQgSUNDUkcuIEJ1dCwgaXQgbWF5IHRyaWdn ZXIgc29tZSB1cGRhdGVzIG9mIHRoZSBwcm90b2NvbCBvciBBUElzIGxhdGVyKQ0KICAgICBhKSBP TElBDQogICAgICAgICAgZHJhZnQta2hhbGlsaS1tcHRjcC1jb25nZXN0aW9uLWNvbnRyb2wtMDUN Cg0KICAgICBiKSBtcHRjcCArIEJCUj8NCiAgICAgICAgICBwcmVzZW50ZWQgYnkgSmluZw0K --_000_719A2C1D4AC73847B6E1BF21DF1545EAE43D5C8Fdggemm514mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEg NiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buR Ow0KCXBhbm9zZS0xOjIgMTEgNSAzIDIgMiA0IDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxA5b6u6L2v6ZuF6buRIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0 IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkRlYXIgY2hhaXIgYW5kIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBz Y2hlZHVsaW5nIGFsZ29yaXRobSBwbGF5cyBhbiBpbXBvcnRhbnQgcm9sZSBmb3IgdGhlIHBlcmZv cm1hbmNlIG9mIE1QVENQIGFuZCBoYXMgYW4gaW1wYWN0IHRvIGl0cyBkZXBsb3ltZW50LCBhbmQg aXQgaXMgYW4gaW1wb3J0YW50IHBhcnQgaW4gdGhlIGNvZGUgYmFzZS4mbmJzcDsgQnV0IGl0IGhh cyBub3QgYmVlbiB3ZWxsIGRvY3VtZW50ZWQgaW4gSUVURi4mbmJzcDsgQWx0aG91Z2gNCiBtb3N0 IHNjaGVkdWxpbmcgYWxnb3JpdGhtcyBkbyBub3QgcmVxdWlyZSBwcm90b2NvbCBleHRlbnNpb24s IGl0IGlzIHVzZWZ1bCB0byBkb2N1bWVudCBzb21lIG9mIHRoZW0gaW50byBleHBlcmltZW50YWwg b3IgaW5mb3JtYXRpb25hbCBjYXRlZ29yaWVzLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5k cmFmdC16dW8tbXB0Y3Atc2NoZWR1bGVyLyBkcmFmdC16dW8tbXB0Y3AtZGVncmFkYXRpb24gLyBk cmFmdC1zb25nLW1wdGNwLW93bCBoYXZlIGRpc2N1c3NlZCBzdWNoIHByb2JsZW0sIGFuZCBJIGFt IGdsYWQgdG8gc2hhcmUgbW9yZSBvZiBvdXIgZXhwZXJpZW5jZSBpbiBmdXR1cmUuDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SmlhbzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1z ZXJpZiI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 5b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPiBtdWx0aXBhdGh0Y3AgW21haWx0bzptdWx0 aXBhdGh0Y3AtYm91bmNlc0BpZXRmLm9yZ10NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJp ZiI+5Luj6KGoIDwvc3Bhbj4NCjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYi Pllvc2hpZnVtaSBOaXNoaWRhPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7l j5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7o va/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+IDIwMTg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2Vy aWYiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj42PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4x NDwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogMTU6MTc8YnI+DQo8L3NwYW4+PGI+5pS2 5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4g bXVsdGlwYXRodGNwICZsdDttdWx0aXBhdGh0Y3BAaWV0Zi5vcmcmZ3Q7PGJyPg0KPC9zcGFuPjxi PuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+ IFttdWx0aXBhdGh0Y3BdIFBvc3NpYmxlIGZ1dHVyZSBpdGVtcyBmb3IgbXB0Y3AgV0c8bzpwPjwv bzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGVsbG8gZXZlcnlvbmUsPGJyPg0KPGJyPg0KUGhp bCBhbmQgSSBoYXZlIGJlZW4gZGlzY3Vzc2luZyB0aGUgbmV4dCBzdGVwIGZvciB0aGUgV0cuPGJy Pg0KQWZ0ZXIgd2UgZmluaXNoIDY4MjRiaXMsIHdlIDwvc3Bhbj7vvZc8c3BhbiBsYW5nPSJFTi1V UyI+b24ndCBoYXZlIGFjdGl2ZSBXRyBpdGVtcyBhcyB0aGUgcHJveHkmbmJzcDt3b3JrIHdpbGwg YmUgZGlzY3Vzc2VkIGF0IHRjcG0gV0cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbmUgc3VnZ2VzdGlvbiBtaWdo dCBiZSB0byBjbG9zZSB0aGUgV0cgb3IgdG8gcHV0IGl0IGluIGRvcm1hbnQgc3RhdGUsIGhvd2V2 ZXIsJm5ic3A7d2UgYXJlIHRoaW5raW5nIHRoZXJlIHN0aWxsIG1pZ2h0IGJlIHNvbWUgbW9yZSB3 b3JraW5nIGl0ZW1zIGFzIHdlJ3ZlIHNlZW4mbmJzcDtpbnRlcmVzdGluZyBwcmVzZW50YXRpb25z IGZvciBuZXcgaWRlYXMsIGV4cGVyaW1lbnQgcmVzdWx0cyBhbmQNCiBzbyBvbiBhdCB0aGUmbmJz cDttZWV0aW5ncyBhbmQgb24gdGhlIE1MLjxicj4NCjxicj4NCkJlbG93IGlzIHRoZSBsaXN0IG9m IHBvdGVudGlhbCB3b3JraW5nIGl0ZW1zIGZyb20gdGhlIGNoYWlycycgcG9pbnQgb2Ygdmlldy48 YnI+DQpQbGVhc2UgbGV0IHVzIGtub3cgaWYgeW91IHRoaW5rIHNvbWUgb2YgdGhlbSBhcmUgaW1w b3J0YW50IGl0ZW1zIGZvciZuYnNwO3RoZSBXRyAoYW5kIHlvdXIgd2lsbGluZ25lc3MgdG8gY29u dHJpYnV0ZSBpZiBwb3NzaWJsZSkgb3IgdGhlcmUgYXJlJm5ic3A7c29tZSBtb3JlIGl0ZW1zLCBv ciB0aGlzIGlzIG5vdCBzb21ldGhpbmcgd2Ugc2hvdWxkIHdvcmsgb24sIGV0Yy48YnI+DQo8YnI+ DQpBbHNvLCBpZiB5b3UgaGF2ZSBzb21lIG9waW5pb25zIG9uIHRoZSBzdGF0dXMgb2YgdGhlIFdH IG9yIHN1Z2dlc3Rpb25zJm5ic3A7dG8gdGhlIGNoYWlycywgcGxlYXNlIGxldCB1cyBoZWFyITxi cj4NCjxicj4NCldlIGFwcHJlY2lhdGUgeW91ciBmZWVkYmFjazxicj4NCjxicj4NClRoYW5rcyw8 YnI+DQotLTxicj4NCllvc2hpICZhbXA7IFBoaWw8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQoxOiBBUEkgZXh0ZW5zaW9ucyAoVGhpcyBpcyBhbHJlYWR5IGluIG91ciBjaGFydGVyKTxicj4N CiZuYnNwOyAmbmJzcDsgZHJhZnQtaGVzbWFucy1tcHRjcC1zb2NrZXQ8YnI+DQombmJzcDsgJm5i c3A7IGRyYWZ0LXNhbWFyLW1wdGNwLXNvY2tldGFwaTxicj4NCjxicj4NCjI6IEZlYXR1cmUgZXh0 ZW5zaW9uczxicj4NCiZuYnNwOyAmbmJzcDsgYSkgcm9idXN0IGluaXRpYWwgc2V0dXA8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcHJvcG9zZWQgYnkgTWFya3VzLCZuYnNwO2Fsc28g S2llbiBwcmVzZW50ZWQgYSBzaW1pbGFyIGlkZWE8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IGIp IGZhc3Qgc3ViZmxvdyBzZXR1cDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBwcm9w b3NlZCBieSBRdWVudGluJm5ic3A7PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBjKSBzZWN1cml0 eSBlbmhhbmNlbWVudDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAxKSBUTFM8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkcmFmdC1ib25hdmVu dHVyZS1tcHRjcC10bHMtMDA8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBkcmFmdC1wYWFzY2gtbXB0Y3AtdGxzLWF1dGhlbnRpY2F0aW9uLTAwPGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDIpIFV0aWxpemUgcHJvcG9zYWxzIGZyb20g dGNwaW5jPzxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAzKSBFbGxpcHRp YyBDdXJ2ZSBDcnlwdG9ncmFwaHk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBkcmFmdC1raW0tbXB0Y3Atc2VtcHRjcC0wMDxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDsgZCkgU29sdXRpb25zIGZvciBvcGVyYXRpb25hbCBpc3N1ZXM8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MSkgaG93IHRvIGhhbmRsZSBuYXQ2NCBpc3N1ZSBwcm9w b3NlZCBieSBRdWVudGluPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzIp IGhvdyB0byBoYW5kbGUgbG9hZCBiYWxhbmNlciBwcm9wb3NlZCBieSBGYWJpZW4sIENocmlzdG9w aCwgQ29zdGluPGJyPg0KPGJyPg0KMzogQ29uZ2VzdGlvbiBDb250cm9sIChUaGlzIHRvcGljIGl0 c2VsZiBzaG91bGQgcHJvYmFibHkgYmUgZGlzY3Vzc2VkIGF0IElDQ1JHLiBCdXQsIGl0IG1heSB0 cmlnZ2VyIHNvbWUgdXBkYXRlcyBvZiB0aGUgcHJvdG9jb2wgb3IgQVBJcyBsYXRlcikgJm5ic3A7 PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDthKSBPTElBPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBkcmFmdC1raGFsaWxpLW1wdGNwLWNvbmdlc3Rpb24tY29udHJvbC0w NTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7YikgbXB0Y3AgJiM0MzsgQkJSPzxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcHJlc2VudGVkIGJ5IEppbmc8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_719A2C1D4AC73847B6E1BF21DF1545EAE43D5C8Fdggemm514mbxchi_-- From nobody Sat Jul 14 04:08:37 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D2B130E02 for ; Sat, 14 Jul 2018 04:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 SCpqYwmI7X7s for ; Sat, 14 Jul 2018 04:08:31 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43BC8130EA5 for ; Sat, 14 Jul 2018 04:08:30 -0700 (PDT) Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EVMED02-UKBR.bt.com (10.216.161.32) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sat, 14 Jul 2018 12:08:27 +0100 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.1293.2; Sat, 14 Jul 2018 12:08:26 +0100 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.1293.004; Sat, 14 Jul 2018 12:08:26 +0100 From: To: CC: Thread-Topic: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis Thread-Index: AdP8pPjqwq5n45WRS2ywhz4YK91ZcQHJh45AAMTUIlAEfjIKAACijZfg Date: Sat, 14 Jul 2018 11:08:25 +0000 Message-ID: References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> In-Reply-To: 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.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 11:08:35 -0000 Hi, Apart from the pure clarifications, there are a few comments from me and Yo= shi that may be worth discussing: -- 2: As we have removed AddrID from MP_PRIO, we have a certain problem in th= e situations like the followings. Let's say a server has two address S1, S2 while the client is behind FW. Si= nce the client is behind firewall, the server uses ADD_ADDR to send the inf= o of S2 through S1, but it wants S2 to be used as a backup. In this case, if MP_PRIO has addr id field, the server is able to specify S= 2 is a backup. However, since MP_PRIO doesn't have addr id any more, all th= e server can do is to wait until the client establishes the connection with= S2. But, this connection doesn't look what the server wants.=20 I guess using 1 bit in ADD_ADDR might solve the issue. -- One other high-level comment: it would be very good if the bis code, imple= mented in linux, could be released - to allow testing of the protocol chang= es in the bis, for instance to make sure that no unexpected issues have bee= n introduced -- Section 2.1 & 3.1 - can you remind me why we changed MP_CAPABLE so that Hos= t A's key is sent only on the ACK (not on the SYN)? Is this so it's only se= nt when we know host B is MPTCP capable, which is therefore a slight securi= ty improvement? (Just send a link to earlier emails, if that's easier) -- Section 3.4.1 ... The 'E' bit exists to provide reliability for this option= ... Not sure - does this open security hole, where an attacker pretends an ADD-= ADDR has been received? (the Echo doesn't include an hmac, so is easy to sp= oof) -- We're waiting for this IPR to get added on the tracker * one is inherited from draft-paasch-mptcp-syncookies (which got include in= rfc6824bis) https://datatracker.ietf.org/ipr/2678/ -- -----Original Message----- From: Alan Ford [mailto:alan.ford@gmail.com]=20 Sent: 11 July 2018 02:23 To: Eardley,PL,Philip,TUD1 R Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis Thank you for your feedback, Phil. All proposed changes look good and we wi= ll wrap these into the next version. @Everyone - we are however awaiting other WGLC feedback before doing a new = revision! Best regards, Alan > On 18 Jun 2018, at 14:59, philip.eardley@bt.com wrote: >=20 > More comments: > Section 3.5 - > Option R (RST) - add (at the end of the bullet) "the Host A enters the=20 > CLOSED state directly" (I think) >=20 > << If a host receives a packet with a valid MP_FASTCLOSE option, it > shall process it as follows :>> > I think the text that follows (apart from the last bullet) is only releva= nt for Option A, where the MP_FASTCLOSE is sent on an ACK - it doesn't appl= y for option R (where it's sent on a RST). Anyway, things could be laid out= slightly differently so the section is clearer.=20 >=20 > Section 3.6 > I wonder if it would be more logical for this section to be before Fast c= lose? >=20 > This section could do with a read through. A few things: > << As discussed in Section 3.5 above, the MP_FASTCLOSE option provides a > connection-level reset roughly analagous to a TCP RST. Regular TCP > RST options remain used to at the subflow-level to indicate the > receiving host has no knowledge of the MPTCP subflow or TCP > connection to which the packet belongs.>> Can this paragraph be=20 > deleted? at least I found it a bit confusing that this text is not about = this section. >=20 > "remain used to at" is ugly >=20 > << However, in MPTCP, there may be many reasons for rejecting the > opening of a subflow, but these semantics cannot be carried in a > standard TCP RST. It would be beneficial for a host to the reasons > why its subflow has been closed with a RST, and thus whether it > should try to re-establish the subflow immediately, later, or never > again. These semantics are carried in the MP_TCPRST option that can > be included on a TCP RST packet.>> > I presume the new MP_TCPRST can be added to a RST, whenever it's created = - the sentence seems to imply it's only when it wants to reject the opening= of a subflow (ie in response to MP_JOIN).=20 > I assume inclusion of the MP_TCPRST option is optional? >=20 > potential better phrasing: > A host sends a TCP RST in order to close a subflow or reject an attempt t= o open a subflow (MP_JOIN). In order to inform the receiving host why a sub= flow is being closed or rejected, the TCP RST packet MAY include the MP_TCP= RST Option. The host MAY use this information to decide, for example, wheth= er it tries to re-establish the subflow immediately, later, or never.=20 >=20 > << o Unspecified error (code 0x0). This is the default error implying > the subflow is not longer available. The receiving host SHOULD > take account of the 'T' bit in deciding whether to re-estbalish > this subflow. The presence of this option shows that the RST was > generated by a MPTCP-aware device.>> >=20 > " The receiving host SHOULD take account of the 'T' bit in deciding wheth= er to re-estbalish this subflow." > Only this sub-bullet mentions the T bit, which may suggest that it should= not be taken account of with the other reason codes. I think the sentence= should be deleted (using the T flag is mentioned earlier).=20 >=20 > <> enough resources >=20 > Section 3.7 > I guess it's OK to refer to it as RST rather than TCP RST? >=20 > << The case described above is a specialized case of fallback, for when > the lack of MPTCP support is detected before any data is acknowledged > at the connection level on a subflow. >> "The case above" - I'm not=20 > sure which of the previous paragraph or paragraphs you're referring to. > "specialised" - maybe "specific" [is it really specialised?] "for=20 > when" -> when >=20 > S3.9.2 > << If the two communicating hosts immediately try to set up subflows > from all available addresses to all available addresses on the other > host, this could end up creating two subflows per path. This is an > inefficient use of resources.>> > is two subflows correct? Multiple I think " could end up creating two=20 > subflows per path" -> "could create multiple subflows over the same path" >=20 > << If a host does not support TCP simultaneous open, it > is RECOMMENDED that some element of randomization is applied to the > time waited before opening new subflows, so that only one subflow > exists between a given address pair. If, however, hosts signal > additional ports to use (for example, for leveraging ECMP on-path), > this heuristic need not apply.>> > "time waited" - ugly phrase? > "exists" -> is created > "need not apply" -> is not appropriate >=20 > Section 5 - Security > This section needs updating to reflect the changes in the bis.: >=20 > Add mention of ADD_ADDR, now with HMAC and reliability, Discuss the=20 > revised MP_CAPABLE I'm not sure if the new fast close option (option=20 > R) has any security impact? > Discuss the MP_PRIO change (no off path address indication) Discuss=20 > downgrade attacks (to v0) during connection initiation >=20 > Section 8 IANA > << This document updates [RFC6824] and as such IANA is requested to > update the TCP option space registry to point to this document for > Multipath TCP>> > This document obsoletes rather than updates... I suspect this means all= the MPTCP options need to be included in this document, but we can leave I= ANA to decide that.=20 >=20 > << | C | Do not attempt to connect to | This document, | > | | source address | Section 3.1 | >>>=20 > I don't think this is a good summary of flag C's meaning. >=20 > << The > contents of this sub-registry are to to this document, as follows: >>>=20 > Is this sentence needed? >=20 > Appendix B TCP Fast Open > Maybe rephrae the title as "TCP Fast Open and MPTCP" or "Considerations a= bout using TCP Fast Open and MPTCP"? >=20 > This section could do with a read through, it could do with a few=20 > minor re-phrasings >=20 >=20 > << TCP Fast Open (TFO) is an experimental TCP extension, described in > [RFC7413], which has been introduced with the objective of gaining > one RTT before transmitting data.>> > " gaining one RTT"? maybe: which allows data to be sent one RTT earlier = than with regular TCP.=20 > << It achieves this by sending the SYN- > segment together with data>> > re-phrase (I think data is referring ot the cookie - but you havent=20 > yet mentioned it - rather than user data) >=20 > "resp." =3D ? >=20 > << TFO and MPTCP can be combined provided that the total length of their > options does not exceed the maximum 40 bytes possible in TCP>>=20 > "their" is wrong, as there may be other options. -> "all the" >=20 > << We also note that this does not entail a loss > of functionality, because TFO-data is always sent when only one path > is active.>> > -> "TFO-data is only ever sent when only a single path is active" > How do you guarantee this? Not sure I understand.=20 >=20 > << To solve this, the TFO data should not be considered part of the Data > Sequence Number space:>> > Is this a SHOULD NOT? Does it imply a change to rfc7413 (the tfo rfc)? I= guess this is really a suggestion to the implementer? >=20 > Section B.3 > I assume this sub-section is an example (so no SHOULD or even MAY are=20 > needed) >=20 > << client server > | | > | S 0(0) , | > | -----------------------------------------------------------> | >>>=20 > Can you explain the S 0(0) nomenclature/ please. >=20 >=20 > Appendix D Finite state machine > I presume we don't need similar FSM for fastclose? >=20 >=20 > Section 2: > Need to add sub-sections on closing subflow & fast close & fallback >=20 > S2.7 - I think the third bullet about notable features could be=20 > slightly altered, with enhanced security for ADD_ADDR and MP_CAPABLE.=20 > You could also add a mention of rfc7430 >=20 >=20 > Section 2.1 & 3.1 - can you remind me why we changed MP_CAPABLE so=20 > that Host A's key is sent only on the ACK (not on the SYN)? Is this so=20 > it's only sent when we know host B is MPTCP capable, which is=20 > therefore a slight security improvement? (Just send a link to earlier=20 > emails, if that's easier) >=20 > Thanks > phil > -----Original Message----- > From: Eardley,PL,Philip,TUD1 R > Sent: 14 June 2018 11:56 > To: 'philip.eardley@bt.com' ;=20 > multipathtcp@ietf.org > Subject: RE: WG Last Call for draft-ietf-mptcp-rfc6824bis >=20 > A few comments as I work through the document, basically minor so far >=20 > Section 3.1 > << Given the SYN exchange is different between v1 and v0 > the exchange cannot be immediately downgraded, and therefore if the > far end has requested a lower version then the initiator SHOULD > respond with an ACK without any MP_CAPABLE option, to fall back to > regular TCP.>> > I think it should say "to ensure the exchange cannot..." >=20 >=20 > << The first 4 bits of the first octet in the MP_CAPABLE option > (Figure 4) define the MPTCP option subtype (see Section 8; for > MP_CAPABLE, this is 0), and the remaining 4 bits of this octet > specify the MPTCP version in use (for this specification, this is 1). >>>=20 > "The first 4 bits of the first octet in the MP_CAPABLE option" Fig 4 show= s two earlier octets (Kind & Length) - I know these arent the MP-CAPABLE op= tion, but I think it might be worth spelling out what they are.=20 >=20 > Would it be better strictly to have "0x0" rather than "0"? (ie match=20 > the IANA registry) >=20 > Section 3.4.1 > < Address ID. Only the rightmost bit - labelled 'E' - is assinged > today. The other bits are currently unassigned and MUST be set to > zero by a sender and MUST be ignored by the receiver. >=20 > The 'E' bit exists to provide reliability for this option. Because > this option will often be sent on pure ACKs, there is no guarantee of > reliability. Therefore, a receiver receiving a fresh ADD_ADDR option > (where E=3D0), will send the same option back to the sender, but not > including the HMAC, and with E=3D1. The lack of this echo can be used > by the initial ADD_ADDR sender to retransmit the ADD_ADDR according > to local policy. >>>=20 > 4 comments: > Assinged /assigned >=20 > The 'E' bit - better to say flag? >=20 > Section 2.3 needs to be amended to show the reply /echo message for ADD-A= DDR. I suggest the pic in S2.3 also shows the E value.=20 >=20 > Not sure - does this open security hole, where an attacker pretends an=20 > ADD-ADDR has been received? (the Echo doesn't include an hmac, so is=20 > easy to spoof) >=20 > And in Fig 12 > | Truncated HMAC (8 octets, if length > 10 octets) | >=20 > Could this be made more straightforward? Ie spell out when length is >10 = octets ie IPv6 (if I understand it). This also seems to mean that IPv4 does= n't include the HMAC, is this right?? >=20 > Thanks > phil >=20 > -----Original Message----- > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of=20 > philip.eardley@bt.com > Sent: 05 June 2018 09:14 > To: multipathtcp@ietf.org > Subject: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis >=20 > This starts a WG Last Call for draft-ietf-mptcp-rfc6824bis. Please send c= omments by the end of June.=20 >=20 > Please note there are three IPR disclosures (we're working on getting the= m added to the rfc6824bis page):=20 >=20 > * two are inherited from RFC6824 https://datatracker.ietf.org/ipr/search= /?submit=3Ddraft&id=3Ddraft-ietf-mptcp-multiaddressed =20 > * one is inherited from draft-paasch-mptcp-syncookies (which got=20 > include in rfc6824bis) https://datatracker.ietf.org/ipr/2678/ >=20 > Thanks, > Phil & Yoshi > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Sat Jul 14 04:35:35 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB05130F2D; Sat, 14 Jul 2018 04:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 KvaRQL3vgjwn; Sat, 14 Jul 2018 04:35:23 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C069130E09; Sat, 14 Jul 2018 04:35:22 -0700 (PDT) Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by EVMED04-UKBR.bt.com (10.216.161.34) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sat, 14 Jul 2018 12:35:18 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03b.domain1.systemhost.net (10.55.202.22) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Sat, 14 Jul 2018 12:35:19 +0100 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.1293.004; Sat, 14 Jul 2018 12:35:19 +0100 From: To: CC: Thread-Topic: WG Last Call for draft-ietf-mptcp-rfc6824bis Thread-Index: AdP8pPjqwq5n45WRS2ywhz4YK91ZcQAGiU/gBBgqcVADkYxTEA== Date: Sat, 14 Jul 2018 11:35:18 +0000 Message-ID: <260cb4ded4a8435ca22bb12d0831e26f@rew09926dag03b.domain1.systemhost.net> References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> <39fbc9f18384473398fca38670c73cf6@rew09926dag03b.domain1.systemhost.net> <8b63f3c2af9b4b1d93ec1ad73422be5b@rew09926dag03b.domain1.systemhost.net> In-Reply-To: <8b63f3c2af9b4b1d93ec1ad73422be5b@rew09926dag03b.domain1.systemhost.net> 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.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] FW: WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 11:35:26 -0000 In case TCPM people missed it, the bis document for the Multipath TCP proto= col is in WG last call - all comments would be very much appreciated. https://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-11=20 Thank-you! Phil & Yoshi -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 26 June 2018 03:33 To: multipathtcp@ietf.org Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis Hi, Just a reminder about the WGLC for the protocol bis. Please send comments, = Thanks! Phil & Yoshi -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 05 June 2018 12:21 To: multipathtcp@ietf.org Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis As a reminder, this document Obsoletes: 6824 (if approved) and its Intended= status is Standards Track. As well as suggested changes or edits, positive review comments ("It's read= y") are also very valuable.=20 -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 05 June 2018 09:14 To: multipathtcp@ietf.org Subject: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis This starts a WG Last Call for draft-ietf-mptcp-rfc6824bis. Please send com= ments by the end of June.=20 Please note there are three IPR disclosures (we're working on getting them = added to the rfc6824bis page):=20 * two are inherited from RFC6824 https://datatracker.ietf.org/ipr/search/?= submit=3Ddraft&id=3Ddraft-ietf-mptcp-multiaddressed =20 * one is inherited from draft-paasch-mptcp-syncookies (which got include in= rfc6824bis) https://datatracker.ietf.org/ipr/2678/=20 Thanks, Phil & 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 _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Sun Jul 15 12:12:22 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61765129C6B for ; Sun, 15 Jul 2018 12:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 MA2LP8e0RX4d for ; Sun, 15 Jul 2018 12:12:18 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BF93130E60 for ; Sun, 15 Jul 2018 12:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1531681937; x=2395595537; 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=eekcl7kYlBuqzysLusf+8eXemUvipHLSSDs0fp3m7Jc=; b=d5mDtUj7llbJQ5Ne6gFWegpHBzkUwz3n71dEOaV8sqrOfFz3YhbkroNdaiG4yjkM doohnU/tT8cR12btHTcTYWrDu0Yd4rdZcNNP2k741o0guXAR7FVylE0e7OaxLAGE DaI03s+e3hj9Jnxf+FKc+MMLUvaqqLQu/qowHwFzECKBjFC4qnlhBzJdrrk0zY4i 74acJVvRTzWe1+GHslkRFhpleNA5UQqnhPh6nLViARHpz40MNu2XxlesT7b2BF+1 qZhe/jUZqFCYvjZSacVc+sTsTAex89XPktVYxAJczqd2+Ugwvvrq/OR2AA3kLQed H2K0fGUGGuNvPPhCtYiDjQ==; X-AuditID: 11973e11-513ff70000005b22-5f-5b4b9c907038 Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 66.D7.23330.09C9B4B5; Sun, 15 Jul 2018 12:12:17 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from ma1-mmpp-sz09.apple.com (ma1-mmpp-sz09.apple.com [17.171.128.183]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PBX006809CGXU70@mr2-mtap-s02.rno.apple.com>; Sun, 15 Jul 2018 12:12:16 -0700 (PDT) Received: from process_viserion-daemon.ma1-mmpp-sz09.apple.com by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PBX00G008T52U00@ma1-mmpp-sz09.apple.com>; Sun, 15 Jul 2018 12:12:16 -0700 (PDT) X-Va-A: X-Va-T-CD: 858e2f4dae29a6016c98c8320829244c X-Va-E-CD: 3bbd785c51ace3f981efd92bc4e82048 X-Va-R-CD: 2b9cdb0e57a359d759a3675f8c35d2a7 X-Va-CD: 0 X-Va-ID: 677d6b0f-7169-4a69-9997-ad71b8093b16 X-V-A: X-V-T-CD: 858e2f4dae29a6016c98c8320829244c X-V-E-CD: 3bbd785c51ace3f981efd92bc4e82048 X-V-R-CD: 2b9cdb0e57a359d759a3675f8c35d2a7 X-V-CD: 0 X-V-ID: ef6d43b7-0201-4079-8df9-fd9235b8c450 Received: from process_milters-daemon.ma1-mmpp-sz09.apple.com by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PBX00C006L6WX00@ma1-mmpp-sz09.apple.com>; Sun, 15 Jul 2018 12:12:15 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-15_07:,, signatures=0 X-Proofpoint-Scanner-Instance: ma-grpmailp-qapp23.corp.apple.com-10000_instance1 Received: from localhost ([17.234.233.123]) by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PBX00I5X9CFKU10@ma1-mmpp-sz09.apple.com>; Sun, 15 Jul 2018 12:12:15 -0700 (PDT) Sender: cpaasch@apple.com Date: Sun, 15 Jul 2018 15:12:14 -0400 From: Christoph Paasch To: philip.eardley@bt.com Cc: multipathtcp@ietf.org Message-id: <20180715191214.GT1471@MacBook-Pro-19.local> References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> <8aaece0dfe6641ad96f4860720308424@rew09926dag03b.domain1.systemhost.net> In-reply-to: <8aaece0dfe6641ad96f4860720308424@rew09926dag03b.domain1.systemhost.net> User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKIsWRmVeSWpSXmKPExsUiuPlRm+7EOd7RBm/msFh8Xn2dzWLZ2hWM DkwebV8mM3ksWfKTKYApissmJTUnsyy1SN8ugSvj5vY1jAW/VCouty5jbGCcK9vFyMkhIWAi 0dDQzNzFyMUhJHCASeJu90xGkASvgKDEj8n3WLoYOTiYBeQlDp4Hq2cWkJZ49HcGO4StJfH9 USsLRO96JomNj9dCDepiktj5egcbxAZ2iT+/drBA2NoSpx9PY4Ox/y6HmARiH/h9FyrOJbFg 62lWCFtX4lvjI0YIm01i/YklTBC2lsTRhYcYYexrbyaywti3739khrA5Jc5/mQg1X0fi67xO NojjOpkkrt/9DHVQtsTp+X+gigIk1iz8yQhR1MQksaHtGdhUYQFJie47d8CmsgioSmze+xUs zga07e3tdjBbBKhmxfZVbJBwAbL/foLq9ZB4fnkuOyRILSROvdwDDa+FjBKzNi1lmsCoNAsp uGchgnsWUnDPQgruBYwsqxiFchMzc3Qz84z0EgsKclL1kvNzNzGC0sV0O8EdjMdXWR1iFOBg VOLhZZjqHS3EmlhWXJl7iFGag0VJnLfT0DNaSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+M8 6RUJKwPiFoX/V3u8yemKzhXTCtXnVpfXt2zdeaGOW2SrxbWQ6WfF36+JOGoQdf3KlV9y65rs g1NNl/+8kbvS8OXp3O2PzK1v1LeI5DHI/7l5P5hp1a6qdi7XrOYlrQIGiYorw7IZWB+b2zzp 9GOX+j7/wUKFD2kNJx/k+DFwbXrOFXDPIFmJpTgj0VCLuag4EQAIQE3w+AIAAA== Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 19:12:22 -0000 Hello Phil, some replies to your comments inline: On 14/06/18 - 10:55:37, philip.eardley@bt.com wrote: > A few comments as I work through the document, basically minor so far > > Section 3.1 > << Given the SYN exchange is different between v1 and v0 > the exchange cannot be immediately downgraded, and therefore if the > far end has requested a lower version then the initiator SHOULD > respond with an ACK without any MP_CAPABLE option, to fall back to > regular TCP.>> > I think it should say "to ensure the exchange cannot..." I'm not sure where you would put the "to ensure the exchange cannot..."? However, reading through this paragraph, I think the SHOULD should rather be a MUST, no? Because, if conflicting versions are being requested we anyways can't do MPTCP. > << The first 4 bits of the first octet in the MP_CAPABLE option > (Figure 4) define the MPTCP option subtype (see Section 8; for > MP_CAPABLE, this is 0), and the remaining 4 bits of this octet > specify the MPTCP version in use (for this specification, this is 1). > >> > "The first 4 bits of the first octet in the MP_CAPABLE option" Fig 4 shows two earlier octets (Kind & Length) - I know these arent the MP-CAPABLE option, but I think it might be worth spelling out what they are. What about: " Like all MPTCP options, the MP_CAPABLE option starts with the Kind and Length to specify the TCP-option kind and its length. Followed by that is the MP_CAPABLE option. The first 4 bits of the first octed in the MP_CAPABLE option (Figure 4) define the MPTCP option subtype ... " > > Would it be better strictly to have "0x0" rather than "0"? (ie match the IANA registry) I agree with that. > > Section 3.4.1 > < Address ID. Only the rightmost bit - labelled 'E' - is assinged > today. The other bits are currently unassigned and MUST be set to > zero by a sender and MUST be ignored by the receiver. > > The 'E' bit exists to provide reliability for this option. Because > this option will often be sent on pure ACKs, there is no guarantee of > reliability. Therefore, a receiver receiving a fresh ADD_ADDR option > (where E=0), will send the same option back to the sender, but not > including the HMAC, and with E=1. The lack of this echo can be used > by the initial ADD_ADDR sender to retransmit the ADD_ADDR according > to local policy. > >> > 4 comments: > Assinged /assigned Fixed. > The 'E' bit - better to say flag? Agreed. > Section 2.3 needs to be amended to show the reply /echo message for ADD-ADDR. I suggest the pic in S2.3 also shows the E value. Agreed - changed this. > Not sure - does this open security hole, where an attacker pretends an ADD-ADDR has been received? (the Echo doesn't include an hmac, so is easy to spoof) I don't think there is a security hole. But worth taking a closer look at. > And in Fig 12 > | Truncated HMAC (8 octets, if length > 10 octets) | > > Could this be made more straightforward? Ie spell out when length is >10 octets ie IPv6 (if I understand it). This also seems to mean that IPv4 doesn't include the HMAC, is this right?? I'm not sure why we have the "if length > 10 octets" in here. The HMAC should be there always. I think, we should remove the "if length > 10 octets". I opened a first pull-request with the changes mentioned in here at https://github.com/multipath-tcp/draft-ietf-mptcp-rfc6824bis/pull/4. Christoph > > Thanks > phil > > -----Original Message----- > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com > Sent: 05 June 2018 09:14 > To: multipathtcp@ietf.org > Subject: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis > > This starts a WG Last Call for draft-ietf-mptcp-rfc6824bis. Please send comments by the end of June. > > Please note there are three IPR disclosures (we're working on getting them added to the rfc6824bis page): > > * two are inherited from RFC6824 https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mptcp-multiaddressed > * one is inherited from draft-paasch-mptcp-syncookies (which got include in rfc6824bis) https://datatracker.ietf.org/ipr/2678/ > > Thanks, > Phil & 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 From nobody Sun Jul 15 13:14:52 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57F5130E4A for ; Sun, 15 Jul 2018 13:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 mU7dP9oBGiEw for ; Sun, 15 Jul 2018 13:14:47 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDAE1130E48 for ; Sun, 15 Jul 2018 13:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1531685687; x=2395599287; 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=JgjBQq7Jqv31QOHEpWeUgck0NRvSM3nSsq8gj7+xg38=; b=ePeNqyLpYcRqN+EZ7rYjaob/zLuADKogxobAbFX4+qUqS8wUVND+YD8O0W4zCO1N icocHlPbKqs7pW1wisoQIlzzD72VUYXNJUQ0aD6GS4FlNHaw0jUFzTtGM0rO8YAB rNIdBXfGUeDtKn/8a7q0DuzOxTBvnDV08kcg/+r6/7Cssc4CyUnGIjJ7IUHXXdEY Y5PW5sM9m2n+PBnF9x5OKL4vYHanYnPe1V8fj3IpvAmvlv3/vkBt47IuGdmHAj2T J/aAe6Cz66IRUlsijSfqeaJ/S6wonV1aeBhkx05cHnIvnli2YHlAyzpJSYxIS7Ma Nx7LG81X1Nzz0zrljsu3yQ==; X-AuditID: 11973e13-615ff7000000242c-54-5b4bab36dacb Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id F4.8D.09260.73BAB4B5; Sun, 15 Jul 2018 13:14:47 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from ma1-mmpp-sz09.apple.com (ma1-mmpp-sz09.apple.com [17.171.128.183]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PBX00FTRC8MR420@ma1-mtap-s01.corp.apple.com>; Sun, 15 Jul 2018 13:14:46 -0700 (PDT) Received: from process_viserion-daemon.ma1-mmpp-sz09.apple.com by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PBX00600BYNX500@ma1-mmpp-sz09.apple.com>; Sun, 15 Jul 2018 13:14:46 -0700 (PDT) X-Va-A: X-Va-T-CD: 858e2f4dae29a6016c98c8320829244c X-Va-E-CD: 3bbd785c51ace3f981efd92bc4e82048 X-Va-R-CD: 2b9cdb0e57a359d759a3675f8c35d2a7 X-Va-CD: 0 X-Va-ID: 58d54861-5d0d-42fb-a0d7-d650c0cf4dd6 X-V-A: X-V-T-CD: 858e2f4dae29a6016c98c8320829244c X-V-E-CD: 3bbd785c51ace3f981efd92bc4e82048 X-V-R-CD: 2b9cdb0e57a359d759a3675f8c35d2a7 X-V-CD: 0 X-V-ID: d3b910d1-58e4-451a-a3b9-a26f68738dc1 Received: from process_milters-daemon.ma1-mmpp-sz09.apple.com by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PBX00600BYMX400@ma1-mmpp-sz09.apple.com>; Sun, 15 Jul 2018 13:14:46 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-15_08:,, signatures=0 X-Proofpoint-Scanner-Instance: ma-grpmailp-qapp21.corp.apple.com-10000_instance1 Received: from localhost ([17.234.233.123]) by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PBX00IYKC8LKU10@ma1-mmpp-sz09.apple.com>; Sun, 15 Jul 2018 13:14:45 -0700 (PDT) Sender: cpaasch@apple.com Date: Sun, 15 Jul 2018 16:14:45 -0400 From: Christoph Paasch To: philip.eardley@bt.com Cc: multipathtcp@ietf.org Message-id: <20180715201445.GU1471@MacBook-Pro-19.local> References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> In-reply-to: User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKIsWRmVeSWpSXmKPExsUiqOHDqmu+2jva4OgqZYvPq6+zWSxbu4LR gcmj7ctkJo8lS34yBTBFcdmkpOZklqUW6dslcGVc7eplK9icW/Hg5zm2Bsb+kC5GTg4JAROJ o8972LsYuTiEBPYxSZy9OpsZJMErICjxY/I9li5GDg5mAXmJg+dlQcLMAtISj/7OYIewtSS+ P2plgejdyCRx/cAzqEFdTBIvH5xjh9jALvHn1w4WCFtb4vTjaWww9t/lM9hh7AO/70LFuSQW bD3NCmHrSrza/owRwmaTWH9iCROErSVxdOEhRhj72puJrDD27fsfmSFsTonzXyZCzdeRuHz8 LDPEcZ1MEpvO/oRqyJaYPOUL1NAAiUePjrJBFDUxSSxtmAx2tbCApET3nTtgU1kEVCW+nzgJ tpkNaNvb2+1gg0SAalZsX8UGCRcg++8nVoheD4nnl+eyQ4LUQmLfipeMEAsWMkqsOP6aaQKj 0iyk4J6FCO5ZSME9Cym4FzCyrGIUyk3MzNHNzDPVSywoyEnVS87P3cQIShfT7YR3MJ5eZXWI UYCDUYmHl2Gqd7QQa2JZcWXuIUZpDhYlcd5OQ89oIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxS DYyBnLf/R+s1uqdIrWoJiJo94c3FZ7q/HGrNp020KPhfqZ7IdeP8Bh7dy6XNTuLTc62W+Zxx 3HYrfVmQKkNDfMmtfzMOvWfiOM30ZbLw2itTVrHYPtQUfWeUHlJvYRnGnnH+B/OCAL4duh+5 j1kqNAnLTt1ppa1xfB8H790JsueljrLve3x9PbMSS3FGoqEWc1FxIgBaXJ9t+AIAAA== Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 20:14:51 -0000 Hello Phil, please see inline: On 18/06/18 - 13:59:12, philip.eardley@bt.com wrote: > More comments: > Section 3.5 - > Option R (RST) - add (at the end of the bullet) "the Host A enters the CLOSED state directly" (I think) > > << If a host receives a packet with a valid MP_FASTCLOSE option, it > shall process it as follows :>> > I think the text that follows (apart from the last bullet) is only relevant for Option A, where the MP_FASTCLOSE is sent on an ACK - it doesn't apply for option R (where it's sent on a RST). Anyway, things could be laid out slightly differently so the section is clearer. Agreed. > Section 3.6 > I wonder if it would be more logical for this section to be before Fast close? Hmmm... Maybe yes. On the other hand, 3.6 is not vital to full MPTCP operation. It is purely informational, thus having the MP_FASTCLOSE before that could make sense. > This section could do with a read through. A few things: > << As discussed in Section 3.5 above, the MP_FASTCLOSE option provides a > connection-level reset roughly analagous to a TCP RST. Regular TCP > RST options remain used to at the subflow-level to indicate the > receiving host has no knowledge of the MPTCP subflow or TCP > connection to which the packet belongs.>> > Can this paragraph be deleted? at least I found it a bit confusing that this text is not about this section. Agreed - I rephrased the beginning of the section, using your suggestion from below. > "remain used to at" is ugly > > << However, in MPTCP, there may be many reasons for rejecting the > opening of a subflow, but these semantics cannot be carried in a > standard TCP RST. It would be beneficial for a host to the reasons > why its subflow has been closed with a RST, and thus whether it > should try to re-establish the subflow immediately, later, or never > again. These semantics are carried in the MP_TCPRST option that can > be included on a TCP RST packet.>> > I presume the new MP_TCPRST can be added to a RST, whenever it's created - the sentence seems to imply it's only when it wants to reject the opening of a subflow (ie in response to MP_JOIN). > I assume inclusion of the MP_TCPRST option is optional? > > potential better phrasing: > A host sends a TCP RST in order to close a subflow or reject an attempt to open a subflow (MP_JOIN). In order to inform the receiving host why a subflow is being closed or rejected, the TCP RST packet MAY include the MP_TCPRST Option. The host MAY use this information to decide, for example, whether it tries to re-establish the subflow immediately, later, or never. I used your text. > > << o Unspecified error (code 0x0). This is the default error implying > the subflow is not longer available. The receiving host SHOULD > take account of the 'T' bit in deciding whether to re-estbalish > this subflow. The presence of this option shows that the RST was > generated by a MPTCP-aware device.>> > > " The receiving host SHOULD take account of the 'T' bit in deciding whether to re-estbalish this subflow." > Only this sub-bullet mentions the T bit, which may suggest that it should not be taken account of with the other reason codes. I think the sentence should be deleted (using the T flag is mentioned earlier). Agreed. > > <> enough resources Fixed. > > Section 3.7 > I guess it's OK to refer to it as RST rather than TCP RST? I think so. What do others think? > << The case described above is a specialized case of fallback, for when > the lack of MPTCP support is detected before any data is acknowledged > at the connection level on a subflow. >> > "The case above" - I'm not sure which of the previous paragraph or paragraphs you're referring to. > "specialised" - maybe "specific" [is it really specialised?] > "for when" -> when I'm actually not sure what this paragraph is adding to the section. Should we simply remove it? > > S3.9.2 > << If the two communicating hosts immediately try to set up subflows > from all available addresses to all available addresses on the other > host, this could end up creating two subflows per path. This is an > inefficient use of resources.>> > is two subflows correct? Multiple I think It would be two subflows on each path (one being initiated by each host). > " could end up creating two subflows per path" -> "could create multiple subflows over the same path" > > << If a host does not support TCP simultaneous open, it > is RECOMMENDED that some element of randomization is applied to the > time waited before opening new subflows, so that only one subflow > exists between a given address pair. If, however, hosts signal > additional ports to use (for example, for leveraging ECMP on-path), > this heuristic need not apply.>> > "time waited" - ugly phrase? Changed to "time to wait" > "exists" -> is created > "need not apply" -> is not appropriate Both fixed. > > Section 5 - Security > This section needs updating to reflect the changes in the bis.: > > Add mention of ADD_ADDR, now with HMAC and reliability, > Discuss the revised MP_CAPABLE > I'm not sure if the new fast close option (option R) has any security impact? > Discuss the MP_PRIO change (no off path address indication) > Discuss downgrade attacks (to v0) during connection initiation Will work on those. > Section 8 IANA > << This document updates [RFC6824] and as such IANA is requested to > update the TCP option space registry to point to this document for > Multipath TCP>> > This document obsoletes rather than updates... I suspect this means all the MPTCP options need to be included in this document, but we can leave IANA to decide that. Changed "updates" to "obsoletes". > > << | C | Do not attempt to connect to | This document, | > | | source address | Section 3.1 | > >> > I don't think this is a good summary of flag C's meaning. Changed to "Don't reuse source address for new subflows." > > << The > contents of this sub-registry are to to this document, as follows: > >> > Is this sentence needed? I don't think so. > Appendix B TCP Fast Open > Maybe rephrae the title as "TCP Fast Open and MPTCP" or "Considerations about using TCP Fast Open and MPTCP"? Picked "TCP Fast Open and MPTCP". > This section could do with a read through, it could do with a few minor re-phrasings > > > << TCP Fast Open (TFO) is an experimental TCP extension, described in > [RFC7413], which has been introduced with the objective of gaining > one RTT before transmitting data.>> > " gaining one RTT"? maybe: which allows data to be sent one RTT earlier than with regular TCP. Changed. > << It achieves this by sending the SYN- > segment together with data>> > re-phrase (I think data is referring ot the cookie - but you havent yet mentioned it - rather than user data) 'data' here is referring to user data. I changed it to "with the application's data", to make it more clear. > > "resp." = ? Changed to respectively. > << TFO and MPTCP can be combined provided that the total length of their > options does not exceed the maximum 40 bytes possible in TCP>> > "their" is wrong, as there may be other options. -> "all the" Fixed. > << We also note that this does not entail a loss > of functionality, because TFO-data is always sent when only one path > is active.>> > -> "TFO-data is only ever sent when only a single path is active" > How do you guarantee this? Not sure I understand. I rephrased this to say that TFO is only ever used on the initial subflow before any other subflows are attempted. > << To solve this, the TFO data should not be considered part of the Data > Sequence Number space:>> > Is this a SHOULD NOT? Does it imply a change to rfc7413 (the tfo rfc)? I guess this is really a suggestion to the implementer? I think, it should even be a "MUST NOT". Otherwise, implementations won't interoperate. As this is in the appendix, I change it to "must not". > Section B.3 > I assume this sub-section is an example (so no SHOULD or even MAY are needed) Indeed - changed the MUST to a must. > > << client server > | | > | S 0(0) , | > | -----------------------------------------------------------> | > >> > Can you explain the S 0(0) nomenclature/ please. tcpdump-style sequence number and length of the segment. Is it ok, if I change the figure for the first time we use this notation to: S Seq=0(Length=0) And from there on leave the one we have now? > Appendix D Finite state machine > I presume we don't need similar FSM for fastclose? > > > Section 2: > Need to add sub-sections on closing subflow & fast close & fallback I will work on those. > > S2.7 - I think the third bullet about notable features could be slightly altered, with enhanced security for ADD_ADDR and MP_CAPABLE. You could also add a mention of rfc7430 Yes, we should do this. > > > Section 2.1 & 3.1 - can you remind me why we changed MP_CAPABLE so that Host A's key is sent only on the ACK (not on the SYN)? Is this so it's only sent when we know host B is MPTCP capable, which is therefore a slight security improvement? (Just send a link to earlier emails, if that's easier) The reason for this is because now that we send the keys reliably in the third ACK / first data-segment, we actually don't need to send the key in the SYN anymore. Thus, we can reduce the size of the MP_CAPABLE in the SYN-segment and gain some bytes. I created another pull-request for review with most of the minor edits at https://github.com/multipath-tcp/draft-ietf-mptcp-rfc6824bis/pull/5 Christoph > > Thanks > phil > -----Original Message----- > From: Eardley,PL,Philip,TUD1 R > Sent: 14 June 2018 11:56 > To: 'philip.eardley@bt.com' ; multipathtcp@ietf.org > Subject: RE: WG Last Call for draft-ietf-mptcp-rfc6824bis > > A few comments as I work through the document, basically minor so far > > Section 3.1 > << Given the SYN exchange is different between v1 and v0 > the exchange cannot be immediately downgraded, and therefore if the > far end has requested a lower version then the initiator SHOULD > respond with an ACK without any MP_CAPABLE option, to fall back to > regular TCP.>> > I think it should say "to ensure the exchange cannot..." > > > << The first 4 bits of the first octet in the MP_CAPABLE option > (Figure 4) define the MPTCP option subtype (see Section 8; for > MP_CAPABLE, this is 0), and the remaining 4 bits of this octet > specify the MPTCP version in use (for this specification, this is 1). > >> > "The first 4 bits of the first octet in the MP_CAPABLE option" Fig 4 shows two earlier octets (Kind & Length) - I know these arent the MP-CAPABLE option, but I think it might be worth spelling out what they are. > > Would it be better strictly to have "0x0" rather than "0"? (ie match the IANA registry) > > Section 3.4.1 > < Address ID. Only the rightmost bit - labelled 'E' - is assinged > today. The other bits are currently unassigned and MUST be set to > zero by a sender and MUST be ignored by the receiver. > > The 'E' bit exists to provide reliability for this option. Because > this option will often be sent on pure ACKs, there is no guarantee of > reliability. Therefore, a receiver receiving a fresh ADD_ADDR option > (where E=0), will send the same option back to the sender, but not > including the HMAC, and with E=1. The lack of this echo can be used > by the initial ADD_ADDR sender to retransmit the ADD_ADDR according > to local policy. > >> > 4 comments: > Assinged /assigned > > The 'E' bit - better to say flag? > > Section 2.3 needs to be amended to show the reply /echo message for ADD-ADDR. I suggest the pic in S2.3 also shows the E value. > > Not sure - does this open security hole, where an attacker pretends an ADD-ADDR has been received? (the Echo doesn't include an hmac, so is easy to spoof) > > And in Fig 12 > | Truncated HMAC (8 octets, if length > 10 octets) | > > Could this be made more straightforward? Ie spell out when length is >10 octets ie IPv6 (if I understand it). This also seems to mean that IPv4 doesn't include the HMAC, is this right?? > > Thanks > phil > > -----Original Message----- > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com > Sent: 05 June 2018 09:14 > To: multipathtcp@ietf.org > Subject: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis > > This starts a WG Last Call for draft-ietf-mptcp-rfc6824bis. Please send comments by the end of June. > > Please note there are three IPR disclosures (we're working on getting them added to the rfc6824bis page): > > * two are inherited from RFC6824 https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mptcp-multiaddressed > * one is inherited from draft-paasch-mptcp-syncookies (which got include in rfc6824bis) https://datatracker.ietf.org/ipr/2678/ > > Thanks, > Phil & 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 From nobody Sun Jul 15 13:21:14 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A13B130DF4 for ; Sun, 15 Jul 2018 13:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 SsUPEk0OcRO3 for ; Sun, 15 Jul 2018 13:21:07 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD7C4130E7E for ; Sun, 15 Jul 2018 13:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1531686067; x=2395599667; 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=rbW8wHkuVZ4VeBdDYeMFI4uL0uQkcGINPqGTvPl/Ezc=; b=HQiM8/bMACg2M/0ILJesto1loAsjxrvT2mNe3A6D1dabTd7J2Yo96eRIZBv03Kn5 9GUMqQWIhPLatnDa9yOO5umesnfBPx5CQGplsDh3OCZj+pBWmJqk+u1wUId1e62j DMSOZY5MkIu9HTh+u8Jpiuf6boadMCQ10Pzos5zOS2Ck70H6f/fdxV0/dMpo9Zp2 9MetyG7a9lShbUSMI06+xuUHrIBuBmPnY8hnZELL2pC7U4RMUp0nqjcmBSQ446iw pX5N0l1nbINRS3E7YcXORClienurMUAiEuYLoY80xnaYbPRqIv2kVjSYnJ6ZJ7RO Z6JtpdbZKWejTX9Ems8Aqw==; X-AuditID: 11973e15-bdfff70000007130-1e-5b4bacb3a1ef Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 16.79.28976.3BCAB4B5; Sun, 15 Jul 2018 13:21:07 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from ma1-mmpp-sz09.apple.com (ma1-mmpp-sz09.apple.com [17.171.128.183]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PBX008DYCJ6P330@mr2-mtap-s02.rno.apple.com>; Sun, 15 Jul 2018 13:21:07 -0700 (PDT) Received: from process_viserion-daemon.ma1-mmpp-sz09.apple.com by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PBX00600BYNX500@ma1-mmpp-sz09.apple.com>; Sun, 15 Jul 2018 13:21:06 -0700 (PDT) X-Va-A: X-Va-T-CD: 858e2f4dae29a6016c98c8320829244c X-Va-E-CD: 3bbd785c51ace3f981efd92bc4e82048 X-Va-R-CD: 2b9cdb0e57a359d759a3675f8c35d2a7 X-Va-CD: 0 X-Va-ID: 6a83795e-5a90-4719-9363-cfc54e16bf64 X-V-A: X-V-T-CD: 858e2f4dae29a6016c98c8320829244c X-V-E-CD: 3bbd785c51ace3f981efd92bc4e82048 X-V-R-CD: 2b9cdb0e57a359d759a3675f8c35d2a7 X-V-CD: 0 X-V-ID: 5d2f317a-5c67-4f06-9f4b-9f75cf1a013a Received: from process_milters-daemon.ma1-mmpp-sz09.apple.com by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PBX00600BYMX400@ma1-mmpp-sz09.apple.com>; Sun, 15 Jul 2018 13:21:05 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-15_08:,, signatures=0 X-Proofpoint-Scanner-Instance: ma-grpmailp-qapp22.corp.apple.com-10000_instance1 Received: from localhost ([17.234.233.123]) by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PBX00I1PCJ4KU20@ma1-mmpp-sz09.apple.com>; Sun, 15 Jul 2018 13:21:05 -0700 (PDT) Sender: cpaasch@apple.com Date: Sun, 15 Jul 2018 16:21:04 -0400 From: Christoph Paasch To: philip.eardley@bt.com Cc: alan.ford@gmail.com, multipathtcp@ietf.org Message-id: <20180715202104.GW1471@MacBook-Pro-19.local> References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> In-reply-to: User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUiuPlRm+7mNd7RBkcXi1usPLeC2eLz6uts FsvWrmB0YPZo+zKZyWPnrLvsHkuW/GQKYI7isklJzcksSy3St0vgyjjxsYW94HhVxez739ga GB/GdjFyckgImEi8WP6VsYuRi0NI4ACTxKUvR5hBErwCghI/Jt9j6WLk4GAWkJc4eF4WJMws IC3x6O8MdghbS+L7o1YWiN71TBJnW08yQThdTBILV7xngtjALvHn1w4WCFtb4vTjaWww9t/l EJNA7AO/70LFuSQWbD3NCmHrSix8dQsqziax/sQSqJlaEkcXHmKEsa+9mcgKY9++/5EZwuaU OP9lItR8HYknJ76B9QoJdDJJTP1XDhHPlpg85QvUzACJeZvnM0M80MQkceTaJ7BmYQFJie47 d5hBIcEioCpx55gkSJgNaNfb2+1ge0WASlZsX8UGCRU9ibXbTjFDtHpIPL88lx0SoBYSX652 Q82fzyRx+fJrpgmMSrOQAnsWIrBnIQX2LKTAXsDIsopRKDcxM0c3M89ML7GgICdVLzk/dxMj KH1MtxPdwXhmldUhRgEORiUeXoap3tFCrIllxZW5hxilOViUxHk7DT2jhQTSE0tSs1NTC1KL 4otKc1KLDzEycXBKNTCyVZ+a7BAd7HC364x8WfCaNalzOwp4Qz70cc/Z5dF0lU/jYcuca7qH 2c2nGBr8erYpLdFt8Y+VqyXZm6rsdB7fTzadzBf7wSDcKL46ium9x1rRX/wNu+TZVHrNX6os 8P4dwX7tk9+Zvbq5n1JyLULrLky61VQY++mA1puwf4cOHU7bdUS7jEuJpTgj0VCLuag4EQA6 J4GDAAMAAA== Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 20:21:11 -0000 Hello, On 14/07/18 - 11:08:25, philip.eardley@bt.com wrote: > Hi, > > Apart from the pure clarifications, there are a few comments from me and Yoshi that may be worth discussing: > > -- > 2: As we have removed AddrID from MP_PRIO, we have a certain problem in the situations like the followings. > > Let's say a server has two address S1, S2 while the client is behind FW. Since the client is behind firewall, the server uses ADD_ADDR to send the info of S2 through S1, but it wants S2 to be used as a backup. > > In this case, if MP_PRIO has addr id field, the server is able to specify S2 is a backup. However, since MP_PRIO doesn't have addr id any more, all the server can do is to wait until the client establishes the connection with S2. But, this connection doesn't look what the server wants. > I guess using 1 bit in ADD_ADDR might solve the issue. I agree - that might be quite useful. > -- > > One other high-level comment: it would be very good if the bis code, implemented in linux, could be released - to allow testing of the protocol changes in the bis, for instance to make sure that no unexpected issues have been introduced I will work this week on getting this sorted out. > -- > > Section 2.1 & 3.1 - can you remind me why we changed MP_CAPABLE so that Host A's key is sent only on the ACK (not on the SYN)? Is this so it's only sent when we know host B is MPTCP capable, which is therefore a slight security improvement? (Just send a link to earlier emails, if that's easier) The reason for this is because now that we send the keys reliably in the third ACK / first data-segment, we actually don't need to send the key in the SYN anymore. Thus, we can reduce the size of the MP_CAPABLE in the SYN-segment and gain some bytes. > > -- > > Section 3.4.1 ... The 'E' bit exists to provide reliability for this option ... > Not sure - does this open security hole, where an attacker pretends an ADD-ADDR has been received? (the Echo doesn't include an hmac, so is easy to spoof) I don't think so, but worth discussing. > -- > > We're waiting for this IPR to get added on the tracker > * one is inherited from draft-paasch-mptcp-syncookies (which got include in rfc6824bis) https://datatracker.ietf.org/ipr/2678/ I am working with Apple's legal team to get the IPR added to RFC6824bis. ETA is end of July. Christoph > > -- > > -----Original Message----- > From: Alan Ford [mailto:alan.ford@gmail.com] > Sent: 11 July 2018 02:23 > To: Eardley,PL,Philip,TUD1 R > Cc: multipathtcp@ietf.org > Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis > > Thank you for your feedback, Phil. All proposed changes look good and we will wrap these into the next version. > > @Everyone - we are however awaiting other WGLC feedback before doing a new revision! > > Best regards, > Alan > > > On 18 Jun 2018, at 14:59, philip.eardley@bt.com wrote: > > > > More comments: > > Section 3.5 - > > Option R (RST) - add (at the end of the bullet) "the Host A enters the > > CLOSED state directly" (I think) > > > > << If a host receives a packet with a valid MP_FASTCLOSE option, it > > shall process it as follows :>> > > I think the text that follows (apart from the last bullet) is only relevant for Option A, where the MP_FASTCLOSE is sent on an ACK - it doesn't apply for option R (where it's sent on a RST). Anyway, things could be laid out slightly differently so the section is clearer. > > > > Section 3.6 > > I wonder if it would be more logical for this section to be before Fast close? > > > > This section could do with a read through. A few things: > > << As discussed in Section 3.5 above, the MP_FASTCLOSE option provides a > > connection-level reset roughly analagous to a TCP RST. Regular TCP > > RST options remain used to at the subflow-level to indicate the > > receiving host has no knowledge of the MPTCP subflow or TCP > > connection to which the packet belongs.>> Can this paragraph be > > deleted? at least I found it a bit confusing that this text is not about this section. > > > > "remain used to at" is ugly > > > > << However, in MPTCP, there may be many reasons for rejecting the > > opening of a subflow, but these semantics cannot be carried in a > > standard TCP RST. It would be beneficial for a host to the reasons > > why its subflow has been closed with a RST, and thus whether it > > should try to re-establish the subflow immediately, later, or never > > again. These semantics are carried in the MP_TCPRST option that can > > be included on a TCP RST packet.>> > > I presume the new MP_TCPRST can be added to a RST, whenever it's created - the sentence seems to imply it's only when it wants to reject the opening of a subflow (ie in response to MP_JOIN). > > I assume inclusion of the MP_TCPRST option is optional? > > > > potential better phrasing: > > A host sends a TCP RST in order to close a subflow or reject an attempt to open a subflow (MP_JOIN). In order to inform the receiving host why a subflow is being closed or rejected, the TCP RST packet MAY include the MP_TCPRST Option. The host MAY use this information to decide, for example, whether it tries to re-establish the subflow immediately, later, or never. > > > > << o Unspecified error (code 0x0). This is the default error implying > > the subflow is not longer available. The receiving host SHOULD > > take account of the 'T' bit in deciding whether to re-estbalish > > this subflow. The presence of this option shows that the RST was > > generated by a MPTCP-aware device.>> > > > > " The receiving host SHOULD take account of the 'T' bit in deciding whether to re-estbalish this subflow." > > Only this sub-bullet mentions the T bit, which may suggest that it should not be taken account of with the other reason codes. I think the sentence should be deleted (using the T flag is mentioned earlier). > > > > <> enough resources > > > > Section 3.7 > > I guess it's OK to refer to it as RST rather than TCP RST? > > > > << The case described above is a specialized case of fallback, for when > > the lack of MPTCP support is detected before any data is acknowledged > > at the connection level on a subflow. >> "The case above" - I'm not > > sure which of the previous paragraph or paragraphs you're referring to. > > "specialised" - maybe "specific" [is it really specialised?] "for > > when" -> when > > > > S3.9.2 > > << If the two communicating hosts immediately try to set up subflows > > from all available addresses to all available addresses on the other > > host, this could end up creating two subflows per path. This is an > > inefficient use of resources.>> > > is two subflows correct? Multiple I think " could end up creating two > > subflows per path" -> "could create multiple subflows over the same path" > > > > << If a host does not support TCP simultaneous open, it > > is RECOMMENDED that some element of randomization is applied to the > > time waited before opening new subflows, so that only one subflow > > exists between a given address pair. If, however, hosts signal > > additional ports to use (for example, for leveraging ECMP on-path), > > this heuristic need not apply.>> > > "time waited" - ugly phrase? > > "exists" -> is created > > "need not apply" -> is not appropriate > > > > Section 5 - Security > > This section needs updating to reflect the changes in the bis.: > > > > Add mention of ADD_ADDR, now with HMAC and reliability, Discuss the > > revised MP_CAPABLE I'm not sure if the new fast close option (option > > R) has any security impact? > > Discuss the MP_PRIO change (no off path address indication) Discuss > > downgrade attacks (to v0) during connection initiation > > > > Section 8 IANA > > << This document updates [RFC6824] and as such IANA is requested to > > update the TCP option space registry to point to this document for > > Multipath TCP>> > > This document obsoletes rather than updates... I suspect this means all the MPTCP options need to be included in this document, but we can leave IANA to decide that. > > > > << | C | Do not attempt to connect to | This document, | > > | | source address | Section 3.1 | > >>> > > I don't think this is a good summary of flag C's meaning. > > > > << The > > contents of this sub-registry are to to this document, as follows: > >>> > > Is this sentence needed? > > > > Appendix B TCP Fast Open > > Maybe rephrae the title as "TCP Fast Open and MPTCP" or "Considerations about using TCP Fast Open and MPTCP"? > > > > This section could do with a read through, it could do with a few > > minor re-phrasings > > > > > > << TCP Fast Open (TFO) is an experimental TCP extension, described in > > [RFC7413], which has been introduced with the objective of gaining > > one RTT before transmitting data.>> > > " gaining one RTT"? maybe: which allows data to be sent one RTT earlier than with regular TCP. > > << It achieves this by sending the SYN- > > segment together with data>> > > re-phrase (I think data is referring ot the cookie - but you havent > > yet mentioned it - rather than user data) > > > > "resp." = ? > > > > << TFO and MPTCP can be combined provided that the total length of their > > options does not exceed the maximum 40 bytes possible in TCP>> > > "their" is wrong, as there may be other options. -> "all the" > > > > << We also note that this does not entail a loss > > of functionality, because TFO-data is always sent when only one path > > is active.>> > > -> "TFO-data is only ever sent when only a single path is active" > > How do you guarantee this? Not sure I understand. > > > > << To solve this, the TFO data should not be considered part of the Data > > Sequence Number space:>> > > Is this a SHOULD NOT? Does it imply a change to rfc7413 (the tfo rfc)? I guess this is really a suggestion to the implementer? > > > > Section B.3 > > I assume this sub-section is an example (so no SHOULD or even MAY are > > needed) > > > > << client server > > | | > > | S 0(0) , | > > | -----------------------------------------------------------> | > >>> > > Can you explain the S 0(0) nomenclature/ please. > > > > > > Appendix D Finite state machine > > I presume we don't need similar FSM for fastclose? > > > > > > Section 2: > > Need to add sub-sections on closing subflow & fast close & fallback > > > > S2.7 - I think the third bullet about notable features could be > > slightly altered, with enhanced security for ADD_ADDR and MP_CAPABLE. > > You could also add a mention of rfc7430 > > > > > > Section 2.1 & 3.1 - can you remind me why we changed MP_CAPABLE so > > that Host A's key is sent only on the ACK (not on the SYN)? Is this so > > it's only sent when we know host B is MPTCP capable, which is > > therefore a slight security improvement? (Just send a link to earlier > > emails, if that's easier) > > > > Thanks > > phil > > -----Original Message----- > > From: Eardley,PL,Philip,TUD1 R > > Sent: 14 June 2018 11:56 > > To: 'philip.eardley@bt.com' ; > > multipathtcp@ietf.org > > Subject: RE: WG Last Call for draft-ietf-mptcp-rfc6824bis > > > > A few comments as I work through the document, basically minor so far > > > > Section 3.1 > > << Given the SYN exchange is different between v1 and v0 > > the exchange cannot be immediately downgraded, and therefore if the > > far end has requested a lower version then the initiator SHOULD > > respond with an ACK without any MP_CAPABLE option, to fall back to > > regular TCP.>> > > I think it should say "to ensure the exchange cannot..." > > > > > > << The first 4 bits of the first octet in the MP_CAPABLE option > > (Figure 4) define the MPTCP option subtype (see Section 8; for > > MP_CAPABLE, this is 0), and the remaining 4 bits of this octet > > specify the MPTCP version in use (for this specification, this is 1). > >>> > > "The first 4 bits of the first octet in the MP_CAPABLE option" Fig 4 shows two earlier octets (Kind & Length) - I know these arent the MP-CAPABLE option, but I think it might be worth spelling out what they are. > > > > Would it be better strictly to have "0x0" rather than "0"? (ie match > > the IANA registry) > > > > Section 3.4.1 > > < > Address ID. Only the rightmost bit - labelled 'E' - is assinged > > today. The other bits are currently unassigned and MUST be set to > > zero by a sender and MUST be ignored by the receiver. > > > > The 'E' bit exists to provide reliability for this option. Because > > this option will often be sent on pure ACKs, there is no guarantee of > > reliability. Therefore, a receiver receiving a fresh ADD_ADDR option > > (where E=0), will send the same option back to the sender, but not > > including the HMAC, and with E=1. The lack of this echo can be used > > by the initial ADD_ADDR sender to retransmit the ADD_ADDR according > > to local policy. > >>> > > 4 comments: > > Assinged /assigned > > > > The 'E' bit - better to say flag? > > > > Section 2.3 needs to be amended to show the reply /echo message for ADD-ADDR. I suggest the pic in S2.3 also shows the E value. > > > > Not sure - does this open security hole, where an attacker pretends an > > ADD-ADDR has been received? (the Echo doesn't include an hmac, so is > > easy to spoof) > > > > And in Fig 12 > > | Truncated HMAC (8 octets, if length > 10 octets) | > > > > Could this be made more straightforward? Ie spell out when length is >10 octets ie IPv6 (if I understand it). This also seems to mean that IPv4 doesn't include the HMAC, is this right?? > > > > Thanks > > phil > > > > -----Original Message----- > > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of > > philip.eardley@bt.com > > Sent: 05 June 2018 09:14 > > To: multipathtcp@ietf.org > > Subject: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis > > > > This starts a WG Last Call for draft-ietf-mptcp-rfc6824bis. Please send comments by the end of June. > > > > Please note there are three IPR disclosures (we're working on getting them added to the rfc6824bis page): > > > > * two are inherited from RFC6824 https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mptcp-multiaddressed > > * one is inherited from draft-paasch-mptcp-syncookies (which got > > include in rfc6824bis) https://datatracker.ietf.org/ipr/2678/ > > > > Thanks, > > Phil & 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 > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Mon Jul 16 07:49:52 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B10131089 for ; Mon, 16 Jul 2018 07:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 VtGAruwY_U39 for ; Mon, 16 Jul 2018 07:49:49 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9CAC130E30 for ; Mon, 16 Jul 2018 07:49:48 -0700 (PDT) Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 16 Jul 2018 15:49:43 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03c.domain1.systemhost.net (10.55.202.26) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 16 Jul 2018 15:49:45 +0100 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.1293.004; Mon, 16 Jul 2018 15:49:45 +0100 From: To: CC: Thread-Topic: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis Thread-Index: AdP8pPjqwq5n45WRS2ywhz4YK91ZcQHJh45ABicRDAAAKmB7oA== Date: Mon, 16 Jul 2018 14:49:45 +0000 Message-ID: <89d03f9796844ab28090b057580e46c6@rew09926dag03b.domain1.systemhost.net> References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> <8aaece0dfe6641ad96f4860720308424@rew09926dag03b.domain1.systemhost.net> <20180715191214.GT1471@MacBook-Pro-19.local> In-Reply-To: <20180715191214.GT1471@MacBook-Pro-19.local> 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.232] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 14:49:52 -0000 In-line -----Original Message----- From: cpaasch@apple.com [mailto:cpaasch@apple.com]=20 Sent: 15 July 2018 15:12 To: Eardley,PL,Philip,TUD1 R Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis Hello Phil, some replies to your comments inline: On 14/06/18 - 10:55:37, philip.eardley@bt.com wrote: > A few comments as I work through the document, basically minor so far >=20 > Section 3.1 > << Given the SYN exchange is different between v1 and v0 > the exchange cannot be immediately downgraded, and therefore if the > far end has requested a lower version then the initiator SHOULD > respond with an ACK without any MP_CAPABLE option, to fall back to > regular TCP.>> > I think it should say "to ensure the exchange cannot..." I'm not sure where you would put the "to ensure the exchange cannot..."? However, reading through this paragraph, I think the SHOULD should rather b= e a MUST, no? Because, if conflicting versions are being requested we anywa= ys can't do MPTCP. [phil] re-reading, I think I mis-interpreted the phrase "Given the SYN exch= ange is different between v1 and v0 the exchange cannot be immediately dow= ngraded". -- I think you're saying "A downgrade attack is not immediately p= ossible because the SYN exchange is different in v0 and v1". I don't unders= tand - the downgrade attack is possible, in what sense isn't it immediately= possible" ?=20 Re SHOULD vs MUST. Are there circumstances when you might want to use mptvp= v0 rather than use tcp?. Perhaps where an operator has control of both end= points (even in a proxy scenario)=20 From nobody Mon Jul 16 08:31:39 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F53413111B for ; Mon, 16 Jul 2018 08:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 E1YCnIuinJTA for ; Mon, 16 Jul 2018 08:31:25 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037031310E3 for ; Mon, 16 Jul 2018 08:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1531755083; x=2395668683; 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=t6NXtmTrjr4dWyxNSFvnHeIse4UMB93VFKeHoUWgujU=; b=qPoZpA/8jtl2bcwN9Xr81hnqU+A+iLBR89DZQB9w8vkLC8RoTCnr4xGAguWOvnC1 BKu0vKWaW5jPf5RS9QxcL2A8e99zEAzJ9CscUlt9IKiU7AL96CIFGwLH7jMldaDH jyyf46UC7WVj4OiajVttgBgF8oxRMQOj3ftHkkNr8I2790k2UE8mIeDcLaMXVyQG 67t+sT3svlV5i6I0K3ZfdbJkiSD56T/iE0RCG8n3+/AzWSgvAhdBxaUfhKA5kBGk yIJppYxqtHFTFCGaMIttJbLZRisWZC9TylajBNDhTOZmWN7w7zO3xbq9dN8C/MQm zxRvtKZU7hZkCYEpFUWiVg==; X-AuditID: 11973e11-a14739e000005b22-62-5b4cba4aecb4 Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 12.67.23330.A4ABC4B5; Mon, 16 Jul 2018 08:31:23 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PBY007O3TSAXC10@ma1-mtap-s03.corp.apple.com>; Mon, 16 Jul 2018 08:31:22 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PBY00L00TS9FD00@nwk-mmpp-sz10.apple.com>; Mon, 16 Jul 2018 08:31:22 -0700 (PDT) X-Va-A: X-Va-T-CD: 858e2f4dae29a6016c98c8320829244c X-Va-E-CD: 3bbd785c51ace3f981efd92bc4e82048 X-Va-R-CD: 2b9cdb0e57a359d759a3675f8c35d2a7 X-Va-CD: 0 X-Va-ID: 07279268-377b-401e-99df-9b30b75d0bbf X-V-A: X-V-T-CD: 858e2f4dae29a6016c98c8320829244c X-V-E-CD: 3bbd785c51ace3f981efd92bc4e82048 X-V-R-CD: 2b9cdb0e57a359d759a3675f8c35d2a7 X-V-CD: 0 X-V-ID: 4ceb6d44-7e15-4aaa-acc4-7af1f4154c6d Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PBY00K00TQ4R500@nwk-mmpp-sz10.apple.com>; Mon, 16 Jul 2018 08:31:20 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-16_04:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp17.corp.apple.com-10000_instance1 Received: from localhost ([17.235.3.38]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PBY00MYQTR9ZZ00@nwk-mmpp-sz10.apple.com>; Mon, 16 Jul 2018 08:30:47 -0700 (PDT) Sender: cpaasch@apple.com Date: Mon, 16 Jul 2018 11:30:45 -0400 From: Christoph Paasch To: philip.eardley@bt.com Cc: multipathtcp@ietf.org Message-id: <20180716153045.GY1471@MacBook-Pro-19.local> References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> <8aaece0dfe6641ad96f4860720308424@rew09926dag03b.domain1.systemhost.net> <20180715191214.GT1471@MacBook-Pro-19.local> <89d03f9796844ab28090b057580e46c6@rew09926dag03b.domain1.systemhost.net> In-reply-to: <89d03f9796844ab28090b057580e46c6@rew09926dag03b.domain1.systemhost.net> User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMIsWRmVeSWpSXmKPExsUiqOHDruu9yyfaoOU2k8Xn1dfZLJatXcHo wOTR9mUyk8eSJT+ZApiiuGxSUnMyy1KL9O0SuDIu/5zKVnBApmL9kk0sDYxXxboYOTkkBEwk mp+8YQexhQT2MUmcu8IBYvMKCEr8mHyPpYuRg4NZQF7i4HlZkDCzgLTEo78z2CFsLYnvj1qB SriAWjcySTxc2MoG4XQxSWyauY0NYgG7xJ9fO1ggbG2J04+nscHYf5dDTAKxD/y+CxXnkliw 9TQrhK0rce34aqgaNon1J5YwQdhaEkcXHmKEsa+9mcgKY9++/5EZwuaUOP9lIlSvjsStVWeZ II7rZJJYsuAVVHO2xKs5DVDNwRIPJ7QxQhT9Z5Q4teUpWJGwgKRE9507YFNZBFQlGiftBLuC DWjb29vtYM0iQDUrtq9ig4QLkP33EytEr4fE88tz2UHByCtgITHrsyjE/NnA4NrexjyBUWkW UmjPQoT2LKTQnoUU2gsYWVYxCuUmZuboZuYZ6SUWFOSk6iXn525iBKWK6XaCOxiPr7I6xCjA wajEw9sw2ydaiDWxrLgy9xCjNAeLkjhvp6FntJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZG 7eTV3jKS5u9+G3uW81i+uvnmhSZz+6R5y1bV3NtxWsWs5YbVUamq0F3Jx7QeLXx0wO+v4dt6 U4lf+pdeqHRPu5ucFBv6Ku6DJ++DE47/GmxUJ3dnLPIqmrNzEsNe0wCRlQfOvSzfJRolKMnA KdNjutrh558nOZrGHswR59Wv1+S11DAriO9UYinOSDTUYi4qTgQAvWKrfPYCAAA= Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 15:31:35 -0000 In-line On 16/07/18 - 14:49:45, philip.eardley@bt.com wrote: > In-line > > -----Original Message----- > From: cpaasch@apple.com [mailto:cpaasch@apple.com] > Sent: 15 July 2018 15:12 > To: Eardley,PL,Philip,TUD1 R > Cc: multipathtcp@ietf.org > Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis > > Hello Phil, > > some replies to your comments inline: > > On 14/06/18 - 10:55:37, philip.eardley@bt.com wrote: > > A few comments as I work through the document, basically minor so far > > > > Section 3.1 > > << Given the SYN exchange is different between v1 and v0 > > the exchange cannot be immediately downgraded, and therefore if the > > far end has requested a lower version then the initiator SHOULD > > respond with an ACK without any MP_CAPABLE option, to fall back to > > regular TCP.>> > > I think it should say "to ensure the exchange cannot..." > > I'm not sure where you would put the "to ensure the exchange cannot..."? > > However, reading through this paragraph, I think the SHOULD should rather be a MUST, no? Because, if conflicting versions are being requested we anyways can't do MPTCP. > > [phil] re-reading, I think I mis-interpreted the phrase "Given the SYN exchange is different between v1 and v0 the exchange cannot be immediately downgraded". -- I think you're saying "A downgrade attack is not immediately possible because the SYN exchange is different in v0 and v1". I don't understand - the downgrade attack is possible, in what sense isn't it immediately possible" ? The paragraph is not really about attackers trying to downgrade an MPTCP-version. What this part is describing is when the client supports v1 (and requests v1 in the SYN), while the server only supports v0. In that case, the server would reply with a SYN/ACK and MP_CAPABLE of version 0. The client then needs to fallback to regular TCP as the two versions are not compatible. (because the SYN-exchange has changed). Re-re-reading again as well, I realize that actually the above would not happen. If a server only supports v0, he will ignore the MP_CAPABLE option in the SYN, because its size is not what it expects. I suggest the following text for this whole paragraph. Please let me know if that looks good: The MP_CAPABLE exchange in this specification (v1) is different to that specified in v0 [RFC6824]. If a host supports multiple versions of MPTCP, the sender of the MP_CAPABLE option SHOULD signal the highest version number it supports. The passive opener, on receipt of this, will signal the version number it wishes to use, which MUST be equal to or lower than the version number indicated in the initial MP_CAPABLE. There is a caveat though with respect to this version negotiation with old servers that only support v0. A server that supports v0 expects that the MP_CAPABLE option in the SYN-segment includes the client's key. If a client however already upgraded to v1, it won't include the key in the SYN-segment. Thus, the server will ignore the MP_CAPABLE of this SYN-segment and reply with a SYN/ACK that does not include an MP_CAPABLE. The client may then retry a new connection with MPTCP v0. Additionally, the client can cache this information for future connections. > Re SHOULD vs MUST. Are there circumstances when you might want to use mptvp v0 rather than use tcp?. Perhaps where an operator has control of both end points (even in a proxy scenario) Yes, I think so that one would rather use MPTCP v0 than use TCP. Christoph From nobody Tue Jul 17 06:31:54 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B89D130F17 for ; Tue, 17 Jul 2018 06:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 KKLZBSZaR93t for ; Tue, 17 Jul 2018 06:31:45 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.142]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 598A6130E79 for ; Tue, 17 Jul 2018 06:31:21 -0700 (PDT) Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by EVMED06-UKBR.bt.com (10.216.161.38) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 17 Jul 2018 14:31:17 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03b.domain1.systemhost.net (10.55.202.22) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 17 Jul 2018 14:31:17 +0100 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.1293.004; Tue, 17 Jul 2018 14:31:17 +0100 From: To: Thread-Topic: SECDIR review of draft-ietf-mptcp-rfc6824bis-11 Thread-Index: AQHUHdBN8bTG60vCqUa6RrGKFYNpRaSTaPIg Date: Tue, 17 Jul 2018 13:31:17 +0000 Message-ID: References: In-Reply-To: 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.216.161.45] Content-Type: multipart/alternative; boundary="_000_bbf93729e5a6401ab3fc53c6bcebf40crew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] FW: SECDIR review of draft-ietf-mptcp-rfc6824bis-11 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 13:31:52 -0000 --_000_bbf93729e5a6401ab3fc53c6bcebf40crew09926dag03bdomain1sy_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgaGF2ZSBhIG5pY2Ugc2VjYXJlYSByZXZpZXcgb2YgdGhlIGRvY3VtZW50IOKAkyB0aGFua3Mg dG8gRG9uYWxkLA0KcGhpbA0KDQpGcm9tOiBEb25hbGQgRWFzdGxha2UgW21haWx0bzpkM2UzZTNA Z21haWwuY29tXQ0KU2VudDogMTcgSnVseSAyMDE4IDA5OjE1DQpUbzogZHJhZnQtaWV0Zi1tcHRj cC1yZmM2ODI0YmlzLmFsbEBpZXRmLm9yZw0KQ2M6IHNlY2RpckBpZXRmLm9yZzsgaWVzZ0BpZXRm Lm9yZw0KU3ViamVjdDogU0VDRElSIHJldmlldyBvZiBkcmFmdC1pZXRmLW1wdGNwLXJmYzY4MjRi aXMtMTENCg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2Vj dXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9j dW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUNCklFU0cuICBEb2N1bWVudCBlZGl0b3JzIGFu ZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3Ro ZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpUaGUgc3VtbWFyeSBvZiB0aGUgcmV2aWV3IGlzIFJl YWR5Lg0KDQpUaGlzIGRyYWZ0IHNwZWNpZmllZCB2ZXJzaW9uIDEgb2YgTXVsdGlwYXRoIFRDUCBv YnNvbGV0aW5nIHZlcnNpb24gMC4gVGhlIHBhdGhzIGFyZSBpZGVudGlmaWVkIGJ5IHRoZSA0LXR1 cGxlIG9mIElQIGFkZHJlc3NlcyBhbmQgcG9ydHMgZm9yIGVhY2ggcGF0aC4gVGhlIHNlcnZpY2Vz IG9mZmVyZWQgdG8gYXBwbGljYXRpb25zIGFyZSB0aGUgc2FtZSBhcyBUQ1AuIFRoZSBhZGRpdGlv bmFsIGluZm9ybWF0aW9uIG5lZWRlZCBmb3Igc2V0dGluZyB1cCBhbmQgdGVhcmluZyBkb3duIHBh dGhzLCBzeW5jaHJvbml6aW5nIGZsb3dzLCBldGMuLCBpcyBjb21tdW5pY2F0ZWQgdXNpbmcgVENQ IG9wdGlvbnMuDQoNClRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIGFwcGVhcnMg dG8gYmUgZ29vZCBhbmQgdGhlIHNlY3VyaXR5IG1lY2hhbmlzbXMgYWRlcXVhdGUgdG8gYWNoaWV2 ZSB0aGUgZG9jdW1lbnRzIGdvYWwgb2YgYmVpbmcgYXMgc2VjdXJlIGFzIFRDUC4gVGhlcmUgaXMg YSBnb29kIGlmIHNvbWV3aGF0IGdlbmVyYWxpemVkIFRocmVhdCBBbmFseXNpcyBpbiBSRkMgNjE4 MSBhcyB3ZWxsIGFzIGFuIEFyY2hpdGVjdHVyZSBkb2N1bWVudCBpbiBSRkMgNjE4MiB0aGF0IGNv bnNpZGVycyBzZWN1cml0eSBhc3BlY3RzLg0KDQpUaGFua3MsDQpEb25hbGQNCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0NCiBEb25hbGQgRS4gRWFzdGxha2UgM3JkICAgKzEtNTA4LTMz My0yMjcwIChjZWxsKQ0KIDE0MjQgUHJvIFNob3AgQ291cnQsIERhdmVucG9ydCwgRkwgMzM4OTYg VVNBDQogZDNlM2UzQGdtYWlsLmNvbTxtYWlsdG86ZDNlM2UzQGdtYWlsLmNvbT4NCg== --_000_bbf93729e5a6401ab3fc53c6bcebf40crew09926dag03bdomain1sy_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5XZSBoYXZlIGEgbmljZSBzZWNhcmVhIHJl dmlldyBvZiB0aGUgZG9jdW1lbnQg4oCTIHRoYW5rcyB0byBEb25hbGQsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+cGhpbDwvc3Bhbj48c3BhbiBsYW5nPSJF TiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IERvbmFsZCBFYXN0bGFrZSBbbWFpbHRv OmQzZTNlM0BnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMTcgSnVseSAyMDE4IDA5OjE1 PGJyPg0KPGI+VG86PC9iPiBkcmFmdC1pZXRmLW1wdGNwLXJmYzY4MjRiaXMuYWxsQGlldGYub3Jn PGJyPg0KPGI+Q2M6PC9iPiBzZWNkaXJAaWV0Zi5vcmc7IGllc2dAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gU0VDRElSIHJldmlldyBvZiBkcmFmdC1pZXRmLW1wdGNwLXJmYzY4MjRiaXMt MTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIHJl dmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUn cyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nl c3NlZCBieSB0aGUmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPklFU0cuJm5ic3A7IERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBz aG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwg Y29tbWVudHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoZSBzdW1tYXJ5IG9mIHRoZSByZXZpZXcgaXMgUmVhZHkuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZHJhZnQgc3BlY2lm aWVkIHZlcnNpb24gMSBvZiBNdWx0aXBhdGggVENQIG9ic29sZXRpbmcgdmVyc2lvbiAwLiBUaGUg cGF0aHMgYXJlIGlkZW50aWZpZWQgYnkgdGhlIDQtdHVwbGUgb2YgSVAgYWRkcmVzc2VzIGFuZCBw b3J0cyBmb3IgZWFjaCBwYXRoLiBUaGUgc2VydmljZXMgb2ZmZXJlZCB0byBhcHBsaWNhdGlvbnMg YXJlIHRoZSBzYW1lIGFzIFRDUC4gVGhlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24NCiBuZWVkZWQg Zm9yIHNldHRpbmcgdXAgYW5kIHRlYXJpbmcgZG93biBwYXRocywgc3luY2hyb25pemluZyBmbG93 cywgZXRjLiwgaXMgY29tbXVuaWNhdGVkIHVzaW5nIFRDUCBvcHRpb25zLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMgc2VjdGlvbiBhcHBlYXJzIHRvIGJlIGdvb2QgYW5kIHRoZSBzZWN1cml0eSBt ZWNoYW5pc21zIGFkZXF1YXRlIHRvIGFjaGlldmUgdGhlIGRvY3VtZW50cyBnb2FsIG9mIGJlaW5n IGFzIHNlY3VyZSBhcyBUQ1AuIFRoZXJlIGlzIGEgZ29vZCBpZiBzb21ld2hhdCBnZW5lcmFsaXpl ZCBUaHJlYXQgQW5hbHlzaXMgaW4gUkZDIDYxODEgYXMgd2VsbCBhcyBhbiBBcmNoaXRlY3R1cmUN CiBkb2N1bWVudCBpbiBSRkMgNjE4MiB0aGF0IGNvbnNpZGVycyBzZWN1cml0eSBhc3BlY3RzLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhhbmtzLDxicj4NCkRvbmFsZDxicj4NCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT08YnI+DQombmJzcDtEb25hbGQgRS4gRWFzdGxha2UgM3JkICZuYnNwOyAmIzQzOzEt NTA4LTMzMy0yMjcwIChjZWxsKTxicj4NCiZuYnNwOzE0MjQgUHJvIFNob3AgQ291cnQsIERhdmVu cG9ydCwgRkwgMzM4OTYgVVNBPGJyPg0KJm5ic3A7PGEgaHJlZj0ibWFpbHRvOmQzZTNlM0BnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj5kM2UzZTNAZ21haWwuY29tPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_bbf93729e5a6401ab3fc53c6bcebf40crew09926dag03bdomain1sy_-- From nobody Tue Jul 17 11:23:43 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818B7130E47 for ; Tue, 17 Jul 2018 11:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 HMHs1z9p6HW0 for ; Tue, 17 Jul 2018 11:23:39 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2734B130E44 for ; Tue, 17 Jul 2018 11:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1531851818; x=2395765418; 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=mkb35bfeQWUZSO14dl1cjbXPntW/diG+CtRnI3PHeUE=; b=yhkmvpafCv1kMlUqdGnX3yQ7CVY8p5tZJ42C3aIxDqf+SCHXCghB15wikWgQ0mH+ IzygLAQ5sRxAcpGDq88YPDisiBEMXPxdGCzHI7i7s7RvfnvKSDHF6Nf59vF4rmcg PZ9f2N5bQ0hl3mHXTqiLyKA7jwvkG+3TuQhf3TD6dTeG9/v67Cr7R1LnTGIrDJYu 7rGBi82EV6GkRHEBi6uPUdjhHmSQkoAi89fj3fyGc6S7k2j1XSxf7ujKFs3w33rf ywGU/1bqfWW2+ipeR5l5r82aoAhsWPoeZ/6wd00588dKBxUS/e/B68q3pPD1ZqhM nrGnuWH9I3bLeavekmamTw==; X-AuditID: 11973e11-a14739e000005b22-81-5b4e342a628a Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 9E.6D.23330.A243E4B5; Tue, 17 Jul 2018 11:23:38 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PC000CGTWFD1WF0@ma1-mtap-s02.corp.apple.com>; Tue, 17 Jul 2018 11:23:38 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PC000200W6DOB00@nwk-mmpp-sz13.apple.com>; Tue, 17 Jul 2018 11:23:37 -0700 (PDT) X-Va-A: X-Va-T-CD: f9100de7060229dbd070d54f47b60742 X-Va-E-CD: 3bbd785c51ace3f981efd92bc4e82048 X-Va-R-CD: 2b9cdb0e57a359d759a3675f8c35d2a7 X-Va-CD: 0 X-Va-ID: 443dbfa1-5368-4bed-a8cf-9922b3fe2e9b X-V-A: X-V-T-CD: f9100de7060229dbd070d54f47b60742 X-V-E-CD: 3bbd785c51ace3f981efd92bc4e82048 X-V-R-CD: 2b9cdb0e57a359d759a3675f8c35d2a7 X-V-CD: 0 X-V-ID: b146cc60-4079-4af0-bb04-deafc38278dc Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PC000200W6ANY00@nwk-mmpp-sz13.apple.com>; Tue, 17 Jul 2018 11:23:37 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-16_06:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp16.corp.apple.com-10000_instance1 Received: from localhost ([17.235.7.82]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PC000JEZWFBS280@nwk-mmpp-sz13.apple.com>; Tue, 17 Jul 2018 11:23:37 -0700 (PDT) Sender: cpaasch@apple.com Date: Tue, 17 Jul 2018 14:23:34 -0400 From: Christoph Paasch To: philip.eardley@bt.com, mptcp-dev@listes.uclouvain.be Cc: multipathtcp@ietf.org Message-id: <20180717182334.GI1471@MacBook-Pro-19.local> References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> In-reply-to: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUiqOHDpqtl4hdt8PSmmcX8e7MYLT6vvs5m sWztCkYHZo+2L5OZPJYs+cnkMfftXfYA5igum5TUnMyy1CJ9uwSujMONUgWP2SumrPrD0sB4 iq2LkZNDQsBE4s2nR6xdjFwcQgL7mCROPtvBDJLgFRCU+DH5HksXIwcHs4C8xMHzsiBhZgFp iUd/Z7BD2FoS3x+1skD0bmSSmLH0HxuE08Uk8fLqVKgN7BJ/fu1ggbC1JU6f7mSGsf8uh5gE Yh/4fReqnktiwdbTrBC2rsTxZ0sZIWw2ifUnljBB2FoSX1/9grOvvZnICmPfvv8Raj6nxPkv E6Hm60jsP9vODnFcJ5PE6wdbmEE+kxDIlujcVAFREyxxfUsbVM1/RolfM/aBLRYWkJTovnMH bCiLgKrEhom/wWw2oGVvb7eDLRYRsJD4eKCFGRIskhIr/n5ihej1kHh+eS47JEQtJI7d/QcW FxIIk/h0bCLrBEalWUiBPQsR2LOQAnsWUmAvYGRZxSiUm5iZo5uZZ6SXWFCQk6qXnJ+7iRGU PKbbCe5gPL7K6hCjAAejEg9vxl/faCHWxLLiytxDjNIcLErivKWGQCGB9MSS1OzU1ILUovii 0pzU4kOMTBycUg2MAUsvTE7wXLLI0Pypbvlux2qDh7LtObOZ8i3EZ6+48KP1VMLD/AkZrua7 GQLmzE/6cf+PYcuV829rquKlElqVQmsXXvuqu8NBze3S3LS1Dw8lhStOWqjEpcLbcjJvZd2x ndOOZos4tO5T0n/I/7Vhvpf0UsFPVUteZ+607FotZdfwfq6rieAeJZbijERDLeai4kQAI6Hl EP8CAAA= Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 18:23:41 -0000 Forwarding to mptcp-dev: Please if you have time and interest, take a look at the RFC 6824bis draft (https://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-11) and send your comments, suggestions, feedback to the IETF mailing-list. Cheers, Christoph On 05/06/18 - 08:13:35, philip.eardley@bt.com wrote: > This starts a WG Last Call for draft-ietf-mptcp-rfc6824bis. Please send comments by the end of June. > > Please note there are three IPR disclosures (we're working on getting them added to the rfc6824bis page): > > * two are inherited from RFC6824 https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mptcp-multiaddressed > * one is inherited from draft-paasch-mptcp-syncookies (which got include in rfc6824bis) https://datatracker.ietf.org/ipr/2678/ > > Thanks, > Phil & Yoshi > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Tue Jul 17 14:02:51 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F443130FD6 for ; Tue, 17 Jul 2018 14:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 rO08Pv8NqxeZ for ; Tue, 17 Jul 2018 14:02:38 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38EF3130DE2 for ; Tue, 17 Jul 2018 14:02:37 -0700 (PDT) Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 17 Jul 2018 22:02:34 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03b.domain1.systemhost.net (10.55.202.22) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 17 Jul 2018 22:02:33 +0100 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.1293.004; Tue, 17 Jul 2018 22:02:33 +0100 From: To: CC: Thread-Topic: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis Thread-Index: AdP8pPjqwq5n45WRS2ywhz4YK91ZcQHJh45ABicRDAAAKmB7oAAALeiAAD9k86A= Date: Tue, 17 Jul 2018 21:02:32 +0000 Message-ID: <7182bd4c840141858db6075538f99dd8@rew09926dag03b.domain1.systemhost.net> References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> <8aaece0dfe6641ad96f4860720308424@rew09926dag03b.domain1.systemhost.net> <20180715191214.GT1471@MacBook-Pro-19.local> <89d03f9796844ab28090b057580e46c6@rew09926dag03b.domain1.systemhost.net> <20180716153045.GY1471@MacBook-Pro-19.local> In-Reply-To: <20180716153045.GY1471@MacBook-Pro-19.local> 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.216.161.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 21:02:47 -0000 Christoph, I think that basically works. >> The client may then retry a new connection with MPTCP v0. Additionally= , the client can cache this information for future connections. I think we could expand this a bit? The client MAY re-try a new connection with MPTCP v0 or with TCP, based on = considerations such as .... Additionally the client MAY cache this informati= on for future connections.=20 Also, the document mostly uses the terms initiator and listener (client & = server as just in the TFO Appendix). phil -----Original Message----- From: cpaasch@apple.com [mailto:cpaasch@apple.com]=20 Sent: 16 July 2018 11:31 To: Eardley,PL,Philip,TUD1 R Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis In-line On 16/07/18 - 14:49:45, philip.eardley@bt.com wrote: > In-line >=20 > -----Original Message----- > From: cpaasch@apple.com [mailto:cpaasch@apple.com] > Sent: 15 July 2018 15:12 > To: Eardley,PL,Philip,TUD1 R > Cc: multipathtcp@ietf.org > Subject: Re: [multipathtcp] WG Last Call for=20 > draft-ietf-mptcp-rfc6824bis >=20 > Hello Phil, >=20 > some replies to your comments inline: >=20 > On 14/06/18 - 10:55:37, philip.eardley@bt.com wrote: > > A few comments as I work through the document, basically minor so=20 > > far > >=20 > > Section 3.1 > > << Given the SYN exchange is different between v1 and v0 > > the exchange cannot be immediately downgraded, and therefore if the > > far end has requested a lower version then the initiator SHOULD > > respond with an ACK without any MP_CAPABLE option, to fall back to > > regular TCP.>> > > I think it should say "to ensure the exchange cannot..." >=20 > I'm not sure where you would put the "to ensure the exchange cannot..."? >=20 > However, reading through this paragraph, I think the SHOULD should rather= be a MUST, no? Because, if conflicting versions are being requested we any= ways can't do MPTCP. >=20 > [phil] re-reading, I think I mis-interpreted the phrase "Given the SYN ex= change is different between v1 and v0 the exchange cannot be immediately d= owngraded". -- I think you're saying "A downgrade attack is not immediately= possible because the SYN exchange is different in v0 and v1". I don't unde= rstand - the downgrade attack is possible, in what sense isn't it immediate= ly possible" ?=20 The paragraph is not really about attackers trying to downgrade an MPTCP-ve= rsion. What this part is describing is when the client supports v1 (and req= uests v1 in the SYN), while the server only supports v0. In that case, the server would reply with a SYN/ACK and MP_CAPABLE of versi= on 0. The client then needs to fallback to regular TCP as the two versions = are not compatible. (because the SYN-exchange has changed). Re-re-reading again as well, I realize that actually the above would not ha= ppen. If a server only supports v0, he will ignore the MP_CAPABLE option in= the SYN, because its size is not what it expects. I suggest the following text for this whole paragraph. Please let me know i= f that looks good: The MP_CAPABLE exchange in this specification (v1) is different to that specified in v0 [RFC6824]. If a host supports multiple versions of MPTCP, the sender of the MP_CAPABLE option SHOULD signal the highest version number it supports. The passive opener, on receipt of this, will signal the version number it wishes to use, which MUST be equal to or lower than the version number indicated in the initial MP_CAPABLE. There is a caveat though with respect to this version negotiation with old servers that only support v0. A server that supports v0 expects that the MP_CAPABLE option in the SYN-segment includes the client's key. If a client however already upgraded to v1, it won't include the key in the SYN-segment. Thus, the server will ignore the MP_CAPABLE of this SYN-segment and reply with a SYN/ACK that does not include an MP_CAPABLE= . The client may then retry a new connection with MPTCP v0. Additionally, the client can cache this information for future connections. > Re SHOULD vs MUST. Are there circumstances when you might want to use=20 > mptvp v0 rather than use tcp?. Perhaps where an operator has control=20 > of both end points (even in a proxy scenario) Yes, I think so that one would rather use MPTCP v0 than use TCP. Christoph From nobody Tue Jul 17 16:30:30 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44DC131095 for ; Tue, 17 Jul 2018 16:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 t2_55tvHN1he for ; Tue, 17 Jul 2018 16:30:21 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53749130EF9 for ; Tue, 17 Jul 2018 16:30:20 -0700 (PDT) Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 18 Jul 2018 00:30:17 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03b.domain1.systemhost.net (10.55.202.22) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 18 Jul 2018 00:30:17 +0100 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.1293.004; Wed, 18 Jul 2018 00:30:17 +0100 From: To: CC: Thread-Topic: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis Thread-Index: AdP8pPjqwq5n45WRS2ywhz4YK91ZcQHJh45AAMTUIlAFZGvbgABoZzJQ Date: Tue, 17 Jul 2018 23:30:15 +0000 Message-ID: References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> <20180715201445.GU1471@MacBook-Pro-19.local> In-Reply-To: <20180715201445.GU1471@MacBook-Pro-19.local> 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.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 23:30:28 -0000 In-line Thanks phil -----Original Message----- From: cpaasch@apple.com [mailto:cpaasch@apple.com]=20 Sent: 15 July 2018 16:15 To: Eardley,PL,Philip,TUD1 R Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis ... >=20 > S3.9.2 > << If the two communicating hosts immediately try to set up subflows > from all available addresses to all available addresses on the other > host, this could end up creating two subflows per path. This is an > inefficient use of resources.>> > is two subflows correct? Multiple I think It would be two subflows on each path (one being initiated by each host). [phil] ok. Can the para be re-phrased so it's clear this is about a new sit= uation (compared to the earlier paras). Something like, "Another issue is t= hat both communicating hosts may simultaneously try to set up a subflow bet= ween the same pair of addresses. This leads to an inefficient use of resour= ces." (I suppose 'inefficient resources' refers to resources on the end ho= st?) ... >=20 > << client server > | | > | S 0(0) , | > | -----------------------------------------------------------> | > >> > Can you explain the S 0(0) nomenclature/ please. tcpdump-style sequence number and length of the segment. Is it ok, if I change the figure for the first time we use this notation to= : S Seq=3D0(Length=3D0) And from there on leave the one we have now? [phil] yes - I suggest in the first figure you add a key that explains the = notation and states it's used in Figures x, y, z. >=20 >=20 > Section 2.1 & 3.1 - can you remind me why we changed MP_CAPABLE so=20 > that Host A's key is sent only on the ACK (not on the SYN)? Is this so=20 > it's only sent when we know host B is MPTCP capable, which is=20 > therefore a slight security improvement? (Just send a link to earlier=20 > emails, if that's easier) The reason for this is because now that we send the keys reliably in the th= ird ACK / first data-segment, we actually don't need to send the key in the= SYN anymore. Thus, we can reduce the size of the MP_CAPABLE in the SYN-seg= ment and gain some bytes. [phil] ok - if I get it right the motivation for the change in the MP_CAPAB= LE protocol exchange starts from the observation that option space is most = constrained in the SYN, so reducing the size of MP_CAPABLE in the SYN allow= s other TCP options to be used in the SYn. As a consequence of this decisio= n, Host A doesn't know that Host B has learnt its key, unless the ACK is se= nt reliably. =20 I think it would be useful to tweak the figure in Section 2.1 - just to say= the ack is delivered reliably.=20 However in Section 3.1 I think it would be good to include a more extensive= figure about this - showing the different ways & timings for when the ack = is known to have been delivered - ie figure showing somehow that A or B may= be one that first sends data - and therefore when A knows that the ACK has= indeed been successfully delivered to B. The actual text (in the para starting " If B has data to send first, then t= he reliable delivery of the ACK...") is pretty good - however, there are a = lot of "this packet", "this is" etc - likely that someone could misinterpre= t what a "this" refers to. A figure would help clarify and/or breaking the = text up . Also I spotted << This option is used to declare the 64-bit keys that the end hosts =20 have generated for this MPTCP connection. This key is used to =20 authenticate the addition of future subflows to this connection.>> This key is -> These keys are ... << Therefore, A's key must be delivered reliably to B, and in order to = =20 do this, the transmission of this packet must be made reliable.>> is it right to say that the protocol makes transmission of the ACK reliable= ? Suppose the Ack is lost. The protocol ensures that A doesn't have the m= istaken belief that B has got the Ack. But does it say anything about how /= when A sends the Ack again? (perhaps it should say something about this?) << Note that new subflows MUST NOT be established (using the process documented in Section 3.2) until a Data Sequence Signal (DSS) option has been successfully received across the path (as documented in Section 3.3).>> In the case where A sends data first, then the MP-CAPABLE is sent instead o= f the DSS. Does the text quoted mean that new subflows are not allowed (unt= il an actual DSS is sent) or are they allowed because DSS has kind of been = inferred? From nobody Wed Jul 18 07:14:02 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D39130E31 for ; Wed, 18 Jul 2018 07:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 tcdnd0BPjddX for ; Wed, 18 Jul 2018 07:13:59 -0700 (PDT) Received: from mail-in23.apple.com (mail-out23.apple.com [17.171.2.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67797130E14 for ; Wed, 18 Jul 2018 07:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1531923238; x=2395836838; 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=FzH3Ilb+8EEL1FQMVgKD9aldykni0Z/khrbho8zOfTY=; b=ktaPbfb0iB7hZ5bhGfuq+OcNIrKzq8i3SJcsrwQhpoJIfI1nDemHRw8FRgJbvz20 /0coRIhgoNXIPPoy5JvItpS+rmksY+Fe/OroiUJCil+HO+c4RtLwn0Ss8tZR0eGE n9n5bT25x9LKjMBkxwMf7pgEO5tuvBqT+Cbi4V1gL7aEF6gVq1Aahl+jRm1YubZS T9kRNfDc9ZKhYPCN7ByhTvIv0YVvQeCfUv+Udka7+2Zk1VgcFg1AWxw6NW5faCne MPzQhLZU+lKA+1Fm5MOTWg41gy4HdC+czyKS0yX9kHzCaJuVSw0TwYu2f8g7AIaU y2KOo3vVv6GLumXUH/9vyQ==; X-AuditID: 11ab0217-24b109e000003e90-62-5b4f4b26cbfd Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in23.apple.com (Apple Secure Mail Relay) with SMTP id E9.47.16016.62B4F4B5; Wed, 18 Jul 2018 07:13:58 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PC200DMPFJ9QU80@mr2-mtap-s03.rno.apple.com>; Wed, 18 Jul 2018 07:13:57 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PC200400F9TLW00@nwk-mmpp-sz11.apple.com>; Wed, 18 Jul 2018 07:13:57 -0700 (PDT) X-Va-A: X-Va-T-CD: 858e2f4dae29a6016c98c8320829244c X-Va-E-CD: 3bbd785c51ace3f981efd92bc4e82048 X-Va-R-CD: 2b9cdb0e57a359d759a3675f8c35d2a7 X-Va-CD: 0 X-Va-ID: 82223510-c77b-44c7-8470-dcfe97d42b11 X-V-A: X-V-T-CD: 858e2f4dae29a6016c98c8320829244c X-V-E-CD: 3bbd785c51ace3f981efd92bc4e82048 X-V-R-CD: 2b9cdb0e57a359d759a3675f8c35d2a7 X-V-CD: 0 X-V-ID: 42a6051c-d85b-4a5c-a7ec-88bc83eaa818 Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PC200400F9SLU00@nwk-mmpp-sz11.apple.com>; Wed, 18 Jul 2018 07:13:57 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-16_06:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp18.corp.apple.com-10000_instance1 Received: from localhost ([17.235.39.85]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PC200AVCFJ71R30@nwk-mmpp-sz11.apple.com>; Wed, 18 Jul 2018 07:13:56 -0700 (PDT) Sender: cpaasch@apple.com Date: Wed, 18 Jul 2018 10:13:55 -0400 From: Christoph Paasch To: philip.eardley@bt.com Cc: multipathtcp@ietf.org Message-id: <20180718141355.GN1471@MacBook-Pro-19.local> References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> <8aaece0dfe6641ad96f4860720308424@rew09926dag03b.domain1.systemhost.net> <20180715191214.GT1471@MacBook-Pro-19.local> <89d03f9796844ab28090b057580e46c6@rew09926dag03b.domain1.systemhost.net> <20180716153045.GY1471@MacBook-Pro-19.local> <7182bd4c840141858db6075538f99dd8@rew09926dag03b.domain1.systemhost.net> In-reply-to: <7182bd4c840141858db6075538f99dd8@rew09926dag03b.domain1.systemhost.net> User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsUiuPlRu66at3+0wYX38hafV19ns1i2dgWj A5NH25fJTB5LlvxkCmCK4rJJSc3JLEst0rdL4MqYPeUqU8FytYrvE36zNzDOk+ti5OSQEDCR eL6ykxnEFhI4yCSxYlsqiM0rICjxY/I9li5GDg5mAXmJg+dlQcLMAtISj/7OYIewtSS+P2oF KuECal3PJHFwdR+U08Ukcen+XUaIBewSf37tYIGwtSVOP57GBmP/XQ4xCcQ+8PsuVJxLYsHW 06wQtq7Es3OfoGrYJNafWMIEYWtJHF14iBHGvvZmIiuMffv+R2YIm1Pi/JeJUL06Ege3TWaC OK6TSeLU0nXsIJ9JCGRLdG6qgDCDJfa/VYYoaWCSOP59Hdg9wgKSEt137oDNZBFQlTg0vwNs FxvQrre328FsEaCaFdtXsUFCBcj++4kVotdD4vnlueyQALWQOLq0gRES0FOZJW6+qZzAqDQL KaxnIcJ6FlJYz0IK6wWMLKsYhXMTM3N0M/OMjPUSCwpyUvWS83M3MYISxWom8R2Mn18bHmIU 4GBU4uHN+OsbLcSaWFZcmXuIUZqDRUmc98MusWghgfTEktTs1NSC1KL4otKc1OJDjEwcnFIN jJIdb4ucG9pUt4d+FY+Z11IhsH1V0zm5+O+z246YF75PU4qxMvCJ8nwcJuMfn8rWVxjAIiOW 11nls+PL48ijKhFbKt6zZzcGWCr0ipyon9x/2+UV15cXkkdXPM1N+HJ1t3t/+joRoUPPnsxf fH3Fy098xdtuyG6y7Xy97+G2G/2RyvpBH/RslViKMxINtZiLihMBTEgi3/UCAAA= Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 14:14:02 -0000 Hello Phil, On 17/07/18 - 21:02:32, philip.eardley@bt.com wrote: > Christoph, > I think that basically works. > > >> The client may then retry a new connection with MPTCP v0. Additionally, > the client can cache this information for future connections. > > I think we could expand this a bit? > The client MAY re-try a new connection with MPTCP v0 or with TCP, based on considerations such as .... Additionally the client MAY cache this information for future connections. thanks I expanded it in your suggested way. > Also, the document mostly uses the terms initiator and listener (client & server as just in the TFO Appendix). Changed client/server to initiator/listener in the TFO appendix. Christoph > > phil > > -----Original Message----- > From: cpaasch@apple.com [mailto:cpaasch@apple.com] > Sent: 16 July 2018 11:31 > To: Eardley,PL,Philip,TUD1 R > Cc: multipathtcp@ietf.org > Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis > > In-line > > On 16/07/18 - 14:49:45, philip.eardley@bt.com wrote: > > In-line > > > > -----Original Message----- > > From: cpaasch@apple.com [mailto:cpaasch@apple.com] > > Sent: 15 July 2018 15:12 > > To: Eardley,PL,Philip,TUD1 R > > Cc: multipathtcp@ietf.org > > Subject: Re: [multipathtcp] WG Last Call for > > draft-ietf-mptcp-rfc6824bis > > > > Hello Phil, > > > > some replies to your comments inline: > > > > On 14/06/18 - 10:55:37, philip.eardley@bt.com wrote: > > > A few comments as I work through the document, basically minor so > > > far > > > > > > Section 3.1 > > > << Given the SYN exchange is different between v1 and v0 > > > the exchange cannot be immediately downgraded, and therefore if the > > > far end has requested a lower version then the initiator SHOULD > > > respond with an ACK without any MP_CAPABLE option, to fall back to > > > regular TCP.>> > > > I think it should say "to ensure the exchange cannot..." > > > > I'm not sure where you would put the "to ensure the exchange cannot..."? > > > > However, reading through this paragraph, I think the SHOULD should rather be a MUST, no? Because, if conflicting versions are being requested we anyways can't do MPTCP. > > > > [phil] re-reading, I think I mis-interpreted the phrase "Given the SYN exchange is different between v1 and v0 the exchange cannot be immediately downgraded". -- I think you're saying "A downgrade attack is not immediately possible because the SYN exchange is different in v0 and v1". I don't understand - the downgrade attack is possible, in what sense isn't it immediately possible" ? > > The paragraph is not really about attackers trying to downgrade an MPTCP-version. What this part is describing is when the client supports v1 (and requests v1 in the SYN), while the server only supports v0. > > In that case, the server would reply with a SYN/ACK and MP_CAPABLE of version 0. The client then needs to fallback to regular TCP as the two versions are not compatible. (because the SYN-exchange has changed). > > Re-re-reading again as well, I realize that actually the above would not happen. If a server only supports v0, he will ignore the MP_CAPABLE option in the SYN, because its size is not what it expects. > > I suggest the following text for this whole paragraph. Please let me know if that looks good: > > The MP_CAPABLE exchange in this specification (v1) is different to > that specified in v0 [RFC6824]. If a host supports multiple versions > of MPTCP, the sender of the MP_CAPABLE option SHOULD signal the > highest version number it supports. The passive opener, on receipt > of this, will signal the version number it wishes to use, which MUST > be equal to or lower than the version number indicated in the initial > MP_CAPABLE. > There is a caveat though with respect to this version negotiation with > old servers that only support v0. A server that supports v0 expects that > the MP_CAPABLE option in the SYN-segment includes the client's key. If a > client however already upgraded to v1, it won't include the key in the > SYN-segment. Thus, the server will ignore the MP_CAPABLE of this > SYN-segment and reply with a SYN/ACK that does not include an MP_CAPABLE. > The client may then retry a new connection with MPTCP v0. Additionally, > the client can cache this information for future connections. > > > Re SHOULD vs MUST. Are there circumstances when you might want to use > > mptvp v0 rather than use tcp?. Perhaps where an operator has control > > of both end points (even in a proxy scenario) > > Yes, I think so that one would rather use MPTCP v0 than use TCP. > > > Christoph > From nobody Wed Jul 18 07:45:41 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137791311C1 for ; Wed, 18 Jul 2018 07:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 Fn5woG6RBa8B for ; Wed, 18 Jul 2018 07:45:31 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D000B131192 for ; Wed, 18 Jul 2018 07:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1531925131; x=2395838731; 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=zo6Yr5f1Gy7+Esb3ID+3BnjR04/ZOBvEKCmYF7tIROo=; b=cyVue069G/mnZSeeLuk5ESMZZIxaXDRSptATeBMwcleREoebXBIe6NlWUrWCKIDM xPkA6ceOs8x1UM8roPxlbazNh48gKL9T0sbTB+U+n9VT4mhYl37mQ77N5m6uLHrE vYJX5mDFOqMl75RM5TNobrzhy+IuBGrVRMcwE4/kUXoCV8pYI0uXoZkfctfbfo70 skhV1Nb8wc3NcWxwOqoqGf+5yMcW1rdWa0f5n9DTCCEtgaq//teuRM3TfX4nGTZ6 q8xFjecFlFw6Os3HAhP+wyitE5P8F3poh2PPVTma53gqI4qucpJ8FS3Yj3eVHOC+ TWMqcLABmcySSSW82j08Lw==; X-AuditID: 11973e11-4fbff70000005b22-93-5b4f528b00fb Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 34.18.23330.B825F4B5; Wed, 18 Jul 2018 07:45:31 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PC2009JYGZVDW00@mr2-mtap-s03.rno.apple.com>; Wed, 18 Jul 2018 07:45:31 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PC200A00GIOB900@nwk-mmpp-sz11.apple.com>; Wed, 18 Jul 2018 07:45:31 -0700 (PDT) X-Va-A: X-Va-T-CD: 858e2f4dae29a6016c98c8320829244c X-Va-E-CD: 3bbd785c51ace3f981efd92bc4e82048 X-Va-R-CD: 2b9cdb0e57a359d759a3675f8c35d2a7 X-Va-CD: 0 X-Va-ID: ea287e4c-592b-41c5-9735-808627408c7c X-V-A: X-V-T-CD: 858e2f4dae29a6016c98c8320829244c X-V-E-CD: 3bbd785c51ace3f981efd92bc4e82048 X-V-R-CD: 2b9cdb0e57a359d759a3675f8c35d2a7 X-V-CD: 0 X-V-ID: 05cef6e0-6183-4af9-98ba-3ec2c3a9c0bd Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PC200H00GX29E00@nwk-mmpp-sz11.apple.com>; Wed, 18 Jul 2018 07:45:30 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-16_06:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp14.corp.apple.com-10000_instance1 Received: from localhost ([17.235.39.85]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PC200AXGGZT1R50@nwk-mmpp-sz11.apple.com>; Wed, 18 Jul 2018 07:45:30 -0700 (PDT) Sender: cpaasch@apple.com Date: Wed, 18 Jul 2018 10:45:28 -0400 From: Christoph Paasch To: philip.eardley@bt.com Cc: multipathtcp@ietf.org Message-id: <20180718144528.GO1471@MacBook-Pro-19.local> References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> <20180715201445.GU1471@MacBook-Pro-19.local> In-reply-to: User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUiuPlRu253kH+0QftRZYvPq6+zWSxbu4LR gcmj7ctkJo8lS34yBTBFcdmkpOZklqUW6dslcGV0bTjOUjDVtGLCl7NsDYy/NLoYOTkkBEwk GqctZu5i5OIQEjjAJPHs4gQWkASvgKDEj8n3gGwODmYBeYmD52VBwswC0hKP/s5gh7C1JL4/ amWB6F3PJLF70TewhJBAF5PE7GXiEAvYJf782sECYWtLnH48jQ3G/rscYhCIfeD3Xag4l8SC radZQfZKCOhKHPsjCRFmk1h/YgkThK0lcXThIUYY+9qbiaww9u37H5khbE6J818mQo3XkXi8 +wvUaZ1Ad761gBifLdG5qQKiJFji5LpGdohXGpgk/m1pBasXFpCU6L5zB2wmi4CqxMvzs8HO ZAPa9fZ2O9heEaCaFdtXsUHCBMj++4kVotdD4vnlueyQ4LSQ+Nh5mRViwWwmicPztzNOYFSa hRTUsxBBPQspqGchBfUCRpZVjEK5iZk5upl5RnqJBQU5qXrJ+bmbGEFpYrqd4A7G46usDjEK cDAq8fBm/PWNFmJNLCuuzD3EKM3BoiTOW2oIFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cB4 UflCqMZuibmXHuQW8khssZ/8akWVWqbezZbWuB37uL6VeXSf2LxdYfGjoPRpq72qHM7NUrM3 2Kv7Rt7+6i9h0YkTGiYu/hQjIbJIzuVLeuf6hL1Pw8I+GCxyOyTC537w0HUJieLX3RnGLO5v xb1u3SyzfdX+4N+UDt+Zxq/VDrLFzGBelFCrxFKckWioxVxUnAgAXDlyLvQCAAA= Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 14:45:39 -0000 Hello Phil, On 17/07/18 - 23:30:15, philip.eardley@bt.com wrote: > In-line > Thanks > phil > -----Original Message----- > From: cpaasch@apple.com [mailto:cpaasch@apple.com] > Sent: 15 July 2018 16:15 > To: Eardley,PL,Philip,TUD1 R > Cc: multipathtcp@ietf.org > Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis > > ... > > > > > S3.9.2 > > << If the two communicating hosts immediately try to set up subflows > > from all available addresses to all available addresses on the other > > host, this could end up creating two subflows per path. This is an > > inefficient use of resources.>> > > is two subflows correct? Multiple I think > > It would be two subflows on each path (one being initiated by each host). > > [phil] ok. Can the para be re-phrased so it's clear this is about a new situation (compared to the earlier paras). Something like, "Another issue is that both communicating hosts may simultaneously try to set up a subflow between the same pair of addresses. This leads to an inefficient use of resources." (I suppose 'inefficient resources' refers to resources on the end host?) > thanks for the suggested text. I adopted it. > ... > > > > > > << client server > > | | > > | S 0(0) , | > > | -----------------------------------------------------------> | > > >> > > Can you explain the S 0(0) nomenclature/ please. > > tcpdump-style sequence number and length of the segment. > > Is it ok, if I change the figure for the first time we use this notation to: > S Seq=0(Length=0) > > And from there on leave the one we have now? > > [phil] yes - I suggest in the first figure you add a key that explains the notation and states it's used in Figures x, y, z. Sure, I annotated the figure. > > Section 2.1 & 3.1 - can you remind me why we changed MP_CAPABLE so > > that Host A's key is sent only on the ACK (not on the SYN)? Is this so > > it's only sent when we know host B is MPTCP capable, which is > > therefore a slight security improvement? (Just send a link to earlier > > emails, if that's easier) > > The reason for this is because now that we send the keys reliably in the third ACK / first data-segment, we actually don't need to send the key in the SYN anymore. Thus, we can reduce the size of the MP_CAPABLE in the SYN-segment and gain some bytes. > > [phil] ok - if I get it right the motivation for the change in the MP_CAPABLE protocol exchange starts from the observation that option space is most constrained in the SYN, so reducing the size of MP_CAPABLE in the SYN allows other TCP options to be used in the SYn. As a consequence of this decision, Host A doesn't know that Host B has learnt its key, unless the ACK is sent reliably. The story actually unfolded the other way around. We identified a need for reliable key-exchanges when talking to stateless servers. Based on this we made the key-exchange reliable in the third ACK/first data segment. Upon this, we realized that we can gain space in the SYN. Thus, the motivation for the change was the need for the reliable MP_CAPABLE. > I think it would be useful to tweak the figure in Section 2.1 - just to say the ack is delivered reliably. Incorporating it into the figure seems tricky to me. I changed the first sentence to mention data as well: "... initial ACK (and data) packets also ..." > However in Section 3.1 I think it would be good to include a more extensive figure about this - showing the different ways & timings for when the ack is known to have been delivered - ie figure showing somehow that A or B may be one that first sends data - and therefore when A knows that the ACK has indeed been successfully delivered to B. > The actual text (in the para starting " If B has data to send first, then the reliable delivery of the ACK...") is pretty good - however, there are a lot of "this packet", "this is" etc - likely that someone could misinterpret what a "this" refers to. A figure would help clarify and/or breaking the text up . Agreed - I will try to work on a proposal for this. > Also I spotted > << This option is used to declare the 64-bit keys that the end hosts > have generated for this MPTCP connection. This key is used to > authenticate the addition of future subflows to this connection.>> > This key is -> These keys are ... Fixed. > << Therefore, A's key must be delivered reliably to B, and in order to > do this, the transmission of this packet must be made reliable.>> > is it right to say that the protocol makes transmission of the ACK reliable? Suppose the Ack is lost. The protocol ensures that A doesn't have the mistaken belief that B has got the Ack. But does it say anything about how /when A sends the Ack again? (perhaps it should say something about this?) There is not really reliability of the ACK. Rather, piggy-backing of the MP_CAPABLE on a data-segment, which implicitly makes the MP_CAPABLE reliable thanks to the data's reliability. I try to clarify this with the figure I will do. > << Note that new subflows MUST NOT be established > (using the process documented in Section 3.2) until a Data Sequence > Signal (DSS) option has been successfully received across the path > (as documented in Section 3.3).>> > In the case where A sends data first, then the MP-CAPABLE is sent instead of the DSS. Does the text quoted mean that new subflows are not allowed (until an actual DSS is sent) or are they allowed because DSS has kind of been inferred? It is allowed. It is not so much about the DSS-option itself, but rather any MPTCP-option that is sent together with data. I will try to clarify this as well. I have another comment. In Section 3.1, there is: If receiving a message with the 'B' flag set to 1, and this is not understood, then this SYN MUST be silently ignored. I suggest to change this to "... then the MP_CAPABLE in this SYN MUST be silently ignored.". Otherwise, hosts setting the B-bit to test for a feature-capability will incur a SYN-retransmission timeout, which is a huge latency penalty. Please let me know if that is acceptable. I created another Pull-Request at https://github.com/multipath-tcp/draft-ietf-mptcp-rfc6824bis/pull/6. To not lose track of outstanding tasks, I listed them in the issues-section of the github: https://github.com/multipath-tcp/draft-ietf-mptcp-rfc6824bis/issues If anyone feels inspired to take onto one of these ... ;-) Christoph From nobody Wed Jul 18 07:53:53 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037FA130DD3 for ; Wed, 18 Jul 2018 07:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 R9YO6YipvNT6 for ; Wed, 18 Jul 2018 07:53:49 -0700 (PDT) Received: from mail-in21.apple.com (mail-out21.apple.com [17.171.2.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22B8C130F9F for ; Wed, 18 Jul 2018 07:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1531925628; x=2395839228; 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=aHWaErI2QbQ6qksNaxMvAxZcVefbHyLqk8cWnoCZRCE=; b=rVu1NJeh2gItXvE3BepNoBoms/11sPJQJjioqGlwLMjHGAy8C+5qICb+SAymbsFn MYUd+JcL3klzr5HKds9NSj70XaOGtSJUU2aJqa++OMPq8924+OP1SqmlBfG2JkBM qYzaqgVCvA7Q6Nc69qflJYaUY7OQPdLSlc/A9ovBbvZ4O4G4GQTpM8qRlCMJeC5k o8ETwHeF6H4q3D1jh89daXdkqLyudgwLmTwMULSFhDXMK2jTIOYUv16j2oJPGwmG EL+vSBiVpE/jAFc/sU0kqztCPZHj6LyjpcURh78Qg931vQeQo9V+DXhWy2qF8RqE ts5Exapa6UezKJ/lt9jIFQ==; X-AuditID: 11ab0215-217ff70000002a18-b1-5b4f547b9b03 Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in21.apple.com (Apple Secure Mail Relay) with SMTP id 82.B2.10776.C745F4B5; Wed, 18 Jul 2018 07:53:48 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PC2009UOHDNDW90@mr2-mtap-s03.rno.apple.com>; Wed, 18 Jul 2018 07:53:47 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PC200200H91GT00@nwk-mmpp-sz11.apple.com>; Wed, 18 Jul 2018 07:53:47 -0700 (PDT) X-Va-A: X-Va-T-CD: 858e2f4dae29a6016c98c8320829244c X-Va-E-CD: 3bbd785c51ace3f981efd92bc4e82048 X-Va-R-CD: 2b9cdb0e57a359d759a3675f8c35d2a7 X-Va-CD: 0 X-Va-ID: 607253ef-ab07-492a-a635-e63ad736d7b5 X-V-A: X-V-T-CD: 858e2f4dae29a6016c98c8320829244c X-V-E-CD: 3bbd785c51ace3f981efd92bc4e82048 X-V-R-CD: 2b9cdb0e57a359d759a3675f8c35d2a7 X-V-CD: 0 X-V-ID: 23496a6a-1a8a-4226-9b94-0b0f005ebac1 Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PC200H00GW18P00@nwk-mmpp-sz11.apple.com>; Wed, 18 Jul 2018 07:53:46 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-16_06:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp18.corp.apple.com-10000_instance1 Received: from localhost ([17.235.39.85]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PC200AH9HDL1R60@nwk-mmpp-sz11.apple.com>; Wed, 18 Jul 2018 07:53:46 -0700 (PDT) Sender: cpaasch@apple.com Date: Wed, 18 Jul 2018 10:53:45 -0400 From: Christoph Paasch To: philip.eardley@bt.com Cc: multipathtcp@ietf.org Message-id: <20180718145345.GP1471@MacBook-Pro-19.local> References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> <39fbc9f18384473398fca38670c73cf6@rew09926dag03b.domain1.systemhost.net> In-reply-to: User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUiuPlRu25NiH+0we2LEhafV19ns1i2dgWj A5NH25fJTB5LlvxkCmCK4rJJSc3JLEst0rdL4Mron6hYsM274uLWDrYGxk12XYycHBICJhKP t/1jBrGFBA4ySUxbkgVi8woISvyYfI+li5GDg1lAXuLgeVmQMLOAtMSjvzPYIWwtie+PWlkg WtczSWx/p9jFyAVkdzFJ/L3VwAoxn13iz68dLBC2tsTpx9PYYOy/yyEGgdgHft+FinNJLNh6 GqpXV+L5wjNQcTaJ9SeWMEHYWhJHFx5ihLGvvZnICmPfvv+RGcLmlDj/ZSLUfB2J1Z17mCGO 62SS2DRrGRvIYxIC2RKdmyogzGCJ/W+VIUoamCRefe0A2yssICnRfecO2EwWAVWJiU0nwXax Ae16e7sdzBYBqlmxfRUbJFCA7L+fWCF6PSSeX57LDglPC4nlHWcZIRa8YZR4evII6wRGpVlI YT0LEdazkMJ6FlJYL2BkWcUonJuYmaObmWdkqJdYUJCTqpecn7uJEZQmVjOJ7mCc/8rwEKMA B6MSD2/GX99oIdbEsuLK3EOM0hwsSuK8H3eJRQsJpCeWpGanphakFsUXleakFh9iZOLglGpg ZJ22PKDZ47aO3gOz3P9e+7e03Lq8wN7fUPZc6ML3pbplfsv66rTu+QU75enFRy1ceSr7d8Cq FLnFXH5ufNzm7g6ySTp1TblFf7nT85rF99y/HPzN4Nk0ke39q4LmuqgxONXZLnSx09joxd+z pcbg4vm0/Uw5lvFnFl69lNOUfaItbuW22PlKLMUZiYZazEXFiQATiUyk9AIAAA== Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 14:53:52 -0000 Hello Phil, this summary looks good to me. Cheers, Christoph On 05/07/18 - 08:20:50, philip.eardley@bt.com wrote: > Hi, > Fyi I prepared some text describing the main differences between the bis and rfc6824, and the reasons for those changes. I wrote it in the context of helping the IESG when they get to reviewing it - but I thought it might be useful to helping prompt WG comments at this stage (which we urgently need). The text is draft. > Best wishes, > Phil > > -- > This summarises the changes in draft-ietf-mptcp-rfc6824bis compared to the RFC6824. > https://tools.ietf.org/rfcdiff?url1=https://www.ietf.org/id/draft-ietf-mptcp-rfc6824bis-11.txt&url2=https://www.rfc-editor.org/rfc/rfc6824.txt > 1. It obsoletes RFC6824. This is considered a replacement for RFC6824, as it improves it in several ways. It is not backwards compatible with RFC6824 (the protocol changes in #4 and #9 in particular). > 2. Its Intended Status is Standards Track. RFC6824 is an Experimental Track document. When it was completed, it was agreed to re-charter the WG with the primary goal to create a bis version of the protocol document on the Standards track. > a. The bis incorporates lessons learnt from the various implementations, deployments and experiments. RFC8041 discusses "Use Cases and Operational Experience with Multipath TCP" https://tools.ietf.org/html/rfc8041 and an IETF Journal article describes "Multipath TCP Deployments" https://www.ietfjournal.org/multipath-tcp-deployments/ > b. In summary, MPTCP is extensively deployed, especially on smartphones (it is in Apple's iOS and macOS operating systems and is in several models of commercial Android smartphones), and is also deployed in some hybrid access networks. > c. The 'reference', maintained Linux implementation of RFC6824 is available at https://multipath-tcp.org/ > d. RFC6824bis-11 has been implemented in Linux, but has not been released (yet). > 3. Christoph Paasch is added as an author, as he proposed several of the new elements > 4. Connection initiation, through the exchange of the MP-CAPABLE MPTCP option, is different from RFC6824. Assuming that host A sends the SYN and ACK, and host B sends the SYN-ACK:- > a. Unlike RFC6824, the SYN doesn't include A's key (it is still sent in the ACK). This change means that A's key, which is sent in the clear, is not sent until B is known to be MPTCP-enabled. > b. The ACK can include data. This change means that A can send data without having to wait for B to send it data, as only then can it be sure the ACK has been received. To handle this case, the MP-CAPABLE option includes fields with the Data-Level Length and optionally a Checksum. > c. In the Flags field, C is now assigned to mean that the sender of this option will not accept additional MPTCP subflows to the source address and port. This is an efficiency improvement, for example where the sender is behind a strict NAT. > d. In the flags field, D now indicates the use of HMAC-SHA256 (rather than HMAC-SHA1). > 5. Connection initiation also defines the procedure for version negotiation, for implementations that support both v0 (RFC6824) and v1 (RFC6824bis). The initiator indicates the highest version it supports, the responder indicates if it supports this version. To prevent a downgrade attack, the initiator SHOULD fall back to regular TCP, alternatively it MAY establish a new connection with the lower version of MPTCP. > 6. The HMAC-SHA256 (rather than HMAC-SHA1) algorithm is used, as the algorithm provides better security. It is used to generate the token in the MP_JOIN and ADD_ADDR messages, and to set the initial data sequence number. > 7. As in RFC6824, a TCP RST for the subflow re-sets the subflow, or (in response to MP_JOIN) rejects an attempt to open a subflow. The change is that the process is enhanced by adding a MP_TCPRST Option:- > a. The new option includes a flag indicating whether the error condition is permanent or temporary, and a field with the "MP_TCPRST Reason Code", which indicates why the TCP RST is being sent. > b. The receiving host MAY use this information to decide, for example, whether it tries to re-establish the subflow immediately, later, or never. > c. IANA is requested to create a further sub-registry with the "MP_TCPRST Reason Codes". > 8. The MP_PRIO option, which is used to signal a change of priority for a subflow, no longer includes the AddrID field. Its purpose was to allow the changed priority to be applied on a subflow other than the one it was sent on. However, it has been realised that this could be used by a man-in-the-middle to divert all traffic on to its own path, and this is an easy attack since MP_PRIO does not include a token or other security mechanism. The issue was discussed at IETF-99 and since no implementer was known to use the address identifier on MP-PRIO, it was agreed that the best approach was to remove it. > 9. The ADD_ADDR option, which is used to inform the other host about another potential address, is different in several ways: > a. It now includes an HMAC of the added address. This is for enhanced security. The RFC6824 procedure for adding an address is open to an attack where an off-path attacker creates a spoofed ADD_ADDR that enables it to hijack an MPTCP-enabled connection. Including an HMAC in the ADD_ADDR message makes it as secure as MP_JOIN. > b. This was the primary driver for incrementing the version number. This was first discussed at an interim meeting in 2015 and subsequently at IETF-96. The WG consensus was that this approach was better than incorporating an alternative add address mechanism within an enhanced version 0 of the protocol. The problem and solution is discussed further in RFC7430. > c. Reliability for the ADD_ADDR option. The IPVer field is replaced with a flag field (the IP version field was not useful, since it is known anyway), and one flag is assigned (E) which is used as an 'Echo' so a host can indicate that it has received the option. Hence this provides reliability for the ADD_ADDR option. > 10. An additional way of performing a Fast Close is described. The host sends a RST containing the MPT_FASTCLOSE option on all subflows. This allows the host to tear down the subflows and the connection immediately. > 11. In the IANA registry a new MPTCP subtype option, MP_EXPERIMENTAL, is Reserved for private experiments. However, the document doesn't define how to use the subtype option. > 12. A new Appendix discusses the usage of both the MPTCP and TCP Fast Open on the same packet. The two main issues are discussed: > a. The potential lack of enough option space in a TCP packet. This is more likely to be an issue on the SYN+ACK packet, and the suggestion is to use a shorter TFO cookie if necessary. > b. A potential problem with data sequence mapping under some circumstances. The suggestion is that the TFO data is not considered part of the Data Sequence Number space. > > -----Original Message----- > From: Eardley,PL,Philip,TUD1 R > Sent: 04 July 2018 08:31 > To: 'multipathtcp@ietf.org' > Subject: RE: WG Last Call for draft-ietf-mptcp-rfc6824bis > > We urgently need your comments about this document. > > It's been in WG last call for just on 4 weeks, but I think the only comments so far are from the WG chairs - clearly we need more comments before the document can advance. We'd like to discuss and close issues before or during the IETF. > > So please can you dedicate some time to checking the document. > > Thanks, > Phil & Yoshi > > -----Original Message----- > From: Eardley,PL,Philip,TUD1 R > Sent: 26 June 2018 08:33 > To: multipathtcp@ietf.org > Subject: RE: WG Last Call for draft-ietf-mptcp-rfc6824bis > > Hi, > Just a reminder about the WGLC for the protocol bis. Please send comments, Thanks! > Phil & Yoshi > > -----Original Message----- > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com > Sent: 05 June 2018 12:21 > To: multipathtcp@ietf.org > Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis > > As a reminder, this document Obsoletes: 6824 (if approved) and its Intended status is Standards Track. > > As well as suggested changes or edits, positive review comments ("It's ready") are also very valuable. > > -----Original Message----- > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com > Sent: 05 June 2018 09:14 > To: multipathtcp@ietf.org > Subject: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis > > This starts a WG Last Call for draft-ietf-mptcp-rfc6824bis. Please send comments by the end of June. > > Please note there are three IPR disclosures (we're working on getting them added to the rfc6824bis page): > > * two are inherited from RFC6824 https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mptcp-multiaddressed > * one is inherited from draft-paasch-mptcp-syncookies (which got include in rfc6824bis) https://datatracker.ietf.org/ipr/2678/ > > Thanks, > Phil & 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 > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Wed Jul 18 08:47:54 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC411311AB for ; Wed, 18 Jul 2018 08:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 1YveTXH-wyx2 for ; Wed, 18 Jul 2018 08:47:48 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1C3A13118F for ; Wed, 18 Jul 2018 08:47:47 -0700 (PDT) Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by EVMED02-UKBR.bt.com (10.216.161.32) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 18 Jul 2018 16:47:41 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03c.domain1.systemhost.net (10.55.202.26) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 18 Jul 2018 16:47:44 +0100 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.1293.004; Wed, 18 Jul 2018 16:47:44 +0100 From: To: CC: Thread-Topic: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis Thread-Index: AdP8pPjqwq5n45WRS2ywhz4YK91ZcQHJh45AAMTUIlAFZGvbgABoZzJQACL4mAAAAvROIA== Date: Wed, 18 Jul 2018 15:47:43 +0000 Message-ID: References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> <20180715201445.GU1471@MacBook-Pro-19.local> <20180718144528.GO1471@MacBook-Pro-19.local> In-Reply-To: <20180718144528.GO1471@MacBook-Pro-19.local> 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.216.161.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 15:47:53 -0000 Something that needs fixing which Christoph and I just noticed during a cha= t at the IETF: S3.7 on Fallback has=20 <> this needs a mod now data is allowed on the third packet. ..... >=20 > [phil] ok - if I get it right the motivation for the change in the MP_CAP= ABLE protocol exchange starts from the observation that option space is mos= t constrained in the SYN, so reducing the size of MP_CAPABLE in the SYN all= ows other TCP options to be used in the SYn. As a consequence of this decis= ion, Host A doesn't know that Host B has learnt its key, unless the ACK is = sent reliably. =20 The story actually unfolded the other way around. We identified a need for = reliable key-exchanges when talking to stateless servers. Based on this we = made the key-exchange reliable in the third ACK/first data segment. Upon this, we realized that we can gain space in the SYN. Thus, the motivation for the change was the need for the reliable MP_CAPABL= E. > I think it would be useful to tweak the figure in Section 2.1 - just to s= ay the ack is delivered reliably.=20 Incorporating it into the figure seems tricky to me. I changed the first se= ntence to mention data as well: "... initial ACK (and data) packets also ..= ." [phil2] the figure in S2.1 (ie in the Operation Overview section) should be= modified. As it is compulsory to send the MP_CAPABLE ACK message on the fi= rst data packet. Sending MP_CAPABLE ACK without data is done if host A does= n't have data to send, but you still have to send ACK later with the first = data. Whereas the natural way to interpret the current fig in S2.1 is that = the Ack is sent once. ...... I have another comment. In Section 3.1, there is: If receiving a message with the 'B' flag set to 1, and this is not understo= od, then this SYN MUST be silently ignored. I suggest to change this to "... then the MP_CAPABLE in this SYN MUST be si= lently ignored.". Otherwise, hosts setting the B-bit to test for a feature-= capability will incur a SYN-retransmission timeout, which is a huge latency= penalty. Please let me know if that is acceptable. [phil2] fine by me - please make it clear this means fallback to TCP (as in= similar text for other cases where we fallback) From nobody Wed Jul 18 08:59:11 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18919130E39 for ; Wed, 18 Jul 2018 08:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 I_m1mwMJRMp6 for ; Wed, 18 Jul 2018 08:59:05 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE62B130DFE for ; Wed, 18 Jul 2018 08:59:04 -0700 (PDT) Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by EVMED02-UKBR.bt.com (10.216.161.32) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 18 Jul 2018 16:58:59 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03b.domain1.systemhost.net (10.55.202.22) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 18 Jul 2018 16:59:02 +0100 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.1293.004; Wed, 18 Jul 2018 16:59:02 +0100 From: To: , CC: , Thread-Topic: Review of RFC6824bis - Multipath TCP Thread-Index: AdQerxiJ3zmxcKJgQ8Kus8ghK021hA== Date: Wed, 18 Jul 2018 15:59:01 +0000 Message-ID: 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.216.161.45] Content-Type: multipart/alternative; boundary="_000_bdcb304e18274eadbfa22013c7a23883rew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] Review of RFC6824bis - Multipath TCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 15:59:09 -0000 --_000_bdcb304e18274eadbfa22013c7a23883rew09926dag03bdomain1sy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Xavier, Rahul, Thank-you very much for agreeing to review the document, it is much appreci= ated. (Rahul - I hope I got the right email address) The right document to review is https://tools.ietf.org/html/draft-ietf-mptc= p-rfc6824bis (-11) Please send comments to the mailing list multipathtcp@ie= tf.org (Don't worry about repeating issues that have already been raised. If you'r= e interested in tracking Christoph's working copy as the issues raised so f= ar are fixed, https://github.com/multipath-tcp/draft-ietf-mptcp-rfc6824bis/= pull/6. And https://github.com/multipath-tcp/draft-ietf-mptcp-rfc6824bis/i= ssues) Thank-you! Phil & Yoshi -- -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 26 June 2018 03:33 To: multipathtcp@ietf.org Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis Hi, Just a reminder about the WGLC for the protocol bis. Please send comments, = Thanks! Phil & Yoshi -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 05 June 2018 12:21 To: multipathtcp@ietf.org Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis As a reminder, this document Obsoletes: 6824 (if approved) and its Intended= status is Standards Track. As well as suggested changes or edits, positive review comments ("It's read= y") are also very valuable. -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 05 June 2018 09:14 To: multipathtcp@ietf.org Subject: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis This starts a WG Last Call for draft-ietf-mptcp-rfc6824bis. Please send com= ments by the end of June. Please note there are three IPR disclosures (we're working on getting them = added to the rfc6824bis page): * two are inherited from RFC6824 https://datatracker.ietf.org/ipr/search/?= submit=3Ddraft&id=3Ddraft-ietf-mptcp-multiaddressed * one is inherited from draft-paasch-mptcp-syncookies (which got include in= rfc6824bis) https://datatracker.ietf.org/ipr/2678/ Thanks, Phil & 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 _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp --_000_bdcb304e18274eadbfa22013c7a23883rew09926dag03bdomain1sy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Xavier, Rahul,

Thank-you very much for agreeing to review the document, it is muc= h appreciated.

(Rahul – I hope I got the right email address)

The right document to review is https:/= /tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis (-11) Please send comm= ents to the mailing list multipathtcp@ietf.org

(Don’t worry about repeating issues that ha= ve already been raised. If you’re interested in tracking Christoph= 217;s working copy as the issues raised so far are fixed, https://github.com/multipath-tcp/draft-ietf-mptcp-rfc6824bis/pull/6.  And https://github.com/multipath-tcp/draft-ietf-mptcp-rfc6824bis/issues)

 

Thank-you!

Phil & Yoshi

--

-----Original Message-----

From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com

Sent: 26 June 2018 03:33

To: mult= ipathtcp@ietf.org

Subject: Re: [multipathtcp] WG Last Call for draf= t-ietf-mptcp-rfc6824bis

 

Hi,

Just a reminder about the WGLC for the protocol b= is. Please send comments, Thanks!

Phil & Yoshi

 

-----Original Message-----

From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com

Sent: 05 June 2018 12:21

To: mult= ipathtcp@ietf.org

Subject: Re: [multipathtcp] WG Last Call for draf= t-ietf-mptcp-rfc6824bis

 

As a reminder, this document Obsoletes: 6824 (if = approved) and its Intended status is Standards Track.

 

As well as suggested changes or edits, positive r= eview comments ("It's ready") are also very valuable.

 

-----Original Message-----

From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com

Sent: 05 June 2018 09:14

To: mult= ipathtcp@ietf.org

Subject: [multipathtcp] WG Last Call for draft-ie= tf-mptcp-rfc6824bis

 

This starts a WG Last Call for draft-ietf-mptcp-r= fc6824bis. Please send comments by the end of June.

 

Please note there are three IPR disclosures (we'r= e working on getting them added to the rfc6824bis page):

 

* two are inherited from RFC6824  https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf= -mptcp-multiaddressed   

* one is inherited from draft-paasch-mptcp-syncoo= kies (which got include in rfc6824bis) https://datatracker.ietf= .org/ipr/2678/

 

Thanks,

Phil & Yoshi

_______________________________________________

multipathtcp mailing list

multipat= htcp@ietf.org

https://www.ietf.org/mailman/listinfo/multipathtcp

 

_______________________________________________

multipathtcp mailing list

multipat= htcp@ietf.org

https://www.ietf.org/mailman/listinfo/multipathtcp

 

_______________________________________________

multipathtcp mailing list

multipat= htcp@ietf.org

https://www.ietf.org/mailman/listinfo/multipathtcp

 

 =

 

--_000_bdcb304e18274eadbfa22013c7a23883rew09926dag03bdomain1sy_-- From nobody Wed Jul 18 09:02:03 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE48130DFE for ; Wed, 18 Jul 2018 09:02:01 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 rFXs9Uq5eBOV for ; Wed, 18 Jul 2018 09:01:59 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (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 22A94129619 for ; Wed, 18 Jul 2018 09:01:59 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id x24-v6so3247945ual.10 for ; Wed, 18 Jul 2018 09:01:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fATRoK44JWiQYMdH/eziiGXIsGRd9KjKo79o8I4q6Ow=; b=nreEqn/uMvtXWmgMrTZERQQL08uWtR2dvtbbw7LQB1S8APGsIjesAZtwCxM+P/OUH+ 9nShScreb2ls6r323I8Hh8WEVeJpH/jBGIWgXe2egdAjf99PYSBFq0f/AvnOYei8iVqT ZMVe9McOtaKItXdQ1k3da0ijggQxfPry+oj0kWscrDu1j9wB/KsiX73HUzTI+w4fbyKc TQLY0s33HT0PNnxdoRZN2yn3rL4gW3VV7XJsYmn27jtq6whG3/vr4VTsqdpZtk9iL+W5 Ao+/1M7eBbHOX45nHNJUiiOtI9JAIVgkP+wiC67ZDurQC4XNRTwQ3CwtLs6SPBIFqWLm yARw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=fATRoK44JWiQYMdH/eziiGXIsGRd9KjKo79o8I4q6Ow=; b=UBkCWpC0UH1UMyg0DW27RxltnjGz/x91hoLFQ6aR6DH7aKzBDr0UX3ip6ajxOSyA/i xYc0N4cvWIlYzNaT3KmUE6tOl2yt8ziJIsSbFTasQdoSYT4FOt+eCkuwTzJtJlL8UmFv SIsKTE9Hg6W3qcSzANrAy0FcLJM+E5ik3G9UZsrCTZFhORM3/G0YA+W8Ij5yjKzNFPuc MPbrFD7VH8UHHbs06JFfEzuME5J0U6vUeKxbSfhuESM0qc/yFbxIAA+MMtI2yHPtCe4v XaZ2VBL9VuR/oTc9BGZ1gaJXLUmqskchy/fUSduvhk+nldAp1IJtNn8z8GkerUjXfJ8L aN6A== X-Gm-Message-State: AOUpUlFXM+wRpUSn/JYKkZgk9bbKJ8bggk9JzLuaVQ677tUsc5/1fm67 0EEMUAetiv+59jSij6/ldXKhgbX/bzIGfYmCW5E= X-Google-Smtp-Source: AAOMgpchYPHJU9op/Mt8DFqjx479tsN/5RzJimZkGJZBzm6/1hK6a7+FoYddu3p5hpbV5C+w9leSPUvwG9uQaOgTpLQ= X-Received: by 2002:ab0:1601:: with SMTP id k1-v6mr4251005uae.83.1531929718034; Wed, 18 Jul 2018 09:01:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rahul Jadhav Date: Wed, 18 Jul 2018 12:01:45 -0400 Message-ID: To: philip.eardley@bt.com Cc: x.defoy.ietf@gmail.com, nishida@sfc.wide.ad.jp, multipathtcp@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [multipathtcp] Review of RFC6824bis - Multipath TCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 16:02:02 -0000 Yep you got the email-id right. And thank you for the pointers. It definitely helps. On Wed, 18 Jul 2018 at 11:59, wrote: > > Xavier, Rahul, > > Thank-you very much for agreeing to review the document, it is much appre= ciated. > > (Rahul =E2=80=93 I hope I got the right email address) > > The right document to review is https://tools.ietf.org/html/draft-ietf-mp= tcp-rfc6824bis (-11) Please send comments to the mailing list multipathtcp@= ietf.org > > (Don=E2=80=99t worry about repeating issues that have already been raised= . If you=E2=80=99re interested in tracking Christoph=E2=80=99s working copy= as the issues raised so far are fixed, https://github.com/multipath-tcp/dr= aft-ietf-mptcp-rfc6824bis/pull/6. And https://github.com/multipath-tcp/dra= ft-ietf-mptcp-rfc6824bis/issues) > > > > Thank-you! > > Phil & Yoshi > > -- > > -----Original Message----- > > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of ph= ilip.eardley@bt.com > > Sent: 26 June 2018 03:33 > > To: multipathtcp@ietf.org > > Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis > > > > Hi, > > Just a reminder about the WGLC for the protocol bis. Please send comments= , Thanks! > > Phil & Yoshi > > > > -----Original Message----- > > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of ph= ilip.eardley@bt.com > > Sent: 05 June 2018 12:21 > > To: multipathtcp@ietf.org > > Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis > > > > As a reminder, this document Obsoletes: 6824 (if approved) and its Intend= ed status is Standards Track. > > > > As well as suggested changes or edits, positive review comments ("It's re= ady") are also very valuable. > > > > -----Original Message----- > > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of ph= ilip.eardley@bt.com > > Sent: 05 June 2018 09:14 > > To: multipathtcp@ietf.org > > Subject: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis > > > > This starts a WG Last Call for draft-ietf-mptcp-rfc6824bis. Please send c= omments by the end of June. > > > > Please note there are three IPR disclosures (we're working on getting the= m added to the rfc6824bis page): > > > > * two are inherited from RFC6824 https://datatracker.ietf.org/ipr/search= /?submit=3Ddraft&id=3Ddraft-ietf-mptcp-multiaddressed > > * one is inherited from draft-paasch-mptcp-syncookies (which got include = in rfc6824bis) https://datatracker.ietf.org/ipr/2678/ > > > > Thanks, > > Phil & 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 > > > > _______________________________________________ > > multipathtcp mailing list > > multipathtcp@ietf.org > > https://www.ietf.org/mailman/listinfo/multipathtcp > > > > > > From nobody Thu Jul 19 07:27:53 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D141130E50 for ; Thu, 19 Jul 2018 07:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 ZcCjf8I_6_5e for ; Thu, 19 Jul 2018 07:27:36 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3400C1310EE for ; Thu, 19 Jul 2018 07:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1532010455; x=2395924055; 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=VjF9ouPhv8VeWwmMnHaO8ykN1ZGorzXfh7ESRI241SA=; b=cSHQyQKnAuu6qBbwrZ5YLN5kHwO8VfY6YAZQ0pl9QbT7YaMMMud3N1M/2tOuCNvv j3a1V3U3bZqm6R9I5cGZP5vag4EgP0RBRnKaqDreooX8zPBywbJZpGsu23S1Mf9P dxDnXHQjcPuAj4WAUU20vCn/l8Qm5iw8II2Z8ymQluLA1Dwq9x9U5eX/6pSf7Krw f+SMAlxFIhU8gb048XBLrnEjjZhzY/m1Jh5dtqCW10/C7rEb6fd3mAftXptKSwWl hRoCx52vw6yccnwa9KqcmLrV7Ail4lOqDEFiwigN58mSwHp6nOpjRs/nVkRuagfh 49z6zF+mevcoSMxaDIqacA==; X-AuditID: 11973e16-6d9ff7000000740c-e2-5b509fd709a5 Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 60.DF.29708.7DF905B5; Thu, 19 Jul 2018 07:27:35 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PC4007DAATZ9EC0@mr2-mtap-s02.rno.apple.com>; Thu, 19 Jul 2018 07:27:35 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PC400H00AKEY900@nwk-mmpp-sz10.apple.com>; Thu, 19 Jul 2018 07:27:35 -0700 (PDT) X-Va-A: X-Va-T-CD: 858e2f4dae29a6016c98c8320829244c X-Va-E-CD: 3bbd785c51ace3f981efd92bc4e82048 X-Va-R-CD: 2b9cdb0e57a359d759a3675f8c35d2a7 X-Va-CD: 0 X-Va-ID: 5c085704-8961-4379-b2cc-8c25373059fe X-V-A: X-V-T-CD: 858e2f4dae29a6016c98c8320829244c X-V-E-CD: 3bbd785c51ace3f981efd92bc4e82048 X-V-R-CD: 2b9cdb0e57a359d759a3675f8c35d2a7 X-V-CD: 0 X-V-ID: 54c0e7c0-11bf-4fbb-ba19-bbeb87a31961 Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PC400H00AK7XZ00@nwk-mmpp-sz10.apple.com>; Thu, 19 Jul 2018 07:27:35 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-19_06:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp18.corp.apple.com-10000_instance1 Received: from localhost ([17.235.10.219]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PC400C6WATYOJ80@nwk-mmpp-sz10.apple.com>; Thu, 19 Jul 2018 07:27:35 -0700 (PDT) Sender: cpaasch@apple.com Date: Thu, 19 Jul 2018 10:27:34 -0400 From: Christoph Paasch To: philip.eardley@bt.com Cc: multipathtcp@ietf.org Message-id: <20180719142734.GZ1471@MacBook-Pro-19.local> References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> <20180715201445.GU1471@MacBook-Pro-19.local> <20180718144528.GO1471@MacBook-Pro-19.local> In-reply-to: User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMIsWRmVeSWpSXmKPExsUiuPlRm+71+QHRBr3XTCw+r77OZrFs7QpG ByaPti+TmTyWLPnJFMAUxWWTkpqTWZZapG+XwJVx7+0ZloImsYoDU2+wNjDuEexi5OSQEDCR uPF/I2sXIxeHkMABJonrsx+xgCR4BQQlfky+B2RzcDALyEscPC8LEmYWkJZ49HcGO4StJfH9 USsLRO96JomGhhlQg7qYJGYcPsAMsYFd4s+vHSwQtrbE6cfT2GDsv8shJoHYB37fhYpzSSzY epoVZLGEgK7EjVshEGE2ifUnljBB2FoSRxceYoSxr72ZyApj377/EWotp8T5LxOhxutIXLy5 DerQTiaJbS9+QzVkSzRu+sQEsStYYv9bZYiaRiaJ36cfgS0QFpCU6L5zB2woi4CqxP9T08GO YANa9vZ2O9gcEaCaFdtXsUFCBcj++4kVotdD4vnlueyQALWQmH32NyPEgqnMEteOnWSbwKg0 CymwZyECexZSYM9CCuwFjCyrGIVyEzNzdDPzzPUSCwpyUvWS83M3MYJSxXQ7sR2MD1dZHWIU 4GBU4uFlcA2IFmJNLCuuzD3EKM3BoiTOKz7JP1pIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD 4z6H9erPQ09Zrz+Xm/HGQER8BUfbCieN6DWXWI5pMXeqan7L61+2jGFn6pH1h63fVk54w3n0 6sQpoWZ3TA6Kn5yw6OJlTnHTRVL1DL//PfnxeLPo+T1NZ/4vM05U89uuF7163ecNs/kSvfIn OPV1FnvlsF7QK/yhcuhSw59F6Tnt/ia1kyflayuxFGckGmoxFxUnAgANSfHK9gIAAA== Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 14:27:50 -0000 On 18/07/18 - 15:47:43, philip.eardley@bt.com wrote: > Something that needs fixing which Christoph and I just noticed during a chat at the IETF: > > S3.7 on Fallback has > < third packet of an MP_CAPABLE or MP_JOIN handshake, since both that > option and a DSS cannot fit in TCP option space.>> > this needs a mod now data is allowed on the third packet. > > ..... Created https://github.com/multipath-tcp/draft-ietf-mptcp-rfc6824bis/issues/12. > > > > > [phil] ok - if I get it right the motivation for the change in the MP_CAPABLE protocol exchange starts from the observation that option space is most constrained in the SYN, so reducing the size of MP_CAPABLE in the SYN allows other TCP options to be used in the SYn. As a consequence of this decision, Host A doesn't know that Host B has learnt its key, unless the ACK is sent reliably. > > The story actually unfolded the other way around. We identified a need for reliable key-exchanges when talking to stateless servers. Based on this we made the key-exchange reliable in the third ACK/first data segment. > > Upon this, we realized that we can gain space in the SYN. > > Thus, the motivation for the change was the need for the reliable MP_CAPABLE. > > > I think it would be useful to tweak the figure in Section 2.1 - just to say the ack is delivered reliably. > > Incorporating it into the figure seems tricky to me. I changed the first sentence to mention data as well: "... initial ACK (and data) packets also ..." > > [phil2] the figure in S2.1 (ie in the Operation Overview section) should be modified. As it is compulsory to send the MP_CAPABLE ACK message on the first data packet. Sending MP_CAPABLE ACK without data is done if host A doesn't have data to send, but you still have to send ACK later with the first data. Whereas the natural way to interpret the current fig in S2.1 is that the Ack is sent once. I will rework this as I review the whole MP_CAPABLE exchange. > > > ...... > > I have another comment. In Section 3.1, there is: > > If receiving a message with the 'B' flag set to 1, and this is not understood, then this SYN MUST be silently ignored. > > > I suggest to change this to "... then the MP_CAPABLE in this SYN MUST be silently ignored.". Otherwise, hosts setting the B-bit to test for a feature-capability will incur a SYN-retransmission timeout, which is a huge latency penalty. > > Please let me know if that is acceptable. > > [phil2] fine by me - please make it clear this means fallback to TCP (as in similar text for other cases where we fallback) Incorporated it into https://github.com/multipath-tcp/draft-ietf-mptcp-rfc6824bis/pull/6. Cheers, Christoph From nobody Thu Jul 19 12:29:10 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225EA130F6C for ; Thu, 19 Jul 2018 12:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 L9cZbUXEEPFp for ; Thu, 19 Jul 2018 12:29:07 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 0666E130EDA for ; Thu, 19 Jul 2018 12:29:07 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id 203-v6so9031551ljj.13 for ; Thu, 19 Jul 2018 12:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=198O4iggAD6dtCY9fRm0QbqZEfL21vKHVnm4pG+NsMc=; b=IpLFZQvKgUsahrZ3GY8UTMRxdJpAv9EH+tL6onTdVLHa+IDy9rw1z64V5YpXsPLqZ2 Af7rjQQ/j29EvfLQOukTLTKu4ZE5DTsnAcTRx/rBe+8DYOrc8ZrBauICnS4QBTri1TQF 4qT4C/OsNx6SWItexhHQNO6LtblskZdoIUQmc0TMgkgw3embngjJkOLz5MHznCGEbyjz KUTBxSakEcya68W8Vy+38IZLuO+MSxA3956t09/ry4zf7+upqUnAWiAgyUX6c6/UDg3v E7Vq/5l6qTRruTBQpEy0hbZJrJhnSzALMSzGr3T6IgnlMHO3OHFFGoJx+gybZL7JuNMI EyJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=198O4iggAD6dtCY9fRm0QbqZEfL21vKHVnm4pG+NsMc=; b=CeVbY79yw0lr+QP898L3g3QK4f1sKbOZmZ40d0uQOfsoDA1irsgNPJpYtJdK5kjH4u 3mVD4DxDLqgCi5s0QqWgMJriyqwesUZbD5rQ/sKQEjbAQxL+Y6/YCtJM4V5wRq9qtBjU An9FfaAAwKWcw2k08/J+3VS13qYcRCta7BEt/bGLh4I7tcl+udPfSZ7hDLPe9I8Kf1GH EdZWuA51kr+r+A41qeGKj8aBhGlCt3yLqO9N9Zs3pSyiWSdcahcNXrKHs3zMkdIARDrM Ml7RPNVeUd/v32KWx0Ixt4BnSWiJQEXBWo8xAnX/7LsgLB11DmioS7nABrXoYtajqr3p KF5Q== X-Gm-Message-State: AOUpUlHHGOxtrpmyO6+Pv47LnHJejXhW4e45QrqqG70TimciUW4nN+C6 u6phfRE+PKbL+S9NwowZ7aA= X-Google-Smtp-Source: AAOMgpeYBDZHQUvOGnWFOquzff9ss+0GDGMZbcCguNrwr4xeMgwxCsTrJ42MHUDwupV2LRpV1u2lXQ== X-Received: by 2002:a2e:8807:: with SMTP id x7-v6mr8471445ljh.98.1532028545342; Thu, 19 Jul 2018 12:29:05 -0700 (PDT) Received: from [192.168.1.66] ([83.216.157.26]) by smtp.gmail.com with ESMTPSA id h7-v6sm1228376ljk.27.2018.07.19.12.29.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 19 Jul 2018 12:29:04 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan Ford In-Reply-To: Date: Thu, 19 Jul 2018 20:29:03 +0100 Cc: cpaasch@apple.com, multipathtcp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> <20180715201445.GU1471@MacBook-Pro-19.local> To: philip.eardley@bt.com X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 19:29:09 -0000 Hi Phil, Catching up on these comments, re this: > On 18 Jul 2018, at 00:30, philip.eardley@bt.com wrote: >=20 > << Note that new subflows MUST NOT be established > (using the process documented in Section 3.2) until a Data Sequence > Signal (DSS) option has been successfully received across the path > (as documented in Section 3.3).>> > In the case where A sends data first, then the MP-CAPABLE is sent = instead of the DSS. Does the text quoted mean that new subflows are not = allowed (until an actual DSS is sent) or are they allowed because DSS = has kind of been inferred? I think the text still holds. We need a DSS to be received (as a DATA = ACK) in order to know the path is fully MPTCP capable. Regards, Alan From nobody Thu Jul 19 13:15:19 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD56E130F85 for ; Thu, 19 Jul 2018 13:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 2NW4yvSEBO-i for ; Thu, 19 Jul 2018 13:14:48 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E343E130F73 for ; Thu, 19 Jul 2018 13:14:47 -0700 (PDT) Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EVMED02-UKBR.bt.com (10.216.161.32) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 19 Jul 2018 21:14:44 +0100 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.1293.2; Thu, 19 Jul 2018 21:14:43 +0100 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.1293.004; Thu, 19 Jul 2018 21:14:43 +0100 From: To: Thread-Topic: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis Thread-Index: AdP8pPjqwq5n45WRS2ywhz4YK91ZcQHJh45AAMTUIlAFZGvbgABoZzJQAF8qoYAAA6qQYA== Date: Thu, 19 Jul 2018 20:14:42 +0000 Message-ID: References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> <20180715201445.GU1471@MacBook-Pro-19.local> In-Reply-To: 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.216.161.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 20:14:58 -0000 A small one - S1.5 requirements language - there is new text to use, see ht= tps://tools.ietf.org/html/rfc8174=20 From nobody Thu Jul 19 13:20:08 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE71130E2A for ; Thu, 19 Jul 2018 13:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 h_MOI9HSFbX3 for ; Thu, 19 Jul 2018 13:20:05 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C88A8130DC9 for ; Thu, 19 Jul 2018 13:20:04 -0700 (PDT) Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EVMED01-UKBR.bt.com (10.216.161.31) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 19 Jul 2018 21:20:02 +0100 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.1293.2; Thu, 19 Jul 2018 21:20:00 +0100 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.1293.004; Thu, 19 Jul 2018 21:20:00 +0100 From: To: CC: , Thread-Topic: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis Thread-Index: AdP8pPjqwq5n45WRS2ywhz4YK91ZcQHJh45AAMTUIlAFZGvbgABoZzJQAF8qoYAAA9oCQA== Date: Thu, 19 Jul 2018 20:20:00 +0000 Message-ID: References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> <20180715201445.GU1471@MacBook-Pro-19.local> In-Reply-To: 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.216.161.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 20:20:07 -0000 I'll leave it to you & Christoph to work on some clearer text -----Original Message----- From: Alan Ford [mailto:alan.ford@gmail.com]=20 Sent: 19 July 2018 15:29 To: Eardley,PL,Philip,TUD1 R Cc: cpaasch@apple.com; multipathtcp@ietf.org Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis Hi Phil, Catching up on these comments, re this: > On 18 Jul 2018, at 00:30, philip.eardley@bt.com wrote: >=20 > << Note that new subflows MUST NOT be established > (using the process documented in Section 3.2) until a Data Sequence > Signal (DSS) option has been successfully received across the path > (as documented in Section 3.3).>> > In the case where A sends data first, then the MP-CAPABLE is sent instead= of the DSS. Does the text quoted mean that new subflows are not allowed (u= ntil an actual DSS is sent) or are they allowed because DSS has kind of bee= n inferred? I think the text still holds. We need a DSS to be received (as a DATA ACK) = in order to know the path is fully MPTCP capable. Regards, Alan From nobody Wed Jul 25 21:54:22 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A461130E00 for ; Wed, 25 Jul 2018 21:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 HPLKblVg-aAx for ; Wed, 25 Jul 2018 21:54:18 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3D1A130DE6 for ; Wed, 25 Jul 2018 21:54:18 -0700 (PDT) Received: from mail-it0-f54.google.com (mail-it0-f54.google.com [209.85.214.54]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 9797927861A for ; Thu, 26 Jul 2018 13:54:15 +0900 (JST) Received: by mail-it0-f54.google.com with SMTP id s7-v6so1051753itb.4 for ; Wed, 25 Jul 2018 21:54:15 -0700 (PDT) X-Gm-Message-State: AOUpUlFIVGMihFZbcy9Zbqw4Ks6LowbuACrRMRxoRgvXJRyoR8EHLoe6 fqIC1SQxzU4RRodVhHPopnjuvBN1RJYGEsZ1X4E= X-Google-Smtp-Source: AAOMgpdD5WrPBcdQ+vVJCz75Zq3Qq1mCQ8Hsu/ld74khpeR416b6YlYGbwmltz6k1tkgTye/9o8qXVIjnRl6fMGDmXA= X-Received: by 2002:a02:98dc:: with SMTP id c28-v6mr364168jak.47.1532580853796; Wed, 25 Jul 2018 21:54:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:7599:0:0:0:0:0 with HTTP; Wed, 25 Jul 2018 21:54:13 -0700 (PDT) From: Yoshifumi Nishida Date: Wed, 25 Jul 2018 21:54:13 -0700 X-Gmail-Original-Message-ID: Message-ID: To: multipathtcp Content-Type: multipart/alternative; boundary="00000000000061535e0571dfc9a6" Archived-At: Subject: [multipathtcp] draft minutes for the montreal meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 04:54:21 -0000 --00000000000061535e0571dfc9a6 Content-Type: text/plain; charset="UTF-8" Hi, I just uploaded a draft minutes for the montreal meeting on the URL below. https://datatracker.ietf.org/meeting/102/materials/minutes-102-mptcp If you have any corrections, questions or comments, please let the chairs know. We appreciate Christoph and Xavier for precise note-taking! Thanks, -- Yoshi & Phil --00000000000061535e0571dfc9a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, I just uploaded a draft minutes for the montreal = meeting on the URL below.

https://datatracker.iet= f.org/meeting/102/materials/minutes-102-mptcp

If= you have any corrections, questions or comments, please let the chairs kno= w.
We appreciate Christoph and Xavier for precise note-taking!

Thanks,
--
Yoshi & Phil
--00000000000061535e0571dfc9a6-- From nobody Thu Jul 26 11:03:21 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E00312DD85 for ; Thu, 26 Jul 2018 11:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 C-R6_H_YPdet for ; Thu, 26 Jul 2018 11:03:17 -0700 (PDT) Received: from mail-in25.apple.com (mail-out25.apple.com [17.171.2.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A110124D68 for ; Thu, 26 Jul 2018 11:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1532628196; x=2396541796; 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=Uwi1+CwlGrQKr/TIArtAeEtbMZzIkPw0q4ykDM4Waxo=; b=ZAIZWoSTOIi6F+Flgn34g4Eaw7Up51jE80Aqau1Z2WV42a0vvovV2SP6AbBbStbt wJIKS8bmxs0LnNmnDdoI6D6VlHMkS82vWoQsJzh5l00uVFkMhJ5i3LeP0SWBpbYt 3b9UO3rGxEptG/Xew9oTnwqutQCxtPuuAOdjz8xrkIiNkZflE+W4KMumtuyBEF5m 3MCFTA/JN0d3+B81Le6pAIzq0m4O5UaCFZWDkH0EV+ypnHuoI0n0yPUwxjMZmqmx oOuwDBw0cZqVDuv78U9U0rn5DdM+P5r6w6s4/oAAtA5Al2QyyI1yZNlS5jmIokIl zqTI9eKQUnxg8l5fsh0A6w==; X-AuditID: 11ab0219-557ff70000004c1b-c6-5b5a0ce3bf91 Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in25.apple.com (Apple Secure Mail Relay) with SMTP id 86.48.19483.4EC0A5B5; Thu, 26 Jul 2018 11:03:16 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from ma1-mmpp-sz10.apple.com (ma1-mmpp-sz10.apple.com [17.171.128.150]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PCH00KGYJHFFDD0@mr2-mtap-s03.rno.apple.com>; Thu, 26 Jul 2018 11:03:15 -0700 (PDT) Received: from process_viserion-daemon.ma1-mmpp-sz10.apple.com by ma1-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PCH00700ITQP600@ma1-mmpp-sz10.apple.com>; Thu, 26 Jul 2018 11:03:15 -0700 (PDT) X-Va-A: X-Va-T-CD: 00a40c71fc5dc0f0d6f171b945617ad8 X-Va-E-CD: 3bbd785c51ace3f981efd92bc4e82048 X-Va-R-CD: 2b9cdb0e57a359d759a3675f8c35d2a7 X-Va-CD: 0 X-Va-ID: 4b20f50c-bb0e-4db5-8498-761650181f2d X-V-A: X-V-T-CD: 00a40c71fc5dc0f0d6f171b945617ad8 X-V-E-CD: 3bbd785c51ace3f981efd92bc4e82048 X-V-R-CD: 2b9cdb0e57a359d759a3675f8c35d2a7 X-V-CD: 0 X-V-ID: 6706c0ef-b734-4147-a2fd-bfa7cf5222d1 Received: from process_milters-daemon.ma1-mmpp-sz10.apple.com by ma1-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PCH00700ISBED00@ma1-mmpp-sz10.apple.com>; Thu, 26 Jul 2018 11:03:13 -0700 (PDT) Received: from localhost ([17.192.155.217]) by ma1-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PCH00JYDJHC9X80@ma1-mmpp-sz10.apple.com>; Thu, 26 Jul 2018 11:03:13 -0700 (PDT) Sender: cpaasch@apple.com Date: Thu, 26 Jul 2018 11:03:12 -0700 From: Christoph Paasch To: philip.eardley@bt.com Cc: multipathtcp@ietf.org Message-id: <20180726180312.GA4863@MacBook-Pro-19.local> References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> <20180715201445.GU1471@MacBook-Pro-19.local> In-reply-to: User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKIsWRmVeSWpSXmKPExsUiuPlRu+4Tnqhog3Md/BafV19ns1i2dgWj A5NH25fJTB5LlvxkCmCK4rJJSc3JLEst0rdL4MrY/uwyS8Fkpoo7L8+wNjC+ZOxi5OCQEDCR mNKY0sXIxSEkcJBJ4vafjcxdjJwcvAKCEj8m32MBqWEWkJc4eF4WJMwsIC3x6O8MdghbS+L7 o1YWiN71TBJ9835BOV1MEv3dn9hAqiQE2CX+/NrBAmFrSzx79pkdxv67fAacfeD3Xah6LokF W0+zQti6EpvOPYXqZZNYf2IJE4StJdH4uIsZxr72ZiIrjH37/keoOKfE+S8ToebrSHw+cJ0N 4rhOJokjs7qgLm1ikljz+B3YVGEBSYnuO3fAulkEVCU2ty8E62YDmvr2djvYBhGgmhXbV7FB /A9k//3ECtHrIfH88lx2SNBZSGzuv8sKsWAms8T+bWfAFnAKhEsc/DEf7B1RAWWJA9uOM01g VJiFFNyzEME9Cym4ZyEF9wJGllWMwrmJmTm6mXlGpnqJBQU5qXrJ+bmbGEHpYjWT5A7Gr68N DzEKcDAq8fD+eBEZLcSaWFZcmXuIUZqDRUmc9+MusWghgfTEktTs1NSC1KL4otKc1OJDjEwc nFINjJs8ufjPnlmxZaOw3t1Dnw62VLu87rg+bati0rIf/EUK8Wp7K+z7uooF+U22MR9h2ee9 /ZI+2132/SJLPwo3PgwO8jT/37riWuKiWIVsHqm729uDn3y8XGiSn3Zia7lMm4ndabeCZYdm 2aXtmu6xZvddQckZD3le8VVrX8n5fISBM/yHYkzfCSWW4oxEQy3mouJEAC4xDWv4AgAA Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 18:03:20 -0000 On 19/07/18 - 20:14:42, philip.eardley@bt.com wrote: > A small one - S1.5 requirements language - there is new text to use, see https://tools.ietf.org/html/rfc8174 Updated it - cfr.: https://github.com/multipath-tcp/draft-ietf-mptcp-rfc6824bis/pull/14 Christoph From nobody Sat Jul 28 00:38:18 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D1E130DDC for ; Sat, 28 Jul 2018 00:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 O2_8b8bXEMRj for ; Sat, 28 Jul 2018 00:38:14 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B454B120049 for ; Sat, 28 Jul 2018 00:38:14 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 12A02F704DBC5 for ; Sat, 28 Jul 2018 08:38:09 +0100 (IST) Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.399.0; Sat, 28 Jul 2018 08:38:10 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.4]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0382.000; Sat, 28 Jul 2018 13:08:01 +0530 From: Rahul Arvind Jadhav To: "multipathtcp@ietf.org" Thread-Topic: 6824bis -11 review Thread-Index: AdQmJDYhfu15UAaeTxKUY+EC058bGg== Date: Sat, 28 Jul 2018 07:38:00 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DC5A15C@BLREML503-MBX.china.huawei.com> Accept-Language: en-IN, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.157.44] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [multipathtcp] 6824bis -11 review X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 07:38:17 -0000 Hi, As promised in IETF102, here is my review for 6824bis-11. As Phil had sugg= ested, I didn't take the trouble to check if my comments overlap with any o= f the previous discussions/comments.=20 1. Section 3.6: Subflow Reset [RJ]: Is MP_TCPRST a SHOULD or MUST to be included along with the TCP_RST ?= Can this be stated explicitly in section 3.6? 2. Section 3.4.2. Remove Address "The sending and receipt (if no keepalive response was received) of this message SHOULD trigger the sending of RSTs by both hosts on the affected subflow(s) " [RJ]: Since a MP_TCPRST should be associated with this RST, what should be = the corresponding Reason Code that can be used in MP_TCPRST for this case? = I checked existing reason codes in section 3.6 and none of those made sense= (may be except for 0x0 ?). 3. Section 3.4.1. Address Advertisement=20 "A host can send an ADD_ADDR message with an already assigned Address ID, but the Address MUST be the same as previously assigned to this Address ID, and the Port MUST be different from one already in use for this Address ID." [RJ]: Didn't understand the rationale for allowing reuse of Address ID only= for port change and not for IP change. 4. Section 3.4.1. Address Advertisement [RJ]: For long-lived MPTCP connection, the ADD_ADDR needs to be resent if t= he sub-flow is closed and if it needs to be reopened in the future. Is this= correct? The reason for me to believe this is, if REMOVE_ADDR is sent and = if the sub-flow is active/functioning, then the REMOVE_ADDR will be ignored= . This means that when the sub-flow is closed, the corresponding Address ID= is removed. Thus it means to establish a new sub-flow from the peer an ADD= _ADDR has to be sent. 5. passive opener [RJ]: The term "passive opener" is used several times in the document. This= term needs to be clarified in Terminology section. 6. Section 3 Figure 3 [RJ]: Length field in figure 3 encompasses Kind, Length and Option payload.= This should be explicitly stated. 7. Section 3.1 says: "it is expected that A will have generated a key local= ly before the initial SYN"=20 [RJ]: Is there any advantage of generating the key in advance? The key gene= ration can be avoided by A if node B responds without MP_CAPABLE. Can this = be left to the implementation? 8. Section 3.2 says: The MP_JOIN option includes an "Address ID". This is = an identifier that only has significance within a single connection, [RJ]: The significance of "Address ID" is only within the connection and __= only on the peer__ who generates the ID. Is this correct?=20 9. Section 3.3 says: M =3D Data Sequence Number (DSN), Subflow Sequence Num= ber (SSN), Data-Level Length, and Checksum present [RJ]: and Checksum present (if negotiated) 10. [RJ]: Can an attacker spoof MP_FAIL option to the receiver with DSN=3D0= (infinite mapping)? This will cause the receiver to discard all the data f= ollowing DSN and the failed data won't be DATA_ACKed. Is there any way to p= rotect this? 11. [RJ]: I was hoping to find a section in the introduction which summariz= es changes in v1. This could be of help for someone who aims to migrate/und= erstand briefly the implications of switching to v1.=20 ------------Editorials: Section 2.7: Currently: "To meet the threats identified in ..." Should be: "To address the threats identified in ..." Section 2.7: Currently: "keys are sent in the clear in the MP_CAPABLE messages" Should be: "keys are sent in clear in the MP_CAPABLE messages" Section 3.1: Spellfix: requsted -> requested Spellfix: wishs -> wishes Section 3.1: Currently: "The key MUST be hard to guess, and it MUST be unique for the se= nding host at any one time." Should be: "The key MUST be hard to guess, and it MUST be unique for the se= nding host across all MPTCP connections." Section 3.1: Currently: "there is not a collision" Should be: "there is no collision" Section 3.1: Currently: "The receiver will acknowledge this data a the connection" Should be: "The receiver will acknowledge this data at the connection" Section 3.4.1: Spellfix: assinged -> assigned Section 3.6: Currently: "Regular TCP RST options remain used to at the subflow-level" Should be: "Regular TCP RST options continue to be used at the subflow-leve= l" Section 3.6: Spellfix: re-estbalish -> re-establish Spellfix: ressources -> resources Section 3.6: Currently: "It would be beneficial for a host to the reasons ..." Should be: "It would be beneficial for a host to provide the reasons ..." From nobody Sat Jul 28 10:19:24 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A89E130DF3 for ; Sat, 28 Jul 2018 10:19:24 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bf9PVz2pdmYk for ; Sat, 28 Jul 2018 10:19:21 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 293BF130DE9 for ; Sat, 28 Jul 2018 10:19:21 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id p6-v6so7040061ljc.5 for ; Sat, 28 Jul 2018 10:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bf4oKDfEdZ4NJra0INkzMa+goOHLp/60pI2dO+3pt+k=; b=A56ycE1NZPu3duoMEatGvm55FdLeLKrlGGXAVNIZyFJwvxgf97Fgz0acpzYGyEVwQV KiK2b7TqBxduaSZtxTfIF8PMoAmZCftgoh9N3IDfpO9qlXtN9ICkMvT3c5pnbLmTbHVd 9KeWtU2JH0cR/SLrOSxLT8HOHTMLRYBXvPFuHJ3dWd+eoQlpACYtkhSdQTRC/kBsPpGA 2oLyk8ikZlLgPzHLapTvtrFoXrNdD+TpziKH5FSwLaCyM3fH0NAuXns1/JJHHKQVKacW b3rRNE9UxV7z+mR6f5+Ce4XTtJ17I5rtFuwK4uLVYA/mrNZzd/b7olJEPBe5ZmA1Gslh /kkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bf4oKDfEdZ4NJra0INkzMa+goOHLp/60pI2dO+3pt+k=; b=Q+nadehvydyejxlgXpGwH8b65SrtVzlvWRJH7pvpjG9aq/Arwx3qTzH6SKafxmPiMn dN5Ek0ZaS8BB+/vM3HKHfkIAf8a4vfJedCl5RgGzUt/pd3vE1TleO3YlVFggdG51OeTr xm8XdtmN1Yq8hYWnHFe7i0lxd8KB5QhiVL61yHNmGCCSWeepzAcxoTzEcQoeuNCHwQnx xhrS53Bz5uXRHhY2Eg9J5A5G2vhPXfJayXAjkGbrUaxCtYqA2yv0kSqNHDg0xB5hze8x rOeRdTi+V1SkMij47DVcGhDSPdGAyo2ZD2STBYQIsNlEL7S8F9EhvX1yvFRS963S+VQf f8sA== X-Gm-Message-State: AOUpUlG8May0J/ww8lFQh6t3Z3JYkY4eaDR6qXrT6DzzkI//cnbn669U 4ZQNLdgui1hEbey9L+XbF/Y= X-Google-Smtp-Source: AAOMgpfTqE3lBMCvji2HygFZ7mM4xRwneuKsamL1jq121xhZVkpjeS8PPqQat0K8tsfGg9g4US2umA== X-Received: by 2002:a2e:944:: with SMTP id 65-v6mr8077833ljj.30.1532798359331; Sat, 28 Jul 2018 10:19:19 -0700 (PDT) Received: from [192.168.1.66] ([83.216.157.78]) by smtp.gmail.com with ESMTPSA id g2-v6sm958874lfb.52.2018.07.28.10.19.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Jul 2018 10:19:18 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alan Ford In-Reply-To: <982B626E107E334DBE601D979F31785C5DC5A15C@BLREML503-MBX.china.huawei.com> Date: Sat, 28 Jul 2018 18:19:16 +0100 Cc: multipathtcp Content-Transfer-Encoding: quoted-printable Message-Id: <92A53501-4728-4E02-816A-92CEE703AA49@gmail.com> References: <982B626E107E334DBE601D979F31785C5DC5A15C@BLREML503-MBX.china.huawei.com> To: Rahul Arvind Jadhav X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [multipathtcp] 6824bis -11 review X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 17:19:24 -0000 Hi Rahul, Thank you very much indeed for this review. > On 28 Jul 2018, at 08:38, Rahul Arvind Jadhav = wrote: >=20 > Hi, >=20 > As promised in IETF102, here is my review for 6824bis-11. As Phil had = suggested, I didn't take the trouble to check if my comments overlap = with any of the previous discussions/comments.=20 >=20 > 1. Section 3.6: Subflow Reset > [RJ]: Is MP_TCPRST a SHOULD or MUST to be included along with the = TCP_RST ? Can this be stated explicitly in section 3.6? It=E2=80=99s a MAY :) We say: "These semantics are carried in the MP_TCPRST option that can be = included on a TCP RST packet.=E2=80=9D We should change that to =E2=80=9CMAY be included=E2=80=9D. > 2. Section 3.4.2. Remove Address > "The sending and receipt (if no keepalive response was received) of > this message SHOULD trigger the sending of RSTs by both hosts on the > affected subflow(s) " > [RJ]: Since a MP_TCPRST should be associated with this RST, what = should be the corresponding Reason Code that can be used in MP_TCPRST = for this case? I checked existing reason codes in section 3.6 and none = of those made sense (may be except for 0x0 ?). That=E2=80=99s an interesting one. There may be some benefit (maybe for = middleboxes, or maybe for security) to sharing this information in the = RST with an explicit reason code. We could add one - but I would be = interested in hearing other opinions. > 3. Section 3.4.1. Address Advertisement=20 > "A host can send an ADD_ADDR message with an already assigned = Address > ID, but the Address MUST be the same as previously assigned to this > Address ID, and the Port MUST be different from one already in use > for this Address ID." > [RJ]: Didn't understand the rationale for allowing reuse of Address ID = only for port change and not for IP change. I cannot recall the rationale here either. Furthermore - as written - this would seem to prevent retransmission. = Which is crazy. If nobody can recall the reason for this I would suggest we remove it. > 4. Section 3.4.1. Address Advertisement > [RJ]: For long-lived MPTCP connection, the ADD_ADDR needs to be resent = if the sub-flow is closed and if it needs to be reopened in the future. = Is this correct? No. Unless an Address + ID has been explicitly removed, it remains = valid. > The reason for me to believe this is, if REMOVE_ADDR is sent and if = the sub-flow is active/functioning, then the REMOVE_ADDR will be = ignored. This means that when the sub-flow is closed, the corresponding = Address ID is removed. Thus it means to establish a new sub-flow from = the peer an ADD_ADDR has to be sent. Hmm. That=E2=80=99s not the intention, but I appreciate things are not = completely clear. We say: The receipt of REMOVE_ADDR SHOULD first trigger the sending of a TCP keepalive [RFC1122] on the path, and if a response is received the path SHOULD NOT be removed. So if REMOVE_ADDR is received for an already-active path, the intention = is that it should be silently ignored. I appreciate this does not explicitly state the logical next step from = this. My first thought was that the Address ID and address in the table = are still active, so if the subflow later was terminated, the far end = would be legitimately able to re-establish it. But that might not be = best. I=E2=80=99m not immediately sure what=E2=80=99s best here for = clarification. Either: a) state that if the REMOVE_ADDR is ignored, the address remains active = in the table for the remainder of the MPTCP connection; b) state that if the REMOVE_ADDR is ignored, the subflow remains active = but the address is removed from the table for any future connections. This is to cover a corner case which should never happen, of course. I = think option b is probably best. > 5. passive opener > [RJ]: The term "passive opener" is used several times in the document. = This term needs to be clarified in Terminology section Thank you. We got told off for =E2=80=9Cserver=E2=80=9D in the early = days, hence why that appeared. You are right we need to be consistent. > 6. Section 3 Figure 3 > [RJ]: Length field in figure 3 encompasses Kind, Length and Option = payload. This should be explicitly stated. That is explicitly stated in the RFC793 definition of TCP options. = However, I see no harm in repeating it here. > 7. Section 3.1 says: "it is expected that A will have generated a key = locally before the initial SYN"=20 > [RJ]: Is there any advantage of generating the key in advance? The key = generation can be avoided by A if node B responds without MP_CAPABLE. = Can this be left to the implementation? I think so yes. This is probably just a hangover from MPTCP v0, and is = definitely an implementation detail. > 8. Section 3.2 says: The MP_JOIN option includes an "Address ID". = This is an identifier that only has significance within a single = connection, > [RJ]: The significance of "Address ID" is only within the connection = and __only on the peer__ who generates the ID. Is this correct?=20 Yes. We can clarify. > 9. Section 3.3 says: M =3D Data Sequence Number (DSN), Subflow = Sequence Number (SSN), Data-Level Length, and Checksum present > [RJ]: and Checksum present (if negotiated) Thank you. > 10. [RJ]: Can an attacker spoof MP_FAIL option to the receiver with = DSN=3D0 (infinite mapping)? This will cause the receiver to discard all = the data following DSN and the failed data won't be DATA_ACKed. Is there = any way to protect this? MP_FAIL DSN must be within the DSN window. > 11. [RJ]: I was hoping to find a section in the introduction which = summarizes changes in v1. This could be of help for someone who aims to = migrate/understand briefly the implications of switching to v1.=20 One has been circulated on the list; it could be included in an = Appendix. > ------------Editorials: > Section 2.7: > Currently: "To meet the threats identified in ..." > Should be: "To address the threats identified in ..." >=20 > Section 2.7: > Currently: "keys are sent in the clear in the MP_CAPABLE messages" > Should be: "keys are sent in clear in the MP_CAPABLE messages" >=20 > Section 3.1: > Spellfix: requsted -> requested > Spellfix: wishs -> wishes >=20 > Section 3.1: > Currently: "The key MUST be hard to guess, and it MUST be unique for = the sending host at any one time." > Should be: "The key MUST be hard to guess, and it MUST be unique for = the sending host across all MPTCP connections." >=20 > Section 3.1: > Currently: "there is not a collision" > Should be: "there is no collision" >=20 > Section 3.1: > Currently: "The receiver will acknowledge this data a the connection" > Should be: "The receiver will acknowledge this data at the connection" >=20 > Section 3.4.1: > Spellfix: assinged -> assigned >=20 > Section 3.6: > Currently: "Regular TCP RST options remain used to at the = subflow-level" > Should be: "Regular TCP RST options continue to be used at the = subflow-level" >=20 > Section 3.6: > Spellfix: re-estbalish -> re-establish > Spellfix: ressources -> resources >=20 > Section 3.6: > Currently: "It would be beneficial for a host to the reasons ..." > Should be: "It would be beneficial for a host to provide the reasons = =E2=80=A6" Thank you again for all this feedback. Best regards, Alan From nobody Sat Jul 28 11:09:09 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEB9130DD3 for ; Sat, 28 Jul 2018 11:09:07 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 WhhFOOk_vlW0 for ; Sat, 28 Jul 2018 11:09:06 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 8200812D7F8 for ; Sat, 28 Jul 2018 11:09:05 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id f18-v6so5589297lfc.2 for ; Sat, 28 Jul 2018 11:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Q3JI+JsjT+h8z06+5iVLyd780wLPC2yknmIqSbUcvSo=; b=C6vPVYEQdYWGhq46J6rmINfCEl9oSL5wyWohZcv3B/nznt7VWCe7or7pFWSZDheT1x 0QtFx5RTIIqNLMW1i5ltGdA6D0u6meEyL/4bMIXWwmVUCLGk69MKgHopum4M5ZoLSbOl HSsfjoTtN0UfYaKrnRET6hH2pGKCkxKO4RUe4BjH5iibVA+cInle8UReQuBbi6TG8gG9 Uq9QiP+0a7KoI8kmmOk+wiVCO2OX7MkkZ0zl4vUguA4mHt5GKu1eRuwtPNVYJwGMqUJV j3OGqpfgC9WIrzYsbqYLCP+GcnJ7bIwmgJGL6jtkDpJe1xxv53gCOZZMX4MCb9ny++25 fU6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Q3JI+JsjT+h8z06+5iVLyd780wLPC2yknmIqSbUcvSo=; b=nFG6ek0+WZRtr9Ft8zaSqb+IbifNK2oJmMc1/CIPJn135M5LPMpHsz7n8BWGhCj69X +L4YT73lemxVnUIMKSHpyy8t3YyLZJAcf7b5AqnW1/X1a/DE7o3fGgIPQIq82NoCFBOe 97ZtqfusOlyPc7ug9yhKSIilQNWHg8pboixShZybI3sHQbby/2WPGNRSFPGwQ+ah2Z1m 6fY4tr0nH5G+CmnoI1ntNBgs0aviZ5GG5AuMaoumK7GWWY+oSNEIKGqXfvTrsZ9rSIxn ugSXKF5jJwOve4Rr/gjpNm1xgmPx7VR0ou2k7yCFrHPhkP2I91fXvDZ7wTtfEsQZE1yk IUEQ== X-Gm-Message-State: AOUpUlHX8InARSeuPt5beZU+/StZhT4hCuxCO25rLQ1whG4Z3Dbj2o4n YVpIhMUt2rF2XiiC/VH8wLs= X-Google-Smtp-Source: AAOMgpdb/NZ1QUkGjnxIk7U8onYPLBJGYrUUp6kPorYLgCFi5xqMF6Yq5AfzZVU2ZVEaO9y+l9VlNA== X-Received: by 2002:a19:ca09:: with SMTP id a9-v6mr6500686lfg.142.1532801343715; Sat, 28 Jul 2018 11:09:03 -0700 (PDT) Received: from [192.168.1.66] ([83.216.157.78]) by smtp.gmail.com with ESMTPSA id h4-v6sm938291lfj.69.2018.07.28.11.09.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Jul 2018 11:09:02 -0700 (PDT) From: Alan Ford Message-Id: <20754FD9-627F-4AAC-A1B5-6EF2BD09B2AD@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4C9FE40A-1C2A-4A84-8EF3-58CA7012110E" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 28 Jul 2018 19:09:00 +0100 In-Reply-To: <92A53501-4728-4E02-816A-92CEE703AA49@gmail.com> Cc: multipathtcp To: Rahul Arvind Jadhav References: <982B626E107E334DBE601D979F31785C5DC5A15C@BLREML503-MBX.china.huawei.com> <92A53501-4728-4E02-816A-92CEE703AA49@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [multipathtcp] 6824bis -11 review X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 18:09:08 -0000 --Apple-Mail=_4C9FE40A-1C2A-4A84-8EF3-58CA7012110E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Addendum... > On 28 Jul 2018, at 18:19, Alan Ford wrote: >=20 >> 3. Section 3.4.1. Address Advertisement=20 >> "A host can send an ADD_ADDR message with an already assigned = Address >> ID, but the Address MUST be the same as previously assigned to this >> Address ID, and the Port MUST be different from one already in use >> for this Address ID." >> [RJ]: Didn't understand the rationale for allowing reuse of Address = ID only for port change and not for IP change. >=20 > I cannot recall the rationale here either. >=20 > Furthermore - as written - this would seem to prevent retransmission. = Which is crazy. >=20 > If nobody can recall the reason for this I would suggest we remove it. Having looked at the text again here, I think I can recall the = rationale. But we need to consider whether this is actually the intended = behaviour. Address ID was originally designed to provide a mechanism whereby a = client behind a NAT could refer to its address without using the IP = address, which would be altered by the NAT. This would allow a client, = whose wifi interface had disappeared, to tell the far end over its = cellular interface that it had gone, by referring to the Address ID it = had used in the MP_JOIN, in the REMOVE_ADDR. There is a secondary use here which I realise we haven=E2=80=99t = explicitly stated. If a client declared its private address in ADD_ADDR, = but also sent a MP_JOIN with the same address ID, but naturally a = different address, the far end would say =E2=80=9Cah, these addresses = don=E2=80=99t match, so I should not bother attempting to connect to the = Address in the ADD_ADDR=E2=80=9D. This is an optimisation but one that = should probably be mentioned. So the point is that Address ID refers purely to the address, and not to = the address + port pair. Therefore a new port can be advertised in a new = ADD_ADDR using the same Address ID. So we should clarify this: a) retransmitting an ADD_ADDR with same ID, address, and port is fine b) this could permit the far end to trigger another connection attempt c) sending a new ADD_ADDR with same ID + address and different port is = fine d) to reassign an address ID you must first REMOVE_ADDR Regards, Alan= --Apple-Mail=_4C9FE40A-1C2A-4A84-8EF3-58CA7012110E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Addendum...

On 28 Jul 2018, at 18:19, Alan = Ford <alan.ford@gmail.com> wrote:

3. = Section 3.4.1. Address Advertisement 
 "A = host can send an ADD_ADDR message with an already assigned Address
 ID, but the Address MUST be the same as previously = assigned to this
 Address ID, and the Port MUST be = different from one already in use
 for this Address = ID."
[RJ]: Didn't understand the rationale for allowing = reuse of Address ID only for port change and not for IP change.

I cannot recall the rationale here either.

Furthermore - as written - this = would seem to prevent retransmission. Which is crazy.

If nobody can recall the reason = for this I would suggest we remove it.

Having looked at the text again here, I think I can = recall the rationale. But we need to consider whether this is actually = the intended behaviour.

Address ID = was originally designed to provide a mechanism whereby a client behind a = NAT could refer to its address without using the IP address, which would = be altered by the NAT. This would allow a client, whose wifi interface = had disappeared, to tell the far end over its cellular interface that it = had gone, by referring to the Address ID it had used in the MP_JOIN, in = the REMOVE_ADDR.

There is a = secondary use here which I realise we haven=E2=80=99t explicitly stated. = If a client declared its private address in ADD_ADDR, but also sent a = MP_JOIN with the same address ID, but naturally a different address, the = far end would say =E2=80=9Cah, these addresses don=E2=80=99t match, so I = should not bother attempting to connect to the Address in the = ADD_ADDR=E2=80=9D. This is an optimisation but one that should probably = be mentioned.

So the point is that = Address ID refers purely to the address, and not to = the address + port pair. Therefore a new port can be advertised in a new = ADD_ADDR using the same Address ID.

So= we should clarify this:

a) = retransmitting an ADD_ADDR with same ID, address, and port is = fine
b) this could permit the far end to trigger another = connection attempt
c) sending a new ADD_ADDR with same ID + = address and different port is fine
d) to reassign an address = ID you must first REMOVE_ADDR

Regards,
Alan
= --Apple-Mail=_4C9FE40A-1C2A-4A84-8EF3-58CA7012110E-- From nobody Sat Jul 28 20:17:45 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971E5130934 for ; Sat, 28 Jul 2018 20:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 fYKFL9U8YRig for ; Sat, 28 Jul 2018 20:17:41 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 201671294D7 for ; Sat, 28 Jul 2018 20:17:41 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 026AF3A3ABA22 for ; Sun, 29 Jul 2018 04:17:37 +0100 (IST) Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Sun, 29 Jul 2018 04:17:37 +0100 Received: from BLREML503-MBS.china.huawei.com ([169.254.12.219]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0399.000; Sun, 29 Jul 2018 08:47:24 +0530 From: Rahul Arvind Jadhav To: Alan Ford CC: multipathtcp Thread-Topic: [multipathtcp] 6824bis -11 review Thread-Index: AdQmJDYhfu15UAaeTxKUY+EC058bGgARMycAAAG8pgAAHRK/4A== Date: Sun, 29 Jul 2018 03:17:24 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DC5D84B@BLREML503-MBS.china.huawei.com> References: <982B626E107E334DBE601D979F31785C5DC5A15C@BLREML503-MBX.china.huawei.com> <92A53501-4728-4E02-816A-92CEE703AA49@gmail.com> <20754FD9-627F-4AAC-A1B5-6EF2BD09B2AD@gmail.com> In-Reply-To: <20754FD9-627F-4AAC-A1B5-6EF2BD09B2AD@gmail.com> Accept-Language: en-IN, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.157.44] Content-Type: multipart/alternative; boundary="_000_982B626E107E334DBE601D979F31785C5DC5D84BBLREML503MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [multipathtcp] 6824bis -11 review X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2018 03:17:44 -0000 --_000_982B626E107E334DBE601D979F31785C5DC5D84BBLREML503MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEFsYW4gZm9yIGNsYXJpZnlpbmcuDQpCdXQgSeKAmW0gc3RpbGwgbm90IGNsZWFyIGFi b3V0IHRoaXMuIFBsZWFzZSBmaW5kIG15IGNvbW1lbnRzIFtSSl0gaW5saW5lLg0KDQpPbiAyOCBK dWwgMjAxOCwgYXQgMTg6MTksIEFsYW4gRm9yZCA8YWxhbi5mb3JkQGdtYWlsLmNvbTxtYWlsdG86 YWxhbi5mb3JkQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQoNCjMuIFNlY3Rpb24gMy40LjEuIEFkZHJl c3MgQWR2ZXJ0aXNlbWVudA0KICJBIGhvc3QgY2FuIHNlbmQgYW4gQUREX0FERFIgbWVzc2FnZSB3 aXRoIGFuIGFscmVhZHkgYXNzaWduZWQgQWRkcmVzcw0KIElELCBidXQgdGhlIEFkZHJlc3MgTVVT VCBiZSB0aGUgc2FtZSBhcyBwcmV2aW91c2x5IGFzc2lnbmVkIHRvIHRoaXMNCiBBZGRyZXNzIElE LCBhbmQgdGhlIFBvcnQgTVVTVCBiZSBkaWZmZXJlbnQgZnJvbSBvbmUgYWxyZWFkeSBpbiB1c2UN CiBmb3IgdGhpcyBBZGRyZXNzIElELiINCltSSl06IERpZG4ndCB1bmRlcnN0YW5kIHRoZSByYXRp b25hbGUgZm9yIGFsbG93aW5nIHJldXNlIG9mIEFkZHJlc3MgSUQgb25seSBmb3IgcG9ydCBjaGFu Z2UgYW5kIG5vdCBmb3IgSVAgY2hhbmdlLg0KDQpJIGNhbm5vdCByZWNhbGwgdGhlIHJhdGlvbmFs ZSBoZXJlIGVpdGhlci4NCg0KRnVydGhlcm1vcmUgLSBhcyB3cml0dGVuIC0gdGhpcyB3b3VsZCBz ZWVtIHRvIHByZXZlbnQgcmV0cmFuc21pc3Npb24uIFdoaWNoIGlzIGNyYXp5Lg0KDQpJZiBub2Jv ZHkgY2FuIHJlY2FsbCB0aGUgcmVhc29uIGZvciB0aGlzIEkgd291bGQgc3VnZ2VzdCB3ZSByZW1v dmUgaXQuDQoNCkhhdmluZyBsb29rZWQgYXQgdGhlIHRleHQgYWdhaW4gaGVyZSwgSSB0aGluayBJ IGNhbiByZWNhbGwgdGhlIHJhdGlvbmFsZS4gQnV0IHdlIG5lZWQgdG8gY29uc2lkZXIgd2hldGhl ciB0aGlzIGlzIGFjdHVhbGx5IHRoZSBpbnRlbmRlZCBiZWhhdmlvdXIuDQoNCkFkZHJlc3MgSUQg d2FzIG9yaWdpbmFsbHkgZGVzaWduZWQgdG8gcHJvdmlkZSBhIG1lY2hhbmlzbSB3aGVyZWJ5IGEg Y2xpZW50IGJlaGluZCBhIE5BVCBjb3VsZCByZWZlciB0byBpdHMgYWRkcmVzcyB3aXRob3V0IHVz aW5nIHRoZSBJUCBhZGRyZXNzLCB3aGljaCB3b3VsZCBiZSBhbHRlcmVkIGJ5IHRoZSBOQVQuIFRo aXMgd291bGQgYWxsb3cgYSBjbGllbnQsIHdob3NlIHdpZmkgaW50ZXJmYWNlIGhhZCBkaXNhcHBl YXJlZCwgdG8gdGVsbCB0aGUgZmFyIGVuZCBvdmVyIGl0cyBjZWxsdWxhciBpbnRlcmZhY2UgdGhh dCBpdCBoYWQgZ29uZSwgYnkgcmVmZXJyaW5nIHRvIHRoZSBBZGRyZXNzIElEIGl0IGhhZCB1c2Vk IGluIHRoZSBNUF9KT0lOLCBpbiB0aGUgUkVNT1ZFX0FERFIuDQoNClRoZXJlIGlzIGEgc2Vjb25k YXJ5IHVzZSBoZXJlIHdoaWNoIEkgcmVhbGlzZSB3ZSBoYXZlbuKAmXQgZXhwbGljaXRseSBzdGF0 ZWQuIElmIGEgY2xpZW50IGRlY2xhcmVkIGl0cyBwcml2YXRlIGFkZHJlc3MgaW4gQUREX0FERFIs IGJ1dCBhbHNvIHNlbnQgYSBNUF9KT0lOIHdpdGggdGhlIHNhbWUgYWRkcmVzcyBJRCwgYnV0IG5h dHVyYWxseSBhIGRpZmZlcmVudCBhZGRyZXNzLCB0aGUgZmFyIGVuZCB3b3VsZCBzYXkg4oCcYWgs IHRoZXNlIGFkZHJlc3NlcyBkb27igJl0IG1hdGNoLCBzbyBJIHNob3VsZCBub3QgYm90aGVyIGF0 dGVtcHRpbmcgdG8gY29ubmVjdCB0byB0aGUgQWRkcmVzcyBpbiB0aGUgQUREX0FERFLigJ0uIFRo aXMgaXMgYW4gb3B0aW1pc2F0aW9uIGJ1dCBvbmUgdGhhdCBzaG91bGQgcHJvYmFibHkgYmUgbWVu dGlvbmVkLg0KDQpbUkpdIFRoZSBmYXIgZW5kIGhlcmUgbWF0Y2hlcyB0aGUgQWRkcmVzcyBJRCwg aWRlbnRpZmllcyB0aGUgQUREX0FERFIgY29udGV4dCwgYW5kIHVzZXMgdGhlIHJlY2VpdmVkIHNv dXJjZSBhZGRyZXNzIC4uIE1heSBiZSB0aGUgZmFyIGVuZCBzaG91bGQga2VlcCB0aGlzIG5ld2x5 IGxlYXJudCBJUCBhZGRyZXNzIHdpdGhpbiB0aGUgQUREX0FERFIgY29udGV4dCBmb3IgZnV0dXJl IE1QX0pPSU4gb25jZSB0aGlzIHN1Yi1mbG93IGNsb3Nlcz8gQXMgSSB1bmRlcnN0YW5kLCBBZGRy ZXNzIElEIGFsb25lIGlzIHRoZSBwcmltYXJ5LWtleSBmb3IgbWF0Y2hpbmcgYW55d2F5cy4NCg0K U28gdGhlIHBvaW50IGlzIHRoYXQgQWRkcmVzcyBJRCByZWZlcnMgcHVyZWx5IHRvIHRoZSBhZGRy ZXNzLCBhbmQgbm90IHRvIHRoZSBhZGRyZXNzICsgcG9ydCBwYWlyLiBUaGVyZWZvcmUgYSBuZXcg cG9ydCBjYW4gYmUgYWR2ZXJ0aXNlZCBpbiBhIG5ldyBBRERfQUREUiB1c2luZyB0aGUgc2FtZSBB ZGRyZXNzIElELg0KDQpbUkpdIEnigJltIG5vdCBzdXJlIGFib3V0IHRoaXMgaW50ZXJwcmV0YXRp b24uIE15IHRoaW5raW5nIHdhcyB0aGF0IEFkZHJlc3MgSUQgcmVmZXJzIHB1cmVseSB0byB0aGUg c3ViLWZsb3cgcG9zc2liaWxpdHkgb24gYW4gaW50ZXJmYWNlIHdpdGhvdXQgYW55IGRlcGVuZGVu Y2Ugb24gYWRkcmVzcyArIHBvcnQuIEFkZHJlc3MgYW5kIHBvcnQgYXJlIHBhcmFtZXRlcnMgZm9y IHRoZSBBZGRyZXNzIElEIHdoaWNoIG1pZ2h0IHBvc3NpYmx5IGNoYW5nZSBpbiB0aGUgZnV0dXJl Lg0KDQpTbyB3ZSBzaG91bGQgY2xhcmlmeSB0aGlzOg0KDQphKSByZXRyYW5zbWl0dGluZyBhbiBB RERfQUREUiB3aXRoIHNhbWUgSUQsIGFkZHJlc3MsIGFuZCBwb3J0IGlzIGZpbmUNCmIpIHRoaXMg Y291bGQgcGVybWl0IHRoZSBmYXIgZW5kIHRvIHRyaWdnZXIgYW5vdGhlciBjb25uZWN0aW9uIGF0 dGVtcHQNCltSSl0gYSAmIGIgaXMgY2xlYXIgZnJvbSBleGlzdGluZyB0ZXh0DQoNCmMpIHNlbmRp bmcgYSBuZXcgQUREX0FERFIgd2l0aCBzYW1lIElEICsgYWRkcmVzcyBhbmQgZGlmZmVyZW50IHBv cnQgaXMgZmluZQ0KW1JKXSBhZ2FpbiB0aGlzIGlzIHdoYXQgdGhlIHRleHQgYWxyZWFkeSBzYXlz LCBidXQgSeKAmW0gbm90IHN0aWxsIGNsZWFyIGFib3V0IHRoaXMuIFdoeSBJRCArIGFkZHJlc3Mg aGFzIHRvIG1hdGNoPyBPbmx5IElEIHNob3VsZCBiZSBlbm91Z2guDQoNCmQpIHRvIHJlYXNzaWdu IGFuIGFkZHJlc3MgSUQgeW91IG11c3QgZmlyc3QgUkVNT1ZFX0FERFINCltSSl0gVGhpcyBhbHNv IEkgZG9u4oCZdCBnZXQuIFdoeSBzaG91bGQgaXQgYmUgbmVjZXNzYXJ5IHRvIGRvIGEgUkVNT1ZF X0FERFIgdG8gY2hhbmdlIGFuIElQIGFkZHJlc3MgZm9yIGFuIGV4aXN0aW5nIElEPyBJZiBhIEFE RF9BRERSIHJlZmVycyB0byBhbiBleGlzdGluZyBJRCB3aXRoIGEgbmV3IEFkZHJlc3MgdGhlbiBj YW7igJl0IHRoaXMgc2ltcGx5IG92ZXJyaWRlIHRoZSBJUCBhZGRyZXNzIGZvciB0aGF0IElEPw0K DQpBbm90aGVyIHdheSB0byBwdXQgdGhpcyBxdWVzdGlvbiwgSW4gd2hpY2ggY2FzZSBhIHJlY2Vp dmVyIGFmdGVyIG1hdGNoaW5nIHRoZSBBZGRyZXNzIElEIChmb3IgTVBfSk9JTiBvciBBRERfQURE Uikgd2lsbCBkZXBlbmQgb24gbWF0Y2hpbmcgYWdhaW5zdCB0aGUgYWRkcmVzcyBmaWVsZCBhbmQg d2hhdCBpcyBhY2hpZXZlZCBieSBtYXRjaGluZyB0aGUgYWRkcmVzcyBmaWVsZD8NCg0KQnkgYWxs b3dpbmcgdG8gb3ZlcnJpZGUgYW4gSVAgYWRkcmVzcyBpbiB0aGUgZXhpc3RpbmcgSUQsIGEgUkVN T1ZFX0FERFIgKyBBRERfQUREUiBjeWNsZSB3aGljaCByZXF1aXJlcyBhdC1sZWFzdCBvbmUgUlRU IHdvdWxkIGJlIHNhdmVkLiBTZWNvbmRseSwgdGhlIGltcGxlbWVudGF0aW9uIGJlY29tZXMgbG90 IG1vcmUgc2ltcGxlciAoZm9yIG1lIHRoaXMgaXMgdGhlIG1ham9yIG1vdGl2YXRpb24pLg0KDQpU aGFua3MsDQpSYWh1bA0K --_000_982B626E107E334DBE601D979F31785C5DC5D84BBLREML503MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFn cmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1h cmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJ bWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uYXBw bGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFj ZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXtt c28tbGlzdC1pZDoxODcyNzYxNzg2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczotMjIwMDM2MTI4IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4 NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0 IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDIN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJv bWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0K CXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmln aHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1p bmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1i b3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzIEFsYW4gZm9yIGNsYXJp ZnlpbmcuIDxvOnA+DQo8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkJ1dCBJ4oCZbSBzdGlsbCBub3QgY2xlYXIgYWJvdXQg dGhpcy4gUGxlYXNlIGZpbmQgbXkgY29tbWVudHMgW1JKXSBpbmxpbmUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIDI4IEp1bCAyMDE4LCBhdCAxODoxOSwgQWxhbiBGb3JkICZsdDs8YSBocmVmPSJtYWls dG86YWxhbi5mb3JkQGdtYWlsLmNvbSI+YWxhbi5mb3JkQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjMuIFNlY3Rpb24g My40LjEuIEFkZHJlc3MgQWR2ZXJ0aXNlbWVudDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQombmJzcDsmcXVvdDtBIGhvc3QgY2FuIHNlbmQgYW4g QUREX0FERFIgbWVzc2FnZSB3aXRoIGFuIGFscmVhZHkgYXNzaWduZWQgQWRkcmVzczxicj4NCiZu YnNwO0lELCBidXQgdGhlIEFkZHJlc3MgTVVTVCBiZSB0aGUgc2FtZSBhcyBwcmV2aW91c2x5IGFz c2lnbmVkIHRvIHRoaXM8YnI+DQombmJzcDtBZGRyZXNzIElELCBhbmQgdGhlIFBvcnQgTVVTVCBi ZSBkaWZmZXJlbnQgZnJvbSBvbmUgYWxyZWFkeSBpbiB1c2U8YnI+DQombmJzcDtmb3IgdGhpcyBB ZGRyZXNzIElELiZxdW90Ozxicj4NCltSSl06IERpZG4ndCB1bmRlcnN0YW5kIHRoZSByYXRpb25h bGUgZm9yIGFsbG93aW5nIHJldXNlIG9mIEFkZHJlc3MgSUQgb25seSBmb3IgcG9ydCBjaGFuZ2Ug YW5kIG5vdCBmb3IgSVAgY2hhbmdlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCkkgY2Fubm90 IHJlY2FsbCB0aGUgcmF0aW9uYWxlIGhlcmUgZWl0aGVyLjxicj4NCjxicj4NCkZ1cnRoZXJtb3Jl IC0gYXMgd3JpdHRlbiAtIHRoaXMgd291bGQgc2VlbSB0byBwcmV2ZW50IHJldHJhbnNtaXNzaW9u LiBXaGljaCBpcyBjcmF6eS48YnI+DQo8YnI+DQpJZiBub2JvZHkgY2FuIHJlY2FsbCB0aGUgcmVh c29uIGZvciB0aGlzIEkgd291bGQgc3VnZ2VzdCB3ZSByZW1vdmUgaXQuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhh dmluZyBsb29rZWQgYXQgdGhlIHRleHQgYWdhaW4gaGVyZSwgSSB0aGluayBJIGNhbiByZWNhbGwg dGhlIHJhdGlvbmFsZS4gQnV0IHdlIG5lZWQgdG8gY29uc2lkZXIgd2hldGhlciB0aGlzIGlzIGFj dHVhbGx5IHRoZSBpbnRlbmRlZCBiZWhhdmlvdXIuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BZGRyZXNzIElEIHdhcyBvcmlnaW5hbGx5IGRlc2lnbmVkIHRv IHByb3ZpZGUgYSBtZWNoYW5pc20gd2hlcmVieSBhIGNsaWVudCBiZWhpbmQgYSBOQVQgY291bGQg cmVmZXIgdG8gaXRzIGFkZHJlc3Mgd2l0aG91dCB1c2luZyB0aGUgSVAgYWRkcmVzcywgd2hpY2gg d291bGQgYmUgYWx0ZXJlZCBieSB0aGUgTkFULiBUaGlzIHdvdWxkIGFsbG93IGEgY2xpZW50LCB3 aG9zZSB3aWZpIGludGVyZmFjZSBoYWQgZGlzYXBwZWFyZWQsDQogdG8gdGVsbCB0aGUgZmFyIGVu ZCBvdmVyIGl0cyBjZWxsdWxhciBpbnRlcmZhY2UgdGhhdCBpdCBoYWQgZ29uZSwgYnkgcmVmZXJy aW5nIHRvIHRoZSBBZGRyZXNzIElEIGl0IGhhZCB1c2VkIGluIHRoZSBNUF9KT0lOLCBpbiB0aGUg UkVNT1ZFX0FERFIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZXJlIGlzIGEgc2Vjb25kYXJ5IHVzZSBoZXJlIHdoaWNoIEkgcmVhbGlzZSB3 ZSBoYXZlbuKAmXQgZXhwbGljaXRseSBzdGF0ZWQuIElmIGEgY2xpZW50IGRlY2xhcmVkIGl0cyBw cml2YXRlIGFkZHJlc3MgaW4gQUREX0FERFIsIGJ1dCBhbHNvIHNlbnQgYSBNUF9KT0lOIHdpdGgg dGhlIHNhbWUgYWRkcmVzcyBJRCwgYnV0IG5hdHVyYWxseSBhIGRpZmZlcmVudCBhZGRyZXNzLCB0 aGUgZmFyIGVuZCB3b3VsZCBzYXkNCiDigJxhaCwgdGhlc2UgYWRkcmVzc2VzIGRvbuKAmXQgbWF0 Y2gsIHNvIEkgc2hvdWxkIG5vdCBib3RoZXIgYXR0ZW1wdGluZyB0byBjb25uZWN0IHRvIHRoZSBB ZGRyZXNzIGluIHRoZSBBRERfQUREUuKAnS4gVGhpcyBpcyBhbiBvcHRpbWlzYXRpb24gYnV0IG9u ZSB0aGF0IHNob3VsZCBwcm9iYWJseSBiZSBtZW50aW9uZWQuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPltSSl0gVGhlIGZhciBlbmQgaGVyZSBtYXRjaGVzIHRoZSBBZGRyZXNz IElELCBpZGVudGlmaWVzIHRoZSBBRERfQUREUiBjb250ZXh0LCBhbmQgdXNlcyB0aGUgcmVjZWl2 ZWQgc291cmNlIGFkZHJlc3MgLi4gTWF5IGJlIHRoZSBmYXIgZW5kIHNob3VsZCBrZWVwIHRoaXMg bmV3bHkNCiBsZWFybnQgSVAgYWRkcmVzcyB3aXRoaW4gdGhlIEFERF9BRERSIGNvbnRleHQgZm9y IGZ1dHVyZSBNUF9KT0lOIG9uY2UgdGhpcyBzdWItZmxvdyBjbG9zZXM/IEFzIEkgdW5kZXJzdGFu ZCwgQWRkcmVzcyBJRCBhbG9uZSBpcyB0aGUgcHJpbWFyeS1rZXkgZm9yIG1hdGNoaW5nIGFueXdh eXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5TbyB0aGUgcG9pbnQgaXMgdGhhdCBBZGRyZXNzIElEIHJlZmVycyBwdXJlbHkgdG8g dGhlIDxpPmFkZHJlc3M8L2k+LCBhbmQgbm90IHRvIHRoZSBhZGRyZXNzICYjNDM7IHBvcnQgcGFp ci4gVGhlcmVmb3JlIGEgbmV3IHBvcnQgY2FuIGJlIGFkdmVydGlzZWQgaW4gYSBuZXcgQUREX0FE RFIgdXNpbmcgdGhlIHNhbWUgQWRkcmVzcyBJRC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+W1JKXSBJ4oCZbSBub3Qgc3VyZSBhYm91dCB0aGlzIGludGVycHJldGF0aW9uLiBN eSB0aGlua2luZyB3YXMgdGhhdCBBZGRyZXNzIElEIHJlZmVycyBwdXJlbHkgdG8gdGhlIHN1Yi1m bG93IHBvc3NpYmlsaXR5IG9uIGFuIGludGVyZmFjZSB3aXRob3V0IGFueSBkZXBlbmRlbmNlDQog b24gYWRkcmVzcyAmIzQzOyBwb3J0LiBBZGRyZXNzIGFuZCBwb3J0IGFyZSBwYXJhbWV0ZXJzIGZv ciB0aGUgQWRkcmVzcyBJRCB3aGljaCBtaWdodCBwb3NzaWJseSBjaGFuZ2UgaW4gdGhlIGZ1dHVy ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNvIHdlIHNob3VsZCBjbGFyaWZ5IHRoaXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmEpIHJldHJhbnNtaXR0aW5nIGFuIEFERF9B RERSIHdpdGggc2FtZSBJRCwgYWRkcmVzcywgYW5kIHBvcnQgaXMgZmluZTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YikgdGhpcyBjb3VsZCBwZXJt aXQgdGhlIGZhciBlbmQgdG8gdHJpZ2dlciBhbm90aGVyIGNvbm5lY3Rpb24gYXR0ZW1wdDxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W1JK XSBhICZhbXA7IGIgaXMgY2xlYXIgZnJvbSBleGlzdGluZyB0ZXh0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmMpIHNl bmRpbmcgYSBuZXcgQUREX0FERFIgd2l0aCBzYW1lIElEICYjNDM7IGFkZHJlc3MgYW5kIGRpZmZl cmVudCBwb3J0IGlzIGZpbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bUkpdIGFnYWluIHRo aXMgaXMgd2hhdCB0aGUgdGV4dCBhbHJlYWR5IHNheXMsIGJ1dCBJ4oCZbSBub3Qgc3RpbGwgY2xl YXIgYWJvdXQgdGhpcy4gV2h5IElEICYjNDM7IGFkZHJlc3MgaGFzIHRvIG1hdGNoPyBPbmx5IElE IHNob3VsZCBiZSBlbm91Z2guDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZCkgdG8gcmVhc3NpZ24gYW4gYWRkcmVz cyBJRCB5b3UgbXVzdCBmaXJzdCBSRU1PVkVfQUREUjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5bUkpdIFRoaXMgYWxzbyBJIGRvbuKAmXQgZ2V0LiBXaHkgc2hvdWxkIGl0IGJlIG5lY2Vz c2FyeSB0byBkbyBhIFJFTU9WRV9BRERSIHRvIGNoYW5nZSBhbiBJUCBhZGRyZXNzIGZvciBhbiBl eGlzdGluZyBJRD8gSWYgYSBBRERfQUREUiByZWZlcnMgdG8gYW4gZXhpc3RpbmcgSUQgd2l0aCBh IG5ldyBBZGRyZXNzIHRoZW4gY2Fu4oCZdCB0aGlzIHNpbXBseSBvdmVycmlkZQ0KIHRoZSBJUCBh ZGRyZXNzIGZvciB0aGF0IElEPyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PkFub3RoZXIgd2F5IHRvIHB1dCB0aGlzIHF1ZXN0aW9uLCBJbiB3aGljaCBjYXNlIGEgcmVjZWl2 ZXIgYWZ0ZXIgbWF0Y2hpbmcgdGhlIEFkZHJlc3MgSUQgKGZvciBNUF9KT0lOIG9yIEFERF9BRERS KSB3aWxsIGRlcGVuZCBvbiBtYXRjaGluZyBhZ2FpbnN0IHRoZSBhZGRyZXNzIGZpZWxkIGFuZCB3 aGF0IGlzIGFjaGlldmVkIGJ5IG1hdGNoaW5nIHRoZSBhZGRyZXNzDQogZmllbGQ/IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QnkgYWxsb3dpbmcgdG8gb3ZlcnJpZGUgYW4g SVAgYWRkcmVzcyBpbiB0aGUgZXhpc3RpbmcgSUQsIGEgUkVNT1ZFX0FERFIgJiM0MzsgQUREX0FE RFIgY3ljbGUgd2hpY2ggcmVxdWlyZXMgYXQtbGVhc3Qgb25lIFJUVCB3b3VsZCBiZSBzYXZlZC4g U2Vjb25kbHksIHRoZSBpbXBsZW1lbnRhdGlvbiBiZWNvbWVzIGxvdCBtb3JlIHNpbXBsZXIgKGZv ciBtZSB0aGlzIGlzIHRoZQ0KIG1ham9yIG1vdGl2YXRpb24pLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5SYWh1bDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_982B626E107E334DBE601D979F31785C5DC5D84BBLREML503MBSchi_-- From nobody Mon Jul 30 01:35:34 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C9A130E08 for ; Mon, 30 Jul 2018 01:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 1pHhPv4HY2sy for ; Mon, 30 Jul 2018 01:35:29 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E1DC130E00 for ; Mon, 30 Jul 2018 01:35:28 -0700 (PDT) Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 30 Jul 2018 09:35:25 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03b.domain1.systemhost.net (10.55.202.22) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 30 Jul 2018 09:35:25 +0100 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.1293.004; Mon, 30 Jul 2018 09:35:25 +0100 From: To: , Thread-Topic: 6824bis -11 review Thread-Index: AdQmJDYhfu15UAaeTxKUY+EC058bGgBu/tsQ Date: Mon, 30 Jul 2018 08:35:24 +0000 Message-ID: <670a7a7ecac74615b307d28f07cbdebe@rew09926dag03b.domain1.systemhost.net> References: <982B626E107E334DBE601D979F31785C5DC5A15C@BLREML503-MBX.china.huawei.com> In-Reply-To: <982B626E107E334DBE601D979F31785C5DC5A15C@BLREML503-MBX.china.huawei.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] 6824bis -11 review X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 08:35:32 -0000 Rahul, Thanks very much for the detailed review, it is much appreciated phil -----Original Message----- From: Rahul Arvind Jadhav [mailto:rahul.jadhav@huawei.com]=20 Sent: 28 July 2018 08:38 To: multipathtcp@ietf.org Cc: Eardley,PL,Philip,TUD1 R ; nishida@sfc.wide.ad.j= p Subject: 6824bis -11 review Hi, As promised in IETF102, here is my review for 6824bis-11. As Phil had sugg= ested, I didn't take the trouble to check if my comments overlap with any o= f the previous discussions/comments.=20 1. Section 3.6: Subflow Reset [RJ]: Is MP_TCPRST a SHOULD or MUST to be included along with the TCP_RST ?= Can this be stated explicitly in section 3.6? 2. Section 3.4.2. Remove Address "The sending and receipt (if no keepalive response was received) of this message SHOULD trigger the sending of RSTs by both hosts on the affected subflow(s) " [RJ]: Since a MP_TCPRST should be associated with this RST, what should be = the corresponding Reason Code that can be used in MP_TCPRST for this case? = I checked existing reason codes in section 3.6 and none of those made sense= (may be except for 0x0 ?). 3. Section 3.4.1. Address Advertisement=20 "A host can send an ADD_ADDR message with an already assigned Address ID, but the Address MUST be the same as previously assigned to this Address ID, and the Port MUST be different from one already in use for this Address ID." [RJ]: Didn't understand the rationale for allowing reuse of Address ID only= for port change and not for IP change. 4. Section 3.4.1. Address Advertisement [RJ]: For long-lived MPTCP connection, the ADD_ADDR needs to be resent if t= he sub-flow is closed and if it needs to be reopened in the future. Is this= correct? The reason for me to believe this is, if REMOVE_ADDR is sent and = if the sub-flow is active/functioning, then the REMOVE_ADDR will be ignored= . This means that when the sub-flow is closed, the corresponding Address ID= is removed. Thus it means to establish a new sub-flow from the peer an ADD= _ADDR has to be sent. 5. passive opener [RJ]: The term "passive opener" is used several times in the document. This= term needs to be clarified in Terminology section. 6. Section 3 Figure 3 [RJ]: Length field in figure 3 encompasses Kind, Length and Option payload.= This should be explicitly stated. 7. Section 3.1 says: "it is expected that A will have generated a key local= ly before the initial SYN"=20 [RJ]: Is there any advantage of generating the key in advance? The key gene= ration can be avoided by A if node B responds without MP_CAPABLE. Can this = be left to the implementation? 8. Section 3.2 says: The MP_JOIN option includes an "Address ID". This is = an identifier that only has significance within a single connection, [RJ]: The significance of "Address ID" is only within the connection and __= only on the peer__ who generates the ID. Is this correct?=20 9. Section 3.3 says: M =3D Data Sequence Number (DSN), Subflow Sequence Num= ber (SSN), Data-Level Length, and Checksum present [RJ]: and Checksum present (if negotiated) 10. [RJ]: Can an attacker spoof MP_FAIL option to the receiver with DSN=3D0= (infinite mapping)? This will cause the receiver to discard all the data f= ollowing DSN and the failed data won't be DATA_ACKed. Is there any way to p= rotect this? 11. [RJ]: I was hoping to find a section in the introduction which summariz= es changes in v1. This could be of help for someone who aims to migrate/und= erstand briefly the implications of switching to v1.=20 ------------Editorials: Section 2.7: Currently: "To meet the threats identified in ..." Should be: "To address the threats identified in ..." Section 2.7: Currently: "keys are sent in the clear in the MP_CAPABLE messages" Should be: "keys are sent in clear in the MP_CAPABLE messages" Section 3.1: Spellfix: requsted -> requested Spellfix: wishs -> wishes Section 3.1: Currently: "The key MUST be hard to guess, and it MUST be unique for the se= nding host at any one time." Should be: "The key MUST be hard to guess, and it MUST be unique for the se= nding host across all MPTCP connections." Section 3.1: Currently: "there is not a collision" Should be: "there is no collision" Section 3.1: Currently: "The receiver will acknowledge this data a the connection" Should be: "The receiver will acknowledge this data at the connection" Section 3.4.1: Spellfix: assinged -> assigned Section 3.6: Currently: "Regular TCP RST options remain used to at the subflow-level" Should be: "Regular TCP RST options continue to be used at the subflow-leve= l" Section 3.6: Spellfix: re-estbalish -> re-establish Spellfix: ressources -> resources Section 3.6: Currently: "It would be beneficial for a host to the reasons ..." Should be: "It would be beneficial for a host to provide the reasons ..." From nobody Mon Jul 30 08:56:07 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC65131116 for ; Mon, 30 Jul 2018 08:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7HSnR813OpsT for ; Mon, 30 Jul 2018 08:55:58 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 F3FD513112B for ; Mon, 30 Jul 2018 08:55:57 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id a4-v6so8513001lff.5 for ; Mon, 30 Jul 2018 08:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=1LLkhN5HjPX6os12gmm3nxMbHHi7CW72zoJ41iXqtIo=; b=K11Z2rOZBBFDipM828oWGze8n9dIzYEDxOtenTf/TnX+yxsRCzKo9qHcTKZQGg78Vl /XrpAqWG4gUgqMS4sRt3FnjguAPcMCcLe7cvOYrSpL/GGf0hN/IRc2cesnAL1Tmrd9X2 5hONgrYAE8Rk2oieh6Ty3XVgZmL9VrSjnwaBy81PbTTRky6ut8uaVCRer8fSI5ctWq9k 1IGj/tEeMisSYjKokwEMeixRuhAWITgEpG1UmgQeScG+9wVDXWA805NI8R6iZHOfLC1r eZXUkj0p5jxdjQQnU+8U+Nm+ygPpxBfTM7XQ1T4fc54zgGvFxjszOhurPsbmxok+FSF1 1ruw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=1LLkhN5HjPX6os12gmm3nxMbHHi7CW72zoJ41iXqtIo=; b=LVr1zTJcZH9IgoARnoUBKoLkUd0RYUD2vQ/qKncVsJx4WvNGikWG9vOZrnq1HhYy/N xBrZOw2/LMhjDnIaucTa95qmTp+HGBl78kwXNA8yQDtB3x01fN0qcTHlHTv0AvH0Lhai sg51zp6w/1hxPFkF2JEs8XnvYEPGY8/uJzI2V5Ohy0lWZABnosNzQBjckln84yhNnBOc 8tHdJx620bl4uU5aRXSHvSQBG1bnx/g6qj0d5VsPNJhsxKoRtWNVMl5OtOHWgO4MZgRX tf/iPeCRmlrrUmGo/h1vjdr2KzJYW2nBgzxMQPzGCAi54w3GICJh1T00sk/a/8HKpIwE bYDA== X-Gm-Message-State: AOUpUlEmN0ElnTODiymOT+5Z09JsIxp2mc1YR+lZ4E3WU/CiqqN0nPvT WP0W5hsGs5rbC2og4+jaamA= X-Google-Smtp-Source: AAOMgpdPc7CplVRPuqV/oLJjPLcYF9JaNyUSbgBRGB+3YbjCxMTzQtZb29ltNK8P3qPeq/gNCIhdTA== X-Received: by 2002:a19:a705:: with SMTP id q5-v6mr11131339lfe.148.1532966156251; Mon, 30 Jul 2018 08:55:56 -0700 (PDT) Received: from [10.44.30.233] ([62.254.152.194]) by smtp.gmail.com with ESMTPSA id m12-v6sm2138930ljh.24.2018.07.30.08.55.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jul 2018 08:55:55 -0700 (PDT) From: Alan Ford Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_19833D02-7C12-4F9B-B69F-B3537D830BEB" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 30 Jul 2018 16:55:53 +0100 In-Reply-To: <982B626E107E334DBE601D979F31785C5DC5D84B@BLREML503-MBS.china.huawei.com> Cc: multipathtcp To: Rahul Arvind Jadhav References: <982B626E107E334DBE601D979F31785C5DC5A15C@BLREML503-MBX.china.huawei.com> <92A53501-4728-4E02-816A-92CEE703AA49@gmail.com> <20754FD9-627F-4AAC-A1B5-6EF2BD09B2AD@gmail.com> <982B626E107E334DBE601D979F31785C5DC5D84B@BLREML503-MBS.china.huawei.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [multipathtcp] 6824bis -11 review X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 15:56:05 -0000 --Apple-Mail=_19833D02-7C12-4F9B-B69F-B3537D830BEB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Rahul, Comments inline... > On 29 Jul 2018, at 04:17, Rahul Arvind Jadhav = wrote: >=20 > Thanks Alan for clarifying.=20 > But I=E2=80=99m still not clear about this. Please find my comments = [RJ] inline. > =20 > On 28 Jul 2018, at 18:19, Alan Ford > wrote: >=20 >=20 > 3. Section 3.4.1. Address Advertisement=20 > "A host can send an ADD_ADDR message with an already assigned Address > ID, but the Address MUST be the same as previously assigned to this > Address ID, and the Port MUST be different from one already in use > for this Address ID." > [RJ]: Didn't understand the rationale for allowing reuse of Address ID = only for port change and not for IP change. >=20 > I cannot recall the rationale here either. >=20 > Furthermore - as written - this would seem to prevent retransmission. = Which is crazy. >=20 > If nobody can recall the reason for this I would suggest we remove it. > =20 > Having looked at the text again here, I think I can recall the = rationale. But we need to consider whether this is actually the intended = behaviour. > =20 > Address ID was originally designed to provide a mechanism whereby a = client behind a NAT could refer to its address without using the IP = address, which would be altered by the NAT. This would allow a client, = whose wifi interface had disappeared, to tell the far end over its = cellular interface that it had gone, by referring to the Address ID it = had used in the MP_JOIN, in the REMOVE_ADDR. > =20 > There is a secondary use here which I realise we haven=E2=80=99t = explicitly stated. If a client declared its private address in ADD_ADDR, = but also sent a MP_JOIN with the same address ID, but naturally a = different address, the far end would say =E2=80=9Cah, these addresses = don=E2=80=99t match, so I should not bother attempting to connect to the = Address in the ADD_ADDR=E2=80=9D. This is an optimisation but one that = should probably be mentioned. > =20 > [RJ] The far end here matches the Address ID, identifies the ADD_ADDR = context, and uses the received source address .. May be the far end = should keep this newly learnt IP address within the ADD_ADDR context for = future MP_JOIN once this sub-flow closes? As I understand, Address ID = alone is the primary-key for matching anyways. Yes, the intention is that the source address from a MP_JOIN can be used = for future connections, creating or updating the mapping to the Address = ID. Which makes me realise we probably need the =E2=80=98C=E2=80=99 bit = on the MP_JOIN. But that=E2=80=99s an aside. > =20 > So the point is that Address ID refers purely to the address, and not = to the address + port pair. Therefore a new port can be advertised in a = new ADD_ADDR using the same Address ID. > =20 > [RJ] I=E2=80=99m not sure about this interpretation. My thinking was = that Address ID refers purely to the sub-flow possibility on an = interface without any dependence on address + port. Address and port are = parameters for the Address ID which might possibly change in the future. For the purposes of MPTCP, I=E2=80=99m not sure how interface and = address are different here. > =20 > So we should clarify this: > =20 > a) retransmitting an ADD_ADDR with same ID, address, and port is fine > b) this could permit the far end to trigger another connection attempt > [RJ] a & b is clear from existing text > =20 > c) sending a new ADD_ADDR with same ID + address and different port is = fine > [RJ] again this is what the text already says, but I=E2=80=99m not = still clear about this. Why ID + address has to match? Only ID should be = enough.=20 Consider: a) ADD_ADDR comes in saying ID=3D2, addr=3D10.0.0.1 (private) b) MP_JOIN comes in saying ID=3D2, addr=3D8.9.10.11 (public) c) ADD_ADDR comes in saying ID=3D2, addr=3D192.168.0.1 What does this mean? Is (c) an implicit REMOVE+ADD? And thus does this = mean the subflow created in (b) is now no longer valid? By keeping the address / ID mapping, if an address is lost, then so is = the subflow. > d) to reassign an address ID you must first REMOVE_ADDR > [RJ] This also I don=E2=80=99t get. Why should it be necessary to do a = REMOVE_ADDR to change an IP address for an existing ID? If a ADD_ADDR = refers to an existing ID with a new Address then can=E2=80=99t this = simply override the IP address for that ID?=20 > =20 > Another way to put this question, In which case a receiver after = matching the Address ID (for MP_JOIN or ADD_ADDR) will depend on = matching against the address field and what is achieved by matching the = address field?=20 > =20 > By allowing to override an IP address in the existing ID, a = REMOVE_ADDR + ADD_ADDR cycle which requires at-least one RTT would be = saved. Secondly, the implementation becomes lot more simpler (for me = this is the major motivation). Again, see the example above. It is my view that it is removes ambiguity = for a sender to have a unique ID to address mapping. Best regards, Alan --Apple-Mail=_19833D02-7C12-4F9B-B69F-B3537D830BEB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Rahul,

Comments = inline...

On 29 Jul 2018, at 04:17, Rahul Arvind Jadhav = <rahul.jadhav@huawei.com> wrote:

Thanks = Alan for clarifying. 
But I=E2=80= =99m still not clear about this. Please find my comments [RJ] = inline.
 
On 28 Jul = 2018, at 18:19, Alan Ford <alan.ford@gmail.com> wrote:


3. Section 3.4.1. = Address Advertisement 
 "A = host can send an ADD_ADDR message with an already assigned Address
 ID, but the Address MUST be the same as previously = assigned to this
 Address ID, and the Port MUST be = different from one already in use
 for this Address = ID."
[RJ]: Didn't understand the rationale for allowing = reuse of Address ID only for port change and not for IP change.

I cannot recall the = rationale here either.

Furthermore - as = written - this would seem to prevent retransmission. Which is crazy.

If nobody can recall the reason for this I = would suggest we remove it.
 
Having looked at the text again here, I think I can = recall the rationale. But we need to consider whether this is actually = the intended behaviour.
 
Address ID was originally designed to = provide a mechanism whereby a client behind a NAT could refer to its = address without using the IP address, which would be altered by the NAT. = This would allow a client, whose wifi interface had disappeared, to tell = the far end over its cellular interface that it had gone, by referring = to the Address ID it had used in the MP_JOIN, in the REMOVE_ADDR.
 
There is a = secondary use here which I realise we haven=E2=80=99t explicitly stated. = If a client declared its private address in ADD_ADDR, but also sent a = MP_JOIN with the same address ID, but naturally a different address, the = far end would say =E2=80=9Cah, these addresses don=E2=80=99t match, so I = should not bother attempting to connect to the Address in the = ADD_ADDR=E2=80=9D. This is an optimisation but one that should probably = be mentioned.
 
[RJ] The far end here = matches the Address ID, identifies the ADD_ADDR context, and uses the = received source address .. May be the far end should keep this newly = learnt IP address within the ADD_ADDR context for future MP_JOIN once = this sub-flow closes? As I understand, Address ID alone is the = primary-key for matching = anyways.

Yes, the intention is that the source address from = a MP_JOIN can be used for future connections, creating or updating the = mapping to the Address ID. Which makes me realise we probably need the = =E2=80=98C=E2=80=99 bit on the MP_JOIN. But that=E2=80=99s an = aside.

 
So the point is that Address ID refers = purely to the address, and not to the address + port pair. Therefore a = new port can be advertised in a new ADD_ADDR using the same Address = ID.
 
[RJ] I=E2=80=99m not = sure about this interpretation. My thinking was that Address ID refers = purely to the sub-flow possibility on an interface without any = dependence on address + port. Address and port are parameters for the = Address ID which might possibly change in the = future.

For the purposes of MPTCP, I=E2=80=99m not sure = how interface and address are = different here.

 
So we should clarify this:
 
a) = retransmitting an ADD_ADDR with same ID, address, and port is fine
b) this could permit the far end to trigger another = connection attempt
[RJ] a & b is clear from existing text
 
c) sending a new ADD_ADDR with same ID + address and = different port is fine
[RJ] again this is what the text already = says, but I=E2=80=99m not still clear about this. Why ID + address has = to match? Only ID should be enough. 

Consider:

a) = ADD_ADDR comes in saying ID=3D2, addr=3D10.0.0.1 (private)
b) = MP_JOIN comes in saying ID=3D2, addr=3D8.9.10.11 (public)
c) = ADD_ADDR comes in saying ID=3D2, addr=3D192.168.0.1

What does this mean? Is (c) an implicit = REMOVE+ADD? And thus does this mean the subflow created in (b) is now no = longer valid?

By keeping the address = / ID mapping, if an address is lost, then so is the subflow.

d) to reassign an address ID you must first = REMOVE_ADDR
[RJ] This also I don=E2=80=99= t get. Why should it be necessary to do a REMOVE_ADDR to change an IP = address for an existing ID? If a ADD_ADDR refers to an existing ID with = a new Address then can=E2=80=99t this simply override the IP address for = that ID? 
 
Another way to put this question, In which case a receiver = after matching the Address ID (for MP_JOIN or ADD_ADDR) will depend on = matching against the address field and what is achieved by matching the = address field? 
 
By = allowing to override an IP address in the existing ID, a REMOVE_ADDR + = ADD_ADDR cycle which requires at-least one RTT would be saved. Secondly, = the implementation becomes lot more simpler (for me this is the major = motivation).

Again, see the example above. It is my view that = it is removes ambiguity for a sender to have a unique ID to address = mapping.

Best = regards,
Alan

= --Apple-Mail=_19833D02-7C12-4F9B-B69F-B3537D830BEB-- From nobody Mon Jul 30 12:03:33 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5401130EAE for ; Mon, 30 Jul 2018 12:03:31 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 c1onZkENwEa6 for ; Mon, 30 Jul 2018 12:03:29 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 7C4FB130EA9 for ; Mon, 30 Jul 2018 12:03:29 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id a5-v6so13287260qtp.2 for ; Mon, 30 Jul 2018 12:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=G/fnMJQ4cz8gX+siZvkMEEH6E+VcCI1d0uXxxx3r7/A=; b=VQKtMiV6F0L9ICeclmOp2OH0Gmru35YnJBNYtSkWMvyqq24FgIQNQovWNhJxhjc5vt 3wkazgQ49zy4FusdzpoMYzrVFvBd5zBjImw3H7Ly5M73I7ubPLnv8BI6O8xnVTotc0+h CLH9/WNz1pZStGM7vXRFRhwnPl/o4dqKdtW5JJfgfOsOP+XJ8IOq9slRJ1xe7r5oa8U9 RM/TkzKkF4tvYxOOzjV7W2nT8eFvl++/sgADwi7eynzoAbEaj11fqHAe3NQJRTPYDFB6 1KiUZg0GAN/bPMWr2rg1Rct9tUeRpTbkpN368InM4AOMS1PL7eeg8DKT3AFbK/xvrFF/ LViQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=G/fnMJQ4cz8gX+siZvkMEEH6E+VcCI1d0uXxxx3r7/A=; b=CiZUpxpHephC0Mu2BS7EzMeXxym8sMy44isNyM17eCdfj1KQzEfhW7q31M7/uIczg/ vrBAvzPSLJNIY03QvK4NzbSLZ8GkSCnHRpOV517U0zKcb5G9SrSyfW4QTE3ChTJkN/Lr FyMb4Ad3CEaO+9i3yz8+A8p9boOEVIZHOIQoxof5TLOoFHPUvi9lj8lXMtZPlJ1QCSk9 MfCXLgxJiN3oinhNkw9V7gzVdCW+zC7xS6pdxMQYfBRy5rPrlzlYxm2T9hXBXiB+QNvI E4CczZdTdqVHr6DqsXwlCj7zWagMYTmg23rk7ZefeihdChr8FMqi2QC7HYbG35J4hME9 kYKA== X-Gm-Message-State: AOUpUlHwxAk+xX9lHH+Wr6pRxyB6UmEQWtiZlJ2+U0rFkImkxGEyepQD NwEAdL2j0sUDkFvfBbM7GS48ZjLdW3t9FZfNweFWR/Js X-Google-Smtp-Source: AAOMgpdlLaoas3faObl5rFwf/Gz6ztSPs3YNFXFBEQgeDFTNYDzrT6/2f8iFWwRFSxztnjvu4bb86ilcONwnQU8LTmc= X-Received: by 2002:ac8:4402:: with SMTP id j2-v6mr17960835qtn.233.1532977408278; Mon, 30 Jul 2018 12:03:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:2ea2:0:0:0:0:0 with HTTP; Mon, 30 Jul 2018 12:03:27 -0700 (PDT) From: Xavier de Foy Date: Mon, 30 Jul 2018 15:03:27 -0400 Message-ID: To: multipathtcp Content-Type: multipart/alternative; boundary="000000000000de854005723c1d3e" Archived-At: Subject: [multipathtcp] rfc6824bis discussion about 5G session continuity support X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 19:03:32 -0000 --000000000000de854005723c1d3e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, As promised during the MPTCP meeting session at IETF 102, here is a summary of our findings related to 5G session continuity support, as part of the review of rfc6824bis. The root problem is the following: in 5G, a client may have IP addresses provided by a mobile network, in association with a session continuity service (SCC mode 1/fixed, 2/distributed anchor + BBM or 3/ distributed anchor + MBB). Such an IP address can be replaced, or be complemented with, another IP address, possibly multiple times during the lifetime of an application session. If the MPTCP stack is not aware of this, it can=E2=80= =99t make the link between these addresses, and can=E2=80=99t make the correct or mos= t efficient decisions in some cases. I think there is at least a case for _local_ usage of session continuity information by the 5G device MPTCP stack. Every new IP address can (locally) be associated with a tuple (address type, original IP address), using the DMM-defined =E2=80=9Caddress types=E2=80=9D which have a 1:1 rela= tionship with the 3GPP SCC modes. For example, using this information, a MPTCP local stack can copy the backup priority property from one IP address to the next when appropriate. **Rationale to send new information over MPTCP (and workarounds) ** In addition to the local usage of this information, here are possible scenarios where sending the tuple (address type, original IP address ID) over MPTCP signaling may help the remote peer making appropriate decisions: Case #1: the IP address in active use is over SSC mode 3/MBB, and there is a MBB handover: - We want both MPTCP peers to start using new path(s) using the new IP address, then wait for its bandwidth usage to ramp up, and, after some time, cleanly remove the old IP address (cleanly =3D not losing/re-sending packets). This is for a smooth transition in term of performance, and to release network resources associated with the old IP address. If both peers have access to the tuple (address type, original IP address), they can both perform these actions. After a while, one side can close the now unused subflow(s), and then remove the IP address. - Possible workaround/solution: there is no need to send the tuple over MPTCP signaling, if the MPTCP client has the possibility to request a clean shutdown of old paths/addresses. When discussing this with Christoph, he proposed a quick way to implement a clean shutdown, if I recall correctly: (1) set the priority of subflows using this address to =E2=80=9Cbackup=E2= =80=9D, (2) wait for in-flight TCP segments to arrive and be acked, (3) remove the IP address. See below in conclusion for additional details on this. Case #2: on the client, the IP address in active use is over SSC mode 2/BBM, and there is another backup IP address: - If no change is made, during the break before make, the peers will switch to use the backup IP address. This may not be the desired outcome (e.g. waking up a radio for a few packets, and changing the properties of the path for a very short period of time). Sending the tuple (address type, original IP address) as above enables avoiding this situation. - Possible workaround/solution: in 5G systems, it may be possible to avoid using SSC mode 2/BBM for applications that use MPTCP, by adjusting SSC policies for those applications. (At this time it is not clear if will be possible in all cases, e.g. applications may also request a specific continuity service using setsc().) **Conclusion** A long term solution for cases #1, #2, and possibly other scenarios that may emerge later, could be to send a tuple (address type, original IP address ID) to the remote peer, over MPTCP. This information would be associated with options that can introduce a new IP address, like ADD_ADDR, MP_JOIN, MP_CAPABLE. Nevertheless, experiments will be needed to determine if it is really needed, or if a local usage of this information on the client side is enough. Since 5G deployments are not yet common, it will take time. Thus it may be best to rely on the experimental extension mechanism, and possibly make sure some minimal support is in place in rfc6824bis. Proposal: (1) Document, in rfc6824bis, a =E2=80=9Cclean remove=E2=80=9D of a live add= ress =E2=80=93 this will enable dealing with the most obvious case #1 (SSC mode 3). - Basically, this can use the mechanism described above. Either now or in a future version of the protocol, it could make sense to avoid corner cases (e.g. use a new =E2=80=9Cinactive=E2=80=9D priority for subflows, and possi= bly a new reason code =E2=80=9Cinactive address=E2=80=9D when closing the subflows). (2) Could we make sure that experimental extensions are available in the new version of the MPTCP protocol? - Additional question: do you think it will be acceptable to mandate sending an extension option within the same packet as another MPTCP option? It would be convenient to place the address type extension within the same packet used to transmit the option it extends (e.g. ADD_ADDR, MP_JOIN, MP_CAPABLE). This would ensure that there is no sync issue between them, due to timing issue or packet loss, and there will be no need to explicitly deal with re-transmission of this particular extension option. Best Regards, Xavier. --000000000000de854005723c1d3e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

As promised during the = MPTCP meeting session at IETF 102, here is a summary of our findings relate= d to 5G session continuity support, as part of the review of rfc6824bis.

=C2=A0

The root problem is the= following: in 5G, a client may have IP addresses provided by a mobile network, in association with a session continuity service (SCC mode 1/fixed, 2/distributed anchor + BBM or 3/ dist= ributed anchor + MBB). Such an IP address can be replaced, or be complemented with, another IP address, possibly multiple times during the lifetime of an application session. If the MPTCP stack is not aware of this, it can=E2=80= =99t make the link between these addresses, and can=E2=80=99t make the correct or most ef= ficient decisions in some cases.

=C2=A0

I think there is at lea= st a case for _local_ usage of session continuity information by the 5G device MPTCP stack.=C2=A0 Eve= ry new IP address can (locally) be associated with a tuple (address type, original IP address), using the DMM-defined =E2=80=9Caddress types=E2=80=9D which have a 1:1 relationship w= ith the 3GPP SCC modes. For example, using this information, a MPTCP local stack can copy the backup priority property from one IP address to the next when appropriate. <= /span>

=C2=A0

**Rationale to send new= information over MPTCP (and workarounds) **

=C2=A0

In addition to the loca= l usage of this information, here are possible scenarios where sending the tuple (address type, original IP addre= ss ID) over MPTCP signaling may help the remote peer making appropriate decisions:=

=C2=A0

Case #1: the IP address= in active use is over SSC mode 3/MBB, and there is a MBB handover:

- We want both MPTCP pe= ers to start using new path(s) using the new IP address, then wait for its bandwidth usage to ramp up, and, after so= me time, cleanly remove the old IP address (cleanly =3D not losing/re-sending packets). This is for a smooth transition in term of performance, and to release network resources associated with the old IP address. If both peers have access to the tuple (address type, original IP address), they can both perform these actions. After a while, one side can close the now unused subflow(s), and then remove the IP address.

- Possible workaround/s= olution: there is no need to send the tuple over MPTCP signaling, if the MPTCP client has the possibility to requ= est a clean shutdown of old paths/addresses. When discussing this with Christop= h, he proposed a quick way to implement a clean shutdown, if I recall correctl= y: (1) set the priority of subflows using this address to =E2=80=9Cbackup=E2= =80=9D, (2) wait for in-flight TCP segments to arrive and be acked, (3) remove the IP address. S= ee below in conclusion for additional details on this.

=C2=A0

Case #2: on the client,= the IP address in active use is over SSC mode 2/BBM, and there is another backup IP address:

- If no change is made,= during the break before make, the peers will switch to use the backup IP address. This may not be the desired outcome (e= .g. waking up a radio for a few packets, and changing the properties of the pat= h for a very short period of time). Sending the tuple (address type, original= IP address) as above enables avoiding this situation.

- Possible workaround/s= olution: in 5G systems, it may be possible to avoid using SSC mode 2/BBM for applications that use MPTCP, by adjusting SSC policies for those applications. (At this time it is not clea= r if will be possible in all cases, e.g. applications may also request a sp= ecific continuity service using setsc().)

=C2=A0

=C2=A0

**Conclusion**

=C2=A0

A long term solution fo= r cases #1, #2, and possibly other scenarios that may emerge later, could be to send a tuple (address type, original IP address ID) to the remote peer, over MPTCP. This information would be associated with options that can introduce a new IP address, like ADD_ADDR, MP_JOIN, MP_CAPABLE. Nevertheless, experiments will be needed to determine = if it is really needed, or if a local usage of this information on the client side i= s enough. Since 5G deployments are not yet common, it will take time. Thus it may be best to r= ely on the experimental extension mechanism, and possibly make sure some minima= l support is in place in rfc6824bis.

=C2=A0

Proposal:<= /p>

=C2=A0

(1) Document, in rfc682= 4bis, a =E2=80=9Cclean remove=E2=80=9D of a live address =E2=80=93 this will enable dealing with the most obvious case #1 (S= SC mode 3).

- Basically, this can u= se the mechanism described above. Either now or in a future version of the = protocol, it could make sense to avoid corner cases (e.g. use a new =E2=80=9Cinactive=E2=80=9D= priority for subflows, and possibly a new reason code =E2=80=9Cinactive address=E2=80=9D when clos= ing the subflows).

=C2=A0

(2) Could we make sure = that experimental extensions are available in the new version of the MPTCP protocol?

- Additional question: = do you think it will be acceptable to mandate sending an extension option within the same packet as another MPTCP= option? It would be convenient to place the address type extension within the same packet used to transmit the option it extends (e.g. ADD_ADDR, MP_JOIN, MP_CAPABLE). This would ensure that there is no sync issue between them, du= e to timing issue or packet loss, and there will be no need to explicitly deal with re-transmiss= ion of this particular extension option.

=C2=A0

Best Regards,

=C2=A0

Xavier.

--000000000000de854005723c1d3e-- From nobody Mon Jul 30 17:21:36 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAA6130EFC for ; Mon, 30 Jul 2018 17:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 JeGaxqkHKhfR for ; Mon, 30 Jul 2018 17:21:32 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6D51130E11 for ; Mon, 30 Jul 2018 17:21:31 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 0F65E7B30575F for ; Tue, 31 Jul 2018 01:21:27 +0100 (IST) Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 31 Jul 2018 01:21:27 +0100 Received: from BLREML503-MBS.china.huawei.com ([169.254.12.219]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0399.000; Tue, 31 Jul 2018 05:51:15 +0530 From: Rahul Arvind Jadhav To: Alan Ford CC: multipathtcp Thread-Topic: [multipathtcp] 6824bis -11 review Thread-Index: AdQmJDYhfu15UAaeTxKUY+EC058bGgARMycAAAG8pgAAHRK/4ABC3E6AAByWRxA= Date: Tue, 31 Jul 2018 00:21:14 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DC6884D@BLREML503-MBS.china.huawei.com> References: <982B626E107E334DBE601D979F31785C5DC5A15C@BLREML503-MBX.china.huawei.com> <92A53501-4728-4E02-816A-92CEE703AA49@gmail.com> <20754FD9-627F-4AAC-A1B5-6EF2BD09B2AD@gmail.com> <982B626E107E334DBE601D979F31785C5DC5D84B@BLREML503-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-IN, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.157.44] Content-Type: multipart/alternative; boundary="_000_982B626E107E334DBE601D979F31785C5DC6884DBLREML503MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [multipathtcp] 6824bis -11 review X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 00:21:33 -0000 --_000_982B626E107E334DBE601D979F31785C5DC6884DBLREML503MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCmMpIHNlbmRpbmcgYSBuZXcgQUREX0FERFIgd2l0aCBzYW1lIElEICsgYWRkcmVzcyBhbmQg ZGlmZmVyZW50IHBvcnQgaXMgZmluZQ0KW1JKXSBhZ2FpbiB0aGlzIGlzIHdoYXQgdGhlIHRleHQg YWxyZWFkeSBzYXlzLCBidXQgSeKAmW0gbm90IHN0aWxsIGNsZWFyIGFib3V0IHRoaXMuIFdoeSBJ RCArIGFkZHJlc3MgaGFzIHRvIG1hdGNoPyBPbmx5IElEIHNob3VsZCBiZSBlbm91Z2guDQoNCkNv bnNpZGVyOg0KDQphKSBBRERfQUREUiBjb21lcyBpbiBzYXlpbmcgSUQ9MiwgYWRkcj0xMC4wLjAu MSAocHJpdmF0ZSkNCmIpIE1QX0pPSU4gY29tZXMgaW4gc2F5aW5nIElEPTIsIGFkZHI9OC45LjEw LjExIChwdWJsaWMpDQpjKSBBRERfQUREUiBjb21lcyBpbiBzYXlpbmcgSUQ9MiwgYWRkcj0xOTIu MTY4LjAuMQ0KDQpXaGF0IGRvZXMgdGhpcyBtZWFuPyBJcyAoYykgYW4gaW1wbGljaXQgUkVNT1ZF K0FERD8gQW5kIHRodXMgZG9lcyB0aGlzIG1lYW4gdGhlIHN1YmZsb3cgY3JlYXRlZCBpbiAoYikg aXMgbm93IG5vIGxvbmdlciB2YWxpZD8NCg0KQnkga2VlcGluZyB0aGUgYWRkcmVzcyAvIElEIG1h cHBpbmcsIGlmIGFuIGFkZHJlc3MgaXMgbG9zdCwgdGhlbiBzbyBpcyB0aGUgc3ViZmxvdy4NCg0K W1JKMl0gUmF0aGVyIHRoYW4gdmlld2luZyAoIGMpIGFzIGFuIGltcGxpY2l0IFJFTU9WRStBREQs IGNhbiB3ZSBzZWUgaXQgYXMgYW4gVVBEQVRFPyBCZWNhdXNlIElEIHJlbWFpbnMgc2FtZS4gU3Vi ZmxvdyBjcmVhdGVkIGluIChiKSByZW1haW5zIHZhbGlkIChub3Qgc3VyZSBpZiBJ4oCZbSBtaXNz aW5nIGFueXRoaW5nIGhlcmUsIEkgc2VlIG5vIHJlYXNvbiB0byBsb3NlIHRoaXMgc3ViZmxvdyku DQpJbiBzdGVwICggYyksIHRoZSByZWNlaXZlciBjYW4gb3ZlcnJpZGUgQWRkcmVzcyBmaWVsZCBp biBjb250ZXh0IHRvIElEPTIgdG8gdGhlIG5ldyBhZGRyICgxOTIuMTY4LjAuMSkg4oCm4oCmICAg OC45LjEwLjExIGlzIGtlcHQgc2VwYXJhdGVseSBhcyB0aGUgbGVhcm50IGFjdHVhbCByY3ZkIElQ IChmcm9tIE1QX0pPSU4pIGluIHRoZSBzYW1lIGNvbnRleHQgSUQ9Mi4gV2UgaGF2ZSB0byBhZ3Jl ZSB0aGF0IGFuIGltcGxlbWVudGF0aW9uIG5lZWRzIHRvIG1haW50YWluIHRoaXMgSVAgc2VwYXJh dGVseSBpbiBjb250ZXh0IHRvIElEPTIgYW55d2F5cy4NClNvIGlmIHdlIGRvIGFuIGV4cGxpY2l0 IFJFTU9WRStBREQsIHRoZSBlbmQgcmVzdWx0IGlzIHRoZSBzYW1lIGFzIHRoaXMgVVBEQVRFIChi dXQgd2l0aCBtdWNoIGxlc3Mgb3ZlcmhlYWQgJiBpbXBsIGVhc2UpLg0KDQoNCg0K --_000_982B626E107E334DBE601D979F31785C5DC6884DBLREML503MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxl LWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Yykgc2VuZGluZyBhIG5ldyBBRERfQUREUiB3 aXRoIHNhbWUgSUQgJiM0MzsgYWRkcmVzcyBhbmQgZGlmZmVyZW50IHBvcnQgaXMgZmluZTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bUkpdIGFnYWluIHRoaXMgaXMgd2hhdCB0aGUg dGV4dCBhbHJlYWR5IHNheXMsIGJ1dCBJ4oCZbSBub3Qgc3RpbGwgY2xlYXIgYWJvdXQgdGhpcy4g V2h5IElEICYjNDM7IGFkZHJlc3MgaGFzIHRvIG1hdGNoPyBPbmx5IElEIHNob3VsZCBiZSBlbm91 Z2guJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbnNpZGVyOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hKSBBRERfQUREUiBjb21lcyBpbiBzYXlpbmcg SUQ9MiwgYWRkcj0xMC4wLjAuMSAocHJpdmF0ZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmIpIE1QX0pPSU4gY29tZXMgaW4gc2F5aW5nIElEPTIs IGFkZHI9OC45LjEwLjExIChwdWJsaWMpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5jKSBBRERfQUREUiBjb21lcyBpbiBzYXlpbmcgSUQ9MiwgYWRk cj0xOTIuMTY4LjAuMTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XaGF0IGRvZXMgdGhpcyBtZWFuPyBJcyAoYykgYW4gaW1wbGljaXQgUkVNT1ZF JiM0MztBREQ/IEFuZCB0aHVzIGRvZXMgdGhpcyBtZWFuIHRoZSBzdWJmbG93IGNyZWF0ZWQgaW4g KGIpIGlzIG5vdyBubyBsb25nZXIgdmFsaWQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ5IGtlZXBpbmcgdGhlIGFkZHJlc3MgLyBJRCBtYXBw aW5nLCBpZiBhbiBhZGRyZXNzIGlzIGxvc3QsIHRoZW4gc28gaXMgdGhlIHN1YmZsb3cuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltSSjJdIFJhdGhlciB0aGFuIHZpZXdpbmcg KCBjKSBhcyBhbiBpbXBsaWNpdCBSRU1PVkUmIzQzO0FERCwgY2FuIHdlIHNlZSBpdCBhcyBhbiBV UERBVEU/IEJlY2F1c2UgSUQgcmVtYWlucyBzYW1lLiBTdWJmbG93IGNyZWF0ZWQgaW4gKGIpIHJl bWFpbnMgdmFsaWQgKG5vdCBzdXJlDQogaWYgSeKAmW0gbWlzc2luZyBhbnl0aGluZyBoZXJlLCBJ IHNlZSBubyByZWFzb24gdG8gbG9zZSB0aGlzIHN1YmZsb3cpLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5J biBzdGVwICggYyksIHRoZSByZWNlaXZlciBjYW4gb3ZlcnJpZGUgQWRkcmVzcyBmaWVsZCBpbiBj b250ZXh0IHRvIElEPTIgdG8gdGhlIG5ldyBhZGRyICgxOTIuMTY4LjAuMSkg4oCm4oCmJm5ic3A7 Jm5ic3A7IDguOS4xMC4xMSBpcyBrZXB0IHNlcGFyYXRlbHkgYXMgdGhlIGxlYXJudCBhY3R1YWwN CiByY3ZkIElQIChmcm9tIE1QX0pPSU4pIGluIHRoZSBzYW1lIGNvbnRleHQgSUQ9Mi4gV2UgaGF2 ZSB0byBhZ3JlZSB0aGF0IGFuIGltcGxlbWVudGF0aW9uIG5lZWRzIHRvIG1haW50YWluIHRoaXMg SVAgc2VwYXJhdGVseSBpbiBjb250ZXh0IHRvIElEPTIgYW55d2F5cy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+U28gaWYgd2UgZG8gYW4gZXhwbGljaXQgUkVNT1ZFJiM0MztBREQsIHRoZSBlbmQgcmVzdWx0 IGlzIHRoZSBzYW1lIGFzIHRoaXMgVVBEQVRFIChidXQgd2l0aCBtdWNoIGxlc3Mgb3ZlcmhlYWQg JmFtcDsgaW1wbCBlYXNlKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_982B626E107E334DBE601D979F31785C5DC6884DBLREML503MBSchi_-- From nobody Tue Jul 31 05:07:15 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B541126CF7 for ; Tue, 31 Jul 2018 05:07:13 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qtc6Knd_a-zk for ; Tue, 31 Jul 2018 05:07:11 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 56742130DC2 for ; Tue, 31 Jul 2018 05:07:11 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id p6-v6so13474770ljc.5 for ; Tue, 31 Jul 2018 05:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=NlhyEe+k47JGKQm5zJldFDSAkt9zo9UF45h0gj7B7Is=; b=dnyQ12O1SnLCvpFzV7NtTKQcrPTyWTln/yuuIFohKA1Wig+jLTXtw+5Zgp8VA52uhH 1DncCBGrTBvKuxdTIbJe9rdaMv33O8lzIXF3UmZB+I/qPCtqUKa1ZNkgP67oR0Yo05CR tstaczy4Ic4pZI9VDLPGI6kkHoBeJuzIpyFToMLW10QsWifzuPVUNhVtcViZZ6q7IMx5 FaDes1ZY7EHH9M3JDcvamcZA48DninXBfjGXOBDZiyXiNOflXkyMmxGPz75JAnOM/aVW dsPQ1MAGOZ3XMp9t4EnqLc7AL19LMNFTibhsUmsrKizL30S5TYyk8+UGCGYh0xi7j4qi rKQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=NlhyEe+k47JGKQm5zJldFDSAkt9zo9UF45h0gj7B7Is=; b=IXAyh5F20tm5vuKK2/qkxz1TmXE4IoR5NdmKyzyefoo0jJU3BjlZkQ/OiSkPyAaviI yVcFnwbdSBZsIB2NLOBbk+XxpEityp9RfCX26PNrwUR08g+XRRNGO2kvVXc71WQCgWW1 bDh+QH94y2g/jwE+N0bDRMmZ0zgNWEKto6SejDJe8PzqKGNXaW9wkid0jy0llnPLXnrP RxEitnhqMnAu20EUYfDEvM+AhhGoftD9hQXvO7S8hNTgKULSBsK1V7NJfteZre8XFSqt LQWpHaE3u5XsM6EVOa/RVE40em+9+OyDkt4mHtTzH/qsPiMyqCF8ArC41/MALqvgmfRj YnNg== X-Gm-Message-State: AOUpUlGU/5jpWrFMovD/E0LXsiKylJIn1PhXGGGDEbZWoqfz63CxDOgx Ztu0SIYYBkSrRE54K0eR9T8= X-Google-Smtp-Source: AAOMgpfMkh8ZEZD9eYUbs+7cgFS5j9FxDk9aLqhItwO/yhp/0hWaavURMcuDTOTUQ8gMR6fu4eycDQ== X-Received: by 2002:a2e:712:: with SMTP id 18-v6mr17171511ljh.101.1533038829565; Tue, 31 Jul 2018 05:07:09 -0700 (PDT) Received: from [192.168.1.66] ([83.216.157.78]) by smtp.gmail.com with ESMTPSA id u24-v6sm2560539lji.4.2018.07.31.05.07.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jul 2018 05:07:08 -0700 (PDT) From: Alan Ford Message-Id: <2FB78E5E-961F-4077-815F-158142B8E7E2@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6F65341A-A73B-4610-A50F-8CEF7A28223D" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 31 Jul 2018 13:07:06 +0100 In-Reply-To: <982B626E107E334DBE601D979F31785C5DC6884D@BLREML503-MBS.china.huawei.com> Cc: multipathtcp To: Rahul Arvind Jadhav , Christoph Paasch References: <982B626E107E334DBE601D979F31785C5DC5A15C@BLREML503-MBX.china.huawei.com> <92A53501-4728-4E02-816A-92CEE703AA49@gmail.com> <20754FD9-627F-4AAC-A1B5-6EF2BD09B2AD@gmail.com> <982B626E107E334DBE601D979F31785C5DC5D84B@BLREML503-MBS.china.huawei.com> <982B626E107E334DBE601D979F31785C5DC6884D@BLREML503-MBS.china.huawei.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [multipathtcp] 6824bis -11 review X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 12:07:14 -0000 --Apple-Mail=_6F65341A-A73B-4610-A50F-8CEF7A28223D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Rahul, all, > On 31 Jul 2018, at 01:21, Rahul Arvind Jadhav = wrote: > =20 > c) sending a new ADD_ADDR with same ID + address and different port is = fine > [RJ] again this is what the text already says, but I=E2=80=99m not = still clear about this. Why ID + address has to match? Only ID should be = enough.=20 > =20 > Consider: > =20 > a) ADD_ADDR comes in saying ID=3D2, addr=3D10.0.0.1 (private) > b) MP_JOIN comes in saying ID=3D2, addr=3D8.9.10.11 (public) > c) ADD_ADDR comes in saying ID=3D2, addr=3D192.168.0.1 > =20 > What does this mean? Is (c) an implicit REMOVE+ADD? And thus does this = mean the subflow created in (b) is now no longer valid? > =20 > By keeping the address / ID mapping, if an address is lost, then so is = the subflow. > =20 > [RJ2] Rather than viewing ( c) as an implicit REMOVE+ADD, can we see = it as an UPDATE? Because ID remains same. Subflow created in (b) remains = valid (not sure if I=E2=80=99m missing anything here, I see no reason to = lose this subflow). > In step ( c), the receiver can override Address field in context to = ID=3D2 to the new addr (192.168.0.1) =E2=80=A6=E2=80=A6 8.9.10.11 is = kept separately as the learnt actual rcvd IP (from MP_JOIN) in the same = context ID=3D2. We have to agree that an implementation needs to = maintain this IP separately in context to ID=3D2 anyways. > So if we do an explicit REMOVE+ADD, the end result is the same as this = UPDATE (but with much less overhead & impl ease). I would be interested in hearing from other implementers here=E2=80=A6 = Is there an issue with =E2=80=9Cupdating=E2=80=9D using ADD_ADDR? Given we say that REMOVE_ADDR should not remove a subflow if it=E2=80=99s = still alive, we have precedent for implying a subflow can exist to an = address which does not have an Address ID - to - IP address mapping. So given that, does updating, as Rahul suggests, cause a problem? Best regards, Alan --Apple-Mail=_6F65341A-A73B-4610-A50F-8CEF7A28223D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Rahul, all,

On 31 Jul 2018, at 01:21, Rahul Arvind Jadhav = <rahul.jadhav@huawei.com> wrote:
 
c) sending a new = ADD_ADDR with same ID + address and different port is fine
[RJ] again this is what the text already says, but I=E2=80=99m = not still clear about this. Why ID + address has to match? Only ID = should be enough. 
 
Consider:
 
a) ADD_ADDR = comes in saying ID=3D2, addr=3D10.0.0.1 (private)
b) MP_JOIN comes in saying ID=3D2, addr=3D8.9.10.11 = (public)
c) ADD_ADDR comes in = saying ID=3D2, addr=3D192.168.0.1
 
What does this mean? Is (c) an implicit = REMOVE+ADD? And thus does this mean the subflow created in (b) is now no = longer valid?
 
By keeping the address / ID mapping, if = an address is lost, then so is the subflow.
 
[RJ2] Rather than = viewing ( c) as an implicit REMOVE+ADD, can we see it as an UPDATE? = Because ID remains same. Subflow created in (b) remains valid (not sure = if I=E2=80=99m missing anything here, I see no reason to lose this = subflow).
In step ( c), the = receiver can override Address field in context to ID=3D2 to the new addr = (192.168.0.1) =E2=80=A6=E2=80=A6   8.9.10.11 is kept = separately as the learnt actual rcvd IP (from MP_JOIN) in the same = context ID=3D2. We have to agree that an implementation needs to = maintain this IP separately in context to ID=3D2 anyways.
So if we do an explicit = REMOVE+ADD, the end result is the same as this UPDATE (but with much = less overhead & impl = ease).

I would be interested in hearing from other = implementers here=E2=80=A6 Is there an issue with =E2=80=9Cupdating=E2=80=9D= using ADD_ADDR?

Given we say that REMOVE_ADDR should not remove a subflow if = it=E2=80=99s still alive, we have precedent for implying a subflow can = exist to an address which does not have an Address ID - to - IP address = mapping.

So = given that, does updating, as Rahul suggests, cause a problem?

Best regards,
Alan

= --Apple-Mail=_6F65341A-A73B-4610-A50F-8CEF7A28223D--