From nobody Sat Mar 1 13:10:41 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE12D1A0308 for ; Sat, 1 Mar 2014 13:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.464 X-Spam-Level: * X-Spam-Status: No, score=1.464 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwotXxWcb_rB for ; Sat, 1 Mar 2014 13:10:33 -0800 (PST) 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 ACEE11A02CD for ; Sat, 1 Mar 2014 13:10:33 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id C1D78278231 for ; Sun, 2 Mar 2014 06:10:30 +0900 (JST) Received: by mail-lb0-f177.google.com with SMTP id z11so3597558lbi.22 for ; Sat, 01 Mar 2014 13:10:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WusuG+M5RD2W2fW3hycw0wI98VxwRpqqjyL9l1r4z+4=; b=kGuF0hr01KM+3e2MzchK/QeJH/iw5pLUnLU170vnh8ii9mLTV45orT+7ny4D320hPJ LNwruh2Y0eImURDArhWqxck+599lwYQDv8TMGUVhuvdWvRQAWtZ7w/WOxlQAQgYSYHVO nohUE5ghM0m1MEv56nMnHqHwQRodNiyVMOkV9MbdpISOGwtiUKDyADtjrby3svlx77qY n9yDaE5SOWdynepIrdjRw+bsmzpj2gxmlxcHT7lWvox3QmZMGTYH7Jwqeh04rrqWAu7x VwiVZhICeVD/sovTipWCg6L8CVEzWAvr1EOCrxbqOEG+NhYZQDe7o5r8PRcHA2KnCj3D 1kVw== MIME-Version: 1.0 X-Received: by 10.112.50.194 with SMTP id e2mr9645281lbo.4.1393708226942; Sat, 01 Mar 2014 13:10:26 -0800 (PST) Received: by 10.114.93.3 with HTTP; Sat, 1 Mar 2014 13:10:26 -0800 (PST) In-Reply-To: <530F0DC7.3060707@uclouvain.be> References: <530D08BB.9080004@uclouvain.be> <530F0DC7.3060707@uclouvain.be> Date: Sat, 1 Mar 2014 13:10:26 -0800 Message-ID: From: Yoshifumi Nishida To: Olivier Bonaventure Content-Type: multipart/alternative; boundary=001a11336c26c99ac804f391fb08 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/RsOZkzP65nP6bTpQSEIgOadhSOk Cc: multipathtcp Subject: Re: [multipathtcp] Hash function usage in Multipath TCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 21:10:38 -0000 --001a11336c26c99ac804f391fb08 Content-Type: text/plain; charset=ISO-8859-1 Hi Olivier, On Thu, Feb 27, 2014 at 2:04 AM, Olivier Bonaventure < Olivier.Bonaventure@uclouvain.be> wrote: > > client sends SYN with MP_CAPABLE indicating HASH1+HASH2 > attacker removes HASH2 from SYN > server replies with HASH1 in SYN+ACK > > If client sends SYN with MP_CAPABLE and only HASH2, it should reply with > RST if it receives HASH1 in SYN+ACK Right. I meant that clients have a mean to avoid downgrading attack if they want. So, I think this probably won't be a severe issue. > Should we already define a new hash functions inside RFC6824bis ? >> >> If yes, then we probably need to structure the Multipath TCP RFCs as >> for TCP-AO, i.e. : >> >> - a first document defines the protocol with abstract crypto >> functions, basically most of the current RFC6824 >> - a second document specifies the crypto algorithms can be used >> with all their requirements parameters >> >> If we go in the direction, are there strong preferences for a second >> hash function for Multipath TCP ? >> >> Hmm. I see your point. But, how many hashes we want to specify now? >> If we just add one more hash to the current spec, the second doc will be >> thin, it might not be a problem, though.. >> > > The second document could even only contain a single hash (SHA-1 today). > If we need to expand the hash functions without chaning MPTCP, we simply > need to update this second document. > > We might want to reserve some bits (e.g. 3) in the MP_CAPABLE option for > the selection of the hash functions that are to be defined in the second > document I see. I don't have strong opinion on having two drafts yet. But, I'm wondering if we need to reserve bits. It seems to me that we can define C-H flags in the second draft. A question might be what we should do when we try to specify B flag=1 usage or define another version, which might affect the usage for C-H or other crypto logic. I'm wondering if we have other drafts or put all changes in the second draft. Thanks, -- Yoshifumi --001a11336c26c99ac804f391fb08 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Olivier,

On Thu, Feb 27, 2014 at 2:04 AM, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> wrote:

client sends SYN with MP_CAPABLE indicating HASH1+HASH2
attacker removes HASH2 from SYN
server replies with HASH1 in SYN+ACK

If client sends SYN with MP_CAPABLE and only HASH2, it should reply with RS= T if it receives HASH1 in SYN+ACK

Right. I = meant that clients have a mean to avoid downgrading attack if they want.=A0=
So, I think this probably won't be a severe issue.=A0
<= div>=A0
=A0 =A0 Should we already define a new hash functions inside RFC6824bis ?
=A0 =A0 If yes, then we probably need to structure the Multipath TCP RFCs a= s
=A0 =A0 for TCP-AO, i.e. :

=A0 =A0 =A0 - a first document defines the protocol with abstract crypto =A0 =A0 functions, basically most of the current RFC6824
=A0 =A0 =A0 - a second document specifies the crypto algorithms can be used=
=A0 =A0 with all their requirements parameters

=A0 =A0 If we go in the direction, are there strong preferences for a secon= d
=A0 =A0 hash function for Multipath TCP ?

Hmm. I see your point. But, how many hashes we want to specify now?
If we just add one more hash to the current spec, the second doc will be thin, it might not be a problem, though..

The second document could even only contain a single hash (SHA-1 today). If= we need to expand the hash functions without chaning MPTCP, we simply need= to update this second document.

We might want to reserve some bits (e.g. 3) in the MP_CAPABLE option for th= e selection of the hash functions that are to be defined in the second docu= ment

I see. I don't have strong opinion= on having two drafts yet. But, I'm wondering if we need to reserve bit= s. It seems to me that we can define C-H flags in the second draft.=A0
A question might be what we should do when we try to specify B flag=3D= 1 usage or define another version, which might affect the usage for C-H or = other crypto logic. I'm wondering if we have other drafts or put all ch= anges in the second draft.

Thanks,
--
Yoshifumi
--001a11336c26c99ac804f391fb08-- From nobody Sat Mar 1 13:10:46 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7642E1A02CD for ; Sat, 1 Mar 2014 13:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.464 X-Spam-Level: * X-Spam-Status: No, score=1.464 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsautILLvlYF for ; Sat, 1 Mar 2014 13:10:32 -0800 (PST) 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 DBC921A0175 for ; Sat, 1 Mar 2014 13:10:31 -0800 (PST) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id C4C67278231 for ; Sun, 2 Mar 2014 06:10:27 +0900 (JST) Received: by mail-qg0-f47.google.com with SMTP id 63so6631576qgz.6 for ; Sat, 01 Mar 2014 13:10:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lBWH8T33AE8T7ZoOjCtrJECHbqWd07zXUfc6VWHym2I=; b=Vmn6Z0Tu58/PjiIjGIkHah2W213V4wdl49blSdIMfe+gh5rFU4soeL7o5CipAavRkN F/ey44qRqjslFoUPfFI+x0EVgqnl8BFRjJdU/q0Dmh41BGAB5XE0ffCGjs9oJsIOVgbb hUA0NB0ljBUm4MBQM9pphyWAg3b9tmgpsmzbw+LEyuQy00dQISo3txwEudJHtHvcs3GG Cn4DpzxUr7/EMHFAThW0gnPI1rCK0yLiJVDmc1zm1obpZedZB03A3HezudqCUgcFXooD G1mB7+4OTcABIiNNvg58GKrKajZxaFVQg4NGXybpTWJVy5JT1sX+/h+oHJh+Nby4x93W 36Iw== MIME-Version: 1.0 X-Received: by 10.224.60.193 with SMTP id q1mr13036302qah.67.1393708225964; Sat, 01 Mar 2014 13:10:25 -0800 (PST) Received: by 10.96.149.231 with HTTP; Sat, 1 Mar 2014 13:10:25 -0800 (PST) In-Reply-To: <530F0DC7.3060707@uclouvain.be> References: <530D08BB.9080004@uclouvain.be> <530F0DC7.3060707@uclouvain.be> Date: Sat, 1 Mar 2014 13:10:25 -0800 Message-ID: From: Yoshifumi Nishida To: Olivier Bonaventure Content-Type: multipart/alternative; boundary=001a1133dee6bacca904f391fb31 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/eyENrbiLutv9-5FB6OQwTgDeOjw Cc: multipathtcp Subject: Re: [multipathtcp] Hash function usage in Multipath TCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 21:10:39 -0000 --001a1133dee6bacca904f391fb31 Content-Type: text/plain; charset=ISO-8859-1 Hi Olivier, On Thu, Feb 27, 2014 at 2:04 AM, Olivier Bonaventure < Olivier.Bonaventure@uclouvain.be> wrote: > > client sends SYN with MP_CAPABLE indicating HASH1+HASH2 > attacker removes HASH2 from SYN > server replies with HASH1 in SYN+ACK > > If client sends SYN with MP_CAPABLE and only HASH2, it should reply with > RST if it receives HASH1 in SYN+ACK Right. I meant that clients have a mean to avoid downgrading attack if they want. So, I think this probably won't be a severe issue. > Should we already define a new hash functions inside RFC6824bis ? >> >> If yes, then we probably need to structure the Multipath TCP RFCs as >> for TCP-AO, i.e. : >> >> - a first document defines the protocol with abstract crypto >> functions, basically most of the current RFC6824 >> - a second document specifies the crypto algorithms can be used >> with all their requirements parameters >> >> If we go in the direction, are there strong preferences for a second >> hash function for Multipath TCP ? >> >> Hmm. I see your point. But, how many hashes we want to specify now? >> If we just add one more hash to the current spec, the second doc will be >> thin, it might not be a problem, though.. >> > > The second document could even only contain a single hash (SHA-1 today). > If we need to expand the hash functions without chaning MPTCP, we simply > need to update this second document. > > We might want to reserve some bits (e.g. 3) in the MP_CAPABLE option for > the selection of the hash functions that are to be defined in the second > document I see. I don't have strong opinion on having two drafts yet. But, I'm wondering if we need to reserve bits. It seems to me that we can define C-H flags in the second draft. A question might be what we should do when we try to specify B flag=1 usage or define another version, which might affect the usage for C-H or other crypto logic. I'm wondering if we have other drafts or put all changes in the second draft. Thanks, -- Yoshifumi --001a1133dee6bacca904f391fb31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Olivier,

On Thu, Feb 27, 2014 at 2:04 AM, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> wrote:

client sends SYN with MP_CAPABLE indicating HASH1+HASH2
attacker removes HASH2 from SYN
server replies with HASH1 in SYN+ACK

If client sends SYN with MP_CAPABLE and only HASH2, it should reply with RS= T if it receives HASH1 in SYN+ACK

Right. I = meant that clients have a mean to avoid downgrading attack if they want.=A0=
So, I think this probably won't be a severe issue.=A0
<= div>=A0
=A0 =A0 Should we already define a new hash functions inside RFC6824bis ?
=A0 =A0 If yes, then we probably need to structure the Multipath TCP RFCs a= s
=A0 =A0 for TCP-AO, i.e. :

=A0 =A0 =A0 - a first document defines the protocol with abstract crypto =A0 =A0 functions, basically most of the current RFC6824
=A0 =A0 =A0 - a second document specifies the crypto algorithms can be used=
=A0 =A0 with all their requirements parameters

=A0 =A0 If we go in the direction, are there strong preferences for a secon= d
=A0 =A0 hash function for Multipath TCP ?

Hmm. I see your point. But, how many hashes we want to specify now?
If we just add one more hash to the current spec, the second doc will be thin, it might not be a problem, though..

The second document could even only contain a single hash (SHA-1 today). If= we need to expand the hash functions without chaning MPTCP, we simply need= to update this second document.

We might want to reserve some bits (e.g. 3) in the MP_CAPABLE option for th= e selection of the hash functions that are to be defined in the second docu= ment

I see. I don't have strong opinion= on having two drafts yet. But, I'm wondering if we need to reserve bit= s. It seems to me that we can define C-H flags in the second draft.=A0
A question might be what we should do when we try to specify B flag=3D= 1 usage or define another version, which might affect the usage for C-H or = other crypto logic. I'm wondering if we have other drafts or put all ch= anges in the second draft.

Thanks,
--
Yoshifumi
--001a1133dee6bacca904f391fb31-- From nobody Mon Mar 3 23:25:11 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458721A03AC for ; Mon, 3 Mar 2014 23:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.758 X-Spam-Level: X-Spam-Status: No, score=-2.758 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40-aTvYkxw87 for ; Mon, 3 Mar 2014 23:25:06 -0800 (PST) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9C51A1A03C6 for ; Mon, 3 Mar 2014 23:25:06 -0800 (PST) Received: from mbpobo.dhcp.info.ucl.ac.be (unknown [172.17.0.12]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id D527A198091 for ; Tue, 4 Mar 2014 08:24:54 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be D527A198091 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1393917894; bh=GoFJzvGnQAQgaALIYhyeAdThck108QdIycPeiJcMCa0=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding; b=znqy8R24j9ioM7NhAf+6dWp3H/kvN0fcHhsrRj0rSbWiEhon/sYC3sfjpCpEb4KUn fRUitvo0WWhcYwCuR4aeG1MClJt3ey16IrV3k6YXCevhkfztzl/IKU24c3YYekREFB XLpYNmJPDh3LmTWAEcpG9yfySKloSLBHZwvlYaQU= Message-ID: <5314DE3D.2010401@uclouvain.be> Date: Mon, 03 Mar 2014 20:55:41 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: multipathtcp 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-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: D527A198091.A36B0 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/_EYai41xhKu45XOV_tq2pzplHKE Subject: [multipathtcp] Adding options in MPTCP RST X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 07:25:09 -0000 Hello, With regular TCP, a host sends a RST when it does not have any state about a TCP connection. The reception of a RST forces the termination of the corresponding TCP connection. Given that a RST segment is a fast way to terminate a TCP connection, some middleboxes are capable of sending spoofed RST segments to terminate TCP connections. We've seen some of these deployed to block some forms of P2P applications, but some DPIs are likely capable of doing this as well. With Multipath TCP, a RST can have a slightly different meaning. It can indicate that a host has lost all its state for the corresponding MPTCP connection. In this case, the other host should discard all its state. However, there are situations where a host could want to send a RST to quickly terminate a subflow without terminating the MPTCP connection (which can continue on other subflows that already exist or will be established). A typical example is a server having two subflows towards a client. The server has sent a window worth of data on the first subflow but this data has not yet been acknowledged. After some tiemout expiration, the server retransmits the data over the second subflow and it gets immediately acknowledged. When the first subflow recovers, the server still needs to retransmit the data over this subflow even if it has already been acknowledged at the MPTCP level. This is inefficient. It would be nice for the server to be able to send a RST over the first subflow with a kind of reason code that indicates that the client should recreate a subflow. Since the client is often behind a NAT, it is impossible for the server to create this subflow by itself. Another example is when the server can support a limited number of subflows, say 2. If it receives a SYN for a third subflow from the client, it would reply with a RST. Adding a reason code indicating that the server supports up to 2 subflows would allow the client to learn that it should not try to establish more subflows. By adding an option in the MPTCP RST, we might also enable the client to distinguish between a RST generated by a middlebox and a RST generated by the endhost. For this, the RST option could include the DATAACK and a HMAC of this DATA_ACK to authenticate it. Any other thoughts on adding options inside the RST ? Olivier From nobody Tue Mar 4 03:38:36 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192CF1A0431 for ; Tue, 4 Mar 2014 03:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.471 X-Spam-Level: **** X-Spam-Status: No, score=4.471 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqxTsmcZwDj4 for ; Tue, 4 Mar 2014 03:38:31 -0800 (PST) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id C0C391A02CE for ; Tue, 4 Mar 2014 03:38:30 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id id10so4301333vcb.27 for ; Tue, 04 Mar 2014 03:38:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ZAdz21+ciYP974119JIDhpbcf8I6ihDYKClvn1+4z10=; b=qquKL6Kyqyovje02Aqhq6tJA3zTa+m4N8wbH00VUM/Ybw/cbQNl4ZoVhqXebt3mgal BMAqne0hIJa7txCmWgdwaMcKHQpS6pt3STpjMb8i0zNcx8G1spGeTT8elypxZLPKwiwH kJSPXb5AdcrUaAj8LeguJz8nwfurkPA+oCksZ1+bhSranjYqpVHhr17/JzHAfbpemkvf ZsTOues0FWTEJoGIAk0rzUm5MN9z1SbrKwO3ZgpttqfMgE3nsGrNRF/hsg/QebUWv/Ac ZERMdbPqTPJOqEqTcJ1LKD9dx41g23nhi/wH9m/o8aGJygZQljtyYahLIuh8BhIP54qj mmDg== MIME-Version: 1.0 X-Received: by 10.52.166.103 with SMTP id zf7mr3448494vdb.30.1393933107353; Tue, 04 Mar 2014 03:38:27 -0800 (PST) Received: by 10.58.100.212 with HTTP; Tue, 4 Mar 2014 03:38:27 -0800 (PST) In-Reply-To: References: <20140214160043.25045.90052.idtracker@ietfa.amsl.com> <2afb52fe3cd3acc-0000a.Richmail.00009030405128129702@chinamobile.com> Date: Tue, 4 Mar 2014 19:38:27 +0800 Message-ID: From: lingli deng To: "multipathtcp@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2c102b45d3a04f3c657e5 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/UBsyQWFoZWlzt1Cw631p8tDslsQ Subject: Re: [multipathtcp] Fw:New Version Notification fordraft-deng-mptcp-mobile-network-proxy-00.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 11:38:34 -0000 --001a11c2c102b45d3a04f3c657e5 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi all, Thanks for the comments and feedback yesterday regarding MPTCP proxy. I recall a question from the floor regarding to applicability of MPTCP proxy to TCPcrypt flows, but I didn=A1=AFt catch the exact question or his = name. Would anyone help in clarifying the question or any other questions that one feel needs to be addressed/discussed by posting to the list, before we can start working on it. Thanks a lot! BR Lingli 2014-02-16 9:26 GMT+08:00 lingli deng : > Hi all, > > We uploaded a new I.D., which discusses the usecases of network deployed > MPTCP proxy. > URL: http://www.ietf.org/internet-drafts/draft-deng- > mptcp-mobile-network-proxy-00.txt > Your review and comments would be highly appreciated. > > Best Regards, > > Lingli > > ---------- Forwarded message ---------- > From: =B5=CB=C1=E9=C0=F2 > Date: 2014-02-14 23:59 GMT+08:00 > Subject: Fw:New Version Notification > fordraft-deng-mptcp-mobile-network-proxy-00.txt > To: denglingli > > > > > ----=D3=CA=BC=FE=D4=AD=CE=C4---- > =B7=A2=BC=FE=C8=CB=A3=BAinternet-drafts > =CA=D5=BC=FE=C8=CB=A3=BATao Sun ,Dapeng Liu >,Deng Lingli,Tao Sun >,Lingli Deng ,Dapeng Liu < > liudapeng@chinamobile.com> > =B3=AD =CB=CD: (=CE=DE) > =B7=A2=CB=CD=CA=B1=BC=E4=A3=BA2014-02-15 00:00:43 > =D6=F7=CC=E2=A3=BANew Version Notification fordraft-deng-mptcp-mobile-net= work-proxy-00.txt > > > A new version of I-D, draft-deng-mptcp-mobile-network-proxy-00.txt > has been successfully submitted by Lingli Deng and posted to the > IETF repository. > > Name: draft-deng-mptcp-mobile-network-proxy > Revision: 00 > Title: MPTCP Proxy for Mobile Networks > Document date: 2014-02-14 > Group: Individual Submission > Pages: 8 > URL: > http://www.ietf.org/internet-drafts/draft-deng-mptcp-mobile-network-proxy= -00.txt > Status: > https://datatracker.ietf.org/doc/draft-deng-mptcp-mobile-network-proxy/ > Htmlized: > http://tools.ietf.org/html/draft-deng-mptcp-mobile-network-proxy-00 > > > Abstract: > This document discusses the motivation and usecases for ISP deployed > MPTCP proxies in mobile networks. > > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > Subject=A3=BANew Version Notification fordraft-deng-mptcp-mobile-network-= proxy-00.txt > > > A new version of I-D, draft-deng-mptcp-mobile-network-proxy-00.txt > has been successfully submitted by Lingli Deng and posted to the > IETF repository. > > Name: draft-deng-mptcp-mobile-network-proxy > Revision: 00 > Title: MPTCP Proxy for Mobile Networks > Document date: 2014-02-14 > Group: Individual Submission > Pages: 8 > URL: > http://www.ietf.org/internet-drafts/draft-deng-mptcp-mobile-network-proxy= -00.txt > Status: > https://datatracker.ietf.org/doc/draft-deng-mptcp-mobile-network-proxy/ > Htmlized: > http://tools.ietf.org/html/draft-deng-mptcp-mobile-network-proxy-00 > > > Abstract: > This document discusses the motivation and usecases for ISP deployed > MPTCP proxies in mobile networks. > > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > > > > -- > =B5=CB=C1=E9=C0=F2/Lingli Deng > =D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/China Mobile Resea= rch Institute > e-mail: denglingli@chinamobile.com > tel: 15801696688-3367 > mobile: 13810597148 > --=20 =B5=CB=C1=E9=C0=F2/Lingli Deng =D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/China Mobile Researc= h Institute e-mail: denglingli@chinamobile.com tel: 15801696688-3367 mobile: 13810597148 --001a11c2c102b45d3a04f3c657e5 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi all,
 
Thanks for the com= ments and feedback yesterday regarding MPTCP proxy.

I r= ecall a question from the floor regarding to applicability of MPTCP proxy to TCPcrypt flows, but I didn&rsq= uo;t catch the exact question or his name.

Wou= ld anyone help in clarifying the question or any other questions that = one feel needs to be addressed/discussed by posting to the list, before&nbs= p;we can start working on it.

&nb= sp;

Thanks a lot!

 

BR

Lingli



2014-02-16 9:26 GMT+08:00 lingli deng <denglingli@gmail.com= >:
Hi all,
&nbs= p;
We uploaded a new I.D., which discusses the usecases of networ= k deployed MPTCP proxy.
Your review and comments would be highly appreciated.
 =
Best Regards,
 
Lingli

---------- Forwarded message= ----------
From: =B5=CB=C1=E9=C0=F2 <dengl= ingli@chinamobile.com>
Date: 2014-02-14 23:59 GMT+08:00
Subject: Fw:New Version Notification fo= rdraft-deng-mptcp-mobile-network-proxy-00.txt
To: denglingli <denglingli@gmail.com= >




----=D3=CA=BC=FE=D4=AD=CE=C4----
=B7=A2=BC=FE=C8=CB= =A3=BAinternet-drafts<internet-drafts@ietf.org>
=CA=D5=BC=FE=C8=CB=A3=BATao=  Sun <suntao@chinamobile.com>,Dapeng Liu<liudapeng@chinamobile.com>= ,Deng Lingli<denglingli@chinamobile.com>,Tao Sun<suntao@chinamobile.com&= gt;,Lingli Deng <denglingli@chinamobile.com>,Dapeng Liu = <liudapen= g@chinamobile.com>
=B3=AD=A1=A1=CB=CD: (=CE=DE)
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA2014-0= 2-15 00:00:43
=D6=F7=CC=E2=A3=BANew Version Notificat= ion fordraft-deng-mptcp-mobile-network-proxy-00.txt


A = new version of I-D, draft-deng-mptcp-mobile-network-pro= xy-00.txt
has been successfully submitted by Lingli Den= g and posted to the
IETF repository.

Name: draft-deng-mptcp-mobile-network-proxy <= br>Revision: 00
Title: MPTCP Proxy for Mobile Netwo= rks
Document date: 2014-02-14
Group: Individual Submissio= n
Pages: 8
URL: http://www= .ietf.org/internet-drafts/draft-deng-mptcp-mobile-network-proxy-00.txt =
Status: https://datatracker.ietf.org/doc/dr= aft-deng-mptcp-mobile-network-proxy/
Htmlized: http://tools.ietf.org/html/draft-deng-mptcp-mobile-network-proxy-00=


Abstract:
 This document discusses the = ;motivation and usecases for ISP deployed
&nbs= p;MPTCP proxies in mobile networks.


  =


Please note that it may take a&nb= sp;couple of minutes from the time of su= bmission
until the htmlized version and diff are = available at = tools.ietf.org.

The IETF Secretariat


Subj= ect=A3=BANew Version Notification fordraft-deng-mptcp-mobile= -network-proxy-00.txt


A new version of I-D, draft-deng-mptcp-mob= ile-network-proxy-00.txt
has been successfully submitted=  by Lingli Deng and posted to the
IE= TF repository.

Name: draft-deng-mptcp-mobile-network-proxy Revision: 00
Title: MPTCP Proxy for Mobile Networks=
Document date: 2014-02-14
Group: Individual Submission <= br>Pages: 8
URL: http://www.ie= tf.org/internet-drafts/draft-deng-mptcp-mobile-network-proxy-00.txt Status: https://datatracker.ietf.org/doc/dr= aft-deng-mptcp-mobile-network-proxy/
Htmlized: http://tools.ietf.org/html/draft-deng-mptcp-mobile-network-proxy-00=


Abstract:
 This document discusses the = ;motivation and usecases for ISP deployed
&nbs= p;MPTCP proxies in mobile networks.


  =


Please note that it may take a&nb= sp;couple of minutes from the time of su= bmission
until the htmlized version and diff are = available at = tools.ietf.org.

The IETF Secretariat







--
=B5=CB=C1=E9=C0=F2/Lingli Deng=D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/China Mobile Resea= rch Institute
e-mail: denglingli@chinamobile.com
tel: 15801696688-3367
mobile: 13810597148



--
=B5=CB=C1=E9=C0=F2/Ling= li Deng
=D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/China Mob= ile Research Institute
e-mail: denglingli@chinamobile.com
tel: 15801696688-3367
mobile: 13810597148
--001a11c2c102b45d3a04f3c657e5-- From nobody Tue Mar 4 04:56:45 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C691A0092 for ; Tue, 4 Mar 2014 04:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SATVh_0I41hb for ; Tue, 4 Mar 2014 04:56:41 -0800 (PST) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id C50871A0070 for ; Tue, 4 Mar 2014 04:56:41 -0800 (PST) Received: from mbpobo.dhcp.info.ucl.ac.be (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id E812E183450; Tue, 4 Mar 2014 13:56:32 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be E812E183450 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1393937792; bh=qmHXp406HgFNBx5JoKoM9PP7KTAmogngaqwPXguBFGQ=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Hjl+5790Uzf0ddOG4WP77JSiTLdEJD2EYtiQyrQQ9kB/Ngg4CfFw4s6mYXP/7nxNZ YDxjp6dp8D8Xgmgabl3yABnJxk5PPKxlIJMYy/PTa5y8T5c0erc20l2obS1+j5GXsU nYD0HSCw2Mljtu+hcX6P2ViN1KNUuLW0Pr28LOsg= Message-ID: <5315CD80.3070808@uclouvain.be> Date: Tue, 04 Mar 2014 13:56:32 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: lingli deng , "multipathtcp@ietf.org" References: <20140214160043.25045.90052.idtracker@ietfa.amsl.com> <2afb52fe3cd3acc-0000a.Richmail.00009030405128129702@chinamobile.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: E812E183450.A1D96 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/uUZ2M93x5y3LUA2cMEbkMjOZn7s Subject: Re: [multipathtcp] Fw:New Version Notification fordraft-deng-mptcp-mobile-network-proxy-00.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 12:56:43 -0000 Lingli, > Thanks for the comments and feedback yesterday regarding MPTCP proxy. > > I recall a question from the floor regarding to applicability of MPTCP > proxy to TCPcrypt flows, but I didn’t catch the exact question or his name. > > Would anyone help in clarifying the question or any other questions that > one feel needs to be addressed/discussed by posting to the list, > before we can start working on it. If I recall correctly, this was a comment from Steve Kent who noted : "If I were using TLS, this would be completely compatible, but tcpcrypt would not be" The reason for the incompatibility with tcpcrypt is that tcpcrypt uses a MAC to protect the end-to-end TCP header while TLS only protects the datastream Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From nobody Wed Mar 5 18:05:52 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557521A0071 for ; Wed, 5 Mar 2014 18:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waa0IcYdFuSV for ; Wed, 5 Mar 2014 18:05:49 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 61C261A0060 for ; Wed, 5 Mar 2014 18:05:49 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s2625bEP018155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 5 Mar 2014 18:05:37 -0800 (PST) Message-ID: <5317D7F2.7080507@isi.edu> Date: Wed, 05 Mar 2014 18:05:38 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Olivier.Bonaventure@uclouvain.be, multipathtcp References: <5314DE3D.2010401@uclouvain.be> In-Reply-To: <5314DE3D.2010401@uclouvain.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/35fi3Sp7NVSISzA5cwc42TEq4R4 Subject: Re: [multipathtcp] Adding options in MPTCP RST X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 02:05:51 -0000 On 3/3/2014 11:55 AM, Olivier Bonaventure wrote: ... > By adding an option in the MPTCP RST, we might also enable the client to > distinguish between a RST generated by a middlebox and a RST generated > by the endhost. For this, the RST option could include the DATAACK and a > HMAC of this DATA_ACK to authenticate it. > > Any other thoughts on adding options inside the RST ? Ian Heavens suggested doing something like this in Jan. 1998, in a long exchange he and I had about TIME-WAIT, where he noted: "Another possibility would be to encode the RST type as a TCP option (suggested to me by Richard Stevens)." I'm not sure where you can/should add RST options unless they're in a TCP option, FWIW. Joe From nobody Thu Mar 20 00:09:17 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9460F1A00D4 for ; Thu, 20 Mar 2014 00:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.464 X-Spam-Level: * X-Spam-Status: No, score=1.464 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hc8r7vTR9SJ0 for ; Thu, 20 Mar 2014 00:09:12 -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 C0F7A1A00B5 for ; Thu, 20 Mar 2014 00:09:11 -0700 (PDT) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 552F7278215 for ; Thu, 20 Mar 2014 16:09:00 +0900 (JST) Received: by mail-la0-f43.google.com with SMTP id e16so286167lan.30 for ; Thu, 20 Mar 2014 00:08:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:content-type; bh=VSIFWGytrbmNY4NH3YloZ4yf/8uHJPugHt1Oo7G0TD0=; b=OPop2gZ/gXczpTqEDdyT8TDcKdgrCXksopkXpoI3qsYovbphqo0nf5OEwEgKQ3HohQ AYRpWu8F531HBqbgwppW0p6HCQ8kw9SqkIKXBcN/kups6HziA5tmdY4x4VHJbGyxTIBr rvqznkTEea1G2jUd8pO0eTqaT9qY1f4+Mrwc6T/vju06usbFN+A397BwlasCnm1dHiYD xgV8DyjQJZnswfgZDYaUZrUaeMPESuvSqzJEu0m7De5f/Locbd/ZTjO62GG/Wd7Izb/b YDDIEiJuSow4QXR+oWQggqLjCmkQ6QRdufGDf0JW0YlTpU1ECdy7HczSvhzJPCMEIRrv jS2Q== MIME-Version: 1.0 X-Received: by 10.152.202.7 with SMTP id ke7mr13908682lac.30.1395299337375; Thu, 20 Mar 2014 00:08:57 -0700 (PDT) Received: by 10.114.95.101 with HTTP; Thu, 20 Mar 2014 00:08:57 -0700 (PDT) Date: Thu, 20 Mar 2014 00:08:57 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: multipart/alternative; boundary=001a1137ef8e5c170104f50471d6 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/yx1miOjF_ZFntWHIOJOILwRvT2Y Subject: [multipathtcp] minutes for London meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 07:09:14 -0000 --001a1137ef8e5c170104f50471d6 Content-Type: text/plain; charset=ISO-8859-1 Hi, Sorry for the delay. I've uploaded a draft minutes for London meeting. It is available at: http://www.ietf.org/proceedings/89/minutes/minutes-89-mptcp Please feel free to check and let us know if there's any mistakes or additional info. We appreciate Mirja and Simone for note taking! BTW, when I checked the audio archive, I could not understand the discussions between Alan and David at the end of Marcelo's presentation. (64bit DSN stuff) I will appreciate if someone could explain this. Thanks, -- Yoshi & Phil --001a1137ef8e5c170104f50471d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,=A0
Sorry for the delay. I've uploaded a draft = minutes for London meeting.
It is available at:

Please feel free to check and let us know if ther= e's any mistakes or additional info.
We appreciate Mirja and = Simone for note taking!


BTW, when I= checked the audio archive, I could not understand the discussions between Alan and David = at the end of=A0Marcelo's presentation. (64bit DSN stuff) =A0I will appreciate = if someone could explain this.

Thanks,
--
Yoshi & Phil

--001a1137ef8e5c170104f50471d6-- From nobody Fri Mar 21 02:35:42 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751251A08A4 for ; Fri, 21 Mar 2014 02:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.35 X-Spam-Level: ** X-Spam-Status: No, score=2.35 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 127ErSyannfQ for ; Fri, 21 Mar 2014 02:35:38 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8394B1A0895 for ; Fri, 21 Mar 2014 02:35:38 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id pa12so2280455veb.1 for ; Fri, 21 Mar 2014 02:35:29 -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=nQPst4/cop6qxNELIfwa5g+A7aKGkYhQ+uh4ibTRJIM=; b=hOi2OGOoe5Gpe9DUW6GEFOD+yMISKZXxkNlXbABZ4gLlW6L1XDzdwciok4A6mf32JN zKmtwaSC+LYuUlBp+w9gyAkyw/y93OG8SoJYisamSwyqlyf9OUp8FL3wTxxr5y+gtF/l GJw4ErUX6ykRs2DnMfqhN0C8UQ3qcOoFKIXHdovY6ZfmRjaLXB5oYesBu6c8jlh9+ihH SIZddBn6lvzcCOD3cV7ANn7XZBobz6uFM9NY9kGr5axLr3SCsCwMBqwx4PvMmR834t8h yuYZOFvYjiloCg1VBwB6AiuJJR4sLD0M3k0FFgrjLA+vOItvG0PjbvblR/lVhSb2E9P9 Cyng== MIME-Version: 1.0 X-Received: by 10.58.221.102 with SMTP id qd6mr172699vec.47.1395394529043; Fri, 21 Mar 2014 02:35:29 -0700 (PDT) Received: by 10.58.100.212 with HTTP; Fri, 21 Mar 2014 02:35:28 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 Mar 2014 17:35:28 +0800 Message-ID: From: lingli deng To: Yoshifumi Nishida Content-Type: multipart/alternative; boundary=047d7bf0e4cc39abd404f51a9b26 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/7RXFyXtexyBDsbi6P1dNEQMVWXM Cc: multipathtcp Subject: Re: [multipathtcp] minutes for London meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 09:35:41 -0000 --047d7bf0e4cc39abd404f51a9b26 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Yoshi, I am afraid that there is one correction to make regarding my response to Keith=A1=AFs comment on MPTCP proxy. Lingli: We have been doing trial and will soon deploy MPTCP proxy over 3G network. In our trial, we can see 20% performance gains by the TCP proxy The above sentence should be replaced by the following. Lingli: We have been doing trial and will soon deploy split TCP proxy over 2G/3G network, which brings over 20% performance gains. The point was that TCP proxy is already there and nothing new for MPTCP. Thanks a lot! Sorry that as my last mail was marked as SPAM, in case that some of you might miss it, I am resending it... Cheers, Lingli 2014-03-20 15:08 GMT+08:00 Yoshifumi Nishida : > Hi, > Sorry for the delay. I've uploaded a draft minutes for London meeting. > It is available at: > http://www.ietf.org/proceedings/89/minutes/minutes-89-mptcp > > Please feel free to check and let us know if there's any mistakes or > additional info. > We appreciate Mirja and Simone for note taking! > > > BTW, when I checked the audio archive, I could not understand the > discussions between Alan and David at the end of Marcelo's presentation. > (64bit DSN stuff) I will appreciate if someone could explain this. > > Thanks, > -- > Yoshi & Phil > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > --=20 =B5=CB=C1=E9=C0=F2/Lingli Deng =D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/China Mobile Researc= h Institute e-mail: denglingli@chinamobile.com tel: 15801696688-3367 mobile: 13810597148 --047d7bf0e4cc39abd404f51a9b26 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

Hi Yoshi,

I a= m afraid that there is one correction to make regarding my response to Keit= h’s comment on MPTCP proxy.

Lingli:

We have been doing tria= l and will soon deploy MPTCP proxy over 3G network.

In our trial, we can see 20% performance gains by the TCP<= /span> proxy

The= above sentence should be replaced by the following.

Lingli:

We have been doing tri= al and will soon deploy split TCP proxy over 2G/3G network, wh= ich brings over 20% performance gains.

=

The point was that TCP proxy is already there and nothing new for MPTCP.=

T= hanks a lot!
 
S= orry that as my last mail was marked as SPAM, in case that some of you migh= t miss it, I am resending it...

=

Cheers,

Lin= gli



2014-03-20 15:08 GMT+08:00 Yoshifumi Nishida <nishida@sfc.wide.ad.jp= >:
Hi, 
Sorry for the delay. I've uploaded a dra= ft minutes for London meeting.
It is available at:

Please feel free to check and let us know if ther= e's any mistakes or additional info.
We appreciate Mirja and = Simone for note taking!


BTW, when I= checked the audio archive, I could not understand the discussions between Alan and David = at the end of Marcelo's presentation. (64bit DSN stuff)  I will appre= ciate if someone could explain this.

Thanks,
--
Yoshi & Phil


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




--
=B5=CB=C1=E9=C0=F2/= Lingli Deng
=D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/China= Mobile Research Institute
e-mail: denglingli@chinamobile.com
tel: 15801696688-3367
mobile: 13810597148
--047d7bf0e4cc39abd404f51a9b26-- From nobody Sat Mar 22 00:52:12 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8251A092D for ; Sat, 22 Mar 2014 00:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.464 X-Spam-Level: * X-Spam-Status: No, score=1.464 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kNS--7Fy2OL for ; Sat, 22 Mar 2014 00:52:09 -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 DF79F1A0584 for ; Sat, 22 Mar 2014 00:52:07 -0700 (PDT) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 0AF51278207 for ; Sat, 22 Mar 2014 16:51:55 +0900 (JST) Received: by mail-la0-f54.google.com with SMTP id mc6so2341952lab.13 for ; Sat, 22 Mar 2014 00:51:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eSV85wEzGKM1q6or+M3Lv+bBrJ0ZOKFdHEXy4TTd7Xs=; b=dU2OZSAU6wNAOx0gGAs9WXvx5nJLCbILCP9dLtkvg8xWhgPHJ0juFR0AD/VsnKfffL JORqtrwPieZ3UkrqJ7zQgc7WArPUipja3h0HYsRTBGhzjaNbwRZwdqavo9wtQqO2zIhS fhosc3qN3fg9y4ZoDFStHnoJKtOSXckyJCXMLxDQx96AZHhxMpRC5BxyIMeKJSIspMIy 5vxUsp9S688jIERQ/aagwCW3nYfM+HKo/wqmru3beGp1Mb2pH02pN6WOXEvLWsnUM+a/ eKII+cqDSf9hnNiJOh8aRbagpPDJidvt442s60Jkea4il41anFDb9mBTq9W7obnim7Cl hROQ== MIME-Version: 1.0 X-Received: by 10.152.23.227 with SMTP id p3mr690460laf.31.1395474713337; Sat, 22 Mar 2014 00:51:53 -0700 (PDT) Received: by 10.114.95.101 with HTTP; Sat, 22 Mar 2014 00:51:53 -0700 (PDT) In-Reply-To: References: Date: Sat, 22 Mar 2014 00:51:53 -0700 Message-ID: From: Yoshifumi Nishida To: lingli deng Content-Type: multipart/alternative; boundary=089e0158ab5c94e57f04f52d4662 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/gdIyaNZrTh-RTn7Ynkg7pgF8qEE Cc: multipathtcp Subject: Re: [multipathtcp] minutes for London meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 07:52:11 -0000 --089e0158ab5c94e57f04f52d4662 Content-Type: text/plain; charset=ISO-8859-1 Hi Lingli, Thanks for the correction! On Fri, Mar 21, 2014 at 2:35 AM, lingli deng wrote: > > Hi Yoshi, > > I am afraid that there is one correction to make regarding my response to Keith's comment on MPTCP proxy. > > Lingli: > > We have been doing trial and will soon deploy MPTCP proxy over 3G network. > > In our trial, we can see 20% performance gains by the TCP proxy > > The above sentence should be replaced by the following. > > Lingli: > > We have been doing trial and will soon deploy split TCP proxy over 2G/3G network, which brings over 20% performance gains. > > The point was that TCP proxy is already there and nothing new for MPTCP. OK. I will update this. But, can I confirm one thing? (sorry for being picky) I want to check if you want to use TCP proxy here. The reason why I'm asking is I tend to think the following way. TCP proxy ... TCP proxy that doesn't understand MPTCP MPTCP proxy ... TCP proxy that can parse and control MPTCP Thanks, -- Yoshi --089e0158ab5c94e57f04f52d4662 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Lingli,

Thanks for the correction!

On Fri= , Mar 21, 2014 at 2:35 AM, lingli deng <denglingli@gmail.com> wrote:
>
> Hi Yoshi,
&g= t;
> I am afraid that there is one correction to make regarding my response= to Keith’s comment on MPTCP proxy.
>
> Lingli:
>> We have been doing trial and will soon deploy MPTCP proxy over 3G ne= twork.
>
> In our trial, we can see 20% performance gains by the TCP prox= y
>
> The above sentence should be replaced by the following.>
> Lingli:
>
> We have been doing trial and will so= on deploy split TCP proxy over 2G/3G network, which brings over 20% perform= ance gains.
>
> The point was that TCP proxy is already there and nothing new = for MPTCP.

OK. I will update this. But, can I confirm one thing? (so= rry for being picky)
I want to check if you want to use TCP proxy here.<= div>
The reason why I'm asking is I tend to think the following way.
=    TCP proxy ... TCP proxy that doesn't understand MPTCP
&= nbsp;  MPTCP proxy ... TCP proxy that can parse and control MPTCP
<= br>Thanks,
--
Yoshi
--089e0158ab5c94e57f04f52d4662-- From nobody Sun Mar 23 20:06:46 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338A31A00D4 for ; Sun, 23 Mar 2014 20:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.151 X-Spam-Level: *** X-Spam-Status: No, score=3.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rtf9m_S8Go7 for ; Sun, 23 Mar 2014 20:06:40 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 846C31A00DE for ; Sun, 23 Mar 2014 20:06:40 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id pa12so5128260veb.1 for ; Sun, 23 Mar 2014 20:06:39 -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=Zj1qFoXVmVyVjT0rmqyeZpyHRESc648/0S0GVgLEaGs=; b=eHHmM/JMHA7lyNFMMJryCgihc9gVaeSLWG3D0O+HnqkdllWhz4HiUuC/7vMF9NU23a 71eRLIyLjL6SG4FFzCzpVYDDEdZEILRgVff5ohfUsMlEwFizHnE26TmpReZu/R9cSbfQ 0bEv/8ByruA6M5OAwl629QdF/IY+cwJ07bd23CLEQ7IsWBZIY/KImmxCGNHJ2rQBdDED NN30QqAuJUDIbba6AKZNPuE4tlk+gEn3klbzFcsNw9gB82rmAQRuAWS3jYBw3d1wliZC U3zF9Cf6u1b0F0kXAZMoi3OhaGyujTanXm5qYPMasqC2sbNChAtoxmF+3Y5IlVQjKbV9 h9hQ== MIME-Version: 1.0 X-Received: by 10.221.29.196 with SMTP id rz4mr48558624vcb.8.1395630399694; Sun, 23 Mar 2014 20:06:39 -0700 (PDT) Received: by 10.58.100.205 with HTTP; Sun, 23 Mar 2014 20:06:39 -0700 (PDT) In-Reply-To: References: Date: Mon, 24 Mar 2014 11:06:39 +0800 Message-ID: From: lingli deng To: Yoshifumi Nishida Content-Type: multipart/alternative; boundary=001a1133a1c0363f6104f551867e Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/yN6zsDHw1jnqdaqKxhPDDwZIrSw Cc: multipathtcp Subject: Re: [multipathtcp] minutes for London meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 03:06:42 -0000 --001a1133a1c0363f6104f551867e Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Yoshi, Yoshifumi Nishida =D3=DA2014=C4=EA3=D4=C222=C8=D5= =D0=C7=C6=DA=C1=F9=D0=B4=B5=C0=A3=BA >> >> The point was that TCP proxy is already there and nothing new for MPTCP. > > OK. I will update this. But, can I confirm one thing? (sorry for being picky) > I want to check if you want to use TCP proxy here. > The reason why I'm asking is I tend to think the following way. > TCP proxy ... TCP proxy that doesn't understand MPTCP > MPTCP proxy ... TCP proxy that can parse and control MPTCP You are right. It is misleading. What I am trying to say is that it might be appealing to follow the architecture framework by upgrading the already-deployed TCP proxy with MPTCP capability, if possible. > > Thanks, > -- > Yoshi > --001a1133a1c0363f6104f551867e Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi Yoshi,

Yoshifumi Nishida <nishida@sfc.wide.ad.jp= >=D3=DA2014=C4=EA3=D4=C222=C8=D5=D0=C7=C6=DA=C1=F9=D0=B4=B5=C0=A3=BA=
>>
>> The point was that TCP proxy is already= there and nothing new for MPTCP.
>
> OK. I will update this. But, can I confirm one thing? (sorry f= or being picky)
> I want to check if you want to use TCP proxy here.<= br> > The reason why I'm asking is I tend to think the following way.>    TCP proxy ... TCP proxy that doesn't understand MPTC= P
>    MPTCP proxy ... TCP proxy that can parse and control= MPTCP

You are right. It is misleading. What I am trying to say is = that it might be appealing to 
follow the architecture frame= work by upgrading the already-deployed TCP proxy with 
MPTCP= capability, if possible. 

>
> Thanks,
> --
> Yoshi
>
--001a1133a1c0363f6104f551867e-- From nobody Mon Mar 24 22:55:44 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A343E1A00EE; Mon, 24 Mar 2014 22:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.811 X-Spam-Level: X-Spam-Status: No, score=-102.811 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eice-CZXZet; Mon, 24 Mar 2014 22:55:35 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1751A00F2; Mon, 24 Mar 2014 22:55:34 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C8FB976B2EA; Tue, 25 Mar 2014 06:55:32 +0100 (CET) X-uc3m-safe: yes Received: from [163.117.203.128] (unknown [163.117.203.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 88B168AA1EE; Tue, 25 Mar 2014 06:55:32 +0100 (CET) Message-ID: <53311A54.6040206@it.uc3m.es> Date: Tue, 25 Mar 2014 06:55:32 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Multipath TCP Mailing List , tcpm@ietf.org References: <20140324230315.20999.31424.idtracker@ietfa.amsl.com> In-Reply-To: <20140324230315.20999.31424.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140324230315.20999.31424.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Tue, 25 Mar 2014 06:55:32 +0100 (CET) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20588.005 X-TM-AS-Result: No--9.892-7.0-31-1 X-imss-scan-details: No--9.892-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/1kEFijej7ehIJ64vd21zPVIDdZs Subject: [multipathtcp] Fwd: New Non-WG Mailing List: Tcpcrypt -- Discussion list for adding encryption to TCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 05:55:38 -0000 FYI -------- Mensaje original -------- Asunto: New Non-WG Mailing List: Tcpcrypt -- Discussion list for adding encryption to TCP Fecha: Mon, 24 Mar 2014 16:03:15 -0700 De: IETF Secretariat Responder a: ietf@ietf.org Para: IETF Announcement List CC: mls.ietf@gmail.com, tcpcrypt@ietf.org A new IETF non-working group email list has been created. List address: tcpcrypt@ietf.org Archive: http://www.ietf.org/mail-archive/web/tcpcrypt/ To subscribe: https://www.ietf.org/mailman/listinfo/tcpcrypt Purpose: The goal of this mailing list is to discuss encryption of TCP sessions, without necessarily requiring endpoint authentication in all cases (but while also making endpoint authentication possible). The initial purpose of the mailing list is to discuss the scope and a potential charter of a WG that would work on the definition of TCP extensions to support such encryption, or to find an existing WG to perform the work. For additional information, please contact the list administrators. From nobody Thu Mar 27 21:41:59 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08D91A043A for ; Thu, 27 Mar 2014 21:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2 X-Spam-Level: ** X-Spam-Status: No, score=2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLpjnjuQqQeY for ; Thu, 27 Mar 2014 21:41:56 -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 049F11A0079 for ; Thu, 27 Mar 2014 21:41:55 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 0132027812F for ; Fri, 28 Mar 2014 13:41:51 +0900 (JST) Received: by mail-lb0-f182.google.com with SMTP id n15so3401714lbi.27 for ; Thu, 27 Mar 2014 21:41:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:content-type; bh=LfrA4KEQyaNcJU9VEfuTNviy1Di9EaIXfBJQsFqxS1Q=; b=TQhOoGMEDILKbNcJHSE52wHs+IsFI3CUjdKOztW0T3R/NyWn98rTX1+hTbky1snu+d XFY6EwnqfS8cp0aXPyoLY9OvmZ7Aaaq/vd39XRPFteIVA5jEgvl+DUCiRKG5QIKA7Wj8 Jck8L9YNuSs9oLAKji0pcedf4easP0th2j1G04hCE1U3otp0kjm01pLvZAOIyeAwwCKG Ru1N6vBFF2rc+XUWmkAJ5G8JnexRG2Gmlr/cAEHYfaBJUO0X/RnJU00emtaiSgTpgpec 6xg4lcOPkYXFIkhSty3IHaI5Yb6Mu7xQ8wh/YHt/xKnIJTAZzN5ZmdAjHGXw/CGItGSK XIKA== MIME-Version: 1.0 X-Received: by 10.112.1.233 with SMTP id 9mr3679668lbp.29.1395981709073; Thu, 27 Mar 2014 21:41:49 -0700 (PDT) Received: by 10.114.95.101 with HTTP; Thu, 27 Mar 2014 21:41:48 -0700 (PDT) Date: Thu, 27 Mar 2014 21:41:48 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/gnwTNzZrHqqlZ3JyikJosDF4-OI Subject: [multipathtcp] WGLC for draft-ietf-mptcp-attacks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 04:41:58 -0000 Hello, As mentioned in the London meeting, we start WGLC on draft-ietf-mptcp-attacks. The WGLC will run until * April 14th *. The intended status of the document is Informational. Please provide your feedback to the ML before the deadline. The draft is available at: http://tools.ietf.org/html/draft-ietf-mptcp-attacks-00 Regards, -- Yoshi & Phil