From internet-drafts@ietf.org Wed Oct 3 14:08:06 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4200711E80D2; Wed, 3 Oct 2012 14:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-iU+eriVHBa; Wed, 3 Oct 2012 14:08:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6746311E8097; Wed, 3 Oct 2012 14:08:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121003210805.17973.39060.idtracker@ietfa.amsl.com> Date: Wed, 03 Oct 2012 14:08:05 -0700 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-10.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 21:08:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multipath TCP Working Group of the IETF. Title : TCP Extensions for Multipath Operation with Multiple Add= resses Author(s) : Alan Ford Costin Raiciu Mark Handley Olivier Bonaventure Filename : draft-ietf-mptcp-multiaddressed-10.txt Pages : 64 Date : 2012-10-03 Abstract: TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network, and thus improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e. reliable bytestream), and provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mptcp-multiaddressed There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mptcp-multiaddressed-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From philip.eardley@bt.com Fri Oct 5 01:42:55 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A702821F8608 for ; Fri, 5 Oct 2012 01:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.113 X-Spam-Level: X-Spam-Status: No, score=-103.113 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZEUfJQFQngI for ; Fri, 5 Oct 2012 01:42:55 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id DC62321F8607 for ; Fri, 5 Oct 2012 01:42:54 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 5 Oct 2012 09:42:52 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.17]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Fri, 5 Oct 2012 09:42:52 +0100 From: To: , Date: Fri, 5 Oct 2012 09:42:52 +0100 Thread-Topic: Atlanta agenda requests Thread-Index: Ac2izgcRUdbMveaUS4Sq40Mf9POM7Q== Message-ID: <9510D26531EF184D9017DF24659BB87F33DD152C0A@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_9510D26531EF184D9017DF24659BB87F33DD152C0AEMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] Atlanta agenda requests 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, 05 Oct 2012 08:42:55 -0000 --_000_9510D26531EF184D9017DF24659BB87F33DD152C0AEMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please let us know if you'd like some time on the agenda. Our *draft* timeslot is Tuesday, Afternoon Session II 1520-1650 (Christoph - we already have your request) Thanks Phil & Yoshifumi --_000_9510D26531EF184D9017DF24659BB87F33DD152C0AEMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please let us know if you̵= 7;d like some time on the agenda.

Our *draft* = timeslot is Tuesday, Afternoon Session II 1520-1650

(= Christoph – we already have your request)

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

Phil & Yoshifumi

 

= --_000_9510D26531EF184D9017DF24659BB87F33DD152C0AEMV65UKRDdoma_-- From dreibh@iem.uni-due.de Fri Oct 5 08:20:52 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639F121F85ED for ; Fri, 5 Oct 2012 08:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 015iOocXuj29 for ; Fri, 5 Oct 2012 08:20:52 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id 34D0B21F85C6 for ; Fri, 5 Oct 2012 08:20:51 -0700 (PDT) Received: from sognsvann.localnet ([77.88.71.189]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id q95FKndo032141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 5 Oct 2012 17:20:50 +0200 From: Thomas Dreibholz To: multipathtcp@ietf.org Date: Fri, 05 Oct 2012 17:20:49 +0200 Message-ID: <1602459.4E83HcCg9a@sognsvann> Organization: University of Duisburg-Essen, Institute for Experimental Mathematics User-Agent: KMail/4.9.1 (Linux/3.2.0-31-generic; KDE/4.9.1; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" 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] [Extended Deadline] Call for Papers of the PAMS 2013 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, 05 Oct 2012 15:20:52 -0000 We apologize if you receive multiple copies of this CFP. CALL FOR PAPERS The 3rd International Workshop on Protocols and Applications with Multi= -Homing=20 Support (PAMS 2013) In conjunction with the 27th IEEE International Conference on Advanced=20= Information Networking and Applications (AINA 2013) Barcelona, Spain, March 25-28, 2013 http://simula.no/pams2013 The intent of our workshop is to bring together people from research an= d industry, in order to provide a discussion forum for state-of-the-art t= opics related to multi-homing on Network, Transport, Session and Application = Layers. The PAMS workshop will include full-paper sessions as well as a poster = session (with short presentations) to introduce preliminary ideas as well as wo= rk in progress. Workshops proceedings will be published by the IEEE CS Conference Publi= shing Service and will be included in the Digital Library. The main topics to be addressed include (but are not limited to): * Network Resilience by Multi-Homing * Network Architectures for Multi-Homed Systems * Performance Evaluation of Multi-Homed Systems * Deployment of Multi-Homed Protocols in Existing Networks with Middleboxes * Design and Implementation of Multi-Homed Systems * Testbeds for Multi-Homed Systems * Load Sharing and Load Balancing for Multi-Homed Systems * Mobility for Multi-Homed Systems * Protocols with Multi-Homing Support * Congestion and Flow Control of Multi-Homed Systems * Quality of Service for Multi-Homed Systems * Multi-Homing for Interconnection Networks * Security of Multi-Homed Systems * Application Deployment and Support for Legacy Applications * Cross-Layer Optimisation for Multi-Homed Systems * Multi-Homing in the Context of the Future Internet GENERAL CHAIRS: * Thomas Dreibholz, Simula Research Laboratory, Norway * Hakim Adhari, University of Duisburg-Essen, Germany PROGRAM CHAIRS: * Martin Becke, University of Duisburg-Essen, Germany * Thomas Dreibholz, Simula Research Laboratory, Norway PUBLICITY CHAIRS: * Glenford Mapp, Middlesex University, United Kingdom * Xing Zhou, Hainan University, China PROGRAM COMMITTEE * Hakim Adhari, University of Duisburg-Essen, Germany * Nicola Altan, ista International, Germany * Paul Amer, University of Delaware, U.S.A. * Holger Bleul, DB Systel, Germany * Anna Brunstr=F6m, Karlstad University, Sweden * Ahmed Elmokashfi, Simula Research Laboratory, Norway * Kristian Evensen, Simula Research Laboratory, Norway * Ernst Gunnar Gran, Simula Research Laboratory, Norway * Seok Joo Koh, Kyungpook National University, South Korea * Amund Kvalbein, Simula Research Laboratory, Norway * Glenford Mapp, Middlesex University, United Kingdom * Preethi Natarajan, Cisco, U.S.A. * Brad Penoff, Google, U.S.A. * Esbold Unurkhaan, Mongolian University of Science and Technology,= =20 Mongolia * Andreas Timm-Giel, TU Hamburg-Harburg, Germany * Alan Wagner, University of British Columbia, Canada * Michael Welzl, University of Oslo, Norway * Xing Zhou, Hainan University, China IMPORTANT DATES * Paper Submission Deadline: October 15, 2012 -- EXTENDED -- * Author Notification: November 25, 2012 * Camera-Ready Paper Submission: December 28, 2012 * Author Registration: January 11, 2013 CONTACT For further information, please contact: * Thomas Dreibholz (dreibh@simula.no) * Hakim Adhari (hakim.adhari@uni-due.de) WEBSITE http://simula.no/pams2013 From christoph.paasch@uclouvain.be Mon Oct 15 04:57:14 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC7B1F0423 for ; Mon, 15 Oct 2012 04:57:14 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EF7QloIfO5kk for ; Mon, 15 Oct 2012 04:57:14 -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 AF5CC1F041C for ; Mon, 15 Oct 2012 04:57:13 -0700 (PDT) Received: from cpaasch-mac.localnet (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 6608D1C5EF0 for ; Mon, 15 Oct 2012 13:57:06 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 6608D1C5EF0 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1350302226; bh=scklOr4UJdOnsp/VBZbaVDfIwFwnlGh8RMIJULB6eXw=; h=From:To:Reply-To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type; b=MwJ2nI6huZKJOrAKslRWqvfrMDjq0S1PfFb1vIozX7qsMAdGIGZS86gBYK5JewStB zQAhk1NBNFTOohQDt7abcFlVvvyYHMWlRF6YkwCvOAOFoqF0e5IJ0UNP2ZEq2K+Kl7 CwGntiTKxufAsQrfqnzjJhnnzKDmB/9khNwVQXoI= From: Christoph Paasch To: MultiPath TCP - IETF WG Date: Mon, 15 Oct 2012 13:57:02 +0200 Message-ID: <3413252.bpSLM7u6aj@cpaasch-mac> Organization: =?UTF-8?B?VW5pdmVyc2l0w6k=?= Catholique de Louvain User-Agent: KMail/4.9.2 (Linux/3.2.0-32-generic; KDE/4.9.2; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: clamav-milter 0.97.3-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 6608D1C5EF0.A0B76 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Subject: [multipathtcp] Fwd: New Version Notification for draft-paasch-mptcp-lowoverhead-00.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Christoph Paasch List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 11:57:14 -0000 Hello, we submitted two IETF drafts about alternative security solutions for t= he=20 MPTCP handshake. The first one is about a low overhead, low security version for control= led=20 environments like data centers. The second integrates application-level security in MPTCP to allow=20 applications like SSL to provide the key for the HMAC-exchange. Please find below the two links to the drafts. Comments are very welcome. I will present these solutions at the WG mee= ting in=20 Atlanta. Cheers, Christoph A new version of I-D, draft-paasch-mptcp-lowoverhead-00.txt has been successfully submitted by Christoph Paasch and posted to the IETF repository. Filename:=09 draft-paasch-mptcp-lowoverhead Revision:=09 00 Title:=09=09 MultiPath TCP Low Overhead Creation date:=09 2012-10-15 WG ID:=09=09 Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-paasch-mptcp= - lowoverhead-00.txt Status: http://datatracker.ietf.org/doc/draft-paasch-mptcp- lowoverhead Htmlized: http://tools.ietf.org/html/draft-paasch-mptcp-lowoverh= ead-00 Abstract: This document describes a low overhead connection establishment mechanism for Multipath TCP. Its goal is to reduce the computationa= l overhead of establishing an MPTCP connection and the associated TCP subflows in controlled environments where security attacks are not a= concern. A new version of I-D, draft-paasch-mptcp-ssl-00.txt has been successfully submitted by Christoph Paasch and posted to the IETF repository. Filename: draft-paasch-mptcp-ssl Revision: 00 Title: Securing the MultiPath TCP handshake with external key= s Creation date: 2012-10-15 WG ID: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-paasch-mptcp= - ssl-00.txt Status: http://datatracker.ietf.org/doc/draft-paasch-mptcp-ssl= Htmlized: http://tools.ietf.org/html/draft-paasch-mptcp-ssl-00 Abstract: Multipath TCP currently relies on the exchange of keys in clear during the initial handshake to authenticate the establishment of additional subflows. This document proposes a variant of the Multipath TCP handshake that allows Multipath TCP to reuse keys negotiated by the Application layer protocol above it such as SSL/TL= S to authenticate the establishment of additional subflows. = =20 ----------------------------------------- --=20 IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be Universit=E9 Catholique de Louvain -- From philip.eardley@bt.com Mon Oct 15 06:32:01 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637ED21F862B for ; Mon, 15 Oct 2012 06:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.178 X-Spam-Level: X-Spam-Status: No, score=-103.178 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9u+m7cnE-hx for ; Mon, 15 Oct 2012 06:32:00 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id C31F521F8766 for ; Mon, 15 Oct 2012 06:31:59 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 15 Oct 2012 14:31:52 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.17]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Mon, 15 Oct 2012 14:31:52 +0100 From: To: , Date: Mon, 15 Oct 2012 14:31:51 +0100 Thread-Topic: Atlanta agenda requests Thread-Index: Ac2izgcRUdbMveaUS4Sq40Mf9POM7QIC072w Message-ID: <9510D26531EF184D9017DF24659BB87F33DD37FEF2@EMV65-UKRD.domain1.systemhost.net> References: <9510D26531EF184D9017DF24659BB87F33DD152C0A@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F33DD152C0A@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_9510D26531EF184D9017DF24659BB87F33DD37FEF2EMV65UKRDdoma_" MIME-Version: 1.0 Subject: Re: [multipathtcp] Atlanta agenda requests 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, 15 Oct 2012 13:32:01 -0000 --_000_9510D26531EF184D9017DF24659BB87F33DD37FEF2EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please send any more requests (so far, only from Christoph) Thanks phil From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of philip.eardley@bt.com Sent: 05 October 2012 09:43 To: multipathtcp@ietf.org; nishida@sfc.wide.ad.jp Subject: [multipathtcp] Atlanta agenda requests Please let us know if you'd like some time on the agenda. Our *draft* timeslot is Tuesday, Afternoon Session II 1520-1650 (Christoph - we already have your request) Thanks Phil & Yoshifumi --_000_9510D26531EF184D9017DF24659BB87F33DD37FEF2EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please send any more requests (so far, only from Christoph)=

Thanks

phil

=

 <= /span>

From: = multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On = Behalf Of philip.eardley@bt.com
Sent: 05 October 2012 09:43To: multipathtcp@ietf.org; nishida@sfc.wide.ad.jp
Subject: [multipathtcp] Atlanta agenda requests

=

 

Please let us know if you&= #8217;d like some time on the agenda.

Our *draft* timeslot is Tuesday, Afternoon Session II 1520-1650

(Chri= stoph – we already have your request)

Thanks

Phil & Yoshifumi

&nb= sp;

= --_000_9510D26531EF184D9017DF24659BB87F33DD37FEF2EMV65UKRDdoma_-- From njwilliams@swin.edu.au Mon Oct 15 21:14:18 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5C621F86CB for ; Mon, 15 Oct 2012 21:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jueNEWLabN4g for ; Mon, 15 Oct 2012 21:14:18 -0700 (PDT) Received: from gpo4.cc.swin.edu.au (gpo4.cc.swin.edu.au [136.186.1.33]) by ietfa.amsl.com (Postfix) with ESMTP id A4BAE21F8646 for ; Mon, 15 Oct 2012 21:14:17 -0700 (PDT) Received: from [136.186.229.154] (nwilliams-laptop.caia.swin.edu.au [136.186.229.154]) by gpo4.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id q9G4EB4T013927; Tue, 16 Oct 2012 15:14:14 +1100 Message-ID: <507CDF0F.6090605@swin.edu.au> Date: Tue, 16 Oct 2012 15:14:07 +1100 From: Nigel Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Christoph Paasch Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multipathtcp Subject: [multipathtcp] Feedback on sha1/key exchange for MPTCP inter-op with FreeBSD 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, 16 Oct 2012 04:14:18 -0000 Dear Christoph, I'm currently doing some interop testing between the Linux MPTCP implementation (built from the git repository as of October 10) and the FreeBSD implementation that I am working on. I have some questions/comments. I've cc'd the mailing list as some of this might be of interest to others. Please let me know if I've missed something obvious! (1) Endianess and the sha1 hashing of local and remote keys: I initially had some trouble matching keys and idsns with the Linux implementation. Having a look through the linux code (function mptcp_key_sha1(local_key) in mptcp_ctrl.c) it looks like the output of sha_transform is converted into big-endian, and the token and idsn are then assigned (as big-endian). Once the mptcp_key_sha1() function returns, 'idsn = ntohll(idsn) + 1;' is called (returning the idsn to host order). The idsn is then typcast as a u32 and this value is used for tcb->seq (which is the starting dseq value of DSN mappings). All this was calculated from 'local_key', which is stored locally in host order. The problem arises then that the local_key is put onto the wire in host byte order, when we were expecting to receive it in network byte order. Is there a reason why the key is not transmitted in network byte order? Also, is it possible to do the conversion to host order of the idsn and token within mptcp_key_sha1(), rather than on return? A quick glance at the function does not make it immediately obvious that the values should be converted into host order on return. Some comments in this function would be useful (for instance the FreeBSD sha1 returns the hash in network order, while Linux does not). (2) Perhaps as a general comment/feedback, it might be worth detailing a little more explicitly in the implementers guide the conversions occurring in this process, as it is currently a little ambiguous and I needed to dig through the linux code in order to make my implementation compatible on the wire. As far as I can tell, the process should be along the lines of: 1. generate 64-bit key (store in host order) 2. sha1 hash of key (byte order is implementation specific) 3. choose the most significant 4 bytes for the token, and least significant 8 bytes, taking into account the byte order of the sha output. 4. store token and idsn locally in host order. 5. get the lower portion of the idsn with an unsigned 32-bit typecast 6. when transmitting the local_key/remote_key, do so in network order. (currently Linux transmits in host order?) As we need to be sure that different implementations are exchanging keys correctly during the handshake, it would be nice to have this information documented, making the endianess of things clear for implementers. It would also be helpful in the future to add some more comments to the Linux code, as it isn't always clear as why things are being done a certain way. regards, nigel From christoph.paasch@uclouvain.be Mon Oct 15 23:32:35 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618E921F89B4 for ; Mon, 15 Oct 2012 23:32:35 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRhgrCbMHNfb for ; Mon, 15 Oct 2012 23:32:28 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 31E3A21F89B3 for ; Mon, 15 Oct 2012 23:32:28 -0700 (PDT) Received: from cpaasch-mac.localnet (unknown [62.197.125.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 69ECE11EDF3; Tue, 16 Oct 2012 08:32:20 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 69ECE11EDF3 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1350369140; bh=pufz1C7ifLCvKTi1MTy7rg7tDeg6YVnq3yDTdGdBdGs=; h=From:To:Reply-To:Cc:Subject:Date:Message-ID:In-Reply-To: References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=qjGYWfDdqFAGRTLdVHHF7lFNavLarzYTTE5dSoA653XosUVEqSyB12yrCDqCVmPr+ ms65chLnBStQHXH0sSZMPDilJm46mA2lsNGRiyDN3hFtu9EAUv91TeIu5h0zrxshxB WHvaINaVJLzEmbJJiSJRoyN+YPdIGEoNd398eezc= From: Christoph Paasch To: Nigel Williams Date: Tue, 16 Oct 2012 08:32:16 +0200 Message-ID: <1577583.oZiYgRU3s0@cpaasch-mac> Organization: =?UTF-8?B?VW5pdmVyc2l0w6k=?= Catholique de Louvain User-Agent: KMail/4.9.2 (Linux/3.2.0-32-generic; KDE/4.9.2; x86_64; ; ) In-Reply-To: <507CDF0F.6090605@swin.edu.au> References: <507CDF0F.6090605@swin.edu.au> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: clamav-milter 0.97.3-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 69ECE11EDF3.A2FF0 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp Subject: Re: [multipathtcp] Feedback on sha1/key exchange for MPTCP inter-op with FreeBSD X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Christoph Paasch List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 06:32:35 -0000 Hello Nigel, On Tuesday 16 October 2012 15:14:07 Nigel Williams wrote: > (1) Endianess and the sha1 hashing of local and remote keys: I initia= lly > had some trouble matching keys and idsns with the Linux implementatio= n. > Having a look through the linux code (function mptcp_key_sha1(local_k= ey) > in mptcp_ctrl.c) it looks like the output of sha_transform is convert= ed > into big-endian, and the token and idsn are then assigned (as big-end= ian). >=20 > Once the mptcp_key_sha1() function returns, 'idsn =3D ntohll(idsn) + = 1;' > is called (returning the idsn to host order). The idsn is then typcas= t > as a u32 and this value is used for tcb->seq (which is the starting d= seq > value of DSN mappings). All this was calculated from 'local_key', whi= ch > is stored locally in host order. >=20 > The problem arises then that the local_key is put onto the wire in ho= st > byte order, when we were expecting to receive it in network byte orde= r. > Is there a reason why the key is not transmitted in network byte orde= r? the key is not stored in host-byte order. When generating the random bi= ts we=20 simply store them in a u64 and send them on the wire. Thus, the keys ar= e in=20 network byte-order. The endianness conversion in mptcp_key_sha1 is part of the SHA-1 algori= thm.=20 SHA-1 does an endianness conversion on the input (done by sha_transform= in=20 lib/sha1.c). When returning the final output another conversion is done in sha1_fina= l=20 (crypto/sha1_generic.c), part of the generic crypto-library of the linu= x=20 kernel. However, in MPTCP we don't use the crypto-library (thus, don't call=20 sha1_final) because we want to spare some CPU cycles. So, we have to do= the=20 endianness conversion at the end of mptcp_key_sha1 by hand. > Also, is it possible to do the conversion to host order of the idsn a= nd > token within mptcp_key_sha1(), rather than on return? A quick glance = at > the function does not make it immediately obvious that the values sho= uld > be converted into host order on return. Some comments in this functio= n > would be useful (for instance the FreeBSD sha1 returns the hash in > network order, while Linux does not). >From what I see in=20 http://www.leidinger.net/FreeBSD/dox/crypto/html/d2/d24/sha1_8c_source.= html the sha-1 algorithm in FreeBSD is also endianness-agnostic. Meaning, if= you=20 call sha1_result at the end, he will also do an endianness conversion s= o that=20 your output matches the endianness of the input. > (2) Perhaps as a general comment/feedback, it might be worth detailin= g a > little more explicitly in the implementers guide the conversions > occurring in this process, as it is currently a little ambiguous and = I > needed to dig through the linux code in order to make my implementati= on > compatible on the wire. I will try to add more comments in the implementation. > As far as I can tell, the process should be along the lines of: >=20 > 1. generate 64-bit key (store in host order) In a certain sense, the endianness of the key doesn't matter. Because, = no=20 arithmetic operations are done on the key. The key is just a sequence of bits, and this sequence of bits should be= sent=20 that way on the wire and applied to the hashing algorithm. And it is th= e=20 hashing algorithm that handles the endianness in order to produce the s= ame=20 results on big-endian and little-endian machines. (as SHA-1 is doing) > 2. sha1 hash of key (byte order is implementation specific) > 3. choose the most significant 4 bytes for the token, and least > significant 8 bytes, taking into account the byte order of the sha ou= tput. > 4. store token and idsn locally in host order. > 5. get the lower portion of the idsn with an unsigned 32-bit typecast= > 6. when transmitting the local_key/remote_key, do so in network order= . > (currently Linux transmits in host order?) >=20 > As we need to be sure that different implementations are exchanging k= eys > correctly during the handshake, it would be nice to have this > information documented, making the endianess of things clear for > implementers. It would also be helpful in the future to add some more= > comments to the Linux code, as it isn't always clear as why things ar= e > being done a certain way. There have been done tests with the Linux Kernel implementation on a bi= g- endian client and a little-endian server. And it was working after we f= ixed=20 one bug. I believe the endianness is now correctly handled in Linux. Cheers, Christoph --=20 IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be Universit=E9 Catholique de Louvain -- From njwilliams@swin.edu.au Tue Oct 16 01:44:21 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F6A21F8759 for ; Tue, 16 Oct 2012 01:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4GsdiomO5pm for ; Tue, 16 Oct 2012 01:44:21 -0700 (PDT) Received: from gpo4.cc.swin.edu.au (gpo4.cc.swin.edu.au [136.186.1.33]) by ietfa.amsl.com (Postfix) with ESMTP id 08DC821F8751 for ; Tue, 16 Oct 2012 01:44:13 -0700 (PDT) Received: from [136.186.229.154] (nwilliams-laptop.caia.swin.edu.au [136.186.229.154]) by gpo4.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id q9G8iA8X015920; Tue, 16 Oct 2012 19:44:11 +1100 Message-ID: <507D1E56.3050701@swin.edu.au> Date: Tue, 16 Oct 2012 19:44:06 +1100 From: Nigel Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Christoph Paasch References: <507CDF0F.6090605@swin.edu.au> <1577583.oZiYgRU3s0@cpaasch-mac> In-Reply-To: <1577583.oZiYgRU3s0@cpaasch-mac> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multipathtcp Subject: Re: [multipathtcp] Feedback on sha1/key exchange for MPTCP inter-op with FreeBSD 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, 16 Oct 2012 08:44:21 -0000 Hi Christoph, Thanks for the response, it's clear where the misunderstanding is now. On 16/10/12 17:32, Christoph Paasch wrote: > Hello Nigel, > > On Tuesday 16 October 2012 15:14:07 Nigel Williams wrote: >> (1) Endianess and the sha1 hashing of local and remote keys: I initially >> had some trouble matching keys and idsns with the Linux implementation. >> Having a look through the linux code (function mptcp_key_sha1(local_key) >> in mptcp_ctrl.c) it looks like the output of sha_transform is converted >> into big-endian, and the token and idsn are then assigned (as big-endian). >> >> Once the mptcp_key_sha1() function returns, 'idsn = ntohll(idsn) + 1;' >> is called (returning the idsn to host order). The idsn is then typcast >> as a u32 and this value is used for tcb->seq (which is the starting dseq >> value of DSN mappings). All this was calculated from 'local_key', which >> is stored locally in host order. >> >> The problem arises then that the local_key is put onto the wire in host >> byte order, when we were expecting to receive it in network byte order. >> Is there a reason why the key is not transmitted in network byte order? > > the key is not stored in host-byte order. When generating the random bits we > simply store them in a u64 and send them on the wire. Thus, the keys are in > network byte-order. > > The endianness conversion in mptcp_key_sha1 is part of the SHA-1 algorithm. > SHA-1 does an endianness conversion on the input (done by sha_transform in > lib/sha1.c). > When returning the final output another conversion is done in sha1_final > (crypto/sha1_generic.c), part of the generic crypto-library of the linux > kernel. > > However, in MPTCP we don't use the crypto-library (thus, don't call > sha1_final) because we want to spare some CPU cycles. So, we have to do the > endianness conversion at the end of mptcp_key_sha1 by hand. > What caused the confusion is that the Linux key is considered to be in network order after it is generated. I don't recall the draft specifying what order the key is to be in when hashed, and it is apparent that it should. I would argue in favour of hashing in host order for semantic reasons: - It seems non-standard behaviour to not perform a network-to-host byte order conversion on arriving options. - Maintains consistency with other stack variables which are kept in host byte order for simplicity of arithmetic (or other things) >> Also, is it possible to do the conversion to host order of the idsn and >> token within mptcp_key_sha1(), rather than on return? A quick glance at >> the function does not make it immediately obvious that the values should >> be converted into host order on return. Some comments in this function >> would be useful (for instance the FreeBSD sha1 returns the hash in >> network order, while Linux does not). > > From what I see in > http://www.leidinger.net/FreeBSD/dox/crypto/html/d2/d24/sha1_8c_source.html > > the sha-1 algorithm in FreeBSD is also endianness-agnostic. Meaning, if you > call sha1_result at the end, he will also do an endianness conversion so that > your output matches the endianness of the input. > Okay. Misunderstood what the Linux code was doing (we thought the FreeBSD code was doing something different to Linux, and this is not the case). >> (2) Perhaps as a general comment/feedback, it might be worth detailing a >> little more explicitly in the implementers guide the conversions >> occurring in this process, as it is currently a little ambiguous and I >> needed to dig through the linux code in order to make my implementation >> compatible on the wire. > > I will try to add more comments in the implementation. > >> As far as I can tell, the process should be along the lines of: >> >> 1. generate 64-bit key (store in host order) > > In a certain sense, the endianness of the key doesn't matter. Because, no > arithmetic operations are done on the key. As the endianness of the key will change the hash output, it does matter. cheers, nigel From christoph.paasch@uclouvain.be Tue Oct 16 02:01:17 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD3B21F88B8 for ; Tue, 16 Oct 2012 02:01:16 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmJDbnxEE9gV for ; Tue, 16 Oct 2012 02:01:16 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id D2DD521F88B4 for ; Tue, 16 Oct 2012 02:01:15 -0700 (PDT) Received: from cpaasch-mac.localnet (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 31E0711EE2D; Tue, 16 Oct 2012 11:01:06 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 31E0711EE2D DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1350378066; bh=j9RqpXnf17dPAkX2dNrTMoitLA3ZMq/TVuqbH+Y4hHo=; h=From:To:Reply-To:Cc:Subject:Date:Message-ID:In-Reply-To: References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=ytjd8denB8J+7typ81nGV2u0tG7daig6W0eEvkEABbdoQnx/0WtQx2JEVdC4apvDO EzvlgqirZlcmm1K65S4fc6juFJBO0w2yEG2MshCehFJtPWM8fkOg28FUoTRqfSar6f F4ZB/tyKPl8jxuBPlUnJlpqzAbKMaV+QrDx8nugY= From: Christoph Paasch To: Nigel Williams Date: Tue, 16 Oct 2012 11:01:02 +0200 Message-ID: <13373637.HTUXtqWYkN@cpaasch-mac> Organization: =?UTF-8?B?VW5pdmVyc2l0w6k=?= Catholique de Louvain User-Agent: KMail/4.9.2 (Linux/3.2.0-32-generic; KDE/4.9.2; x86_64; ; ) In-Reply-To: <507D1E56.3050701@swin.edu.au> References: <507CDF0F.6090605@swin.edu.au> <1577583.oZiYgRU3s0@cpaasch-mac> <507D1E56.3050701@swin.edu.au> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: clamav-milter 0.97.3-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 31E0711EE2D.AF4EF X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp Subject: Re: [multipathtcp] Feedback on sha1/key exchange for MPTCP inter-op with FreeBSD X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Christoph Paasch List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 09:01:17 -0000 On Tuesday 16 October 2012 19:44:06 Nigel Williams wrote: > > The endianness conversion in mptcp_key_sha1 is part of the SHA-1 > > algorithm. > > SHA-1 does an endianness conversion on the input (done by sha_trans= form in > > lib/sha1.c). > > When returning the final output another conversion is done in sha1_= final > > (crypto/sha1_generic.c), part of the generic crypto-library of the = linux > > kernel. > >=20 > > However, in MPTCP we don't use the crypto-library (thus, don't call= > > sha1_final) because we want to spare some CPU cycles. So, we have t= o do > > the > > endianness conversion at the end of mptcp_key_sha1 by hand. >=20 > What caused the confusion is that the Linux key is considered to be i= n=20 > network order after it is generated. I don't recall the draft specify= ing=20 > what order the key is to be in when hashed, and it is apparent that i= t=20 > should. You should not look at the key as a 64-bit integer. It is rather a sequ= ence of=20 8 bytes. When hashing, the key has to be in the same order as it was se= en on=20 the wire. SHA-1 algorithm makes sure that the hash produces as a result= the=20 same bit-sequence on little-endian and big-endian machines. If we would convert the key to host-byte-order, the bit-sequence input = to the=20 sha-1 algorithm will be different on little-endian and big-endian machi= nes.=20 Thus SHA-1 won't produce the same result anymore. > I would argue in favour of hashing in host order for semantic reasons= : > - It seems non-standard behaviour to not perform a network-to-host by= te=20 > order conversion on arriving options. > - Maintains consistency with other stack variables which are kept in=20= > host byte order for simplicity of arithmetic (or other things) Actually they are only stored in host-byte order if arithmetic operatio= ns are=20 performed on them. TCP-MD5-options are not converted. For the same reason why the MPTCP-ke= y is=20 not converted, because we are working on a sequence of bits/bytes. Same for TCP Cookie extensions. Christoph --=20 IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be Universit=E9 Catholique de Louvain -- From njwilliams@swin.edu.au Wed Oct 17 17:49:33 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EC821F8589 for ; Wed, 17 Oct 2012 17:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K59Zx9ma0bhE for ; Wed, 17 Oct 2012 17:49:28 -0700 (PDT) Received: from gpo2.cc.swin.edu.au (gpo2.cc.swin.edu.au [136.186.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id 6431921F865D for ; Wed, 17 Oct 2012 17:49:27 -0700 (PDT) Received: from [136.186.229.154] (nwilliams-laptop.caia.swin.edu.au [136.186.229.154]) by gpo2.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id q9I0nNBY004121 for ; Thu, 18 Oct 2012 11:49:25 +1100 Message-ID: <507F520E.6060201@swin.edu.au> Date: Thu, 18 Oct 2012 11:49:18 +1100 From: Nigel Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: multipathtcp References: <507E2D35.7040606@swin.edu.au> In-Reply-To: <507E2D35.7040606@swin.edu.au> X-Forwarded-Message-Id: <507E2D35.7040606@swin.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [multipathtcp] Fwd: Re: Feedback on sha1/key exchange for MPTCP inter-op with FreeBSD 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, 18 Oct 2012 00:49:33 -0000 Sorry, forgot to cc the list on this one. cheers, nigel >> On Wednesday 17 October 2012 14:59:49 Nigel Williams wrote: >> Hi Christoph, Alan, >> >>> On 16/10/12 20:01, Christoph Paasch wrote: >>> You should not look at the key as a 64-bit integer. It is rather a sequence of >>> 8 bytes. When hashing, the key has to be in the same order as it was seen on >>> the wire. SHA-1 algorithm makes sure that the hash produces as a result the >>> same bit-sequence on little-endian and big-endian machines. >>> >>> If we would convert the key to host-byte-order, the bit-sequence input to the >>> sha-1 algorithm will be different on little-endian and big-endian machines. >>> Thus SHA-1 won't produce the same result anymore. >>> >> Okay, looks like I misunderstood how the sha function worked internally. >> Ran a little test application and now see what you mean. >> >> A couple of proposals for inclusion in the draft (Section 3.1): >> - It should be stated that the generated key is hashed in network byte >> order. >> - Also mention that the least significant bits are the rightmost bits of >> the sha1 digest, as per [1]. >> >> >> Another observation re interop testing: There is an amendment to the end >> of section 3.1 that on first glance seems to be at odds with how we see >> the current Linux implementation behave: >> >> "The initial Data Sequence Number (IDSN) on a MPTCP connection MUST be >> hard to guess. It is RECOMMENDED that the IDSN is generated as a >> hash from the Key ... however a receiver MUST NOT make any assumptions >> about the IDSN generation algorithm." >> >> From out observations the Linux implementation will include a Data ACK >> in each packet immediately after the TCP handshake (potentially before >> the remote host has sent any packets with DSN mappings). If the remote >> host were to use a different method to generate the IDSN, these D-ACKs >> would be out of sequence space. Were these D-ACKs added for debugging >> purposes? >> [1] FIPS 180-3: Secure Hash Standard, >> http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf > > Yes, we always include DATA_ACK's in the packets, because it was easier to implement. > > The part you are citing from the draft about the IDSN will be changed in the draft > version 11. The IDSN generation will be made deterministic. > > Cheers, > Christoph From internet-drafts@ietf.org Fri Oct 19 02:08:33 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A4421F859A; Fri, 19 Oct 2012 02:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znCepzxRUoBz; Fri, 19 Oct 2012 02:08:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AC321F8567; Fri, 19 Oct 2012 02:08:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121019090832.12637.67517.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2012 02:08:32 -0700 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-11.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 09:08:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multipath TCP Working Group of the IETF. Title : TCP Extensions for Multipath Operation with Multiple Add= resses Author(s) : Alan Ford Costin Raiciu Mark Handley Olivier Bonaventure Filename : draft-ietf-mptcp-multiaddressed-11.txt Pages : 65 Date : 2012-10-19 Abstract: TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network, and thus improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e. reliable bytestream), and provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mptcp-multiaddressed There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mptcp-multiaddressed-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 22 09:39:15 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA39A21F8437; Mon, 22 Oct 2012 09:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOplCstsm0Q3; Mon, 22 Oct 2012 09:39:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B45221F8427; Mon, 22 Oct 2012 09:39:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022163914.8373.11643.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 09:39:14 -0700 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-12.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:39:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multipath TCP Working Group of the IETF. Title : TCP Extensions for Multipath Operation with Multiple Add= resses Author(s) : Alan Ford Costin Raiciu Mark Handley Olivier Bonaventure Filename : draft-ietf-mptcp-multiaddressed-12.txt Pages : 63 Date : 2012-10-22 Abstract: TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network, and thus improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e. reliable bytestream), and provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mptcp-multiaddressed There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mptcp-multiaddressed-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 22 09:45:33 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762CB11E80A2; Mon, 22 Oct 2012 09:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xwtujiu38YCr; Mon, 22 Oct 2012 09:45:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140EE21F89EC; Mon, 22 Oct 2012 09:45:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022164533.10328.63010.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 09:45:33 -0700 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-api-06.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:45:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multipath TCP Working Group of the IETF. Title : MPTCP Application Interface Considerations Author(s) : Michael Scharf Alan Ford Filename : draft-ietf-mptcp-api-06.txt Pages : 30 Date : 2012-10-22 Abstract: Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications. Finally, the document describes a basic application interface which is a simple extension of TCP's interface for MPTCP-aware applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mptcp-api There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mptcp-api-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mptcp-api-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nishida@sfc.wide.ad.jp Thu Oct 25 01:52:09 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39EA21F899F for ; Thu, 25 Oct 2012 01:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.614 X-Spam-Level: X-Spam-Status: No, score=-96.614 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLMr9++Acn+5 for ; Thu, 25 Oct 2012 01:52:08 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id D73B121F89A2 for ; Thu, 25 Oct 2012 01:52:07 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id E30812780B3 for ; Thu, 25 Oct 2012 17:52:00 +0900 (JST) Received: by mail-we0-f172.google.com with SMTP id u46so821847wey.31 for ; Thu, 25 Oct 2012 01:51:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.84.41 with SMTP id v9mr12159726wiy.8.1351155118643; Thu, 25 Oct 2012 01:51:58 -0700 (PDT) Received: by 10.194.90.101 with HTTP; Thu, 25 Oct 2012 01:51:58 -0700 (PDT) Date: Thu, 25 Oct 2012 01:51:58 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: multipart/alternative; boundary=f46d044289ece2185f04ccde50c0 Subject: [multipathtcp] comments on draft-paasch-mptcp-lowoverhead and draft-paasch-mptcp-ssl 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, 25 Oct 2012 08:52:09 -0000 --f46d044289ece2185f04ccde50c0 Content-Type: text/plain; charset=ISO-8859-1 Hello, I have read draft-paasch-mptcp-lowoverhead and draft-paasch-mptcp-ssl. I have the following questions and comments on the drafts. 1: I'm wondering if experimental status might be better for them. Is there any thoughts on this? 2: How is the relationships between these drafts? Is it totally independent? 3: In my feeling, it could be dangerous If token is used for high-order 32bit. (draft-paasch-mptcp-lowoverhead) We might want to emphasize this point. 4: In section 5 of draft-paasch-mptcp-lowoverhead. "if an attacker manages to join an existing connection...". Does this mean the attacker steals the token? I just would like to confirm.. Thanks, -- Yoshifumi --f46d044289ece2185f04ccde50c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

I have read draft-paasch-mptcp-lowoverhead and draft-paasch-= mptcp-ssl.
I have the following questions and comments on the drafts.
1: I'm wondering if experimental status might be better for them. = Is there any thoughts on this?

2: How is the relationships between these drafts? Is it totally indepen= dent?

3: In my feeling, it could be dangerous If token is used for = high-order 32bit. (draft-paasch-mptcp-lowoverhead)
=A0=A0=A0 We might w= ant to emphasize this point.

4: In section 5 of draft-paasch-mptcp-lowoverhead.
=A0=A0=A0 "i= f an attacker manages to join an existing connection...".
=A0=A0= =A0 Does this mean the attacker steals the token? I just would like to conf= irm..

Thanks,
--
Yoshifumi

--f46d044289ece2185f04ccde50c0-- From christoph.paasch@uclouvain.be Thu Oct 25 02:26:05 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F4B21F89BB for ; Thu, 25 Oct 2012 02:26: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHdV4DUwR2SD for ; Thu, 25 Oct 2012 02:26:05 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3018C21F87BD for ; Thu, 25 Oct 2012 02:26:05 -0700 (PDT) Received: from cpaasch-mac.localnet (cpaasch-mac.dhcp.info.ucl.ac.be [130.104.228.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id DF2C611EF86; Thu, 25 Oct 2012 11:25:58 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be DF2C611EF86 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1351157158; bh=phVeemNkLYX8KJT/HcuxPGMCuorC+4Vl4CGUURdaA08=; h=From:To:Reply-To:Cc:Subject:Date:Message-ID:In-Reply-To: References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=trQwHSdjbcByZubeVX+WSnD6Cc2yKQfR1tUScwF4ga7a3R/fqtECTvzTS3YsU8dTj AHi28/z1OnQwBJUyQGY0XSMCfubNkkyFfG4qCIXb6VWPFG5l0Zuz/nzlz1QeZ17gIi S18C81AViFJSV7C3zkEDXXjRA2OuDZw/an0riN4k= From: Christoph Paasch To: multipathtcp@ietf.org Date: Thu, 25 Oct 2012 11:25:58 +0200 Message-ID: <8555143.2iqzCu1CV5@cpaasch-mac> Organization: =?UTF-8?B?VW5pdmVyc2l0w6k=?= Catholique de Louvain User-Agent: KMail/4.9.2 (Linux/3.2.0-33-mptcp; KDE/4.9.2; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: clamav-milter 0.97.3-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: DF2C611EF86.A1C0A X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Subject: Re: [multipathtcp] comments on draft-paasch-mptcp-lowoverhead and draft-paasch-mptcp-ssl X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Christoph Paasch List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 09:26:06 -0000 Hi Yoshifumi, thanks for your comments. Please find my replies below. On Thursday 25 October 2012 01:51:58 Yoshifumi Nishida wrote: > 1: I'm wondering if experimental status might be better for them. Is = there > any thoughts on this? You are probably right. I can change this for the next version. > 2: How is the relationships between these drafts? Is it totally > independent? Yes, they are independent from each other. MPTCP v0 or MPTCP v1 (low ov= erhead)=20 can use a key provided by the application. > 3: In my feeling, it could be dangerous If token is used for high-ord= er > 32bit. (draft-paasch-mptcp-lowoverhead) > We might want to emphasize this point. What part in the draft are you referring to? It is the random number that is used for the 32 high-order bits of the = IDSN. Or do you mean that we just should explain why the random number is use= d, and=20 not the token for the high-order bits. > 4: In section 5 of draft-paasch-mptcp-lowoverhead. > "if an attacker manages to join an existing connection...". > Does this mean the attacker steals the token? I just would like t= o > confirm.. The attacker might know (through sniffing) the token or guess it and th= us can=20 add a subflow to the connection. Cheers, Christoph --=20 IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be Universit=E9 Catholique de Louvain -- From nishida@sfc.wide.ad.jp Thu Oct 25 03:02:28 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D569621F89A9 for ; Thu, 25 Oct 2012 03:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.874 X-Spam-Level: X-Spam-Status: No, score=-99.874 tagged_above=-999 required=5 tests=[AWL=-1.401, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQb4v1ubzODf for ; Thu, 25 Oct 2012 03:02:27 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 3341321F899E for ; Thu, 25 Oct 2012 03:02:27 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 9CC092780C3 for ; Thu, 25 Oct 2012 19:02:19 +0900 (JST) Received: by mail-la0-f44.google.com with SMTP id b11so1379390lam.31 for ; Thu, 25 Oct 2012 03:02:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.100.164 with SMTP id ez4mr6998694lbb.106.1351159337103; Thu, 25 Oct 2012 03:02:17 -0700 (PDT) Received: by 10.112.103.193 with HTTP; Thu, 25 Oct 2012 03:02:17 -0700 (PDT) In-Reply-To: <8555143.2iqzCu1CV5@cpaasch-mac> References: <8555143.2iqzCu1CV5@cpaasch-mac> Date: Thu, 25 Oct 2012 03:02:17 -0700 Message-ID: From: Yoshifumi Nishida To: Christoph Paasch Content-Type: multipart/alternative; boundary=f46d04016a5b52b03804ccdf4c7e Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] comments on draft-paasch-mptcp-lowoverhead and draft-paasch-mptcp-ssl 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, 25 Oct 2012 10:02:28 -0000 --f46d04016a5b52b03804ccdf4c7e Content-Type: text/plain; charset=ISO-8859-1 Hello Christoph, Thank you so much for your clarification. On Thu, Oct 25, 2012 at 2:25 AM, Christoph Paasch < christoph.paasch@uclouvain.be> wrote: > Hi Yoshifumi, > > thanks for your comments. Please find my replies below. > > > On Thursday 25 October 2012 01:51:58 Yoshifumi Nishida wrote: > > 1: I'm wondering if experimental status might be better for them. Is > there > > any thoughts on this? > > You are probably right. I can change this for the next version. > > > 2: How is the relationships between these drafts? Is it totally > > independent? > > Yes, they are independent from each other. MPTCP v0 or MPTCP v1 (low > overhead) > can use a key provided by the application. > > > 3: In my feeling, it could be dangerous If token is used for high-order > > 32bit. (draft-paasch-mptcp-lowoverhead) > > We might want to emphasize this point. > > What part in the draft are you referring to? > It is the random number that is used for the 32 high-order bits of the > IDSN. > > Or do you mean that we just should explain why the random number is used, > and > not the token for the high-order bits. > Sorry. I was not clear enough. Yes, that's what I meant. I thought if someone overlooks this part, it might be dangerous. Thanks, -- Yoshifumi --f46d04016a5b52b03804ccdf4c7e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Christoph,

Thank you so much for your clarification.

On Thu, Oct 25, 2012 at 2:25 AM, Christoph Paasch = <christoph.paasch@uclouvain.be> wrote:
Hi Yoshifumi,

thanks for your comments. Please find my replies below.


On Thursday 25 October 2012 01:51:58 Yoshifumi Nishida wrote:
> 1: I'm wondering if experimental status might be better for them. = Is there
> any thoughts on this?

You are probably right. I can change this for the next version.

> 2: How is the relationships between these drafts? Is it totally
> independent?

Yes, they are independent from each other. MPTCP v0 or MPTCP v1 (low = overhead)
can use a key provided by the application.

> 3: In my feeling, it could be dangerous If token is used for high-orde= r
> 32bit. (draft-paasch-mptcp-lowoverhead)
> =A0 =A0 We might want to emphasize this point.

What part in the draft are you referring to?
It is the random number that is used for the 32 high-order bits of the IDSN= .

Or do you mean that we just should explain why the random number is used, a= nd
not the token for the high-order bits.

Sorry. I wa= s not clear enough. Yes, that's what I meant.
I thought if someone = overlooks this part, it might be dangerous.

Thanks,
--
Yoshifu= mi
--f46d04016a5b52b03804ccdf4c7e-- From philip.eardley@bt.com Thu Oct 25 06:35:28 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C205A21F8971 for ; Thu, 25 Oct 2012 06:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.247 X-Spam-Level: X-Spam-Status: No, score=-103.247 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRi9gLLkxnDe for ; Thu, 25 Oct 2012 06:35:27 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 60A5A21F896F for ; Thu, 25 Oct 2012 06:35:27 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 25 Oct 2012 14:35:18 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.20]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Thu, 25 Oct 2012 14:35:18 +0100 From: To: Date: Thu, 25 Oct 2012 14:35:18 +0100 Thread-Topic: Atlanta agenda requests Thread-Index: Ac2izgcRUdbMveaUS4Sq40Mf9POM7QIC072wAfcFVsA= Message-ID: <9510D26531EF184D9017DF24659BB87F33EA74F214@EMV65-UKRD.domain1.systemhost.net> References: <9510D26531EF184D9017DF24659BB87F33DD152C0A@EMV65-UKRD.domain1.systemhost.net> <9510D26531EF184D9017DF24659BB87F33DD37FEF2@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F33DD37FEF2@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_9510D26531EF184D9017DF24659BB87F33EA74F214EMV65UKRDdoma_" MIME-Version: 1.0 Subject: Re: [multipathtcp] Atlanta agenda requests 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, 25 Oct 2012 13:35:28 -0000 --_000_9510D26531EF184D9017DF24659BB87F33EA74F214EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft agenda uploaded - we have some time spare, if there are any more requ= ests please let us know soon thanks From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of philip.eardley@bt.com Sent: 15 October 2012 14:32 To: multipathtcp@ietf.org; nishida@sfc.wide.ad.jp Subject: Re: [multipathtcp] Atlanta agenda requests Please send any more requests (so far, only from Christoph) Thanks phil From: multipathtcp-bounces@ietf.org [= mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 05 October 2012 09:43 To: multipathtcp@ietf.org; nishida@sfc.wide.a= d.jp Subject: [multipathtcp] Atlanta agenda requests Please let us know if you'd like some time on the agenda. Our *draft* timeslot is Tuesday, Afternoon Session II 1520-1650 (Christoph - we already have your request) Thanks Phil & Yoshifumi --_000_9510D26531EF184D9017DF24659BB87F33EA74F214EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Draft agenda uploaded – we have some time spare, if there are an= y more requests please let us know soon

thanks

 

From: multipathtcp-= bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: 15 October 2012 14:32
To: = multipathtcp@ietf.org; nishida@sfc.wide.ad.jp
Subject: Re: [multi= pathtcp] Atlanta agenda requests

 

Please send any more requests (so far, only from Christoph)

Thanks

phil

 

From: multipathtcp-bounces@ietf.org<= /a> [mailto:multipathtcp-b= ounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: 05 October 2012 09:43
<= b>To: multipathtcp@ietf.org; nishida@sfc.wide.ad.jp
= Subject: [multipathtcp] Atlanta agenda requests

 

Please let us= know if you’d like some time on the agenda.

O= ur *draft* timeslot is Tuesday, Afternoon Session II 1520-1650<= /o:p>

(Christoph – we already have your request)

Thanks

Phil & Yoshifumi

 

= --_000_9510D26531EF184D9017DF24659BB87F33EA74F214EMV65UKRDdoma_-- From georg.hampel@alcatel-lucent.com Fri Oct 26 13:54:33 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453CC21F84CA for ; Fri, 26 Oct 2012 13:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1-TkpAzAOXs for ; Fri, 26 Oct 2012 13:54:31 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF4A21F84EC for ; Fri, 26 Oct 2012 13:54:30 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q9QKsTCZ003395 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 26 Oct 2012 22:54:29 +0200 Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 26 Oct 2012 22:54:29 +0200 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.149]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Fri, 26 Oct 2012 16:54:28 -0400 From: "Hampel, K Georg (K Georg)" To: multipathtcp Thread-Topic: code release for MPTCP Proxy Thread-Index: Ac2zvBV/qD4uD9i3R/OxSn1qTtty7Q== Date: Fri, 26 Oct 2012 20:54:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_EA966EA2AAB21B44B4BBB188587598F902C40AUS70TWXCHMBA11zam_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [multipathtcp] code release for MPTCP Proxy 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, 26 Oct 2012 20:54:33 -0000 --_000_EA966EA2AAB21B44B4BBB188587598F902C40AUS70TWXCHMBA11zam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, We are announcing the source-code release for the MPTCP PROXY developed at = Bell Labs and presented at the IETF 83 WG meeting (Paris '12). WHAT IS MPTCP PROXY? The MPTCP Proxy operates on a packet filter of a Linux host with convention= al TCP/IP stack. It translates TCP (inside host) into MPTCP (outside host) = via packet-header rewriting. The MPTCP Proxy has been developed for mobilit= y support. The present version of the MPTCP Proxy runs in userspace using Netfilter/IP= tables. All Linux kernels >=3D2.6.14 are supported. The MPTCP Proxy supports almost all signaling features of the present MPTCP= design. It has been tested for interoperability with the native MPTCP impl= ementation currently supported by Olivier Bonaventure's group. This testing= has led to bug fixes on both implementations. Results of these tests are p= resented at the coming IETF 85 WG meeting (Atlanta '12). HOW DO I GET MPTCP PROXY? Go to: http://open-innovation.alcatel-lucent.com/projects/mptcp-proxy . Find "Latest File Releases" (bottom left box) and select "DocManager: Proje= ct Documentation" Under "Uncategorized Submissions", find and download "Installation & Operat= ion" guide as well as "mptcp_proxy_0-9" which is the .TAR file of the sourc= e code. SHOULD I USE MPTCP PROXY? Yes! Everybody is welcome to play with the code and to improve it. Please t= ake all further information from the "Installation & Operation" guide. --_000_EA966EA2AAB21B44B4BBB188587598F902C40AUS70TWXCHMBA11zam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
 
We are announcing the source-code release for the MPTCP PROXY develope= d at Bell Labs and presented at the IETF 83 WG meeting (Paris ’12).
 
 
WHAT IS MPTCP PROXY?
 
The MPTCP Proxy operates on a packet filter of a Linux host with conve= ntional TCP/IP stack. It translates TCP (inside host) into MPTCP (outside h= ost) via packet-header rewriting. The MPTCP Proxy has been developed for mo= bility support.
 
The present version of the MPTCP Proxy runs in userspace using Netfilt= er/IPtables. All Linux kernels >=3D2.6.14 are supported.
 
The MPTCP Proxy supports almost all signaling features of the present = MPTCP design. It has been tested for interoperability with the native MPTCP= implementation currently supported by Olivier Bonaventure’s group. T= his testing has led to bug fixes on both implementations. Results of these tests are presented at the coming IETF 85= WG meeting (Atlanta ’12).
 
 
HOW DO I GET MPTCP PROXY?
 
Find "Latest File Releases" (bottom left box) and select &qu= ot;DocManager: Project Documentation"
Under "Uncategorized Submissions", find and download “= Installation & Operation” guide as well as “mptcp_proxy_0-9= ” which is the .TAR file of the source code.
 
 
SHOULD I USE MPTCP PROXY?

Yes! Everybody is welcome to play with the code and to improve it. Please t= ake all further information from the “Installation & Operation= 221; guide.
 
 
 
 --_000_EA966EA2AAB21B44B4BBB188587598F902C40AUS70TWXCHMBA11zam_-- From iesg-secretary@ietf.org Mon Oct 29 15:53:50 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B684521F86BA; Mon, 29 Oct 2012 15:53:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbgSQ7ay4w2f; Mon, 29 Oct 2012 15:53:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185E521F86C4; Mon, 29 Oct 2012 15:53:50 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121029225350.30351.55716.idtracker@ietfa.amsl.com> Date: Mon, 29 Oct 2012 15:53:50 -0700 Cc: mptcp mailing list , mptcp chair , RFC Editor Subject: [multipathtcp] Document Action: 'TCP Extensions for Multipath Operation with Multiple Addresses' to Experimental RFC (draft-ietf-mptcp-multiaddressed-12.txt) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 22:53:50 -0000 The IESG has approved the following document: - 'TCP Extensions for Multipath Operation with Multiple Addresses' (draft-ietf-mptcp-multiaddressed-12.txt) as Experimental RFC This document is the product of the Multipath TCP Working Group. The IESG contact persons are Wesley Eddy and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mptcp-multiaddressed/ Technical Summary This draft describes the specification of Multipath TCP that is a set of new extension of TCP. Multipath TCP is designed to provides the ability to simultaneously use multiple paths between peers. This document presents message formats of Multipath TCP extensions and their interactions as well as the operational overviews and brief introduction. Working Group Summary This draft has been discussed for two years in the WG and there has been no major controversial points. There is a strong consensus in the WG for publication as we already have several implantation activities. Document Quality This document has been reviewed by various people. Several implementation projects have already started based on this and detailed comments from the implementors contributed a lot to improve the quality of the draft. Personnel Yoshifumi Nishida is the Document Shepherd for this document. The Responsible Area Director is Wesley Eddy.