From lars@netapp.com Thu Aug 1 00:43:22 2013 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 8258A21F8EB2 for ; Thu, 1 Aug 2013 00:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.032 X-Spam-Level: X-Spam-Status: No, score=-5.032 tagged_above=-999 required=5 tests=[AWL=-2.433, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqVfn74B4MWR for ; Thu, 1 Aug 2013 00:43:17 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7033D21F9D53 for ; Thu, 1 Aug 2013 00:43:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,792,1367996400"; d="asc'?scan'208";a="38097390" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 01 Aug 2013 00:43:15 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.240]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Thu, 1 Aug 2013 00:43:15 -0700 From: "Eggert, Lars" To: Multipath TCP Mailing List Thread-Topic: standards track now Thread-Index: AQHOjorHlyUJtWggVEOPGo7OEq8mnQ== Date: Thu, 1 Aug 2013 07:43:14 +0000 Message-ID: <86D5F8DA-93EE-4F17-BBCE-C61F410829AE@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.114] Content-Type: multipart/signed; boundary="Apple-Mail=_3759AFC5-FC68-4932-A2EE-D8CB3BE5C79B"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: [multipathtcp] standards track now X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 07:43:22 -0000 --Apple-Mail=_3759AFC5-FC68-4932-A2EE-D8CB3BE5C79B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, as I just said during TSVAREA, I think we should recharter the WG to = allow work on a PS spec now. The issues that remain to be worked on a clearly tractable and can be = resolved during the normal process of pushing an ID towards RFC = publication. Lars --Apple-Mail=_3759AFC5-FC68-4932-A2EE-D8CB3BE5C79B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQCVAwUBUfoRkdZcnpRveo1xAQLJHAQAkr1y9DeQCMF4xzXuTkccbdndGvjEtVYc JSmr/HjtdoIe4QXbLo59Hozb4eksvbk0x45ASgDgAHj6WM1InO72U1RqNePiJ9mk CGzNc246DXJLr2Jrp+2RTFGGNgpyyATz/ILE52q3+NdDcj5q6b7AxMn2+440bm72 zy2DWfoI5LQ= =t+Mr -----END PGP SIGNATURE----- --Apple-Mail=_3759AFC5-FC68-4932-A2EE-D8CB3BE5C79B-- From swb@internet2.edu Thu Aug 1 00:58:08 2013 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 2DFEB21F9ADD for ; Thu, 1 Aug 2013 00:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2QGTOe4vqb0 for ; Thu, 1 Aug 2013 00:58:02 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 908A221F9AD8 for ; Thu, 1 Aug 2013 00:58:02 -0700 (PDT) Received: from mail111-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.22; Thu, 1 Aug 2013 07:58:01 +0000 Received: from mail111-va3 (localhost [127.0.0.1]) by mail111-va3-R.bigfish.com (Postfix) with ESMTP id 874D924019F; Thu, 1 Aug 2013 07:58:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.232.53; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0811HT002.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: S-1(zzbb2dI98dI154cP1432Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz8275ch17326ah1de096h1de097hz2dh2a8h668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h18e1h190ch1946h19b4h19c3h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1f5fh1b1cn1b1bi1155h) Received: from mail111-va3 (localhost.localdomain [127.0.0.1]) by mail111-va3 (MessageSwitch) id 1375343879495076_2164; Thu, 1 Aug 2013 07:57:59 +0000 (UTC) Received: from VA3EHSMHS036.bigfish.com (unknown [10.7.14.253]) by mail111-va3.bigfish.com (Postfix) with ESMTP id 73E3EA0047; Thu, 1 Aug 2013 07:57:59 +0000 (UTC) Received: from BLUPRD0811HT002.namprd08.prod.outlook.com (157.56.232.53) by VA3EHSMHS036.bigfish.com (10.7.99.46) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 1 Aug 2013 07:57:59 +0000 Received: from dhcp-1668.meeting.ietf.org (130.129.22.104) by pod51019.outlook.com (10.255.123.37) with Microsoft SMTP Server (TLS) id 14.16.341.1; Thu, 1 Aug 2013 07:57:58 +0000 Message-ID: <51FA1504.6030001@internet2.edu> Date: Thu, 1 Aug 2013 09:57:56 +0200 From: Scott Brim Organization: Internet2 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Eggert, Lars" References: <86D5F8DA-93EE-4F17-BBCE-C61F410829AE@netapp.com> In-Reply-To: <86D5F8DA-93EE-4F17-BBCE-C61F410829AE@netapp.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [130.129.22.104] X-OriginatorOrg: internet2.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] standards track now X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 07:58:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/01/13 09:43, Eggert, Lars allegedly wrote: > Hi, > > as I just said during TSVAREA, I think we should recharter the WG > to allow work on a PS spec now. > > The issues that remain to be worked on a clearly tractable and can > be resolved during the normal process of pushing an ID towards RFC > publication. > > Lars I'm going to be the person who says "let's not be hasty". (1) A fundamental point in MPTCP is balancing traffic on subflows and overall coordinated congestion management. Ramin Khalili's presentation showed that what we have so far seems pretty experimental, and we're essentially still at the research stage. (2) NATs are real, so ADD_ADDR is going to get used, but it's a security hole. That's "clearly tractable" but what we have now is not ready for even limited deployment. Maybe ADD_ADDR should be taken out of the standards track docs and added later. Scott -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlH6FQQACgkQF0TR2hENFARCdACfVOVd1qXv0bnB5LJEOTqNJ4BD BmkAn0Au+FfCvkURa1AlxFVfvbE0mNlK =POc0 -----END PGP SIGNATURE----- From lars@netapp.com Thu Aug 1 01:04:43 2013 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 184D521F9E04 for ; Thu, 1 Aug 2013 01:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.987 X-Spam-Level: X-Spam-Status: No, score=-8.987 tagged_above=-999 required=5 tests=[AWL=1.612, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swRoIx7XmnLA for ; Thu, 1 Aug 2013 01:04:38 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id EBE9921F94FF for ; Thu, 1 Aug 2013 01:04:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,792,1367996400"; d="asc'?scan'208";a="77641295" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx12-out.netapp.com with ESMTP; 01 Aug 2013 01:04:37 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.240]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Thu, 1 Aug 2013 01:04:37 -0700 From: "Eggert, Lars" To: Scott Brim Thread-Topic: [multipathtcp] standards track now Thread-Index: AQHOjorHlyUJtWggVEOPGo7OEq8mnZmAce0AgAAB24A= Date: Thu, 1 Aug 2013 08:04:36 +0000 Message-ID: <808EF0C3-6A1F-4A81-93C3-7011E4AB3938@netapp.com> References: <86D5F8DA-93EE-4F17-BBCE-C61F410829AE@netapp.com> <51FA1504.6030001@internet2.edu> In-Reply-To: <51FA1504.6030001@internet2.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: multipart/signed; boundary="Apple-Mail=_3572809D-5359-49CA-BAC9-7BF4639027D8"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] standards track now X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 08:04:43 -0000 --Apple-Mail=_3572809D-5359-49CA-BAC9-7BF4639027D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On Aug 1, 2013, at 9:57, Scott Brim wrote: > I'm going to be the person who says "let's not be hasty". >=20 > (1) A fundamental point in MPTCP is balancing traffic on subflows and > overall coordinated congestion management. Ramin Khalili's > presentation showed that what we have so far seems pretty > experimental, and we're essentially still at the research stage. right. But we can start the work on 6824bis now, and not yet start = 6356bis until this has been investigated more. We will probably want a normative reference from 6824bis to 6536bis, so = we can't actually publish 6824bis before finishing 6356bis. But we can = start the work on 6824bis. > (2) NATs are real, so ADD_ADDR is going to get used, but it's a > security hole. That's "clearly tractable" but what we have now is not > ready for even limited deployment. Maybe ADD_ADDR should be taken out > of the standards track docs and added later. Sure, that's a discussion we can have. But we can have it during the = work on draft-ietf-rfc6824bis, right? Lars PS: Phil pointed out to me that the WG is already chartered for PS work, = so no recharter needed. --Apple-Mail=_3572809D-5359-49CA-BAC9-7BF4639027D8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQCVAwUBUfoWk9ZcnpRveo1xAQI8QQP+IKDhbC+vmEWAEujNX1v+IhUaPWAS/QYJ KoxRVpnlpvEbaiIo5GDz1rtT6h5YIBFxCX70PdU12LljJuDi0BUJEqPGH850ixev jzgJqneI+BI7fqT9d6Mr3C6i9EcliDy5+Bi6jn+yC82y6Y0+ohb8AMfrUHS5nGWb pD9U3Wlx1aI= =a0LU -----END PGP SIGNATURE----- --Apple-Mail=_3572809D-5359-49CA-BAC9-7BF4639027D8-- From grmocg@gmail.com Thu Aug 1 01:07:06 2013 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 460AB21F859B for ; Thu, 1 Aug 2013 01:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFfe4bFLpVUx for ; Thu, 1 Aug 2013 01:07:05 -0700 (PDT) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 43C8E21F9BB6 for ; Thu, 1 Aug 2013 01:07:02 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id i10so3633786oag.2 for ; Thu, 01 Aug 2013 01:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sibl7A597CD75QR6hcsk+bOb05zvAQeasI/UnRJNJEQ=; b=NOfphDXPtU/b5vjvZHxCzrHaq0WH1R6vym0J+G/QZGDsWWJ3pUzKF2T3jClXcoaD9Y d403RO2AhrUE5y/pOk+jET/ry7slaSshd/9WYlG3dOjJhumk5Xn9LIboWcMUYQ0Ma1hJ oIbF+1s9gw+3PqQsFCwqnYGmsj0KD7exH7sDWB3VJt9Ne6QhW8hAbgK3TzfXd1TB2Gne 5LNlCw31Oy0rAJWJ6wZ/kCxo5pWPy6HXvSxkDYwd9L5AI+Qx339IOnvWpDx5ljiaaWkh CajEM+VIt+teeRvDMFkVuSCuzEf5vZ/OVvPrXRw9YTccybdqULekEZj5rYAIQON/ilfz cPuQ== MIME-Version: 1.0 X-Received: by 10.182.87.198 with SMTP id ba6mr218848obb.71.1375344421735; Thu, 01 Aug 2013 01:07:01 -0700 (PDT) Received: by 10.76.91.229 with HTTP; Thu, 1 Aug 2013 01:07:01 -0700 (PDT) In-Reply-To: <51FA1504.6030001@internet2.edu> References: <86D5F8DA-93EE-4F17-BBCE-C61F410829AE@netapp.com> <51FA1504.6030001@internet2.edu> Date: Thu, 1 Aug 2013 10:07:01 +0200 Message-ID: From: Roberto Peon To: Scott Brim Content-Type: multipart/alternative; boundary=089e0111c03ab3952c04e2de5380 Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] standards track now X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 08:07:06 -0000 --089e0111c03ab3952c04e2de5380 Content-Type: text/plain; charset=ISO-8859-1 ADD_ADDR and similar man-in-the-middle policy generation allows for cheap successful semi-passive attacks whereby traffic is moved through a centralized proxy which analyzes the content or metadata for that content. I am not sure that these mechanisms will survive review by the security working group without significant change, and as a result, I'm not sure if this is the time to be going for RFC if it includes these features (which, are essentially fundamental to the protocol's advantages....) -=R On Thu, Aug 1, 2013 at 9:57 AM, Scott Brim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/01/13 09:43, Eggert, Lars allegedly wrote: > > Hi, > > > > as I just said during TSVAREA, I think we should recharter the WG > > to allow work on a PS spec now. > > > > The issues that remain to be worked on a clearly tractable and can > > be resolved during the normal process of pushing an ID towards RFC > > publication. > > > > Lars > > I'm going to be the person who says "let's not be hasty". > > (1) A fundamental point in MPTCP is balancing traffic on subflows and > overall coordinated congestion management. Ramin Khalili's > presentation showed that what we have so far seems pretty > experimental, and we're essentially still at the research stage. > > (2) NATs are real, so ADD_ADDR is going to get used, but it's a > security hole. That's "clearly tractable" but what we have now is not > ready for even limited deployment. Maybe ADD_ADDR should be taken out > of the standards track docs and added later. > > Scott > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.13 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlH6FQQACgkQF0TR2hENFARCdACfVOVd1qXv0bnB5LJEOTqNJ4BD > BmkAn0Au+FfCvkURa1AlxFVfvbE0mNlK > =POc0 > -----END PGP SIGNATURE----- > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > --089e0111c03ab3952c04e2de5380 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
ADD_ADDR and similar man-in-the-middle policy generation a= llows for cheap successful semi-passive attacks whereby traffic is moved th= rough a centralized proxy which analyzes the content or metadata for that c= ontent.

I am not sure that these mechanisms will survive review by t= he security working group without significant change, and as a result, I= 9;m not sure if this is the time to be going for RFC if it includes these f= eatures (which, are essentially fundamental to the protocol's advantage= s....)

-=3DR


On Thu, Aug 1, 2013 at 9:57 AM, Scott Brim <swb@in= ternet2.edu> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/01/13 09:43, Eggert, Lars allegedly wrote:
> Hi,
>
> as I just said during TSVAREA, I think we should recharter the WG
> to allow work on a PS spec now.
>
> The issues that remain to be worked on a clearly tractable and can
> be resolved during the normal process of pushing an ID towards RFC
> publication.
>
> Lars

I'm going to be the person who says "let's not be = hasty".

(1) A fundamental point in MPTCP is balancing traffic on subflows and
overall coordinated congestion management. =A0Ramin Khalili's
presentation showed that what we have so far seems pretty
experimental, and we're essentially still at the research stage.

(2) NATs are real, so ADD_ADDR is going to get used, but it's a
security hole. =A0That's "clearly tractable" but what we have= now is not
ready for even limited deployment. =A0Maybe ADD_ADDR should be taken out of the standards track docs and added later.

Scott
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlH6FQQACgkQF0TR2hENFARCdACfVOVd1qXv0bnB5LJEOTqNJ4BD
BmkAn0Au+FfCvkURa1AlxFVfvbE0mNlK
=3DPOc0
-----END PGP SIGNATURE-----

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

--089e0111c03ab3952c04e2de5380-- From olivier.bonaventure@uclouvain.be Thu Aug 1 01:39:03 2013 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 7DE2121F9D98 for ; Thu, 1 Aug 2013 01:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJ2stfHNsZ9p for ; Thu, 1 Aug 2013 01:38:58 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id E531021F9DB0 for ; Thu, 1 Aug 2013 01:38:52 -0700 (PDT) Received: from dhcp-90b2.meeting.ietf.org (unknown [172.17.0.12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id AA8FE1C70A0; Thu, 1 Aug 2013 10:38:45 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be AA8FE1C70A0 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1375346325; bh=OdvNpx6/+d9KLpXcNgt36YmtFYaf7SAycF85aQmY4Ss=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=PAGojTAYMbwijCVDXs98vt5q3odT0rweThbaiahQxFm/zyagXJg5FdTH7fiGAY25k jqxW33DNA7jby1xn8y6x+rJr0zzXlYyUbtP4Ay8AlChE0ukpy5WOgkFul8lP9+Ez9c FtxgZcDCfGZ7ntH97MdTwaGrLXzr6cGqQ7d9aLIk= Message-ID: <51FA1EF5.3030007@uclouvain.be> Date: Thu, 01 Aug 2013 10:40:21 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Scott Brim References: <86D5F8DA-93EE-4F17-BBCE-C61F410829AE@netapp.com> <51FA1504.6030001@internet2.edu> In-Reply-To: <51FA1504.6030001@internet2.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: AA8FE1C70A0.A58F2 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] standards track now X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 08:39:03 -0000 Scott, >> >> as I just said during TSVAREA, I think we should recharter the WG >> to allow work on a PS spec now. >> >> The issues that remain to be worked on a clearly tractable and can >> be resolved during the normal process of pushing an ID towards RFC >> publication. >> >> Lars > > I'm going to be the person who says "let's not be hasty". > (1) A fundamental point in MPTCP is balancing traffic on subflows and > overall coordinated congestion management. Ramin Khalili's > presentation showed that what we have so far seems pretty > experimental, and we're essentially still at the research stage. Experience with congestion control schemes shows that improvements are possible. For TCP, this started in 1988 and hasn't yet stopped. The IETF has basically opted for NewReno like congestion control scheme for single path TCP despite the fact that there have been other proposals. Several TCP stacks have used different congestion control schemes. For Multipath TCP, history repeats. This is not surprising. OLIA improves LIA, like several unipath congestion control schemes improve NewReno... > (2) NATs are real, so ADD_ADDR is going to get used, but it's a > security hole. That's "clearly tractable" but what we have now is not > ready for even limited deployment. Maybe ADD_ADDR should be taken out > of the standards track docs and added later. ADD_ADDR may cause a security issue, as identified by Marcelo's draft, but this issue can be easily fixed. The discussion that needs to be done in the mptcp working group is whether we want to have the current ADD_ADDR capability os not. We have to look at the use cases for ADD_ADDR. The current implementations tend to either open subflows only from the client side, or only open one subflow at a time. In these cases, there is no benefit for the client to send ADD_ADDR (REMOVE_ADDR still makes sense to indicate that an address does not work anymore). The main benefit that I see currently from ADD_ADDR is for multihomed servers (currently probably a small fraction of the servers) and dual-stack servers (hopefully a growing fraction of the servers). I see benefits with ADD_ADDR on dual-stack servers to allow the client to learn easily the other address of the server. Thus the important question for me is whether we want the ability to exchange IP address information within Multipath TCP. I think that there are interesting use cases for that. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From mark@handley.org.uk Thu Aug 1 02:10:40 2013 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 BDFE921F9BF1 for ; Thu, 1 Aug 2013 02:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5520zgokhnS4 for ; Thu, 1 Aug 2013 02:10:34 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id DC07021F9D1B for ; Thu, 1 Aug 2013 02:10:23 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C88312118E; Thu, 1 Aug 2013 05:10:07 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Thu, 01 Aug 2013 05:10:07 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=dG0z2v2zbAznWY7V7AbhXABrLBo=; b=Bz7 TK9pePANwhzR4kL2nf/cRibjtvvuyWtjo7adXlwGRTJdp3gIS3Q+rSP0hs0iNaJK /u0D1uctL9+G+xPxmqq4doTTAr/eV+5pCL0KYg+8vsJRRO7byuUXOqZOccqwUkZ1 zjs/nR9Wj/7ZcVTUw4bduyA9ZgZWN4Pph/ZrUSS8= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id A2433B01FCB; Thu, 1 Aug 2013 05:10:07 -0400 (EDT) Message-Id: <1375348207.14729.4222255.3089DAA8@webmail.messagingengine.com> X-Sasl-Enc: YqUWyGcbQ+H8kZA9LPcA3BGWGt1s4G5zPG7XTXTJDUOI 1375348207 From: Mark Handley To: Scott Brim , "Eggert, Lars" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-2d520484 In-Reply-To: <51FA1504.6030001@internet2.edu> References: <86D5F8DA-93EE-4F17-BBCE-C61F410829AE@netapp.com> <51FA1504.6030001@internet2.edu> Date: Thu, 01 Aug 2013 02:10:07 -0700 Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] standards track now X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:10:40 -0000 On Thu, Aug 1, 2013, at 12:57 AM, Scott Brim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > I'm going to be the person who says "let's not be hasty". > > (1) A fundamental point in MPTCP is balancing traffic on subflows and > overall coordinated congestion management. Ramin Khalili's > presentation showed that what we have so far seems pretty > experimental, and we're essentially still at the research stage. As Olivier has said, I don't think any of us claimed LIA was the ultimate MPTCP congestion control. It's likely to be safe though, and that has been a good starting point, just the same was that TCP Tahoe was a good starting point back in 1988. > (2) NATs are real, so ADD_ADDR is going to get used, but it's a > security hole. That's "clearly tractable" but what we have now is not > ready for even limited deployment. Maybe ADD_ADDR should be taken out > of the standards track docs and added later. Part of the problem with the current ADD_ADDR mechanism is that we don't negotiate its use. ADD_ADDR is probably safe and may be useful in environments such as a datacenter, where on-path hijack is not an issue. Sure, you can have the server connect back to the client in those cases, but things get more complicated controlling which subflows are set up if both ends are doing it. Out in the public Internet, ADD_ADDR's authentication may be unacceptably week because if its ability to turn a passive eavesdropper into an active man-in-the-middle. The only way around this seems to be strong crypto - we spent a _lot_ of time looking for alternatives, but in the presence of NATs, there's nothing else stable to bind the authentication to. And we didn't really want to mandate strong crypto within MPTCP. [well, I did, hence tcpcrypt, but there's not consensus on that] For this, the simplest useful solution comes from Christophe and Olivier - allow the app to supply the secret. This is especially useful when the app uses TLS or ssh, and the trend is in that direction anyway. What's missing is MPTCP's ability to signal that this is the ADD_ADDR mechanism the endpoints will use. In my view, this is probably something we should change. - Mark From c.raiciu@cs.ucl.ac.uk Thu Aug 1 04:34:21 2013 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 A42D321E80BC for ; Thu, 1 Aug 2013 04:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hDZidrdfSbg for ; Thu, 1 Aug 2013 04:34:15 -0700 (PDT) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by ietfa.amsl.com (Postfix) with ESMTP id 88C4D21E80B2 for ; Thu, 1 Aug 2013 04:34:15 -0700 (PDT) Received: from [213.233.85.6] (helo=[192.168.43.231]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1V4r8y-0001rm-IC; Thu, 01 Aug 2013 12:34:10 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Costin Raiciu In-Reply-To: <1375348207.14729.4222255.3089DAA8@webmail.messagingengine.com> Date: Thu, 1 Aug 2013 14:33:22 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <828408D9-4A2A-45EB-857B-69BF0D7FD476@cs.ucl.ac.uk> References: <86D5F8DA-93EE-4F17-BBCE-C61F410829AE@netapp.com> <51FA1504.6030001@internet2.edu> <1375348207.14729.4222255.3089DAA8@webmail.messagingengine.com> To: Mark Handley X-Mailer: Apple Mail (2.1085) Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] standards track now X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 11:34:21 -0000 I strongly support going to standards track. There is a lot of interest = in MPTCP and real deployment seems likely in the near future. As for the two issues brought up: - The security issues are solvable (see discussion below) albeit without = strong crypto we will have to restrict the use cases for MPTCP. - The congestion control is safe and works - if we wait for the perfect = controller we might wait forever. Now the discussion about MPTCP security and redirection.=20 I will start by saying that I like ADD_ADDR because it allows = flexiblity: - one can insert explicit middleboxes on path (there were two bofs at = this ietf that would like to have this) - one can use v4 and v6 in the same tcp connection (without add_addr = this is not possible);=20 - it allows mobility even when the other end is behind a NAT On the security front, I think we are raising the bar for MPTCP a bit = too high, given that today on-path boxes can also redirect TCP by: - tunneling data to another middlebox - by using MPLS / Openflow/any other routing.=20 In fact many networks mess with TCP connections, and can apply any of = the attacks that are possible with MPTCP redirections, albeit only in = the same administrative domain. One positive aspect of MPTCP = redirections is that they are explicit: at least the endpoints know the = connection is being redirected (which is not the case today with all = these transparent boxes and routing tricks!).=20 Coming back to MPTCP attacks. there are two ways we can make MPTCP more = secure. 1) MPTCP with plaintext keys.=20 ADD_ADDR is not the only issue - it's just the most obvious one. The = attacks draft shows that an off-path attacker can hijack the connection = by using the ADD_ADDR (with a bit of effort). As mentioned, this attack = is easy to counter by adding an HMAC or the token to the ADD_ADDR.=20 An on-path attacker, however, can still use ADD_ADDR because it knows = the keys. So to stop these guys we must drop ADD_ADDR altogether.=20 However, even removing ADD_ADDR does not completely solve the hijacking = issue. Anyone on path can snoop on the initial handshake and learn the = key. With the key, this attacker can go off-path and start two subflows, = one to the client and one to the server (it knows the crypto material), = and proxy the data between the two. This attack does not use ADD_ADDR = and is relatively easy to execute. One way to stop this attack is to = mandate that all subflows are opened in the same direction as the intial = one; this allows client mobility, but does not allow server mobility = (except make before break if we allow ADD_ADDR). In summary: by removing ADD_ADDR and restricting the direction in which = subflows can be opened MPTCP redirection is not possible anymore even = for on path attackers. However, while doing this we lose flexiblity - = server mobility is not possible anymore, v4+v6 mptcp connections are not = possible anymore, etc.=20 2) For traffic people care about, TLS is used with TCP today. The same = will be true with MPTCP: sensitive traffic will run over TLS. In this = context, since the data is encrypted, even if traffic is redirected it = doesn't really matter - so I think we should allow ADD_ADDR without any = extra authentication needed (i.e. leave it as it is today). =20 Of course if we have a secret key between the endpoints we can restrict = sending ADD_ADDR to the connection endpoints. However, the fact that = on-path middleboxes can also use it is a bonus in my view, because it = allows operators to route the traffic via middleboxes (which they = already do!) but in an explicit way - at least the endpoints know about = the redirection. Cheers, Costin From elopez@fortinet.com Thu Aug 1 05:25:52 2013 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 CB29721E81F2 for ; Thu, 1 Aug 2013 05:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wMCTivyW0zV for ; Thu, 1 Aug 2013 05:25:47 -0700 (PDT) Received: from smtp.fortinet.com (smtp.fortinet.com [208.91.113.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0539E21E80D3 for ; Thu, 1 Aug 2013 05:21:18 -0700 (PDT) From: Edward Lopez To: Multipath TCP Mailing List Thread-Topic: [multipathtcp] standards track now Thread-Index: AQHOjorHlyUJtWggVEOPGo7OEq8mnZmAce0AgAAUK4CAACgGAIAADV0A Date: Thu, 1 Aug 2013 12:21:13 +0000 Message-ID: <7E5B399E-A243-40D4-BA7F-C8CB40ECD9B4@fortinet.com> References: <86D5F8DA-93EE-4F17-BBCE-C61F410829AE@netapp.com> <51FA1504.6030001@internet2.edu> <1375348207.14729.4222255.3089DAA8@webmail.messagingengine.com> <828408D9-4A2A-45EB-857B-69BF0D7FD476@cs.ucl.ac.uk> In-Reply-To: <828408D9-4A2A-45EB-857B-69BF0D7FD476@cs.ucl.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.22.151] Content-Type: multipart/alternative; boundary="_000_7E5B399EA24340D4BA7FC8CB40ECD9B4fortinetcom_" MIME-Version: 1.0 Subject: Re: [multipathtcp] standards track now X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 12:25:53 -0000 --_000_7E5B399EA24340D4BA7FC8CB40ECD9B4fortinetcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I feel that we have not given due consideration to the role of middleboxe= s here. Middleboxes providing proxy and DPI services will not function c= orrectly if they do not have visibility of all sub-flows. The idea of removing ADD_ADDR and restricting sub-flow direction will lik= ely result in middleboxes forcing fallback to standard tcp, upon detectio= n of an mptcp stream. Consider the case of of IPS device, which might be= required to be in place due to regulation (such as PCI-DSS). Such a dev= ice, without recourse to redirect sub-flows, would have to view mptcp as = an evasion attack. I do recognize the problem here. I see middleboxes potentially participa= ting with mptcp in a relay and proxy mode. By relay mode, this is where= a given middlebox has visibility to all sub-flows. It is likely that th= e ability to create this relay (a benevolent MitM per se) would require t= he ADD_ADDR function. In a proxy mode, a middlebox may actually receive = standard tcp or mptcp sessions, and proxy them into new mptcp sessions. = I sense that this form of middlebox as an mptcp proxy will be a more like= ly use case, which must be explored in depth. Rdgs, Ed Lopez On Aug 1, 2013, at 7:33 AM, Costin Raiciu > wrote: I strongly support going to standards track. There is a lot of interest = in MPTCP and real deployment seems likely in the near future. As for the two issues brought up: - The security issues are solvable (see discussion below) albeit without = strong crypto we will have to restrict the use cases for MPTCP. - The congestion control is safe and works - if we wait for the perfect c= ontroller we might wait forever. Now the discussion about MPTCP security and redirection. I will start by saying that I like ADD_ADDR because it allows flexiblity:= - one can insert explicit middleboxes on path (there were two bofs at thi= s ietf that would like to have this) - one can use v4 and v6 in the same tcp connection (without add_addr this= is not possible); - it allows mobility even when the other end is behind a NAT On the security front, I think we are raising the bar for MPTCP a bit too= high, given that today on-path boxes can also redirect TCP by: - tunneling data to another middlebox - by using MPLS / Openflow/any other routing. In fact many networks mess with TCP connections, and can apply any of the= attacks that are possible with MPTCP redirections, albeit only in the sa= me administrative domain. One positive aspect of MPTCP redirections is t= hat they are explicit: at least the endpoints know the connection is bein= g redirected (which is not the case today with all these transparent boxe= s and routing tricks!). Coming back to MPTCP attacks. there are two ways we can make MPTCP more s= ecure. 1) MPTCP with plaintext keys. ADD_ADDR is not the only issue - it's just the most obvious one. The atta= cks draft shows that an off-path attacker can hijack the connection by us= ing the ADD_ADDR (with a bit of effort). As mentioned, this attack is eas= y to counter by adding an HMAC or the token to the ADD_ADDR. An on-path attacker, however, can still use ADD_ADDR because it knows the= keys. So to stop these guys we must drop ADD_ADDR altogether. However, even removing ADD_ADDR does not completely solve the hijacking = issue. Anyone on path can snoop on the initial handshake and learn the ke= y. With the key, this attacker can go off-path and start two subflows, on= e to the client and one to the server (it knows the crypto material), and= proxy the data between the two. This attack does not use ADD_ADDR and is= relatively easy to execute. One way to stop this attack is to mandate t= hat all subflows are opened in the same direction as the intial one; this= allows client mobility, but does not allow server mobility (except make = before break if we allow ADD_ADDR). In summary: by removing ADD_ADDR and restricting the direction in which s= ubflows can be opened MPTCP redirection is not possible anymore even for = on path attackers. However, while doing this we lose flexiblity - server = mobility is not possible anymore, v4+v6 mptcp connections are not possibl= e anymore, etc. 2) For traffic people care about, TLS is used with TCP today. The same wi= ll be true with MPTCP: sensitive traffic will run over TLS. In this conte= xt, since the data is encrypted, even if traffic is redirected it doesn't= really matter - so I think we should allow ADD_ADDR without any extra au= thentication needed (i.e. leave it as it is today). Of course if we have a secret key between the endpoints we can restrict s= ending ADD_ADDR to the connection endpoints. However, the fact that on-pa= th middleboxes can also use it is a bonus in my view, because it allows o= perators to route the traffic via middleboxes (which they already do!) bu= t in an explicit way - at least the endpoints know about the redirection.= Cheers, Costin _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp *** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. *** --_000_7E5B399EA24340D4BA7FC8CB40ECD9B4fortinetcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <90D015921672314A80FAEDDADE3F7086@fortinet-us.com> Content-Transfer-Encoding: quoted-printable
I feel that we have not given due consideration to the role of middl= eboxes here.  Middleboxes providing proxy and DPI services will not = function correctly if they do not have visibility of all sub-flows.  = ;

The idea of removing ADD_ADDR and restricting sub-flow direction wil= l likely result in middleboxes forcing fallback to standard tcp, upon det= ection of an mptcp stream.  Consider the case of of IPS device, whic= h might be required to be in place due to regulation (such as PCI-DSS).  Such a device, without recourse to redirect sub= -flows, would have to view mptcp as an evasion attack.

I do recognize the problem here.  I see middleboxes potentially= participating with mptcp in a relay and proxy mode.   By relay mode= , this is where a given middlebox has visibility to all sub-flows.  = It is likely that the ability to create this relay (a benevolent MitM per se) would require the ADD_ADDR function.  In a = proxy mode, a middlebox may actually receive standard tcp or mptcp sessio= ns, and proxy them into new mptcp sessions.  I sense that this form = of middlebox as an mptcp proxy will be a more likely use case, which must be explored in depth.

Rdgs,
Ed Lopez


On Aug 1, 2013, at 7:33 AM, Costin Raiciu <c.raiciu@cs.ucl.ac.uk> wrote:

I strongly support  going to standards tra= ck. There is a lot of interest in MPTCP and real deployment seems likely = in the near future.

As for the two issues brought up:
- The security issues are solvable (see discussion below) albeit without = strong crypto we will have to restrict the use cases for MPTCP.
- The congestion control is safe and works - if we wait for the perfect c= ontroller we might wait forever.

Now the discussion about MPTCP security and redirection.

I will start by saying that I like ADD_ADDR because it allows flexiblity:=
- one can insert explicit middleboxes on path (there were two bofs at thi= s ietf that would like to have this)
- one can use v4 and v6 in the same tcp connection (without add_addr this= is not possible);
- it allows mobility even when the other end is behind a NAT

On the security front, I think we are raising the bar for MPTCP a bit too= high, given that today on-path boxes can also redirect TCP by:
-  tunneling data to another middlebox
- by using MPLS / Openflow/any other routing.
In fact many networks mess with TCP connections, and can apply any of the= attacks that are possible with MPTCP redirections, albeit only in the sa= me administrative domain.  One positive aspect of MPTCP redirections= is that they are explicit: at least the endpoints know the connection is being redirected (which is not the case today wit= h all these transparent boxes and routing tricks!).

Coming back to MPTCP attacks. there are two ways we can make MPTCP more s= ecure.

1) MPTCP with plaintext keys.

ADD_ADDR is not the only issue - it's just the most obvious one. The atta= cks draft shows that an off-path attacker can hijack the connection by us= ing the ADD_ADDR (with a bit of effort). As mentioned, this attack is eas= y to counter by adding an HMAC or the token to the ADD_ADDR.

An on-path attacker, however, can still use ADD_ADDR because it knows the= keys. So to stop these guys we must drop ADD_ADDR altogether.

However, even removing ADD_ADDR  does not completely solve the hijac= king issue. Anyone on path can snoop on the initial handshake and learn t= he key. With the key, this attacker can go off-path and start two subflow= s, one to the client and one to the server (it knows the crypto material), and proxy the data between the two. This= attack does not use ADD_ADDR and is relatively easy to execute.  On= e way to stop this attack is to mandate that all subflows are opened in t= he same direction as the intial one; this allows client mobility, but does not allow server mobility (except make before = break if we allow ADD_ADDR).

In summary: by removing ADD_ADDR and restricting the direction in which s= ubflows can be opened MPTCP redirection is not possible anymore even for = on path attackers. However, while doing this we lose flexiblity - server = mobility is not possible anymore, v4+v6 mptcp connections are not possible anymore, etc.

2) For traffic people care about, TLS is used with TCP today. The same wi= ll be true with MPTCP: sensitive traffic will run over TLS. In this conte= xt, since the data is encrypted, even if traffic is redirected it doesn't= really matter - so I think we should allow ADD_ADDR without any extra authentication needed (i.e. leave it as= it is today).   

Of course if we have a secret key between the endpoints we can restrict s= ending ADD_ADDR to the connection endpoints. However, the fact that on-pa= th middleboxes can also use it is a bonus in my view, because it allows o= perators to route the traffic via middleboxes (which they already do!) but in an explicit way - at least the endpoints= know about the redirection.

Cheers,
Costin


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


*** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. ***
--_000_7E5B399EA24340D4BA7FC8CB40ECD9B4fortinetcom_-- From philip.eardley@bt.com Thu Aug 1 05:47:03 2013 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 EA79C21F9E35 for ; Thu, 1 Aug 2013 05:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.49 X-Spam-Level: X-Spam-Status: No, score=-103.49 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmHWfkfoqf+Q for ; Thu, 1 Aug 2013 05:46:57 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id BD4C921E810E for ; Thu, 1 Aug 2013 05:46:40 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 1 Aug 2013 13:46:38 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.69]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Thu, 1 Aug 2013 13:46:38 +0100 From: To: Date: Thu, 1 Aug 2013 13:46:38 +0100 Thread-Topic: Consensus call to create WG doc for RFC6897bis Thread-Index: AQHOjrUpKiSPb/DjQ0SeCp8DNM7sPw== Message-ID: <9510D26531EF184D9017DF24659BB87F35CD1BF577@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F35CD1BF577EMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] Consensus call to create WG doc for RFC6897bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 12:47:03 -0000 --_000_9510D26531EF184D9017DF24659BB87F35CD1BF577EMV65UKRDdoma_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, This is a consensus call to create a WG doc, draft-ietf-mptcp-rfc6897bis-00= . The -00 document will be almost identical to RFC6897, with these changes: * Intended status: Standards track * Obsoletes (when published): RFC6897 This is basically a consensus call that RFC6897 is the right place for the = WG to start - towards meeting our objective of a standards track MPTCP sign= alling doc. Just to be clear - we're not asking if the doc is ready to send to IESG - w= e know that further thought (and perhaps further work) is needed on securit= y issues. Indeed our AD, Martin, has kindly offered to help us get a securi= ty advisor from the sec-area. Best wishes, phil --_000_9510D26531EF184D9017DF24659BB87F35CD1BF577EMV65UKRDdoma_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
=  
This is= a consensus call to create a WG do= c, draft-ietf-mptcp-rfc6897bis-00.
The -00= document will be almost identical to RFC6897, with these changes:
* Intended status: Standards track
* Obsoletes (when published): RFC6897
This is basically a consensus call that RFC6897 is the right= place for the WG to start - towards meeting our objective of a standards t= rack MPTCP signalling doc.
 
Just to be clear - we're not as= king if the doc is ready to send to IESG - we know that further thought (and perhaps further work) is needed on security issues. Indeed our AD, Martin, has kin= dly offered to help us get a security advisor from the sec-area.
 
Best wishes,
phil
 <= /div>
--_000_9510D26531EF184D9017DF24659BB87F35CD1BF577EMV65UKRDdoma_-- From mark@handley.org.uk Thu Aug 1 06:42:09 2013 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 BB80221F8528 for ; Thu, 1 Aug 2013 06:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Oy7Jjf1Ge4g for ; Thu, 1 Aug 2013 06:42:01 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 919A521F9A43 for ; Thu, 1 Aug 2013 06:41:50 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id E1EC4208C6; Thu, 1 Aug 2013 09:41:49 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute5.internal (MEProxy); Thu, 01 Aug 2013 09:41:49 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=BldSjNdjUzL+6QrdWHX0jGasWko=; b=PHE dd/Cby5eTxstcNbR4ptFSMEnadswv92OsVyRUVbfKmAw7wr6SiQgUMBWpYpzXGqL bFODX6V3inBoIaTaccOk/pOUlxTqQMsO/7WwewLMs7J3M5rfSjWD7QmlCfQTlyWT 5ddXv8X790zlNw7tcbUMDFMWI4wIuxOSRExX/cfc= Received: by web6.nyi.mail.srv.osa (Postfix, from userid 99) id BF786286E00; Thu, 1 Aug 2013 09:41:49 -0400 (EDT) Message-Id: <1375364509.5427.4518615.4B0201B9@webmail.messagingengine.com> X-Sasl-Enc: wnWSvMrLBnIOLTsHJnUULkbtMrBb3d2XeZ+FSMo0gdVh 1375364509 From: Mark Handley To: philip.eardley@bt.com, multipathtcp@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_137536450954274"; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-2d520484 In-Reply-To: <9510D26531EF184D9017DF24659BB87F35CD1BF577@EMV65-UKRD.domain1.systemhost.net> References: <9510D26531EF184D9017DF24659BB87F35CD1BF577@EMV65-UKRD.domain1.systemhost.net> Date: Thu, 01 Aug 2013 06:41:49 -0700 Subject: Re: [multipathtcp] Consensus call to create WG doc for RFC6897bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 13:42:09 -0000 This is a multi-part message in MIME format. --_----------=_137536450954274 Content-Transfer-Encoding: 7bit Content-Type: text/plain I agree with this action. Mark On Thu, Aug 1, 2013, at 05:46 AM, [1]philip.eardley@bt.com wrote: Hi, This is a consensus call to create a WG doc, draft-ietf-mptcp-rfc6897bis-00. The -00 document will be almost identical to RFC6897, with these changes: * Intended status: Standards track * Obsoletes (when published): RFC6897 This is basically a consensus call that RFC6897 is the right place for the WG to start - towards meeting our objective of a standards track MPTCP signalling doc. Just to be clear - we're not asking if the doc is ready to send to IESG - we know that further thought (and perhaps further work) is needed on security issues. Indeed our AD, Martin, has kindly offered to help us get a security advisor from the sec-area. Best wishes, phil _______________________________________________ multipathtcp mailing list [2]multipathtcp@ietf.org [3]https://www.ietf.org/mailman/listinfo/multipathtcp References 1. mailto:philip.eardley@bt.com 2. mailto:multipathtcp@ietf.org 3. https://www.ietf.org/mailman/listinfo/multipathtcp --_----------=_137536450954274 Content-Transfer-Encoding: 7bit Content-Type: text/html
I agree with this action.
 
Mark
 
 
On Thu, Aug 1, 2013, at 05:46 AM, philip.eardley@bt.com wrote:
 
Hi,
 
This is a consensus call to create a WG doc, draft-ietf-mptcp-rfc6897bis-00.
The -00 document will be almost identical to RFC6897, with these changes:
* Intended status: Standards track
* Obsoletes (when published): RFC6897
This is basically a consensus call that RFC6897 is the right place for the WG to start - towards meeting our objective of a standards track MPTCP signalling doc.
 
Just to be clear - we're not asking if the doc is ready to send to IESG - we know that further thought (and perhaps further work) is needed on security issues. Indeed our AD, Martin, has kindly offered to help us get a security advisor from the sec-area.
 
Best wishes,
phil
 
_______________________________________________
multipathtcp mailing list
--_----------=_137536450954274-- From marcelo@it.uc3m.es Thu Aug 1 07:14:53 2013 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 E7AC621E8207 for ; Thu, 1 Aug 2013 07:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.2 X-Spam-Level: X-Spam-Status: No, score=-106.2 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyRc2jKrxbZh for ; Thu, 1 Aug 2013 07:14:47 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6A121E81ED for ; Thu, 1 Aug 2013 07:14:44 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id AF7A08B6FFE for ; Thu, 1 Aug 2013 16:14:42 +0200 (CEST) X-uc3m-safe: yes Received: from dhcp-1147.meeting.ietf.org (dhcp-1147.meeting.ietf.org [130.129.17.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 64E8C76622A for ; Thu, 1 Aug 2013 16:14:41 +0200 (CEST) Message-ID: <51FA6D55.5080400@it.uc3m.es> Date: Thu, 01 Aug 2013 16:14:45 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: multipathtcp@ietf.org References: <9510D26531EF184D9017DF24659BB87F35CD1BF577@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F35CD1BF577@EMV65-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTHACL 134 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Thu, 01 Aug 2013 16:14:42 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20050.007 X-TM-AS-Result: No--16.972-7.0-31-1 X-imss-scan-details: No--16.972-7.0-31-1 Subject: Re: [multipathtcp] Consensus call to create WG doc for RFC6897bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 14:14:53 -0000 I support this. El 01/08/13 14:46, philip.eardley@bt.com escribió: > Hi, > This is a consensus call to create a WG doc, > draft-ietf-mptcp-rfc6897bis-00. > The -00 document will be almost identical to RFC6897, with these changes: > * Intended status: Standards track > * Obsoletes (when published): RFC6897 > This is basically a consensus call that RFC6897 is the right place for > the WG to start - towards meeting our objective of a standards track > MPTCP signalling doc. > Just to be clear - we're not asking if the doc is ready to send to > IESG - we know that further thought (and perhaps further work) is > needed on security issues. Indeed our AD, Martin, has kindly offered > to help us get a security advisor from the sec-area. > Best wishes, > phil > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From michael.scharf@alcatel-lucent.com Thu Aug 1 10:51:46 2013 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 E771E21E8117 for ; Thu, 1 Aug 2013 10:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.5 X-Spam-Level: X-Spam-Status: No, score=-10.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p93KfUwj4t5l for ; Thu, 1 Aug 2013 10:51:40 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8963121E815C for ; Thu, 1 Aug 2013 10:51:35 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r71HpUJR025514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 1 Aug 2013 12:51:31 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r71HpTek014256 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Aug 2013 19:51:29 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 1 Aug 2013 19:51:29 +0200 From: "Scharf, Michael (Michael)" To: "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: Consensus call to create WG doc for RFC6897bis Thread-Index: AQHOjrUpKiSPb/DjQ0SeCp8DNM7sP5mAoaWQ Date: Thu, 1 Aug 2013 17:51:28 +0000 Message-ID: <655C07320163294895BBADA28372AF5D07C31C@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <9510D26531EF184D9017DF24659BB87F35CD1BF577@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F35CD1BF577@EMV65-UKRD.domain1.systemhost.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [multipathtcp] Consensus call to create WG doc for RFC6897bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 17:51:47 -0000 s/6897/6824/ ? Michael (author of RFC 6897) > -----Original Message----- > From: multipathtcp-bounces@ietf.org=20 > [mailto:multipathtcp-bounces@ietf.org] On Behalf Of=20 > philip.eardley@bt.com > Sent: Thursday, August 01, 2013 2:47 PM > To: multipathtcp@ietf.org > Subject: [multipathtcp] Consensus call to create WG doc for RFC6897bis >=20 > Hi, > =20 > This is a consensus call to create a WG doc,=20 > draft-ietf-mptcp-rfc6897bis-00. > The -00 document will be almost identical to RFC6897, with=20 > these changes: > * Intended status: Standards track > * Obsoletes (when published): RFC6897 >=20 > This is basically a consensus call that RFC6897 is the right=20 > place for the WG to start - towards meeting our objective of=20 > a standards track MPTCP signalling doc. > =20 > Just to be clear - we're not asking if the doc is ready to=20 > send to IESG - we know that further thought (and perhaps=20 > further work) is needed on security issues. Indeed our AD,=20 > Martin, has kindly offered to help us get a security advisor=20 > from the sec-area. > =20 > Best wishes, > phil > =20 > = From nishida@sfc.wide.ad.jp Thu Aug 1 12:15:58 2013 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 8222811E8150 for ; Thu, 1 Aug 2013 12:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.941 X-Spam-Level: X-Spam-Status: No, score=-101.941 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q30D2G+uFfbq for ; Thu, 1 Aug 2013 12:15:57 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 4F79011E8138 for ; Thu, 1 Aug 2013 12:15:56 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 23E6D2780AF for ; Fri, 2 Aug 2013 04:15:52 +0900 (JST) Received: by mail-lb0-f177.google.com with SMTP id r11so1787388lbv.8 for ; Thu, 01 Aug 2013 12:15:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wOAwuc16nH6ipFgSNiPe6rr1p3fKK3KiYOAAgtmEpDA=; b=oeCC0mupW5gKYkLkJu2o1ZQnwYIvBfSHcOcOMVmFKDN6E6KiCeH4Sn+Z+172igAM5Z /s3VKrgFDyjETlxQzOtS3wxOtpUdS32n5YSB5Of6l9M8hMJ2hgl0Owc01HNg/9qu0qCs +7U7sIf7izFXzUVm7j3mmoIot4KzGbGaoDHzdLISe37AydL92HqZuVHJ9q/rHE22zHA3 o6MBjgNvzkW30DHN+aoZBRA2WsP6Z0f+p0QX4RETgCLoBy+6pGguOWLx8U1hguSzQcBv o8vuV8dJQViwE0teFBlfWQ8N5PjRFopCjV+w44b5Mnjrm4UTN4ByAQ38mdgmgqZ8Zq5a +JBA== MIME-Version: 1.0 X-Received: by 10.112.157.226 with SMTP id wp2mr1963870lbb.65.1375384550691; Thu, 01 Aug 2013 12:15:50 -0700 (PDT) Received: by 10.114.92.238 with HTTP; Thu, 1 Aug 2013 12:15:50 -0700 (PDT) In-Reply-To: <51FA1504.6030001@internet2.edu> References: <86D5F8DA-93EE-4F17-BBCE-C61F410829AE@netapp.com> <51FA1504.6030001@internet2.edu> Date: Thu, 1 Aug 2013 12:15:50 -0700 Message-ID: From: Yoshifumi Nishida To: Scott Brim Content-Type: text/plain; charset=ISO-8859-1 Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] standards track now X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 19:15:58 -0000 Hi folks, Since I couldn't attend the meeting, I might miss something, but anyway.. For (2), we have SCTP which already has similar feature for ADD_ADDR. It's well designed and has been used for a while. And RFC5061 is PS. I'm wondering how MPTCP is vulnerable compared to SCTP and how much protection we'll need. Thanks, -- Yoshifumi On Thu, Aug 1, 2013 at 12:57 AM, Scott Brim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/01/13 09:43, Eggert, Lars allegedly wrote: >> Hi, >> >> as I just said during TSVAREA, I think we should recharter the WG >> to allow work on a PS spec now. >> >> The issues that remain to be worked on a clearly tractable and can >> be resolved during the normal process of pushing an ID towards RFC >> publication. >> >> Lars > > I'm going to be the person who says "let's not be hasty". > > (1) A fundamental point in MPTCP is balancing traffic on subflows and > overall coordinated congestion management. Ramin Khalili's > presentation showed that what we have so far seems pretty > experimental, and we're essentially still at the research stage. > > (2) NATs are real, so ADD_ADDR is going to get used, but it's a > security hole. That's "clearly tractable" but what we have now is not > ready for even limited deployment. Maybe ADD_ADDR should be taken out > of the standards track docs and added later. > > Scott > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.13 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlH6FQQACgkQF0TR2hENFARCdACfVOVd1qXv0bnB5LJEOTqNJ4BD > BmkAn0Au+FfCvkURa1AlxFVfvbE0mNlK > =POc0 > -----END PGP SIGNATURE----- > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From elopez@fortinet.com Thu Aug 1 13:56:29 2013 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 41E3911E8165 for ; Thu, 1 Aug 2013 13:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8alFhSXMwYF for ; Thu, 1 Aug 2013 13:56:25 -0700 (PDT) Received: from smtp.fortinet.com (smtp.fortinet.com [208.91.113.81]) by ietfa.amsl.com (Postfix) with ESMTP id 22A8C11E815C for ; Thu, 1 Aug 2013 13:56:25 -0700 (PDT) From: Edward Lopez To: "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call to create WG doc for RFC6897bis Thread-Index: AQHOjvmSMHzD+KKiPEqdUfeGfbu9LA== Date: Thu, 1 Aug 2013 20:56:19 +0000 Message-ID: References: <9510D26531EF184D9017DF24659BB87F35CD1BF577@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F35CD1BF577@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_DC77E94D11E04F4D8EAE3E7B855FB401fortinetcom_" MIME-Version: 1.0 Subject: Re: [multipathtcp] Consensus call to create WG doc for RFC6897bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 20:56:29 -0000 --_000_DC77E94D11E04F4D8EAE3E7B855FB401fortinetcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you for the clarification. I concur with the direction towards st= andards track and creation of the WG document. I agree much work is need= ed in security Rdgs, Ed Lopez Sent from my iPhone ... Sorry for any auto-correct errors On Aug 1, 2013, at 3:34 PM, "philip.eardley@bt.com" > wrote: Hi, This is a consensus call to create a WG doc, draft-ietf-mptcp-rfc6897bis-= 00. The -00 document will be almost identical to RFC6897, with these changes:= * Intended status: Standards track * Obsoletes (when published): RFC6897 This is basically a consensus call that RFC6897 is the right place for th= e WG to start - towards meeting our objective of a standards track MPTCP = signalling doc. Just to be clear - we're not asking if the doc is ready to send to IESG -= we know that further thought (and perhaps further work) is needed on sec= urity issues. Indeed our AD, Martin, has kindly offered to help us get a = security advisor from the sec-area. Best wishes, phil _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp *** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. *** --_000_DC77E94D11E04F4D8EAE3E7B855FB401fortinetcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thank you for the clarification.  I concur  with the direc= tion towards standards track and creation of the WG document.  I agr= ee much work is needed in security

Rdgs,
Ed Lopez

Sent from my iPhone ... Sorry for any auto-correct errors

On Aug 1, 2013, at 3:34 PM, "philip.eardley@bt.com" <philip.eardley@bt.com> wrote:

Hi,
 
This = is a consensus call to create a WG = doc, draft-ietf-mptcp-rfc6897bis-00.
The -= 00 document will be almost identical to RFC6897, with these changes:
* Intended status: Standards track
* Obsoletes (when published): RFC6897
This is basically a consensus call that RFC6897 is the r= ight place for the WG to start - towards meeting our objective of a stand= ards track MPTCP signalling doc.
 
Just to be clear - we're no= t asking if the doc is ready to send to IESG - we know that further thought (and perhaps further work) is needed on security issues. Indeed our AD, Martin, has k= indly offered to help us get a security advisor from the sec-area.=
 
Best wishes,
phil
 = ;
_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org<= /span>
http= s://www.ietf.org/mailman/listinfo/multipathtcp

*** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. ***
--_000_DC77E94D11E04F4D8EAE3E7B855FB401fortinetcom_-- From grmocg@gmail.com Thu Aug 1 23:13:43 2013 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 D93CD11E8221 for ; Thu, 1 Aug 2013 23:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCEBFcgcpEkv for ; Thu, 1 Aug 2013 23:13:43 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id CB18911E824E for ; Thu, 1 Aug 2013 23:13:37 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id j6so571562oag.28 for ; Thu, 01 Aug 2013 23:13:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=v0dwBvf/0POQ+VhlwVR1r+1cad9B6jQwYqA8ZiFmfFU=; b=oWqmcDq3XWkt1kbRMWFl5BThzuIx/hLKaMlgzdSe/vD9iIyL69qPvXpZQ2RvA++DKe Ysd76Yqu0DGqVYTydlVVmjtIc/YPBWQKPrDGyj8l3MQXc0/HAb10ZfLNe68v6F/+uURq E77DnfUDnTzXQt2ZZrR3TnM0dgrb/deYx1HcZUyr9x6s020u1tksPaKU2LYMRCNUvwbi J+f2KV5U82Z/Mk8xky/qbnIzEFx/Wiwn0NGz0X14I4H7vekwogslezAUd2BaLabS1yC9 PaFHZVbHTceT0ZeT8zp8MSl4OtPcbHiIoiLWAByE6XMahzSon6kfKTZtWSBrbV84WroV VsVw== MIME-Version: 1.0 X-Received: by 10.60.45.38 with SMTP id j6mr4024572oem.56.1375424017373; Thu, 01 Aug 2013 23:13:37 -0700 (PDT) Received: by 10.76.91.229 with HTTP; Thu, 1 Aug 2013 23:13:37 -0700 (PDT) In-Reply-To: References: <86D5F8DA-93EE-4F17-BBCE-C61F410829AE@netapp.com> <51FA1504.6030001@internet2.edu> Date: Fri, 2 Aug 2013 08:13:37 +0200 Message-ID: From: Roberto Peon To: Yoshifumi Nishida Content-Type: multipart/alternative; boundary=089e015367ecf89d0f04e2f0db64 Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] standards track now X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 06:13:44 -0000 --089e015367ecf89d0f04e2f0db64 Content-Type: text/plain; charset=ISO-8859-1 Similar vulnerabilities exist for SCTP. When SCTP was defined these attacks were far more theoretical than the attacks we're seeing done today. Analogies about jumping off of bridges because someone else did come to mind... :) -=R On Thu, Aug 1, 2013 at 9:15 PM, Yoshifumi Nishida wrote: > Hi folks, > > Since I couldn't attend the meeting, I might miss something, but anyway.. > For (2), we have SCTP which already has similar feature for ADD_ADDR. > It's well designed and has been used for a while. And RFC5061 is PS. > I'm wondering how MPTCP is vulnerable compared to SCTP and how much > protection we'll need. > > Thanks, > -- > Yoshifumi > > On Thu, Aug 1, 2013 at 12:57 AM, Scott Brim wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 08/01/13 09:43, Eggert, Lars allegedly wrote: > >> Hi, > >> > >> as I just said during TSVAREA, I think we should recharter the WG > >> to allow work on a PS spec now. > >> > >> The issues that remain to be worked on a clearly tractable and can > >> be resolved during the normal process of pushing an ID towards RFC > >> publication. > >> > >> Lars > > > > I'm going to be the person who says "let's not be hasty". > > > > (1) A fundamental point in MPTCP is balancing traffic on subflows and > > overall coordinated congestion management. Ramin Khalili's > > presentation showed that what we have so far seems pretty > > experimental, and we're essentially still at the research stage. > > > > (2) NATs are real, so ADD_ADDR is going to get used, but it's a > > security hole. That's "clearly tractable" but what we have now is not > > ready for even limited deployment. Maybe ADD_ADDR should be taken out > > of the standards track docs and added later. > > > > Scott > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.13 (Darwin) > > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > > > iEYEARECAAYFAlH6FQQACgkQF0TR2hENFARCdACfVOVd1qXv0bnB5LJEOTqNJ4BD > > BmkAn0Au+FfCvkURa1AlxFVfvbE0mNlK > > =POc0 > > -----END PGP SIGNATURE----- > > > > _______________________________________________ > > 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 > --089e015367ecf89d0f04e2f0db64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Similar vulnerabilities exist for SCTP.
When SCTP was = defined these attacks were far more theoretical than the attacks we're = seeing done today.=A0

Analogies about jumping off of bri= dges because someone else did come to mind... :)
-=3DR


On Thu, Aug 1, 2013 at 9:15 PM, Yoshifumi Nishida <n= ishida@sfc.wide.ad.jp> wrote:
Hi folks,

Since I couldn't attend the meeting, I might miss something, but anyway= ..
For (2), we have SCTP which already has similar feature for ADD_ADDR.
It's well designed and has been used for a while. And RFC5061 is PS. I'm wondering how MPTCP is vulnerable compared to SCTP and how much
protection we'll need.

Thanks,
--
Yoshifumi

On Thu, Aug 1, 2013 at 12:57 AM, Scott Brim <swb@internet2.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 08/01/13 09:43, Eggert, Lars allegedly wrote:
>> Hi,
>>
>> as I just said during TSVAREA, I think we should recharter the WG<= br> >> to allow work on a PS spec now.
>>
>> The issues that remain to be worked on a clearly tractable and can=
>> be resolved during the normal process of pushing an ID towards RFC=
>> publication.
>>
>> Lars
>
> I'm going to be the person who says "let's not be hasty&q= uot;.
>
> (1) A fundamental point in MPTCP is balancing traffic on subflows and<= br> > overall coordinated congestion management. =A0Ramin Khalili's
> presentation showed that what we have so far seems pretty
> experimental, and we're essentially still at the research stage. >
> (2) NATs are real, so ADD_ADDR is going to get used, but it's a > security hole. =A0That's "clearly tractable" but what we= have now is not
> ready for even limited deployment. =A0Maybe ADD_ADDR should be taken o= ut
> of the standards track docs and added later.
>
> Scott
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlH6FQQACgkQF0TR2hENFARCdACfVOVd1qXv0bnB5LJEOTqNJ4BD
> BmkAn0Au+FfCvkURa1AlxFVfvbE0mNlK
> =3DPOc0
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> 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

--089e015367ecf89d0f04e2f0db64-- From dreibh@iem.uni-due.de Fri Aug 2 03:17:33 2013 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 C1DE421E8328 for ; Fri, 2 Aug 2013 03:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_05=-1.11, GB_I_INVITATION=-2, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTdwU031cjQA for ; Fri, 2 Aug 2013 03:17:29 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id BC69321E80CA for ; Fri, 2 Aug 2013 03:17:28 -0700 (PDT) Received: from lupo.localnet (dhcp-40ef.meeting.ietf.org [130.129.64.239]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id r72AHQBV003401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Aug 2013 12:17:26 +0200 From: Thomas Dreibholz To: multipathtcp@ietf.org Date: Fri, 02 Aug 2013 12:17:26 +0200 Message-ID: <1629512.nCQDT4tthG@lupo> Organization: University of Duisburg-Essen, Institute for Experimental Mathematics User-Agent: KMail/4.10.5 (Linux/3.8.0-27-generic; KDE/4.10.5; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1745823.13WK4oYokI"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Subject: [multipathtcp] Invitation to the NorNet Users Workshop (NNUW-1) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 10:17:33 -0000 --nextPart1745823.13WK4oYokI Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" [Our apologies if you receive multiple copies of this message.] CALL FOR PARTICIPATION We cordially invite you to join us at: The 1st International NorNet Users Workshop (NNUW-1) at the Simula Research Laboratory in Fornebu, Akershus/Norway September 18-19, 2013 http://www.nornet-testbed.no/workshops/nnuw-1/ There is *no* workshop fee! Please register as early as possible. More than one year ago, the NorNet project has started with the intenti= on to=20 build up the world=E2=80=99s first large-scale network testbed for mul= ti-homed=20 systems. NorNet should provide researchers the possibility to perform=20= experiments in real-world wired and wireless setups. Now, the wired par= t =E2=80=93=20 denoted as NorNet Core =E2=80=93 as well as the wireless part =E2=80=93= denoted as NorNet Edge=20 =E2=80=93 have reached a stage that allows further researchers to start= running such=20 experiments. That is, currently 11 NorNet Core sites and more than 300 = NorNet=20 Edge nodes are ready to support your research ideas on resilience, mobi= lity,=20 security, multi-path transport and further subjects! This workshop intends to provide current as well as new and future NorN= et=20 users the possibility to get information about the NorNet testbed and i= nitial=20 research results, to discuss their ideas with the testbed developers an= d to=20 get the possibility for obtaining access to NorNet. Further details on the workshop are available at: http://www.nornet-testbed.no/workshops/nnuw-1/ An information sheet in PDF format can be found here: http://www.nornet-testbed.no/wp-content/uploads/2013/06/NNUW-1-CallForP= articipation.pdf A detailed description of NorNet can be found at: http://www.nntb.no/ We are looking forward to see you in Fornebu! The NNUW-1 Organisers --nextPart1745823.13WK4oYokI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlH7hzYACgkQ32BbsHYPLWWzmQCcCbbMiKi6ZsPS4Ero7Nln11So CNsAn3n47QgIHOFvqrkouGNxLjHZsf2U =vgOz -----END PGP SIGNATURE----- --nextPart1745823.13WK4oYokI-- From philip.eardley@bt.com Mon Aug 5 08:31:35 2013 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 AB3BC21F9EC3 for ; Mon, 5 Aug 2013 08:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.541 X-Spam-Level: X-Spam-Status: No, score=-103.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7iJ7ERdaFgU for ; Mon, 5 Aug 2013 08:31:30 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id BB4B121F9EC4 for ; Mon, 5 Aug 2013 08:31:20 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 5 Aug 2013 16:31:18 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.69]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Mon, 5 Aug 2013 16:31:18 +0100 From: To: Date: Mon, 5 Aug 2013 16:31:16 +0100 Thread-Topic: Consensus call to create WG doc for RFC6824bis Thread-Index: Ac6R8ANtlVUSoOxJRi2KVDSVVXT0Aw== Message-ID: <9510D26531EF184D9017DF24659BB87F35CD05F60F@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F35CD05F60FEMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] Consensus call to create WG doc for RFC6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 15:31:35 -0000 --_000_9510D26531EF184D9017DF24659BB87F35CD05F60FEMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry for the typo, I meant RFC6824: TCP Extensions for Multipath Operation= with Multiple Addresses (and not 6897, which is the Application Interface= Considerations doc) luckily you all seem to have known what I meant! No need to reply to this email if you already replied to the original one. Thanks phil From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of philip.eardley@bt.com Sent: 01 August 2013 13:47 To: multipathtcp@ietf.org Subject: [multipathtcp] Consensus call to create WG doc for RFC6897bis Hi, This is a consensus call to create a WG doc, draft-ietf-mptcp-rfc6897bis-00= . The -00 document will be almost identical to RFC6897, with these changes: * Intended status: Standards track * Obsoletes (when published): RFC6897 This is basically a consensus call that RFC6897 is the right place for the = WG to start - towards meeting our objective of a standards track MPTCP sign= alling doc. Just to be clear - we're not asking if the doc is ready to send to IESG - w= e know that further thought (and perhaps further work) is needed on securit= y issues. Indeed our AD, Martin, has kindly offered to help us get a securi= ty advisor from the sec-area. Best wishes, phil --_000_9510D26531EF184D9017DF24659BB87F35CD05F60FEMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry for the typo, I mea= nt RFC6824: TCP Extensions for Multipath Operation with Multiple Addresses&= nbsp; (and not 6897, which is the Application Interface Considerations doc)=

 

l= uckily you all seem to have known what I meant!

No need to reply to this email if you already replied to the original= one.

 

Thanks

phil

 

= From: multipathtcp-bounces@ietf.org [mailto:multipatht= cp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent:<= /b> 01 August 2013 13:47
To: multipathtcp@ietf.org
Subject:= [multipathtcp] Consensus call to create WG doc for RFC6897bis

 

Hi,

 

This is a consensus call to create a WG doc, draft-ietf-mptcp-rfc6897bis-= 00.

The -00 docume= nt will be almost identical to RFC6897, with these changes:
* Intended s= tatus: Standards track
* Obsoletes (when published): RFC6897<= /span>

This is basically a consensus= call that RFC6897 is the right place for the WG to start - towards meeting= our objective of a standards track MPTCP signalling doc.=

 

<= div>

Just to be clear - we're not asking if the doc= is ready to send to IESG - we know that further thought (and perhaps = further work) is needed on security issues. Indeed our AD, Martin, has kind= ly offered to help us get a security advisor from the sec-area.<= /span>

 

<= /div>

Best wishes,

=

phil

 

= --_000_9510D26531EF184D9017DF24659BB87F35CD05F60FEMV65UKRDdoma_-- From philip.eardley@bt.com Mon Aug 5 08:54:14 2013 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 361DD21F99BF for ; Mon, 5 Aug 2013 08:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.543 X-Spam-Level: X-Spam-Status: No, score=-103.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wk8we3NUgb0q for ; Mon, 5 Aug 2013 08:54:10 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id BAC9721F99B0 for ; Mon, 5 Aug 2013 08:54:09 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 5 Aug 2013 16:54:07 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.69]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Mon, 5 Aug 2013 16:54:07 +0100 From: To: Date: Mon, 5 Aug 2013 16:54:06 +0100 Thread-Topic: Congestion control work Thread-Index: Ac6R8T1VR2DZTnPWTCekaLnoevh6Zg== Message-ID: <9510D26531EF184D9017DF24659BB87F35CD05F635@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F35CD05F635EMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] Congestion control work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 15:54:14 -0000 --_000_9510D26531EF184D9017DF24659BB87F35CD05F635EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I wanted to let you know that Ramin Khalili and I met with Martin Stiemerli= ng, our AD. Ramin has been working on a new coupled congestion control algorithm, which= he presented in ICCRG this time (and MPTCP in Orlando). Our current charter doesn't include work on coupled congestion control - th= e main item is to progress the protocol doc on the standards track. In orde= r to keep the WG focus on our main aim, we won't add congestion control wor= k at this time. We'll review this in about 6 months, to see if we've made e= nough progress to think about re-chartering. In the meantime, Ramin will revise his drafts [from http://datatracker.ietf= .org/wg/mptcp/] and of course would welcome reviews. Best wishes phil --_000_9510D26531EF184D9017DF24659BB87F35CD05F635EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I wanted to let you know that Ramin Khalil= i and I met with Martin Stiemerling, our AD.

 

Ramin has been working on a new coupled congestion control algori= thm, which he presented in ICCRG this time (and MPTCP in Orlando).

 

Our current charter doesn’t include w= ork on coupled congestion control – the main item is to progress the = protocol doc on the standards track. In order to keep the WG focus on our m= ain aim, we won’t add congestion control work at this time. We’= ll review this in about 6 months, to see if we’ve made enough progres= s to think about re-chartering.

=  

In = the meantime, Ramin will revise his drafts [from http://datatracker= .ietf.org/wg/mptcp/] and of course would welcome reviews.

 

Best wishes

phil=

= --_000_9510D26531EF184D9017DF24659BB87F35CD05F635EMV65UKRDdoma_-- From olivier.bonaventure@uclouvain.be Mon Aug 5 10:36:39 2013 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 E322821E80DB for ; Mon, 5 Aug 2013 10:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f23uKpgNYK2I for ; Mon, 5 Aug 2013 10:36:35 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1AF21F9C4E for ; Mon, 5 Aug 2013 10:36:32 -0700 (PDT) Received: from mbpobo.local (unknown [172.17.0.12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 8914B1C6F14; Mon, 5 Aug 2013 19:36:25 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 8914B1C6F14 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1375724185; bh=eQ/OxO/ivdPGSLAlgs4m1cB1sAYjJOqCzGVjrXNr8Hc=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=qp693MHDQxOjcYjcug/cCgtolE/CgXeIZHnWv3R8g2Fwm2uDSenL3MpP4YevkbSl+ KYwpmqbwcnQgN1LG4kKMKXi1huwd783n2B9ZAJpzlL8GT46GZN1N9v3FNAEhHCoswR p9fOCxOR8BSuXi97nfOL4dQi2owpC/XLe4WL2SUk= Message-ID: <51FFE307.3070200@uclouvain.be> Date: Mon, 05 Aug 2013 19:38:15 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: philip.eardley@bt.com References: <9510D26531EF184D9017DF24659BB87F35CD05F60F@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F35CD05F60F@EMV65-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 8914B1C6F14.A396A X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp Subject: Re: [multipathtcp] Consensus call to create WG doc for RFC6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 17:36:40 -0000 Phil, > Sorry for the typo, I meant RFC6824: TCP Extensions for Multipath > Operation with Multiple Addresses (and not 6897, which is the > Application Interface Considerations doc) > > luckily you all seem to have known what I meant! > > No need to reply to this email if you already replied to the original one. The implementation survey that you presented in Berlin shows that RFC6824 is mature since it has already been implemented by several completely independant teams. There are some parts to be improved and this work could be done while progressing towards standards track. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From jpronans@gmail.com Mon Aug 5 12:59:56 2013 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 0881321F8C93 for ; Mon, 5 Aug 2013 12:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRDtMVpfHylp for ; Mon, 5 Aug 2013 12:59:55 -0700 (PDT) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id E70FA21F8E2D for ; Mon, 5 Aug 2013 12:59:52 -0700 (PDT) Received: by mail-ea0-f169.google.com with SMTP id z7so1807508eaf.14 for ; Mon, 05 Aug 2013 12:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=D0fubxzMvGP4Vh4/+OkPDDlrZ6BFKi3QeYKan7lqO90=; b=yqCq4dH77/ahBSGf1Y4wDrHzs1xE7hU+kAv0xU2AUAfa0MjDJG41S7G5HZMO0RK9My m1lT4ip52DumRw6I0f7Iz3z3739hlAbGB3rTJu+IJ9TaAxQsYJcH+eHZvAG1MKXuB535 5RCAOGd8RuHv5o9bgYBXbAQZn2nYEPo/I1N51xqgZQcG6wgeBrABw1FIVcZJhcOmurGK kEpaRXi3e8bNtH2oPAfzgj4eLGXeDwIlXSTCZB4qOoUD9+MAP5Mi/XecrU2w5ucjWx3I 0IkjDCqPLXRSP8dHqaeEx8qkYJFyeqx5ss+BVqWZP+zg5qFotq7BkR7SJXG5cSr43ZU7 t/zw== X-Received: by 10.15.54.67 with SMTP id s43mr18379599eew.133.1375732791800; Mon, 05 Aug 2013 12:59:51 -0700 (PDT) Received: from ?IPv6:2001:770:100:4e::2? (cl-79.dub-01.ie.sixxs.net. [2001:770:100:4e::2]) by mx.google.com with ESMTPSA id e1sm1102579eev.8.2013.08.05.12.59.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Aug 2013 12:59:50 -0700 (PDT) Message-ID: <52000434.6070700@gmail.com> Date: Mon, 05 Aug 2013 20:59:48 +0100 From: John Ronan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: philip.eardley@bt.com References: <9510D26531EF184D9017DF24659BB87F35CD05F60F@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F35CD05F60F@EMV65-UKRD.domain1.systemhost.net> Content-Type: multipart/alternative; boundary="------------000601000305060207030903" Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Consensus call to create WG doc for RFC6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 19:59:56 -0000 This is a multi-part message in MIME format. --------------000601000305060207030903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/08/13 16:31, philip.eardley@bt.com wrote: > Sorry for the typo, I meant RFC6824: TCP Extensions for Multipath > Operation with Multiple Addresses I concur with the creation of a Working Group document and work towards standards track. Regards John --------------000601000305060207030903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 05/08/13 16:31, philip.eardley@bt.com wrote:
Sorry for the typo, I meant RFC6824: TCP Extensions for Multipath Operation with Multiple Addresses 
I concur with the creation of a Working Group document and work towards standards track.

Regards
John

--------------000601000305060207030903-- From scott.brim@gmail.com Mon Aug 5 13:41:49 2013 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 1B15521F9D2A for ; Mon, 5 Aug 2013 13:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qrQJmWhr17Y for ; Mon, 5 Aug 2013 13:41:48 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE4E21F9BBF for ; Mon, 5 Aug 2013 13:41:48 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id 29so1686945yhl.10 for ; Mon, 05 Aug 2013 13:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=WXuPVDOweb3mgCLOL6upg7O9DBpKrAh1NknuWEIeCuo=; b=IiBp4jQ6urktam2Zu2pKW2SGTT8UGf9GEmGa9IFmNH4WUNZn4mP9W2E/57oq9gAMS3 8d9NKJueWaVG6ZhQ43MkmAgReMAMtSjFyCPKrVFWwmAomNewhginSDYQn27FZJ8qrH4e myUzdcAgmHu9XQ4u6XpHMUpMX8i9Yk9/T+X7SYZwRaPmJCS15ZlT97hu6kor0RNaEMYA KwpjoBpT4MxIlvhvdErQ3pEp9JL87xn2jX/7FlpQ+eW2ZMS2WHP3P1zt0GCWoyQql658 jbewCik6mt9x4SD+V95dS2gpmGckDR7/TxG4RZW4qztdUFLhVCR723iAKko+ArFZdmhJ YWQQ== X-Received: by 10.236.132.175 with SMTP id o35mr777346yhi.56.1375735306990; Mon, 05 Aug 2013 13:41:46 -0700 (PDT) Received: from swbi2mbp.local (cpe-67-241-75-185.twcny.res.rr.com. [67.241.75.185]) by mx.google.com with ESMTPSA id b48sm1224071yhc.8.2013.08.05.13.41.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Aug 2013 13:41:45 -0700 (PDT) Message-ID: <52000E08.2070203@gmail.com> Date: Mon, 05 Aug 2013 16:41:44 -0400 From: Scott Brim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: philip.eardley@bt.com References: <9510D26531EF184D9017DF24659BB87F35CD05F635@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F35CD05F635@EMV65-UKRD.domain1.systemhost.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Congestion control work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 20:41:49 -0000 On 08/05/13 11:54, philip.eardley@bt.com allegedly wrote: > Our current charter doesn’t include work on coupled congestion control – > the main item is to progress the protocol doc on the standards track. In > order to keep the WG focus on our main aim, we won’t add congestion > control work at this time. We’ll review this in about 6 months, to see > if we’ve made enough progress to think about re-chartering. Phil, I'm a little surprised. Since imho the main issue in making MPTCP work was getting the coupled congestion control working, why is improving it out of scope? swb From nishida@sfc.wide.ad.jp Mon Aug 5 15:19:47 2013 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 E7A9C21F95DC for ; Mon, 5 Aug 2013 15:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.945 X-Spam-Level: X-Spam-Status: No, score=-101.945 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4sL3nfG8xRu for ; Mon, 5 Aug 2013 15:19:47 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id BDC5E21F918C for ; Mon, 5 Aug 2013 15:19:46 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id E19AA2780A0 for ; Tue, 6 Aug 2013 07:19:43 +0900 (JST) Received: by mail-lb0-f177.google.com with SMTP id r11so2464951lbv.22 for ; Mon, 05 Aug 2013 15:19:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=njrwPNyXhiZ5EgqxVi9gEOsk7FWRSTR2mrC8UjgH9dM=; b=UT17G7cQrWigtkZbv1lAAF0uSyP9rXhQjo08jvH1WpaN3B7SaJ3c08cw8tHlyU10V/ VpY3dISN+GX4ReyrZUmPo7tfChQllM2XFG9VB9xxPBbNfEHEs5rIkAkcU/Vug9uG++IZ eFDnxcGC2J8X7vOpk5o6+HCmi486AYQ5dIJPzwv6lJm2Wt+SNSiwyA6oOVDe3Yyrtd9F rQKZwn6RnI/QbN0+61Z5h8Swi0tetQEM1W8lbrl2kt/vF9MmrnLGyCZ4XPSVaJ5+WX+F dj6OIpQGk1xsQYnL0Doc73q7zsaAhFpNFGiC58onKebTQPfs3tLJ0GjGXRcno1BzsSHB Jl2g== MIME-Version: 1.0 X-Received: by 10.112.158.228 with SMTP id wx4mr9855660lbb.29.1375741181134; Mon, 05 Aug 2013 15:19:41 -0700 (PDT) Received: by 10.114.1.115 with HTTP; Mon, 5 Aug 2013 15:19:41 -0700 (PDT) In-Reply-To: <52000E08.2070203@gmail.com> References: <9510D26531EF184D9017DF24659BB87F35CD05F635@EMV65-UKRD.domain1.systemhost.net> <52000E08.2070203@gmail.com> Date: Mon, 5 Aug 2013 15:19:41 -0700 Message-ID: From: Yoshifumi Nishida To: Scott Brim Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: multipathtcp Subject: Re: [multipathtcp] Congestion control work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 22:19:48 -0000 Hi Scott, There's no big reason. It's just because we didn't see much energy for it in the WG when we discussed re-chartering. We brought it up several times during the discussion, but we didn't see strong support for it. I (personally) agree with you this is an important point. Thanks, -- Yoshifumi On Mon, Aug 5, 2013 at 1:41 PM, Scott Brim wrote: > On 08/05/13 11:54, philip.eardley@bt.com allegedly wrote: >> Our current charter doesn=92t include work on coupled congestion control= =96 >> the main item is to progress the protocol doc on the standards track. In >> order to keep the WG focus on our main aim, we won=92t add congestion >> control work at this time. We=92ll review this in about 6 months, to see >> if we=92ve made enough progress to think about re-chartering. > > Phil, I'm a little surprised. Since imho the main issue in making MPTCP > work was getting the coupled congestion control working, why is > improving it out of scope? > > swb > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From christoph.paasch@uclouvain.be Tue Aug 6 00:16:04 2013 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 DC65D21F9A23 for ; Tue, 6 Aug 2013 00:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sllRYMPI4P9p for ; Tue, 6 Aug 2013 00:15:58 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8044221F99F8 for ; Tue, 6 Aug 2013 00:15:56 -0700 (PDT) Received: from localhost (188-193-79-188-dynip.superkabel.de [188.193.79.188]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 10F741C614A; Tue, 6 Aug 2013 09:15:46 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 10F741C614A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1375773346; bh=9utlvAKPaBz6JXinyWqKx4cJEM38tgY+z7GgRKtgFbQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=yz173La65Ga8z9N5hfqGn/9nRXnvZzJOZpxPIZvxbpNQAToQPtS4t7D3aalPsEOuA W3mhIrkxQUGKYLD7qiyXJ9vmOvCTlicGlDuP0ysCZ0Mvm+WgwOhzvAsDe3HVROVJOD wo1EftRilcI9UcxjHa2W790RtNrY6SR+7iYElaEs= Date: Tue, 6 Aug 2013 09:15:45 +0200 From: Christoph Paasch To: philip.eardley@bt.com Message-ID: <20130806071545.GB3970@cpaasch-mac> References: <9510D26531EF184D9017DF24659BB87F35CD05F60F@EMV65-UKRD.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9510D26531EF184D9017DF24659BB87F35CD05F60F@EMV65-UKRD.domain1.systemhost.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 10F741C614A.A289C X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Consensus call to create WG doc for RFC6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 07:16:04 -0000 Hello Phil, On 05/08/13 - 16:31:16, philip.eardley@bt.com wrote: > Sorry for the typo, I meant RFC6824: TCP Extensions for Multipath > Operation with Multiple Addresses (and not 6897, which is the Application > Interface Considerations doc) I'm in favor of creating an RFC6824-bis WG-doc. The remaining security-issues can be solved while progressing towards standards track. Cheers, Christoph From scott.brim@gmail.com Tue Aug 6 02:43:22 2013 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 BDCD621F9A44 for ; Tue, 6 Aug 2013 02:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXrhFPJQCPvr for ; Tue, 6 Aug 2013 02:43:22 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4F52F21F99F8 for ; Tue, 6 Aug 2013 02:43:22 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id m1so311455oag.32 for ; Tue, 06 Aug 2013 02:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=O9HRvvZKeRo0AD4EAwtqh0lo9luhhQ0egnAgYlVXTTk=; b=l3hHCh1ohGGjhsIRUrVreoMIazTvIaK4D2bjvX/scz/PJHnkEdnIDh74kAuj6963sV QBcbipyGnII/qnFzQBvroHArrxVlmPH6EOUc6SOZJAsl59LggdBFkZeQQEZFBSAZw0rf nIWU2VHDc4KXihgGgUrg3joD0CHf7cUUyE5hroIoLsVQ9BjbzMGzObllU1BcuJ8V9RFw /GSL56ENctHEZ3JxeSGK9RG0D4um/HDlbLKpBcnSERXqqtyQvqgIJ1KTefdo6dEfBrB5 PhEUWmdOf8S/RVVVu0+DpIGGOaWlhYo8SsyqSzElJUbkxJoBaj+Y/IfqfkjMBE0CsOZg uw/g== X-Received: by 10.60.117.34 with SMTP id kb2mr316151oeb.54.1375782201896; Tue, 06 Aug 2013 02:43:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.44.105 with HTTP; Tue, 6 Aug 2013 02:43:01 -0700 (PDT) In-Reply-To: References: <9510D26531EF184D9017DF24659BB87F35CD05F635@EMV65-UKRD.domain1.systemhost.net> <52000E08.2070203@gmail.com> From: Scott Brim Date: Tue, 6 Aug 2013 05:43:01 -0400 Message-ID: To: Yoshifumi Nishida Content-Type: multipart/alternative; boundary=047d7b417b496eb67904e3444116 Cc: multipathtcp Subject: Re: [multipathtcp] Congestion control work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 09:43:22 -0000 --047d7b417b496eb67904e3444116 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 5, 2013 at 6:19 PM, Yoshifumi Nishida wrote: > Hi Scott, > > There's no big reason. It's just because we didn't see much energy for > it in the WG when we discussed re-chartering. > We brought it up several times during the discussion, but we didn't > see strong support for it. > I (personally) agree with you this is an important point. > > Thanks, > -- > Yoshifumi OK. Understood. Thanks. --047d7b417b496eb67904e3444116 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Aug 5, 2013 at 6:19 PM, Yoshifumi Nishida <nishida@sfc.wide.a= d.jp> wrote:
Hi Scott,

There's no big reason. It's just because we didn't see much ene= rgy for
it in the WG when we discussed re-chartering.
We brought it up several times during the discussion, but we didn't
see strong support for it.
I (personally) agree with you this is an important point.

Thanks,
--
Yoshifumi

OK. =A0Understood. =A0Thanks.=A0<= /div>
--047d7b417b496eb67904e3444116-- From philip.eardley@bt.com Tue Aug 6 05:48:51 2013 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 CB35121F9E26 for ; Tue, 6 Aug 2013 05:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.545 X-Spam-Level: X-Spam-Status: No, score=-103.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqYMbMOjCgrn for ; Tue, 6 Aug 2013 05:48:47 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 9360921F9E2B for ; Tue, 6 Aug 2013 05:48:44 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 6 Aug 2013 13:48:41 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.69]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Tue, 6 Aug 2013 13:48:41 +0100 From: To: Date: Tue, 6 Aug 2013 13:48:40 +0100 Thread-Topic: MPTCP interim (audio) meeting on security, late September Thread-Index: Ac6SoyaM2riJg+/VT8mY+Ug44bT7Kw== Message-ID: <9510D26531EF184D9017DF24659BB87F35CD40D536@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F35CD40D536EMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] MPTCP interim (audio) meeting on security, late September X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 12:48:51 -0000 --_000_9510D26531EF184D9017DF24659BB87F35CD40D536EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We think it would a good idea to have an interim (audio) meeting, in order = to make progress on advancing RFC 6824 on the standards track. We will discuss the security of the MPTCP protocol. The aim is to reach con= sensus on what security improvements are needed - and what are not needed -= in order to progress MPTCP on the Standards track. We hope to cover both t= he threat(s) that we will handle and, at a high-level, the solutions that w= ill be defined. Please fill in the doodle at http://doodle.com/xdf8eaiavvna9bcy#table For previous MPTCP WG interims, ~3pm GMT has been OK. Please shout if the t= ime is no good for you. In the meantime, please keep discussing MPTCP's security on the list! Thanks, Best wishes Phil & Yoshifumi --_000_9510D26531EF184D9017DF24659BB87F35CD40D536EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We think it would a good = idea to have an interim (audio) meeting, in order to make progress on advan= cing RFC 6824 on the standards track.

 

We will discuss the security of the MPT= CP protocol. The aim is to reach consensus on what security improvements ar= e needed - and what are not needed - in order to progress MPTCP on the Stan= dards track. We hope to cover both the threat(s) that we will handle and, a= t a high-level, the solutions that will be defined.

 

Please fill in the doodle= at http://doodle.com/= xdf8eaiavvna9bcy#table

 

For previous MPTCP WG interims, ~3pm GMT has been= OK. Please shout if the time is no good for you.

 

In the meantime, please kee= p discussing MPTCP’s security on the list!

 

Thanks,

Best wishes

Phil & Yoshi= fumi

= --_000_9510D26531EF184D9017DF24659BB87F35CD40D536EMV65UKRDdoma_-- From nishida@sfc.wide.ad.jp Thu Aug 15 23:41:51 2013 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 A033B11E8255 for ; Thu, 15 Aug 2013 23:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sup2tGqi75E8 for ; Thu, 15 Aug 2013 23:41:50 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id DFCCF21F9B26 for ; Thu, 15 Aug 2013 23:41:45 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 43B1D278075 for ; Fri, 16 Aug 2013 15:41:43 +0900 (JST) Received: by mail-la0-f51.google.com with SMTP id es20so1184685lab.10 for ; Thu, 15 Aug 2013 23:41:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=HmBB0+gvpOmuQUbjRtP+1wtiiI0H1er5O2seI6XIldE=; b=oOezTyJnle5LfapKxozyJGIKqz71C3PZlxNYvXA3uAL+Daz/oVnIKqS8goCD/xKzLg hjgGny9X4uDZ95yXetno/xVVLSN+qwwmdb1SAMtFyx+2UwEQk9s3xG3ssv64FIXUcD49 uPxXm2w32EW1xtin9UOyoJkvqiyOHEMKjzeXuM7WII8rC5H6SeWzSMl+vBDljviR2IFX BdsVxvoZ1cU9g8dC8FqkkUIUKH2L4eVzqRD88eo6LK9aUgYfhnmNHcaN1Ue8OvMMLStk QkDaGMGYQiNrQUOxw1/q0T5RD+c9ol7KSW9Pv2iYE4/bkUQEqyt3mjthAyqY+y2pmPWx rsZg== MIME-Version: 1.0 X-Received: by 10.152.6.202 with SMTP id d10mr62475laa.49.1376635301382; Thu, 15 Aug 2013 23:41:41 -0700 (PDT) Received: by 10.114.1.115 with HTTP; Thu, 15 Aug 2013 23:41:41 -0700 (PDT) Date: Thu, 15 Aug 2013 23:41:41 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] draft minutes for Berlin meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 06:41:51 -0000 Hello, We appreciate everyone who contributed to lively discussions in Berlin. We're still editing, but we uploaded a draft minute at: http://tools.ietf.org/wg/mptcp/minutes?item=minutes-87-mptcp.html If there's any mistakes or additional info, please feel free to let us know! Thanks Alan for note taking! -- Yoshi & Phil From philip.eardley@bt.com Wed Aug 21 00:35:59 2013 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 B46FF11E81C0 for ; Wed, 21 Aug 2013 00:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAZRwqLevSuj for ; Wed, 21 Aug 2013 00:35:55 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 97A9F11E81D3 for ; Wed, 21 Aug 2013 00:35:52 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 21 Aug 2013 08:35:50 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.199]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Wed, 21 Aug 2013 08:35:50 +0100 From: To: , Date: Wed, 21 Aug 2013 08:35:49 +0100 Thread-Topic: [multipathtcp] MPTCP interim (audio) meeting on security, late September Thread-Index: Ac6SoyaM2riJg+/VT8mY+Ug44bT7KwLnctXg Message-ID: References: <9510D26531EF184D9017DF24659BB87F35CD40D536@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F35CD40D536@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF8C54EF8EMV67UKRDdoma_" MIME-Version: 1.0 Subject: Re: [multipathtcp] MPTCP interim (audio) meeting on security, late September X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 07:36:00 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF8C54EF8EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a reminder, as I know a lot of people have been on holiday, please fil= l in the doodle Thanks phil From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of philip.eardley@bt.com Sent: 06 August 2013 13:49 To: multipathtcp@ietf.org Subject: [multipathtcp] MPTCP interim (audio) meeting on security, late Sep= tember We think it would a good idea to have an interim (audio) meeting, in order = to make progress on advancing RFC 6824 on the standards track. We will discuss the security of the MPTCP protocol. The aim is to reach con= sensus on what security improvements are needed - and what are not needed -= in order to progress MPTCP on the Standards track. We hope to cover both t= he threat(s) that we will handle and, at a high-level, the solutions that w= ill be defined. Please fill in the doodle at http://doodle.com/xdf8eaiavvna9bcy#table For previous MPTCP WG interims, ~3pm GMT has been OK. Please shout if the t= ime is no good for you. In the meantime, please keep discussing MPTCP's security on the list! Thanks, Best wishes Phil & Yoshifumi --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF8C54EF8EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a reminde= r, as I know a lot of people have been on holiday, please fill in the doodl= e

 

=

Thanks

p= hil

 

From: multipathtcp-bounces@ie= tf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.ea= rdley@bt.com
Sent: 06 August 2013 13:49
To: multipathtc= p@ietf.org
Subject: [multipathtcp] MPTCP interim (audio) meeting = on security, late September

 

We think it would a good idea to ha= ve an interim (audio) meeting, in order to make progress on advancing RFC 6= 824 on the standards track.

 

We will discuss the security of the MPTCP protoco= l. The aim is to reach consensus on what security improvements are needed -= and what are not needed - in order to progress MPTCP on the Standards trac= k. We hope to cover both the threat(s) that we will handle and, at a high-l= evel, the solutions that will be defined.

=  

Please fill in the doodle at http://doodle.com/xdf8eaiavv= na9bcy#table

 =

For previous MPTCP WG interims, ~3pm GMT has been OK. Pleas= e shout if the time is no good for you.

 

In the meantime, please keep discussi= ng MPTCP’s security on the list!

 

Thanks,

Best wishes

Phil & Yoshifumi<= /o:p>

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF8C54EF8EMV67UKRDdoma_-- From philip.eardley@bt.com Fri Aug 23 03:06:55 2013 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 E976C11E8111 for ; Fri, 23 Aug 2013 03:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1XtN3id2lti for ; Fri, 23 Aug 2013 03:06:49 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 4F44011E80FF for ; Fri, 23 Aug 2013 03:06:49 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 23 Aug 2013 11:06:46 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.199]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Fri, 23 Aug 2013 11:06:47 +0100 From: To: Date: Fri, 23 Aug 2013 11:06:46 +0100 Thread-Topic: Consensus call to create WG doc for RFC6824bis Thread-Index: Ac6R8ANtlVUSoOxJRi2KVDSVVXT0AwN+DuSw Message-ID: References: <9510D26531EF184D9017DF24659BB87F35CD05F60F@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F35CD05F60F@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF8C5532BEMV67UKRDdoma_" MIME-Version: 1.0 Subject: Re: [multipathtcp] Consensus call to create WG doc for RFC6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 10:06:55 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF8C5532BEMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the replies, we have consensus for this Authors, please can you create the first version of the WG draft for RFC682= 4bis Thanks From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of philip.eardley@bt.com Sent: 05 August 2013 16:31 To: multipathtcp@ietf.org Subject: [multipathtcp] Consensus call to create WG doc for RFC6824bis Sorry for the typo, I meant RFC6824: TCP Extensions for Multipath Operation= with Multiple Addresses (and not 6897, which is the Application Interface= Considerations doc) luckily you all seem to have known what I meant! No need to reply to this email if you already replied to the original one. Thanks phil From: multipathtcp-bounces@ietf.org [= mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 01 August 2013 13:47 To: multipathtcp@ietf.org Subject: [multipathtcp] Consensus call to create WG doc for RFC6897bis Hi, This is a consensus call to create a WG doc, draft-ietf-mptcp-rfc6897bis-00= . The -00 document will be almost identical to RFC6897, with these changes: * Intended status: Standards track * Obsoletes (when published): RFC6897 This is basically a consensus call that RFC6897 is the right place for the = WG to start - towards meeting our objective of a standards track MPTCP sign= alling doc. Just to be clear - we're not asking if the doc is ready to send to IESG - w= e know that further thought (and perhaps further work) is needed on securit= y issues. Indeed our AD, Martin, has kindly offered to help us get a securi= ty advisor from the sec-area. Best wishes, phil --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF8C5532BEMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the replies, we have= consensus for this

 

Authors, please can you create the first version of the WG draft fo= r RFC6824bis

 

T= hanks

 

From: multipathtcp-boun= ces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phi= lip.eardley@bt.com
Sent: 05 August 2013 16:31
To: multi= pathtcp@ietf.org
Subject: [multipathtcp] Consensus call to create= WG doc for RFC6824bis

 

Sorry for the typo, I meant RFC6824: TCP= Extensions for Multipath Operation with Multiple Addresses  (and not = 6897, which is the Application Interface Considerations doc)

 

luckily you all = seem to have known what I meant!

= No need t= o reply to this email if you already replied to the original one.

 

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Thanks

phil

 

From: multipathtcp-b= ounces@ietf.org [mailt= o:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: 01 August = 2013 13:47
To: multipath= tcp@ietf.org
Subject: [multipathtcp] Consensus call to create= WG doc for RFC6897bis

 

Hi,

 

This is a consensus call to create a WG do= c, draft-ietf-mptcp-rfc6897bis-00.

The -00 document will be almost identical to RFC6897, with= these changes:
* Intended status: Standards track
* Obsoletes (when = published): RFC6897

This is basically a consensus call that RFC6897 is the right place for th= e WG to start - towards meeting our objective of a standards track MPTCP si= gnalling doc.

&nbs= p;

Just to be clea= r - we're not asking if the doc is ready to send to IESG - we know tha= t further thought (and perhaps further work) is needed on security issues. = Indeed our AD, Martin, has kindly offered to help us get a security advisor= from the sec-area.

 

Best wi= shes,

phil

 <= /p>

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF8C5532BEMV67UKRDdoma_-- From dreibh@iem.uni-due.de Fri Aug 23 06:03:46 2013 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 44F4A11E80FF for ; Fri, 23 Aug 2013 06:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C06++NY2vIY8 for ; Fri, 23 Aug 2013 06:03:41 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id F414211E8161 for ; Fri, 23 Aug 2013 06:03:37 -0700 (PDT) Received: from nordmarka.simula.nornet ([77.88.71.158]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id r7ND3a0U032183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Aug 2013 15:03:37 +0200 From: Thomas Dreibholz To: multipathtcp@ietf.org Date: Fri, 23 Aug 2013 15:03:36 +0200 Message-ID: <3787215.rHeZLKpNg0@nordmarka.simula.nornet> User-Agent: KMail/4.10.5 (Linux/3.8.0-29-generic; KDE/4.10.5; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2688249.v9jR4EBNJB"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Subject: [multipathtcp] Invitation to the NorNet Users Workshop (NNUW-1) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 13:03:46 -0000 --nextPart2688249.v9jR4EBNJB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" [Our apologies if you receive multiple copies of this message.] CALL FOR PARTICIPATION We cordially invite you to join us at: The 1st International NorNet Users Workshop (NNUW-1) at the Simula Research Laboratory in Fornebu, Akershus/Norway September 18-19, 2013 http://www.nornet-testbed.no/workshops/nnuw-1/ There is *no* workshop fee! Please register as early as possible. More than one year ago, the NorNet project has started with the intenti= on to=20 build up the world=E2=80=99s first large-scale network testbed for mul= ti-homed=20 systems. NorNet should provide researchers the possibility to perform=20= experiments in real-world wired and wireless setups. Now, the wired par= t =E2=80=93=20 denoted as NorNet Core =E2=80=93 as well as the wireless part =E2=80=93= denoted as NorNet Edge=20 =E2=80=93 have reached a stage that allows further researchers to start= running such=20 experiments. That is, currently 11 NorNet Core sites and more than 300 = NorNet=20 Edge nodes are ready to support your research ideas on resilience, mobi= lity,=20 security, multi-path transport and further subjects! This workshop intends to provide current as well as new and future NorN= et=20 users the possibility to get information about the NorNet testbed and i= nitial=20 research results, to discuss their ideas with the testbed developers an= d to=20 get the possibility for obtaining access to NorNet. Further details on the workshop are available at: http://www.nornet-testbed.no/workshops/nnuw-1/ An information sheet in PDF format can be found here: http://www.nornet-testbed.no/wp-content/uploads/2013/06/NNUW-1-CallForP= articipation.pdf A detailed description of NorNet can be found at: http://www.nntb.no/ We are looking forward to see you in Fornebu! The NNUW-1 Organisers --nextPart2688249.v9jR4EBNJB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlIXXagACgkQ32BbsHYPLWUBCACfRiv3+TXEwloAl7HTJJeSZ94k p0UAniA7JTPOlFN8dXePpgvjreyRoboT =xPe7 -----END PGP SIGNATURE----- --nextPart2688249.v9jR4EBNJB-- From yungchih@cs.umass.edu Fri Aug 30 12:16:05 2013 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 8516B21F9D70 for ; Fri, 30 Aug 2013 12:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EL+3jxEWn-Lx for ; Fri, 30 Aug 2013 12:16:00 -0700 (PDT) Received: from mail.cs.umass.edu (loki.cs.umass.edu [128.119.240.93]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF6E21F9D62 for ; Fri, 30 Aug 2013 12:15:59 -0700 (PDT) Received: from [128.119.245.94] (canpea.cs.umass.edu [128.119.245.94]) (authenticated bits=0 authid=yungchih) by mail.cs.umass.edu (8.13.8/8.13.1) with ESMTP id r7UJFvdu002366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 30 Aug 2013 15:15:58 -0400 Message-ID: <5220EF6C.6060102@cs.umass.edu> Date: Fri, 30 Aug 2013 15:15:56 -0400 From: Yung-Chih Chen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: multipathtcp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [multipathtcp] a measurement study of multipath TCP in the wild X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 19:16:05 -0000 Dear MultiPath TCP community: We have done some measurement study of multipath TCP performance over wireless networks (WiFi, 3G/4G LTE) and would like to share the results with you. The goal is to understand how well mptcp performs in the wild under different scenarios, as well as the effect of different congestion controllers (i.e., uncoupled New Reno, coupled, and olia). Here is a pointer to the paper (will appear in IMC this year). http://www.cs.umass.edu/~yungchih/publication/imc_mtcp.pdf Best, Yung-Chih Abstract: With the popularity of mobile devices and the pervasive use of cellular technology, there is widespread interest in hybrid networks and on how to achieve robustness and good performance from them. As most smart phones and mobile devices are equipped with dual interfaces (WiFi and 3G/4G), a promising approach is through the use of multi-path TCP, which leverages path diversity to improve performance and provide robust data transfers. We explore the performance of multi-path TCP in the wild, focusing on simple 2-path multi-path TCP scenarios. We seek to answer the following questions: How much can a user benefit from using multi-path TCP over cellular and WiFi relative to using the either interface alone? What is the impact of flow size on average latency? What is the effect of the rate/route control algorithm on performance? We are especially interested in understanding how application level performance is affected when path characteristics (e.g., round trip times and loss rates) are diverse. We address these questions by conducting measurements using one commercial Internet service provider and three major cellular carriers in the US.