From nishida@sfc.wide.ad.jp Sun Nov 4 01:27:49 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 866FC21F86AD for ; Sun, 4 Nov 2012 01:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.207 X-Spam-Level: X-Spam-Status: No, score=-97.207 tagged_above=-999 required=5 tests=[AWL=-1.147, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 h6DK2+A4IxUO for ; Sun, 4 Nov 2012 01:27:49 -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 14A9121F86AE for ; Sun, 4 Nov 2012 01:27:49 -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 AF8212780DC for ; Sun, 4 Nov 2012 17:27:39 +0900 (JST) Received: by mail-la0-f44.google.com with SMTP id b11so3713057lam.31 for ; Sun, 04 Nov 2012 01:27:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.104.50 with SMTP id gb18mr6201312lab.9.1352017657195; Sun, 04 Nov 2012 01:27:37 -0700 (PDT) Received: by 10.112.103.193 with HTTP; Sun, 4 Nov 2012 01:27:37 -0700 (PDT) Date: Sun, 4 Nov 2012 01:27:37 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] slides for Atlanta meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 08:27:49 -0000 Hello, We would like to ask presenters to send the presentation materials to Phil and me by Tuesday morning. We appreciate the folks who already sent the slides. Thanks, -- Yoshifumi & Phil From philip.eardley@bt.com Mon Nov 5 11:02: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 2451921F88B9 for ; Mon, 5 Nov 2012 11:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 UYtDWSG1hSxh for ; Mon, 5 Nov 2012 11:02:54 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 4E06721F87F1 for ; Mon, 5 Nov 2012 11:02:54 -0800 (PST) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 5 Nov 2012 19:02:52 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.155]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Mon, 5 Nov 2012 19:02:52 +0000 From: To: , Date: Mon, 5 Nov 2012 19:01:32 +0000 Thread-Topic: [multipathtcp] slides for Atlanta meeting Thread-Index: Ac26ZklAaAax5D+XSzu/XlvOrHFqEQBIa7ov Message-ID: <9510D26531EF184D9017DF24659BB87F33EC4BD040@EMV65-UKRD.domain1.systemhost.net> References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [multipathtcp] slides for Atlanta meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 19:02:55 -0000 ps "by Tuesday morning" =3D before 9am please (not "before 11.59am"!) thanks! phil ________________________________________ From: multipathtcp-bounces@ietf.org [multipathtcp-bounces@ietf.org] On Beha= lf Of Yoshifumi Nishida [nishida@sfc.wide.ad.jp] Sent: 04 November 2012 08:27 To: multipathtcp Subject: [multipathtcp] slides for Atlanta meeting Hello, We would like to ask presenters to send the presentation materials to Phil and me by Tuesday morning. We appreciate the folks who already sent the slides. Thanks, -- Yoshifumi & Phil _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp= From olivier.bonaventure@uclouvain.be Tue Nov 6 00:25:46 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 3719C21F858E for ; Tue, 6 Nov 2012 00:25:46 -0800 (PST) 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 sXHbdEJAonor for ; Tue, 6 Nov 2012 00:25:45 -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 817AF21F8462 for ; Tue, 6 Nov 2012 00:25:45 -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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id BE2CF11EC41; Tue, 6 Nov 2012 09:25:35 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be BE2CF11EC41 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1352190335; bh=+joC8Xc3KkTqGU/oKXdkn6eQ/HW2zrWN9cyNTPKWnYY=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding; b=vUv4NYqZbtvKtq+WzmPnhX6O2r0LOu5OCMpWyJGEW7Usv90t18VKuFMt24VJ7H7kV iSK7dUqjjzscSnk5XAlGawy68IHNFcTQyQz8wMOi3LkjfN/LtKR4Yh5/kfGzVgcMdH s6esb9mLR7WJtMnZhlvMft60RCFBAFDz5KVdiD+k= Message-ID: <5098C9DF.9090203@uclouvain.be> Date: Tue, 06 Nov 2012 09:27:11 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: multipathtcp , "" X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: BE2CF11EC41.A2C9A X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Subject: [multipathtcp] Bibliography of Multipath TCP papers X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 08:25:46 -0000 Hello, For an MPTCP tutorial that I'm preparing, I'd like to assemble a bibliography that contains most of the scientific papers published on Multipath TCP. I guess that I already know many of them, but if you have recently published a paper on Multipath TCP, I'd appreciate if you could send me a quick note. The bibliography will be placed on http://www.multipath-tcp.org before the end of this month. Thanks Olivier Bonaventure -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From gregory.detal@uclouvain.be Wed Nov 7 01:40:12 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 13BB821F8B6E for ; Wed, 7 Nov 2012 01:40:12 -0800 (PST) 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 V0hSIzC7u-6y for ; Wed, 7 Nov 2012 01:40:11 -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 7A32121F8B67 for ; Wed, 7 Nov 2012 01:40:11 -0800 (PST) Received: from [IPv6:2001:6a8:3080:2:59b9:4f6f:c821:a159] (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: gdetal@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 574D111F0CA; Wed, 7 Nov 2012 10:40:01 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 574D111F0CA DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1352281201; bh=x/O9hd76PTow0HU6aSVK10YFYqYXCa2JlCzUIWxXUe8=; h=From:Content-Type:Content-Transfer-Encoding:Date:Subject:To: Message-Id:Mime-Version; b=EOFBoOJncLzTffcpI1PVpOSH4wMIz74HCaGnvSA6MUAjDS9FJ+oe6vkWPp4h+BGQa Y1vFQcm85kIuY40wLO6KBzIDvb8xuGgsE/g773TZEwQ5GV/MmsD90as2kmWwHUSpLi qktGuNYFsNkAXGWvtNg6gK9P0h2RtfsFEaZIf5ZM= From: Gregory Detal Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Nov 2012 10:40:01 +0100 To: multipathtcp , "mptcp-dev@listes.uclouvain.be List" Message-Id: <6B56241A-30AD-45CE-9B65-0E60347A7845@uclouvain.be> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) 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: 574D111F0CA.AFC49 X-SGSI-MailScanner: Found to be clean X-SGSI-From: gregory.detal@uclouvain.be X-SGSI-Spam-Status: No Subject: [multipathtcp] Multipath TCP on Mac OSX 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, 07 Nov 2012 09:40:12 -0000 Hello, We worked on a solution to allow Mac OSX users to try MPTCP. Our = solution involves a virtual machine running our Linux kernel implementation of = MPTCP. By configuring a HTTP proxy, you can use all the available interfaces on = your mac with a MPTCP-enabled server as well as perform mobility. If you are = interested and you want to try it then everything is available at https://github.com/gdetal/mptcp-virtual. The solution relies on a single = bash script and only requires you to install VirtualBox. It has been tested to work on Mac OSX 10.6, 10.7 and 10.8. If you are = using it and you find some issues/bugs then contact me. People are also welcome = to improve it and port it to other systems such as Windows, Freebsd or = Linux. Gregory.= From njwilliams@swin.edu.au Sun Nov 11 22:53: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 9008F21F84C4 for ; Sun, 11 Nov 2012 22:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_33=0.6] 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 kUFnB1ks+hbL for ; Sun, 11 Nov 2012 22:53:54 -0800 (PST) Received: from gpo1.cc.swin.edu.au (gpo1.cc.swin.edu.au [136.186.1.30]) by ietfa.amsl.com (Postfix) with ESMTP id 4F77721F8488 for ; Sun, 11 Nov 2012 22:53:48 -0800 (PST) Received: from [136.186.229.154] (nwilliams-laptop.caia.swin.edu.au [136.186.229.154]) by gpo1.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id qAC6rbZn025722 for ; Mon, 12 Nov 2012 17:53:42 +1100 Message-ID: <50A09CF1.2060302@swin.edu.au> Date: Mon, 12 Nov 2012 17:53:37 +1100 From: Nigel Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [multipathtcp] draft terminology: MPTCP control block variable SND.NXT 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, 12 Nov 2012 06:53:55 -0000 Hi all. Thanks to Yoshifumi for keeping an eye on jabber during the session, though the time-lag did prove to be a bit of an obstacle. Following on from the point we had regarding 'DS SND.NXT'. From the draft [1] v12, p59, Section B.1.2 (variables in the MPTCP control block): "SND.NXT (64 bits): This is the Data Sequence Number of the next byte to be sent. SND.NXT is used to determine the value of the DSN in the DSS option." This terminology is borrowed from regular single flow TCP, but it's meaning does not seem to us to be the same in the MPTCP context. When a subflow asks the scheduler for new data to send, the scheduler allocates a chunk of the TX socket buffer to the subflow, tells the subflow the starting DS value for the chunk and the length of the chunk. The subflow then proceeds to send a DS map for the chunk and all the associated data before calling back up to the scheduler to get a new chunk allocated. Each subflow's internal concept of snd.nxt makes sense as in the regular single flow TCP case, but at the DS level, packets leave the machine with DS-level sequence numbers that jump all over the place (when using mappings > 1-MSS on multiple subflows). The interesting variable at the DS level is really the largest DS value mapped to a subflow i.e. the right most edge of the TX socket buffer which designates the boundary between bytes which have been mapped into subflows and bytes which have not. This is not analogous to an individual TCP flow's SND.NXT though, hence the point of discussion. cheers, nigel [1] http://www.ietf.org/id/draft-ietf-mptcp-multiaddressed-12.txt From christoph.paasch@uclouvain.be Mon Nov 12 01:14:49 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 E5CC121F854C for ; Mon, 12 Nov 2012 01:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 0lTPlQJGF4l8 for ; Mon, 12 Nov 2012 01:14:44 -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 7968C21F854B for ; Mon, 12 Nov 2012 01:14:38 -0800 (PST) Received: from cpaasch-mac.localnet (unknown [172.17.0.12]) (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 669B11C5A2C; Mon, 12 Nov 2012 10:14:31 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 669B11C5A2C DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1352711671; bh=1xVaaIPsw0hPZC7hIg7BvMHHXmIoQVrwZT6s2QbGF2I=; h=From:To:Reply-To:Cc:Subject:Date:Message-ID:In-Reply-To: References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=WL4Ao9fo32teXksCI7NQS2fSYkC+Aymc8gvj3+C9nq84QCdfEEsa3wLgL4q9W3p5f Oif9B9vvFOvKBv9sS+1xdN//5PM0+w2b5Q2VwJurCnc6vYAirgJngsbpRS527BMK/S TX+cKXuB120oZGfGZeoCXmKv/YmolnNzHiY/IaN8= From: Christoph Paasch To: multipathtcp@ietf.org Date: Mon, 12 Nov 2012 10:14:27 +0100 Message-ID: <1434931.3sf8zDIuhj@cpaasch-mac> Organization: =?UTF-8?B?VW5pdmVyc2l0w6k=?= Catholique de Louvain User-Agent: KMail/4.9.2 (Linux/3.2.0-33-mptcp-proxy; KDE/4.9.2; x86_64; ; ) In-Reply-To: <50A09CF1.2060302@swin.edu.au> References: <50A09CF1.2060302@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-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 669B11C5A2C.AFD9C X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Subject: Re: [multipathtcp] draft terminology: MPTCP control block variable SND.NXT 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, 12 Nov 2012 09:14:49 -0000 Hi Nigel, On Monday 12 November 2012 17:53:37 Nigel Williams wrote: > From the draft [1] v12, p59, Section B.1.2 (variables in the MPTCP > control block): > "SND.NXT (64 bits): This is the Data Sequence Number of the next byt= e > to be sent. SND.NXT is used to determine the value of the DSN in the= > DSS option." >=20 > This terminology is borrowed from regular single flow TCP, but it's > meaning does not seem to us to be the same in the MPTCP context. When= a > subflow asks the scheduler for new data to send, the scheduler alloca= tes > a chunk of the TX socket buffer to the subflow, tells the subflow the= > starting DS value for the chunk and the length of the chunk. The subf= low > then proceeds to send a DS map for the chunk and all the associated d= ata > before calling back up to the scheduler to get a new chunk allocated.= >=20 > Each subflow's internal concept of snd.nxt makes sense as in the regu= lar > single flow TCP case, but at the DS level, packets leave the machine > with DS-level sequence numbers that jump all over the place (when usi= ng > mappings > 1-MSS on multiple subflows). This depends on the scheduler, and I don't see why mappings > 1-MSS aff= ects=20 this. Is the data leaving the sender out-of-order on the data-sequence number= space=20 in your implementation? In our implementation, even if the mapping would be > 1-MSS, the SND.NX= T is=20 simply increasing as new data is pushed out on the network. I believe that. sending the data in-order on the DS-level allows an eas= ier=20 handling of the meta-level retransmission timer. Cheers, Christoph > The interesting variable at the > DS level is really the largest DS value mapped to a subflow i.e. the > right most edge of the TX socket buffer which designates the boundary= > between bytes which have been mapped into subflows and bytes which ha= ve > not. This is not analogous to an individual TCP flow's SND.NXT though= , > hence the point of discussion. >=20 > cheers, > nigel >=20 >=20 > [1] http://www.ietf.org/id/draft-ietf-mptcp-multiaddressed-12.txt > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp --=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 Mon Nov 12 18:04:20 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 6A97C21F8827 for ; Mon, 12 Nov 2012 18:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.01 X-Spam-Level: X-Spam-Status: No, score=-98.01 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_33=0.6, 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 BYvbwstIjW9A for ; Mon, 12 Nov 2012 18:04:15 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 4034021F87BF for ; Mon, 12 Nov 2012 18:04:15 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id B790A2780BD for ; Tue, 13 Nov 2012 11:04:08 +0900 (JST) Received: by mail-lb0-f172.google.com with SMTP id y2so1975216lbk.31 for ; Mon, 12 Nov 2012 18:04:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.27.97 with SMTP id s1mr8562985lbg.135.1352772246091; Mon, 12 Nov 2012 18:04:06 -0800 (PST) Received: by 10.112.142.196 with HTTP; Mon, 12 Nov 2012 18:04:06 -0800 (PST) In-Reply-To: <1434931.3sf8zDIuhj@cpaasch-mac> References: <50A09CF1.2060302@swin.edu.au> <1434931.3sf8zDIuhj@cpaasch-mac> Date: Mon, 12 Nov 2012 18:04:06 -0800 Message-ID: From: Yoshifumi Nishida To: Christoph Paasch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] draft terminology: MPTCP control block variable SND.NXT 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, 13 Nov 2012 02:04:20 -0000 Hi Christoph, Nigel, In my understanding, in TCP, seqno before SND.NXT is already sent to the network, while in case of MPTCP, this is not always correct. So, in a sense, the meaning of SND.NXT might be slightly different, although I'm not very sure if this is a problem. Thanks, -- Yoshifumi On Mon, Nov 12, 2012 at 1:14 AM, Christoph Paasch wrote: > Hi Nigel, > > On Monday 12 November 2012 17:53:37 Nigel Williams wrote: >> From the draft [1] v12, p59, Section B.1.2 (variables in the MPTCP >> control block): >> "SND.NXT (64 bits): This is the Data Sequence Number of the next byte >> to be sent. SND.NXT is used to determine the value of the DSN in the >> DSS option." >> >> This terminology is borrowed from regular single flow TCP, but it's >> meaning does not seem to us to be the same in the MPTCP context. When a >> subflow asks the scheduler for new data to send, the scheduler allocates >> a chunk of the TX socket buffer to the subflow, tells the subflow the >> starting DS value for the chunk and the length of the chunk. The subflow >> then proceeds to send a DS map for the chunk and all the associated data >> before calling back up to the scheduler to get a new chunk allocated. >> >> Each subflow's internal concept of snd.nxt makes sense as in the regular >> single flow TCP case, but at the DS level, packets leave the machine >> with DS-level sequence numbers that jump all over the place (when using >> mappings > 1-MSS on multiple subflows). > > This depends on the scheduler, and I don't see why mappings > 1-MSS affec= ts > this. > > Is the data leaving the sender out-of-order on the data-sequence number s= pace > in your implementation? > > In our implementation, even if the mapping would be > 1-MSS, the SND.NXT = is > simply increasing as new data is pushed out on the network. > I believe that. sending the data in-order on the DS-level allows an easie= r > handling of the meta-level retransmission timer. > > > Cheers, > Christoph > >> The interesting variable at the >> DS level is really the largest DS value mapped to a subflow i.e. the >> right most edge of the TX socket buffer which designates the boundary >> between bytes which have been mapped into subflows and bytes which have >> not. This is not analogous to an individual TCP flow's SND.NXT though, >> hence the point of discussion. >> >> cheers, >> nigel >> >> >> [1] http://www.ietf.org/id/draft-ietf-mptcp-multiaddressed-12.txt >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp > -- > 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 > -- > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From njwilliams@swin.edu.au Tue Nov 13 15:58:31 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 C2A1621F87B1 for ; Tue, 13 Nov 2012 15:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.551 X-Spam-Level: X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_33=0.6] 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 SnjDSFOzFWSA for ; Tue, 13 Nov 2012 15:58:31 -0800 (PST) Received: from gpo2.cc.swin.edu.au (gpo2.cc.swin.edu.au [136.186.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id CA42B21F852A for ; Tue, 13 Nov 2012 15:58:29 -0800 (PST) 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 qADNvxuE000703; Wed, 14 Nov 2012 10:58:04 +1100 Message-ID: <50A2DE86.1080703@swin.edu.au> Date: Wed, 14 Nov 2012 10:57:58 +1100 From: Nigel Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Christoph Paasch References: <50A09CF1.2060302@swin.edu.au> <1434931.3sf8zDIuhj@cpaasch-mac> In-Reply-To: <1434931.3sf8zDIuhj@cpaasch-mac> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] draft terminology: MPTCP control block variable SND.NXT 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, 13 Nov 2012 23:58:31 -0000 Hi Christoph, On 12/11/12 20:14, Christoph Paasch wrote: > Hi Nigel, > > On Monday 12 November 2012 17:53:37 Nigel Williams wrote: >> From the draft [1] v12, p59, Section B.1.2 (variables in the MPTCP >> control block): >> "SND.NXT (64 bits): This is the Data Sequence Number of the next byte >> to be sent. SND.NXT is used to determine the value of the DSN in the >> DSS option." >> >> This terminology is borrowed from regular single flow TCP, but it's >> meaning does not seem to us to be the same in the MPTCP context. When a >> subflow asks the scheduler for new data to send, the scheduler allocates >> a chunk of the TX socket buffer to the subflow, tells the subflow the >> starting DS value for the chunk and the length of the chunk. The subflow >> then proceeds to send a DS map for the chunk and all the associated data >> before calling back up to the scheduler to get a new chunk allocated. >> >> Each subflow's internal concept of snd.nxt makes sense as in the regular >> single flow TCP case, but at the DS level, packets leave the machine >> with DS-level sequence numbers that jump all over the place (when using >> mappings > 1-MSS on multiple subflows). > > This depends on the scheduler, and I don't see why mappings > 1-MSS affects > this. > This is why we think the variable name might be inappropriate, as, depending on the scheduler, ds snd.nxt might not always be the actual bytes 'sent next'. So in cases where the scheduler might provide multiple packet mappings to multiple subflows at the same time, the single-flow TCP meaning of snd.nxt doesn't translate to mptcp (as what snd.nxt points to is not always the next bytes transmitted). > Is the data leaving the sender out-of-order on the data-sequence number space > in your implementation? > In our implementation, depending on the scheduler, for certain scenarios where there are multiple subflows and DS mappings that cover multiple packets, it would be possible for packets to leave the sender out-of-order (DS-wise). A quick explanation of how our send buffer works might help demonstrate this. Given that the subflows share a send buffer, in order to minimise locking of the send buffer and mptcp control structure a scheduler might pre-allocate 'chunks' of data to each subflow. The subflow knows the DS-number at the start of the chunk and is able to send the entire chunk without needing to call into the mptcp layer/sendbuffer. We do not strictly increment a DS-level snd.nxt at this time, our equivalent might be called the 'ds_unmapped' (i.e. the highest sequence number that has been mapped to a subflow + 1). Each subflow maintains its own snd.nxt pointer into the mapping (as per standard tcp). At the subflow level, DSS maps can be used for the first packet of the mapping. For example, in the case where we have two subflows transmitting data at the same time, they are each allocated a contiguous chunk from the send buffer (Subflows A and B in Figure 1). Each subflow then will attempt to transmit the bytes it has been allocated from the send buffer, and does not call back into the ds-level until the map is exhausted (ideally). Given that subflow A and B start from different DS-numbers, and they are transmitting at the same time, the segments leave the sender out-of-order at the DS level. <--------- increasing DS +=========+========+=========+ |uuuuuuuuuubbbbbbbbbaaaaaaaaaa |uuuuuuuuuubbbbbbbbbaaaaaaaaaa +=========+========+=========+ | | | | ds_unmapped B | A | ds_una (for e.g.) Figure 1: Maps allocated to subflows A and B from the send buffer. Assume maps are greater than 1-MSS. ds_una is increased based on D-ACKS. So from the implementation perspective, the variable represents the next unmapped byte in the DS-space, rather than the next DS byte to be sent. > In our implementation, even if the mapping would be > 1-MSS, the SND.NXT is > simply increasing as new data is pushed out on the network. I can't picture how this works, would you be able to provide a similar explanation (as above) as to how you are able to transmit packets in DS-order with multiple concurrent subflows with mappings > 1-MSS? Perhaps we could schedule a Skype chat to discuss some of these points? cheers, nigel > I believe that. sending the data in-order on the DS-level allows an easier > handling of the meta-level retransmission timer. > > > Cheers, > Christoph > >> The interesting variable at the >> DS level is really the largest DS value mapped to a subflow i.e. the >> right most edge of the TX socket buffer which designates the boundary >> between bytes which have been mapped into subflows and bytes which have >> not. This is not analogous to an individual TCP flow's SND.NXT though, >> hence the point of discussion. >> >> cheers, >> nigel >> >> >> [1] http://www.ietf.org/id/draft-ietf-mptcp-multiaddressed-12.txt >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp From christoph.paasch@uclouvain.be Wed Nov 14 01:48:54 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 591CC21F860D for ; Wed, 14 Nov 2012 01:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 oUvF8OZ1TZ-q for ; Wed, 14 Nov 2012 01:48:53 -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 1B84C21F8621 for ; Wed, 14 Nov 2012 01:48:52 -0800 (PST) Received: from cpaasch-mac.localnet (unknown [172.17.0.12]) (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 C0ED51C6194; Wed, 14 Nov 2012 10:48:47 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be C0ED51C6194 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1352886527; bh=IY360Wa9mtA+x05F6l4wl72w/MYm3+/Z2EndbomjkEQ=; h=From:To:Reply-To:Cc:Subject:Date:Message-ID:In-Reply-To: References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=dggoBaIz9ryXCPR/RSai/zh5Uk+yWx+RRAgR2uoyVTRhzdZJbWA/yl4V7yEfG5tZt BYCR/q1i1mDhGZCQPeHiOwWbcs65A5mqalaCz03b8wEQCvRiHgAXq95dn+XPCCZCdT 4hiakPyaLpIUJbxB03eSbqvDelUsU6vQNIkA87cI= From: Christoph Paasch To: Nigel Williams Date: Wed, 14 Nov 2012 10:48:44 +0100 Message-ID: <2084870.5phkxIDxER@cpaasch-mac> Organization: =?UTF-8?B?VW5pdmVyc2l0w6k=?= Catholique de Louvain User-Agent: KMail/4.9.3 (Linux/3.5.0-18-generic; KDE/4.9.3; x86_64; ; ) In-Reply-To: <50A2DE86.1080703@swin.edu.au> References: <50A09CF1.2060302@swin.edu.au> <1434931.3sf8zDIuhj@cpaasch-mac> <50A2DE86.1080703@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-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: C0ED51C6194.A1868 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] draft terminology: MPTCP control block variable SND.NXT 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: Wed, 14 Nov 2012 09:48:54 -0000 Hi Nigel, On Wednesday 14 November 2012 10:57:58 Nigel Williams wrote: [...] > > Is the data leaving the sender out-of-order on the data-sequence nu= mber > > space in your implementation? >=20 > In our implementation, depending on the scheduler, for certain scenar= ios > where there are multiple subflows and DS mappings that cover multiple= > packets, it would be possible for packets to leave the sender > out-of-order (DS-wise). A quick explanation of how our send buffer wo= rks > might help demonstrate this. >=20 > Given that the subflows share a send buffer, in order to minimise > locking of the send buffer and mptcp control structure a scheduler mi= ght > pre-allocate 'chunks' of data to each subflow. The subflow knows the > DS-number at the start of the chunk and is able to send the entire ch= unk > without needing to call into the mptcp layer/sendbuffer. We do not > strictly increment a DS-level snd.nxt at this time, our equivalent mi= ght > be called the 'ds_unmapped' (i.e. the highest sequence number that ha= s > been mapped to a subflow + 1). Each subflow maintains its own snd.nxt= > pointer into the mapping (as per standard tcp). >=20 > At the subflow level, DSS maps can be used for the first packet of th= e > mapping. For example, in the case where we have two subflows > transmitting data at the same time, they are each allocated a contigu= ous > chunk from the send buffer (Subflows A and B in Figure 1). Each subfl= ow > then will attempt to transmit the bytes it has been allocated from th= e > send buffer, and does not call back into the ds-level until the map i= s > exhausted (ideally). Given that subflow A and B start from different > DS-numbers, and they are transmitting at the same time, the segments > leave the sender out-of-order at the DS level. >=20 >=20 > <--------- increasing DS > +=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D= =3D=3D=3D=3D+ >=20 > |uuuuuuuuuubbbbbbbbbaaaaaaaaaa > |uuuuuuuuuubbbbbbbbbaaaaaaaaaa >=20 > +=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D= =3D=3D=3D=3D+ >=20 > ds_unmapped B | A >=20 > ds_una (for e.g.) >=20 > Figure 1: Maps allocated to subflows A and B from the send buffer. > Assume maps are greater than 1-MSS. ds_una is increased based on D-AC= KS. >=20 > So from the implementation perspective, the variable represents the n= ext > unmapped byte in the DS-space, rather than the next DS byte to be sen= t. ok, I understand now what you mean. Thanks for the clarifications. The DS-snd.nxt must be seen from the MPTCP-level point-of-view, where t= he=20 subflow-level is one layer below the MPTCP-level. As soon as a subflow has been allocated to a chunk of the data, this ch= unk has=20 "moved" from the MPTCP-level to the subflow-level, and thus the send-ne= xt must=20 increase. "moving" the chunk to the subflow-level can be seen as sendin= g the=20 data. It is the same as for the TCP-level snd-nxt. Pushing a segment from the= TCP- layer down to the IP-layer, and thus increasing snd-nxt, does not neces= sarily=20 mean that the segment is "physically" leaving the machine. It may be de= layed=20 for a long time in underlying queues (e.g., inside a tc qdisc) of the=20= operating system. So, in general I would say that "send" just means that the data is "mov= ed" one=20 layer further down the stack. > > In our implementation, even if the mapping would be > 1-MSS, the SN= D.NXT > > is > > simply increasing as new data is pushed out on the network. >=20 > I can't picture how this works, would you be able to provide a simila= r > explanation (as above) as to how you are able to transmit packets in > DS-order with multiple concurrent subflows with mappings > 1-MSS? > Perhaps we could schedule a Skype chat to discuss some of these point= s? For me, "sending" at the MPTCP-layer simply means that the data is push= ed one=20 level further - thus down to the subflow-level. So, the packets may be = leaving=20 the machine out-of-order at the DS-level, but we anyways can't control = this. Cheers, Christoph > cheers, > nigel >=20 > > I believe that. sending the data in-order on the DS-level allows an= easier > > handling of the meta-level retransmission timer. > >=20 > >=20 > > Cheers, > > Christoph > >=20 > >> The interesting variable at the > >> DS level is really the largest DS value mapped to a subflow i.e. t= he > >> right most edge of the TX socket buffer which designates the bound= ary > >> between bytes which have been mapped into subflows and bytes which= have > >> not. This is not analogous to an individual TCP flow's SND.NXT tho= ugh, > >> hence the point of discussion. > >>=20 > >> cheers, > >> nigel > >>=20 > >>=20 > >> [1] http://www.ietf.org/id/draft-ietf-mptcp-multiaddressed-12.txt > >> _______________________________________________ > >> multipathtcp mailing list > >> multipathtcp@ietf.org > >> https://www.ietf.org/mailman/listinfo/multipathtcp --=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 wes@mti-systems.com Thu Nov 15 09:28:31 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 1BBF921F89CC for ; Thu, 15 Nov 2012 09:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.292 X-Spam-Level: X-Spam-Status: No, score=-1.292 tagged_above=-999 required=5 tests=[AWL=-0.653, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 kapw92KAUQ75 for ; Thu, 15 Nov 2012 09:28:30 -0800 (PST) Received: from atl4mhob09.myregisteredsite.com (atl4mhob09.myregisteredsite.com [209.17.115.47]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFCB21F89C8 for ; Thu, 15 Nov 2012 09:28:30 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob09.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAFHSSud027806 for ; Thu, 15 Nov 2012 12:28:28 -0500 Received: (qmail 31072 invoked by uid 0); 15 Nov 2012 17:28:28 -0000 Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.45.111.81) by 0 with ESMTPA; 15 Nov 2012 17:28:28 -0000 Message-ID: <50A52636.8020106@mti-systems.com> Date: Thu, 15 Nov 2012 12:28:22 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [multipathtcp] IESG Review comments on MPTCP API 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, 15 Nov 2012 17:28:31 -0000 Hi, just to explain some emails that I'm about to forward to the WG mailing list, while reviewing the MPTCP API, the IESG came up with a handful of good questions that don't have immediately obvious answers, and which I think it would be of benefit to discuss in the working group. For now, the document is going to remain in the IESG Review state, while we're all looking at these questions. Please feel free to copy the IESG (iesg@ietf.org) if you'd like to include them on your responses. Several ADs are eager, I think, to help find ways to maximize use of MPTCP, and will be happy to see responses to their comments. -- Wes Eddy MTI Systems From wes@mti-systems.com Thu Nov 15 09:29:20 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 AA36D21F89DF for ; Thu, 15 Nov 2012 09:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 z0HWQrCRGwf5 for ; Thu, 15 Nov 2012 09:29:20 -0800 (PST) Received: from atl4mhob12.myregisteredsite.com (atl4mhob12.myregisteredsite.com [209.17.115.50]) by ietfa.amsl.com (Postfix) with ESMTP id 1B15521F89AC for ; Thu, 15 Nov 2012 09:29:20 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob12.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAFHTIeT015803 for ; Thu, 15 Nov 2012 12:29:18 -0500 Received: (qmail 961 invoked by uid 0); 15 Nov 2012 17:29:18 -0000 Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.45.111.81) by 0 with ESMTPA; 15 Nov 2012 17:29:18 -0000 Message-ID: <50A52667.2000006@mti-systems.com> Date: Thu, 15 Nov 2012 12:29:11 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: multipathtcp , Stephen Farrell References: <20121113171931.620.96985.idtracker@ietfa.amsl.com> In-Reply-To: <20121113171931.620.96985.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121113171931.620.96985.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) 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, 15 Nov 2012 17:29:20 -0000 -------- Original Message -------- Subject: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) Date: Tue, 13 Nov 2012 09:19:31 -0800 From: Stephen Farrell To: The IESG CC: draft-ietf-mptcp-api@tools.ietf.org, mptcp-chairs@tools.ietf.org Stephen Farrell has entered the following ballot position for draft-ietf-mptcp-api-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- These ought be easy to resolve. If they're real issues, I'm fine with making them into comments that can be resolved by the chairs/AD or holding the discuss if that's better. If not, then I'll be glad I checked anyway:-) (1) Sorry if this is the wrong document for this comment, but it only occurred to me now to check, so maybe you can say if it applies and we can see what, if anything to do then. RFC 5246 section 7.2.1 says that once you've gotten a TLS close_notify then you close the TLS session, and also that each side is required to send a close_notify before closing the write side of a TCP connection. Does that mean we missed a security consideration in MPTCP that should have highlighted that there may be work to be done in a TLS implementation for it to run over MPTCP gracefully if one side wants to close some of the subflows? Or, is that something that should/could go in here where e.g. we say if using a basic or advanced API to implement TLS then don't do that? If something ought go in this draft then it'd probably be a good plan to check the text with the TLS wg before you're done. (2) In a similar vein, if TLS with an SNI with an IP address is being used (rfc6066 says you can't, but who knows what's done in the wild) and/or if a TLS certificate has IP addresses in the SAN, then should something special be done to handle that or could it cause an unexpected failure? Again, if text is needed it should probably be checked with the TLS wg. This may also affect TLS/MPTCP via a legacy API (not sure). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - Would it be useful to add a security consideration to the effect that applications may need to revisit some assumptions about the sockets API that could impact on security? Not sure what text precisely but I'd expect new buffer problems might be likely here in practice if the size of the return from getpeername() etc changes and not all calling code is aware that MPTCP is in use. From wes@mti-systems.com Thu Nov 15 09:29:46 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 6739E21F8A10 for ; Thu, 15 Nov 2012 09:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.031 X-Spam-Level: X-Spam-Status: No, score=-1.031 tagged_above=-999 required=5 tests=[AWL=-0.392, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 Z0oV-vOUgF61 for ; Thu, 15 Nov 2012 09:29:46 -0800 (PST) Received: from atl4mhob05.myregisteredsite.com (atl4mhob05.myregisteredsite.com [209.17.115.43]) by ietfa.amsl.com (Postfix) with ESMTP id 86D3B21F89CD for ; Thu, 15 Nov 2012 09:29:45 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob05.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAFHTiWG019053 for ; Thu, 15 Nov 2012 12:29:44 -0500 Received: (qmail 394 invoked by uid 0); 15 Nov 2012 17:29:44 -0000 Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.45.111.81) by 0 with ESMTPA; 15 Nov 2012 17:29:44 -0000 Message-ID: <50A52681.6040700@mti-systems.com> Date: Thu, 15 Nov 2012 12:29:37 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: multipathtcp References: <20121114161653.3585.85269.idtracker@ietfa.amsl.com> In-Reply-To: <20121114161653.3585.85269.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121114161653.3585.85269.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Robert Sparks Subject: [multipathtcp] Fwd: Robert Sparks' No Objection on draft-ietf-mptcp-api-06: (with COMMENT) 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, 15 Nov 2012 17:29:46 -0000 -------- Original Message -------- Subject: Robert Sparks' No Objection on draft-ietf-mptcp-api-06: (with COMMENT) Date: Wed, 14 Nov 2012 08:16:53 -0800 From: Robert Sparks To: The IESG CC: draft-ietf-mptcp-api@tools.ietf.org, mptcp-chairs@tools.ietf.org Robert Sparks has entered the following ballot position for draft-ietf-mptcp-api-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Apologies if I missed it, but is there a way using this Basic API for an application to learn that the mptcp stack it is using has accepted a new substream without polling? If not, should there be? Or was this explicitly deferred to the advanced API? From wes@mti-systems.com Thu Nov 15 09:30:27 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 8E25521F84D4 for ; Thu, 15 Nov 2012 09:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.966 X-Spam-Level: X-Spam-Status: No, score=-0.966 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 kHFBMlRCG+qa for ; Thu, 15 Nov 2012 09:30:27 -0800 (PST) Received: from atl4mhob07.myregisteredsite.com (atl4mhob07.myregisteredsite.com [209.17.115.45]) by ietfa.amsl.com (Postfix) with ESMTP id F3ADA21F84CA for ; Thu, 15 Nov 2012 09:30:26 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob07.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAFHUP2c003531 for ; Thu, 15 Nov 2012 12:30:25 -0500 Received: (qmail 19575 invoked by uid 0); 15 Nov 2012 17:30:25 -0000 Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.45.111.81) by 0 with ESMTPA; 15 Nov 2012 17:30:25 -0000 Message-ID: <50A526AB.1060102@mti-systems.com> Date: Thu, 15 Nov 2012 12:30:19 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: multipathtcp , Sean Turner References: <20121115160525.4910.71855.idtracker@ietfa.amsl.com> In-Reply-To: <20121115160525.4910.71855.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121115160525.4910.71855.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [multipathtcp] Fwd: Sean Turner's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) 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, 15 Nov 2012 17:30:27 -0000 -------- Original Message -------- Subject: Sean Turner's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) Date: Thu, 15 Nov 2012 08:05:25 -0800 From: Sean Turner To: The IESG CC: draft-ietf-mptcp-api@tools.ietf.org, mptcp-chairs@tools.ietf.org Sean Turner has entered the following ballot position for draft-ietf-mptcp-api-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 1) s3.2.*: I'm keying here on the multiple IP bit, so if I'm misunderstanding something just let me know: - There's got to be a logging/storage impact based on mptcp? If servers were tracking source IP addresses and now instead of one coming from a client there's two that means at least a double - right? - There's protocols that include things like IP addresses in the received from header will it now need to include one for each subflow? - If certificates are used by an application and the certificates include an IP address, how many need to be included in the certificate? Will the application know how many subflows are going to get started? It's going to have know which subflow to give which cert? 2) I echo Stephen's concerns wrt TLS. TLS explicitly discusses a DoS attack based on an attacker who initiates a large number of TCP connections (F.5 of RFC 5246). Are we now making lots of people potential attackers? Should some guidance on the # of connections to open be given? Also, isn't this worth a mention in the security considerations. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) s3.1.1: The throughput assertion isn't always true -right? If you have one of the two links splitting what would have gone down one link go down then don't you have less than half the throughput of the original link - at least until the now combined subflow ramps back up? 2) s3.1.1: Should you also point out that if all the subflows collapse in to one that the overhead actually lowers the throughput compared to regular TCP? 3) s3.1.2: Wouldn't there also be a delay with the collapse of a subflow? From wes@mti-systems.com Thu Nov 15 09:31: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 04B6521F84D8 for ; Thu, 15 Nov 2012 09:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 aaWh68NJzj6h for ; Thu, 15 Nov 2012 09:31:05 -0800 (PST) Received: from atl4mhob06.myregisteredsite.com (atl4mhob06.myregisteredsite.com [209.17.115.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0863C21F84D4 for ; Thu, 15 Nov 2012 09:31:04 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob06.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAFHV28b030983 for ; Thu, 15 Nov 2012 12:31:02 -0500 Received: (qmail 15994 invoked by uid 0); 15 Nov 2012 17:31:00 -0000 Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.45.111.81) by 0 with ESMTPA; 15 Nov 2012 17:31:00 -0000 Message-ID: <50A526CE.5040802@mti-systems.com> Date: Thu, 15 Nov 2012 12:30:54 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: multipathtcp References: <20121115040234.23391.899.idtracker@ietfa.amsl.com> In-Reply-To: <20121115040234.23391.899.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121115040234.23391.899.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Pete Resnick Subject: [multipathtcp] Fwd: Pete Resnick's No Objection on draft-ietf-mptcp-api-06: (with COMMENT) 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, 15 Nov 2012 17:31:06 -0000 -------- Original Message -------- Subject: Pete Resnick's No Objection on draft-ietf-mptcp-api-06: (with COMMENT) Date: Wed, 14 Nov 2012 20:02:34 -0800 From: Pete Resnick To: The IESG CC: draft-ietf-mptcp-api@tools.ietf.org, mptcp-chairs@tools.ietf.org Pete Resnick has entered the following ballot position for draft-ietf-mptcp-api-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [Note: These are things I've found in my review with a couple of comments from friends in Apps. I've asked -- no, begged -- the apps-discuss list for some additional opinions as we all seem to have missed this during Last Call. Mea culpa; bad AD. I will update with additional comments should they come in. At this point, I see no showstoppers, so I'm leaving this as No Objection.] 4.2.2 This section gives me the most pause. I am worried (though not enough to hold up the document over) about how the legacy getsockname and getpeername APIs will perform. In particular: This problem is addressed as follows: If used by a legacy application, the MPTCP stack MUST always return the addresses of the first subflow of an MPTCP connection, in all circumstances, even if that particular subflow is no longer in use. Is it possible that an IP Address/Port pair can be reused while a connection is still in progress? So, I start on 1.2.3.4:23456. MPTCP makes some subflows, and then 1.2.3.4:23456 goes away. Is it possible for another process on the machine to pick up 1.2.3.4:23456 at this point? On a different note: As this address may not be valid any more if the first subflow is closed, the MPTCP stack MAY close the whole MPTCP connection if the first subflow is closed (i.e. fate sharing between the initial subflow and the MPTCP connection as a whole). I don't understand why this is in there. Of course, any implementation can close a connection for any reason it chooses, but that MAY makes it sound like fate sharing the initial subflow is a good idea. AFAICT, it's a terrible idea. Why is this paragraph in there? If fate-sharing the initial subflow remains, I assume this will be configurable in the Advanced API, yes? It is not mentioned in Appendix A. 5.3.1: Why is the connection identifier only 32-bit? From philip.eardley@bt.com Tue Nov 20 08:23: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 53CC321F8711 for ; Tue, 20 Nov 2012 08:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 f6-XeNqoY0wy for ; Tue, 20 Nov 2012 08:23:00 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 1753D21F8695 for ; Tue, 20 Nov 2012 08:23:00 -0800 (PST) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 20 Nov 2012 16:22:58 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.94]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Tue, 20 Nov 2012 16:22:58 +0000 From: To: Date: Tue, 20 Nov 2012 16:22:57 +0000 Thread-Topic: Informal MPTCP discussion in Atlanta Thread-Index: Ac3HO00tR97UhhvxRZSpfHwCi7ddWg== Message-ID: <9510D26531EF184D9017DF24659BB87F33F36442E3@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_9510D26531EF184D9017DF24659BB87F33F36442E3EMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] Informal MPTCP discussion in Atlanta 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, 20 Nov 2012 16:23:01 -0000 --_000_9510D26531EF184D9017DF24659BB87F33F36442E3EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some of us met with Stephen Farrell in Atlanta, to discuss about moving MPT= CP from Experimental to Standards track, from a security perspective. This was very much an informal discussion. One thing is that, if we want, S= tephen can try and identify a security advisor to work with us. My summary = of the discussion about things we could work on: (1) more secure method th= an the current spec (possibly implemented by default, even if not turned on= by default); (2) perhaps how to swap in better algorithms (slightly more d= efined than in the current spec); (3) perhaps part of the work would be to = re-check the threat analysis (as 'similar security to TCP' may not be a goo= d long term goal). Thanks phil --_000_9510D26531EF184D9017DF24659BB87F33F36442E3EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Some of us met with Stephen Fa= rrell in Atlanta, to discuss about moving MPTCP from Experimental to Standa= rds track, from a security perspective.

This was very= much an informal discussion. One thing is that, if we want, Stephen can tr= y and identify a security advisor to work with us. My summary of the discus= sion  about things we could work on: (1) more secure method than the c= urrent spec (possibly implemented by default, even if not turned on by defa= ult); (2) perhaps how to swap in better algorithms (slightly more defined t= han in the current spec); (3) perhaps part of the work would be to re-check= the threat analysis (as ‘similar security to TCP’ may not be a= good long term goal). 

Thanks

phil

 

= --_000_9510D26531EF184D9017DF24659BB87F33F36442E3EMV65UKRDdoma_-- From nishida@sfc.wide.ad.jp Wed Nov 21 00:05:45 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 DF3CC21F874A for ; Wed, 21 Nov 2012 00:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.579 X-Spam-Level: X-Spam-Status: No, score=-97.579 tagged_above=-999 required=5 tests=[AWL=-0.594, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 df-zLWtDkEie for ; Wed, 21 Nov 2012 00:05:45 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id E669A21F873A for ; Wed, 21 Nov 2012 00:05:44 -0800 (PST) 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 765E52780AD for ; Wed, 21 Nov 2012 17:05:38 +0900 (JST) Received: by mail-la0-f44.google.com with SMTP id d3so5562438lah.31 for ; Wed, 21 Nov 2012 00:05:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.86.35 with SMTP id m3mr7419525lbz.7.1353485135686; Wed, 21 Nov 2012 00:05:35 -0800 (PST) Received: by 10.112.142.196 with HTTP; Wed, 21 Nov 2012 00:05:35 -0800 (PST) Date: Wed, 21 Nov 2012 00:05:35 -0800 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] minutes for Atlanta meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 08:05:46 -0000 Hello, I've uploaded a draft minute for Atlanta meeting on the following URL. If you have comments or corrections on this, please let us know. http://tools.ietf.org/wg/mptcp/minutes?item=minutes-85-mptcp.html We appreciate Peer and Alan for note taking. Thanks, -- Yoshifumi & Phil From nishida@sfc.wide.ad.jp Wed Nov 21 15:25:53 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 747CD21E803D for ; Wed, 21 Nov 2012 15:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.683 X-Spam-Level: X-Spam-Status: No, score=-97.683 tagged_above=-999 required=5 tests=[AWL=-0.410, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_52=0.6, 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 NfIh3BwriAu6 for ; Wed, 21 Nov 2012 15:25:52 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 6D52521E803C for ; Wed, 21 Nov 2012 15:25:52 -0800 (PST) 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 80C8E2780E5 for ; Thu, 22 Nov 2012 08:25:46 +0900 (JST) Received: by mail-la0-f44.google.com with SMTP id d3so6265488lah.31 for ; Wed, 21 Nov 2012 15:25:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.105.68 with SMTP id gk4mr19052132lab.48.1353540343863; Wed, 21 Nov 2012 15:25:43 -0800 (PST) Received: by 10.112.142.196 with HTTP; Wed, 21 Nov 2012 15:25:43 -0800 (PST) In-Reply-To: <50A52667.2000006@mti-systems.com> References: <20121113171931.620.96985.idtracker@ietfa.amsl.com> <50A52667.2000006@mti-systems.com> Date: Wed, 21 Nov 2012 15:25:43 -0800 Message-ID: From: Yoshifumi Nishida To: multipathtcp , Stephen Farrell Content-Type: multipart/alternative; boundary=f46d040714af62976004cf09ab1e Subject: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 23:25:53 -0000 --f46d040714af62976004cf09ab1e Content-Type: text/plain; charset=ISO-8859-1 Hello Stephen, Thanks for the comments. I would like to clarify some points. > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > These ought be easy to resolve. If they're real issues, I'm > fine with making them into comments that can be resolved by the > chairs/AD or holding the discuss if that's better. If not, > then I'll be glad I checked anyway:-) > > (1) Sorry if this is the wrong document for this comment, but > it only occurred to me now to check, so maybe you can say if it > applies and we can see what, if anything to do then. RFC 5246 > section 7.2.1 says that once you've gotten a TLS close_notify > then you close the TLS session, and also that each side is > required to send a close_notify before closing the write side > of a TCP connection. Does that mean we missed a security > consideration in MPTCP that should have highlighted that there > may be work to be done in a TLS implementation for it to run > over MPTCP gracefully if one side wants to close some of the > subflows? Or, is that something that should/could go in here > where e.g. we say if using a basic or advanced API to implement > TLS then don't do that? If something ought go in this draft > then it'd probably be a good plan to check the text with the > TLS wg before you're done. In basic API, application uses one socket to utilize MPTCP with conventional APIs and doesn't know about if some of subflows are connected or disconnected. There's no way to control subflows from the application except closing all subflows, which indicates terminating the session. So, in my understanding, we won't need to do anything for application when some(but not all) of the subflows are disconnected/closed for some reasons. When the socket is about to close, I think we'll need to do the same things as what TLS over normal TCP does. But, this will be a generic guideline for application, not specific to TLS. Could you elaborate the concerns about TLS over MPTCP? > (2) In a similar vein, if TLS with an SNI with an IP address is > being used (rfc6066 says you can't, but who knows what's done > in the wild) and/or if a TLS certificate has IP addresses in > the SAN, then should something special be done to handle that > or could it cause an unexpected failure? Again, if text is > needed it should probably be checked with the TLS wg. This may > also affect TLS/MPTCP via a legacy API (not sure). The basic APIs utilize single IP address which is the IP address of first subflow. This might cause problems since there might be a situation where the IP address is not accessible anymore while MPTCP is still running. But, I'm not very sure if this will be a problem in this case. Could you explain the cases where might cause failures? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - Would it be useful to add a security consideration to the > effect that applications may need to revisit some > assumptions about the sockets API that could impact on > security? Not sure what text precisely but I'd expect new > buffer problems might be likely here in practice if the > size of the return from getpeername() etc changes and > not all calling code is aware that MPTCP is in use. As the basic APIs utilize single IP address, I think the size of the returned parameters will be the same as conventional APIs. So, I think there's at least no buffer problem here. Could you let us know if there're other security implications? (BTW, 4.4.3 describes some guidelines related to socket buffer size) Thanks, -- Yoshifumi Nishida --f46d040714af62976004cf09ab1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Stephen,

Thanks for the comments.
I would like to clarify = some points.

> --------------------------------------------------= --------------------
> DISCUSS:
> -----------------------------= -----------------------------------------
>
>
> These ought be easy to resolve. If they're real is= sues, I'm
> fine with making them into comments that can be resol= ved by the
> chairs/AD or holding the discuss if that's better. I= f not,
> then I'll be glad I checked anyway:-)
>
> (1) Sorry if= this is the wrong document for this comment, but
> it only occurred = to me now to check, so maybe you can say if it
> applies and we can s= ee what, if anything to do then. RFC 5246
> section 7.2.1 says that once you've gotten a TLS close_notify
&= gt; then you close the TLS session, and also that each side is
> requ= ired to send a close_notify before closing the write side
> of a TCP = connection. Does that mean we missed a security
> consideration in MPTCP that should have highlighted that there
>= may be work to be done in a TLS implementation for it to run
> over = MPTCP gracefully if one side wants to close some of the
> subflows? O= r, is that something that should/could go in here
> where e.g. we say if using a basic or advanced API to implement
>= ; TLS then don't do that? If something ought go in this draft
> t= hen it'd probably be a good plan to check the text with the
> TLS= wg before you're done.

In basic API, application uses one socket to utilize MPTCP with convent= ional APIs and doesn't know about if some of subflows are connected or = disconnected. There's no way to control subflows from the application e= xcept closing all subflows, which indicates terminating the session.
So, in my understanding, we won't need to do anything for application w= hen some(but not all) of the subflows are disconnected/closed for some reas= ons.
When the socket is about to close, I think we'll need to do th= e same things as what TLS over normal TCP does. But, this will be a generic= guideline for application, not specific to TLS.
Could you elaborate the concerns about TLS over MPTCP?

> (2) In a= similar vein, if TLS with an SNI with an IP address is
> being used = (rfc6066 says you can't, but who knows what's done
> in the w= ild) and/or if a TLS certificate has IP addresses in
> the SAN, then should something special be done to handle that
> = or could it cause an unexpected failure? =A0Again, if text is
> neede= d it should probably be checked with the TLS wg. This may
> also affe= ct TLS/MPTCP via a legacy API (not sure).

The basic APIs utilize single IP address which is the IP address of fir= st subflow.
This might cause problems since there might be a situation w= here the IP address is not accessible anymore while MPTCP is still running.=
But, I'm not very sure if this will be a problem in this case. Could yo= u explain the cases where might cause failures?

>
>
>= ----------------------------------------------------------------------
> COMMENT:
> -----------------------------------------------------= -----------------
>
>
> - Would it be useful to add a sec= urity consideration to the
> effect that applications may need to rev= isit some
> assumptions about the sockets API that could impact on
> securit= y? Not sure what text precisely but I'd expect new
> buffer probl= ems might be likely here in practice if the
> size of the return from= getpeername() etc changes and
> not all calling code is aware that MPTCP is in use.

As the basi= c APIs utilize single IP address, I think the size of the returned paramete= rs will be the same as conventional APIs.
So, I think there's at lea= st no buffer problem here.
Could you let us know if there're other security implications?=A0 (BTW= , 4.4.3 describes some guidelines related to socket buffer size)

Tha= nks,
--
Yoshifumi Nishida

--f46d040714af62976004cf09ab1e-- From stephen.farrell@cs.tcd.ie Thu Nov 22 01:37:32 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 537EA21F8796; Thu, 22 Nov 2012 01:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_52=0.6, 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 7AUnKuIiLcaf; Thu, 22 Nov 2012 01:37:31 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3478E21F86D1; Thu, 22 Nov 2012 01:37:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AC9DDBE96; Thu, 22 Nov 2012 09:36:59 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUwx0OginRba; Thu, 22 Nov 2012 09:36:58 +0000 (GMT) Received: from [192.168.254.247] (55.28-78-194.adsl-static.isp.belgacom.be [194.78.28.55]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 613ACBE86; Thu, 22 Nov 2012 09:36:58 +0000 (GMT) Message-ID: <50ADF23A.8070905@cs.tcd.ie> Date: Thu, 22 Nov 2012 09:36:58 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Yoshifumi Nishida References: <20121113171931.620.96985.idtracker@ietfa.amsl.com> <50A52667.2000006@mti-systems.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: multipathtcp , IESG Subject: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) 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, 22 Nov 2012 09:37:32 -0000 (cc'ing iesg, since some other folks had similar concerns to mine) On 11/21/2012 11:25 PM, Yoshifumi Nishida wrote: > Hello Stephen, > > Thanks for the comments. > I would like to clarify some points. > >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> These ought be easy to resolve. If they're real issues, I'm >> fine with making them into comments that can be resolved by the >> chairs/AD or holding the discuss if that's better. If not, >> then I'll be glad I checked anyway:-) >> >> (1) Sorry if this is the wrong document for this comment, but >> it only occurred to me now to check, so maybe you can say if it >> applies and we can see what, if anything to do then. RFC 5246 >> section 7.2.1 says that once you've gotten a TLS close_notify >> then you close the TLS session, and also that each side is >> required to send a close_notify before closing the write side >> of a TCP connection. Does that mean we missed a security >> consideration in MPTCP that should have highlighted that there >> may be work to be done in a TLS implementation for it to run >> over MPTCP gracefully if one side wants to close some of the >> subflows? Or, is that something that should/could go in here >> where e.g. we say if using a basic or advanced API to implement >> TLS then don't do that? If something ought go in this draft >> then it'd probably be a good plan to check the text with the >> TLS wg before you're done. > > In basic API, application uses one socket to utilize MPTCP with > conventional APIs and doesn't know about if some of subflows are connected > or disconnected. There's no way to control subflows from the application > except closing all subflows, which indicates terminating the session. > So, in my understanding, we won't need to do anything for application when > some(but not all) of the subflows are disconnected/closed for some reasons. > When the socket is about to close, I think we'll need to do the same things > as what TLS over normal TCP does. But, this will be a generic guideline for > application, not specific to TLS. > Could you elaborate the concerns about TLS over MPTCP? Ah, that may be partly a misreading on my part, I missed that the TCP_MULTIPATH_SUBFLOWS was only a get and not a set option. So, in this case, it may be fine to just say that a TLS implementation on top of the basic API ought not close_notify just because the set of subflows has changed, and perhaps note that this could be more of an issue for the advanced API. I could buy an argument that this doesn't need to be stated, as it might open cans of worms since you're not saying how other existing applications make use of the basic API though. OTOH, it might still be worth including, since its a real case where someone might do the wrong thing otherwise. What do you think? > >> (2) In a similar vein, if TLS with an SNI with an IP address is >> being used (rfc6066 says you can't, but who knows what's done >> in the wild) and/or if a TLS certificate has IP addresses in >> the SAN, then should something special be done to handle that >> or could it cause an unexpected failure? Again, if text is >> needed it should probably be checked with the TLS wg. This may >> also affect TLS/MPTCP via a legacy API (not sure). > > The basic APIs utilize single IP address which is the IP address of first > subflow. > This might cause problems since there might be a situation where the IP > address is not accessible anymore while MPTCP is still running. > But, I'm not very sure if this will be a problem in this case. Could you > explain the cases where might cause failures? I can well imagine that different TLS/MPTCP implementations might react differently since there are different reasonable things one might do here, and that could break interop. At one end of the spectrum, an implementer might conclude that if IP addresses are in a TLS client or server cert then all addresses for all subflows MUST be mentioned. This might be called the 'strict' approach. At the other end, another implementer might conclude that if any IP address of any subflow is mentioned in the cert then its all ok. (Possibly even ignoring if that address is for the 1st subflow or not I guess.) This might be called the 'lax' approach. So, don't you need to say if 'strict' or 'lax' or something in between is right, because if you don't then TLS sessions between 'strict' and 'lax' implementations might fail depending on the content of the cert, which'd seem wrong to me. Cheers, S. > >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - Would it be useful to add a security consideration to the >> effect that applications may need to revisit some >> assumptions about the sockets API that could impact on >> security? Not sure what text precisely but I'd expect new >> buffer problems might be likely here in practice if the >> size of the return from getpeername() etc changes and >> not all calling code is aware that MPTCP is in use. > > As the basic APIs utilize single IP address, I think the size of the > returned parameters will be the same as conventional APIs. > So, I think there's at least no buffer problem here. > Could you let us know if there're other security implications? (BTW, 4.4.3 > describes some guidelines related to socket buffer size) > > Thanks, > -- > Yoshifumi Nishida > From michael.scharf@alcatel-lucent.com Sun Nov 25 14:57:12 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 E56A121F8686; Sun, 25 Nov 2012 14:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.028 X-Spam-Level: X-Spam-Status: No, score=-9.028 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_52=0.6, 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 rcEqLBCPfj1D; Sun, 25 Nov 2012 14:57:11 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id EB2D621F8500; Sun, 25 Nov 2012 14:57:10 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qAPMusLX021112 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 25 Nov 2012 23:56:57 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sun, 25 Nov 2012 23:56:54 +0100 From: "Scharf, Michael (Michael)" To: Yoshifumi Nishida , multipathtcp , Stephen Farrell Date: Sun, 25 Nov 2012 23:56:54 +0100 Thread-Topic: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) Thread-Index: Ac3IP5Bx6M2Q8BF6TImKnN53tWBOWADG9lZj Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B3@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <20121113171931.620.96985.idtracker@ietfa.amsl.com> <50A52667.2000006@mti-systems.com>, In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: multipart/alternative; boundary="_000_2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B3FRMRSSXCHMBSE_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "iesg@ietf.org" Subject: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) 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: Sun, 25 Nov 2012 22:57:13 -0000 --_000_2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B3FRMRSSXCHMBSE_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stephen, Yoshifumi, Please find some comments inline, marked by [MSC]. Thanks Michael ________________________________ Von: multipathtcp-bounces@ietf.org [multipathtcp-bounces@ietf.org] im Auftr= ag von Yoshifumi Nishida [nishida@sfc.wide.ad.jp] Gesendet: Donnerstag, 22. November 2012 00:25 An: multipathtcp; Stephen Farrell Betreff: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mp= tcp-api-06: (with DISCUSS and COMMENT) Hello Stephen, Thanks for the comments. I would like to clarify some points. > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > These ought be easy to resolve. If they're real issues, I'm > fine with making them into comments that can be resolved by the > chairs/AD or holding the discuss if that's better. If not, > then I'll be glad I checked anyway:-) > > (1) Sorry if this is the wrong document for this comment, but > it only occurred to me now to check, so maybe you can say if it > applies and we can see what, if anything to do then. RFC 5246 > section 7.2.1 says that once you've gotten a TLS close_notify > then you close the TLS session, and also that each side is > required to send a close_notify before closing the write side > of a TCP connection. Does that mean we missed a security > consideration in MPTCP that should have highlighted that there > may be work to be done in a TLS implementation for it to run > over MPTCP gracefully if one side wants to close some of the > subflows? Or, is that something that should/could go in here > where e.g. we say if using a basic or advanced API to implement > TLS then don't do that? If something ought go in this draft > then it'd probably be a good plan to check the text with the > TLS wg before you're done. In basic API, application uses one socket to utilize MPTCP with conventiona= l APIs and doesn't know about if some of subflows are connected or disconne= cted. There's no way to control subflows from the application except closin= g all subflows, which indicates terminating the session. So, in my understanding, we won't need to do anything for application when = some(but not all) of the subflows are disconnected/closed for some reasons. When the socket is about to close, I think we'll need to do the same things= as what TLS over normal TCP does. But, this will be a generic guideline fo= r application, not specific to TLS. Could you elaborate the concerns about TLS over MPTCP? [MSC] I am also struggling with understanding why TLS should have problems = with MPTCP (but, indeed, it is a fair question - I don't recall much discus= sion on TLS in the working group). First, I'd assume that TLS could be unde= rstood as a legacy application, without any additional API. If TLS sends a = "close()", the draft-ietf-mptcp-api-06 in section 4.3.1 states that the who= le MPTCP conncetion will be closed - same as for TCP. Thus, MPTCP and TCP s= hould behave in the same way. It is not clear to me why closing should ther= efore result a security issue for TLS. Apart from that, you raise an intere= sting question, namely whether and how TLS would use the basic API. I've no= t looked into TLS, but at first sight that would mainly make sense if TLS u= ses any of the more "advanced" socket calls already today. Any recommended = pointer on that? (But, it may be offtopic, see below.) > (2) In a similar vein, if TLS with an SNI with an IP address is > being used (rfc6066 says you can't, but who knows what's done > in the wild) and/or if a TLS certificate has IP addresses in > the SAN, then should something special be done to handle that > or could it cause an unexpected failure? Again, if text is > needed it should probably be checked with the TLS wg. This may > also affect TLS/MPTCP via a legacy API (not sure). The basic APIs utilize single IP address which is the IP address of first s= ubflow. This might cause problems since there might be a situation where the IP add= ress is not accessible anymore while MPTCP is still running. But, I'm not very sure if this will be a problem in this case. Could you ex= plain the cases where might cause failures? [MSC] Use of addresses in TLS certificates is an interesting question that = I have not been aware of. Thanks for raising this. But I am not sure if TLS= would actually want to care about subflow addresses. This would probably r= equire a own specification "TLS over MPTCP". If it requires changes in TLS,= it is probably not in scope of this document. And this actually contracts = the idea of MPTCP, which intends to keep subflow details transparent to wha= tever runs on top. My impression is that we should first sort out the case = that TLS is using the legacy API only, i. e., unware of MPTCP at all. I thi= nk that TLS could just continue to use the addresses of the first subflows = in certificates, because at the time of connection setup they are valid. I = am currently thinking whether TLS would require the use of 'fate-sharing', = i. e., that the MPTCP connection has to be closed if the first subflow dies= . This would ensure that the certificate's data is indeed valid during the = whole MPTCP connection. But 'fate-sharing' as a whole is an area that needs= further experiments. In summary, I think that we need a dedicated paragrap= h on TLS in the security considerations, but my current understanding is th= at TLS is not really affected when using the legacy API. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - Would it be useful to add a security consideration to the > effect that applications may need to revisit some > assumptions about the sockets API that could impact on > security? Not sure what text precisely but I'd expect new > buffer problems might be likely here in practice if the > size of the return from getpeername() etc changes and > not all calling code is aware that MPTCP is in use. As the basic APIs utilize single IP address, I think the size of the return= ed parameters will be the same as conventional APIs. So, I think there's at least no buffer problem here. Could you let us know if there're other security implications? (BTW, 4.4.3= describes some guidelines related to socket buffer size) [MSC] The data structures of the legacy API are the same, i. e., security s= hould not be affected. The basic API is defined only in an abstract way wit= hout data structures, i.e., we can not mandate any type checks etc. We can = certainly put a warning sign for implementors of the basic API. But it seem= s to me like a corner issue. Thanks, -- Yoshifumi Nishida --_000_2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B3FRMRSSXCHMBSE_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Stephen, Yoshifumi,
 
Please find some comments inline, marked by [MSC= ].
 
Thanks
 
Michael
 
=  
Von: multipathtcp= -bounces@ietf.org [multipathtcp-bounces@ietf.org] im Auftrag von Yoshifumi = Nishida [nishida@sfc.wide.ad.jp]
Gesendet: Donnerstag, 22. November 2012 00:25
An: multipathtcp; Stephen Farrell
Betreff: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-= ietf-mptcp-api-06: (with DISCUSS and COMMENT)

Hello Stephen,

Thanks for the comments.
I would like to clarify some points.

> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
>
> These ought be easy to resolve. If they're real issues, I'm
> fine with making them into comments that can be resolved by the
> chairs/AD or holding the discuss if that's better. If not,
> then I'll be glad I checked anyway:-)
>
> (1) Sorry if this is the wrong document for this comment, but
> it only occurred to me now to check, so maybe you can say if it
> applies and we can see what, if anything to do then. RFC 5246
> section 7.2.1 says that once you've gotten a TLS close_notify
> then you close the TLS session, and also that each side is
> required to send a close_notify before closing the write side
> of a TCP connection. Does that mean we missed a security
> consideration in MPTCP that should have highlighted that there
> may be work to be done in a TLS implementation for it to run
> over MPTCP gracefully if one side wants to close some of the
> subflows? Or, is that something that should/could go in here
> where e.g. we say if using a basic or advanced API to implement
> TLS then don't do that? If something ought go in this draft
> then it'd probably be a good plan to check the text with the
> TLS wg before you're done.

In basic API, application uses one socket to utilize MPTCP with conventiona= l APIs and doesn't know about if some of subflows are connected or disconne= cted. There's no way to control subflows from the application except closin= g all subflows, which indicates terminating the session.
So, in my understanding, we won't need to do anything for application when = some(but not all) of the subflows are disconnected/closed for some reasons.
When the socket is about to close, I think we'll need to do the same things= as what TLS over normal TCP does. But, this will be a generic guideline fo= r application, not specific to TLS.
Could you elaborate the concerns about TLS over MPTCP?

[MSC] I am also struggling with understanding why = TLS should have problems with MPTCP (but, indeed, it is a fair question - I= don't recall much discussion on TLS in the working group). First, I'd assu= me that TLS could be understood as a legacy application, without any additional API. If TLS sends a "clo= se()", the draft-ietf-mptcp-api-06 in section 4.3.1 states that the wh= ole MPTCP conncetion will be closed - same as for TCP. Thus, MPTCP and TCP = should behave in the same way. It is not clear to me why closing should therefore result a security issue for TLS. A= part from that, you raise an interesting question, namely whether and how T= LS would use the basic API. I've not looked into TLS, but at first sight th= at would mainly make sense if TLS uses any of the more "advanced" socket calls already today. Any recom= mended pointer on that? (But, it may be offtopic, see below.)


> (2) In a similar vein, if TLS with an SNI with an IP address is
> being used (rfc6066 says you can't, but who knows what's done
> in the wild) and/or if a TLS certificate has IP addresses in
> the SAN, then should something special be done to handle that
> or could it cause an unexpected failure?  Again, if text is
> needed it should probably be checked with the TLS wg. This may
> also affect TLS/MPTCP via a legacy API (not sure).

The basic APIs utilize single IP address which is the IP address of first s= ubflow.
This might cause problems since there might be a situation where the IP add= ress is not accessible anymore while MPTCP is still running.
But, I'm not very sure if this will be a problem in this case. Could you ex= plain the cases where might cause failures?

[MSC] Use of addresses in TLS certificates is an i= nteresting question that I have not been aware of. Thanks for rai= sing this. But I am not sure if TLS would actually want to care about = subflow addresses. This would probably require a own specification "TLS over MPTCP". If it requires changes in TL= S, it is probably not in scope of this document. And this actually con= tracts the idea of MPTCP, which intends to keep subflow details transparent= to whatever runs on top. My impression is that we should first sort out the case that TLS is using the legacy API only, i= . e., unware of MPTCP at all. I think that TLS could just continue to = use the addresses of the first subflows in certificates, because at the tim= e of connection setup they are valid. I am currently thinking whether TLS would require the use of 'fate-sh= aring', i. e., that the MPTCP connection has to be closed if the first subf= low dies. This would ensure that the certificate's data is indeed= valid during the whole MPTCP connection. But 'fate-sharing' as a whole is an area that needs further experiments. In summary, I think = that we need a dedicated paragraph on TLS in the security consideratio= ns, but my current understanding is that TLS is not really affected when us= ing the legacy API.


>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
>
> - Would it be useful to add a security consideration to the
> effect that applications may need to revisit some
> assumptions about the sockets API that could impact on
> security? Not sure what text precisely but I'd expect new
> buffer problems might be likely here in practice if the
> size of the return from getpeername() etc changes and
> not all calling code is aware that MPTCP is in use.

As the basic APIs utilize single IP address, I think the size of the return= ed parameters will be the same as conventional APIs.
So, I think there's at least no buffer problem here.
Could you let us know if there're other security implications?  (BTW, = 4.4.3 describes some guidelines related to socket buffer size)

[MSC] The data structures of the legacy API a= re the same, i. e., security should not be affected. The basic AP= I is defined only in an abstract way without data structures, i.e., we can = not mandate any type checks etc. We can certainly put a warning sign for implementors of the basic API. But it seems to me l= ike a corner issue.

 

 


Thanks,
--
Yoshifumi Nishida

--_000_2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B3FRMRSSXCHMBSE_-- From michael.scharf@alcatel-lucent.com Sun Nov 25 15:43:07 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 8830321F8692; Sun, 25 Nov 2012 15:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.629 X-Spam-Level: X-Spam-Status: No, score=-9.629 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 EMy3FMrP3+DV; Sun, 25 Nov 2012 15:43:06 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0C021F868F; Sun, 25 Nov 2012 15:43:05 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qAPNgxqQ025057 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 26 Nov 2012 00:42:59 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 26 Nov 2012 00:42:58 +0100 From: "Scharf, Michael (Michael)" To: Wesley Eddy , multipathtcp , Sean Turner Date: Mon, 26 Nov 2012 00:42:57 +0100 Thread-Topic: [multipathtcp] Fwd: Sean Turner's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) Thread-Index: Ac3DVwE589H34iufT1W1ml6QmbtybgICX2Ib Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B4@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <20121115160525.4910.71855.idtracker@ietfa.amsl.com>, <50A526AB.1060102@mti-systems.com> In-Reply-To: <50A526AB.1060102@mti-systems.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "iesg@ietf.org" Subject: Re: [multipathtcp] Fwd: Sean Turner's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) 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: Sun, 25 Nov 2012 23:43:07 -0000 Sean, =20 Thanks for your feedback! Please find some comments inline, marked by [MSC]= . =20 Michael ________________________________________ Von: multipathtcp-bounces@ietf.org [multipathtcp-bounces@ietf.org] im Auftr= ag von Wesley Eddy [wes@mti-systems.com] Gesendet: Donnerstag, 15. November 2012 18:30 An: multipathtcp; Sean Turner Betreff: [multipathtcp] Fwd: Sean Turner's Discuss on draft-ietf-mptcp-api-= 06: (with DISCUSS and COMMENT) -------- Original Message -------- Subject: Sean Turner's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) Date: Thu, 15 Nov 2012 08:05:25 -0800 From: Sean Turner To: The IESG CC: draft-ietf-mptcp-api@tools.ietf.org, mptcp-chairs@tools.ietf.org Sean Turner has entered the following ballot position for draft-ietf-mptcp-api-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 1) s3.2.*: I'm keying here on the multiple IP bit, so if I'm misunderstanding something just let me know: - There's got to be a logging/storage impact based on mptcp? If servers were tracking source IP addresses and now instead of one coming from a client there's two that means at least a double - right? [MSC] Valid point. We should mention that logging MPTCP results in differen= ces compared to TCP. Probably this is not only about storage. If a logging = wants to keep track of the subflow dynamics, it may even need several log e= ntries per connection. My suggestion would be to add a short paragraph on t= he logging implications of MPTCP. - There's protocols that include things like IP addresses in the received from header will it now need to include one for each subflow? [MSC] No, I don't think that an application will have to care of subflows a= t all. It can always refer to the addresses of the initial subflow and exch= ange them in an application protocol. This is the most reasonable behavior = as of now. If an application uses IP addresses in an application protocol, = the key question is whether 'fate-sharing' is required, as explained in the= document. This question requires further studies, as also stated in the dr= aft. In a draft revision, we could elaborate a bit more on how the use of I= P addresses in applications could interact with MPTCP. But given the potent= ial dynamics of subflows, this can become arbitrarily complex for an app. T= hus, my recommendation would be that apps should stay away from that as far= as possible. - If certificates are used by an application and the certificates include an IP address, how many need to be included in the certificate? Will the application know how many subflows are going to get started? It's going to have know which subflow to give which cert? [MSC] This question has also been raised in a similar way by Stephen (cf. m= y response there). I currently assume that certificates do hot have to chan= ge if the application uses the 'legacy API'. But it is a very valid questio= n and I'd be interested in further insights. If certificates have to change= , specifying that seems to be outside the scope of this document. Also, fee= dback from the MPTCP working group suggested that the basic API should not = contain a tight control of subflow management. Without that, an application= will not know in advance how many subflows will get started; this is left = for further study. In summary, I think that a legacy application will not a= nd does not have to care about these questions. But we probably have to exp= lain more explicitly that MPTCP-aware applications may need changes in the = application protocols running on top if they want indeed to handle subflow = addresses. 2) I echo Stephen's concerns wrt TLS. TLS explicitly discusses a DoS attack based on an attacker who initiates a large number of TCP connections (F.5 of RFC 5246). Are we now making lots of people potential attackers? Should some guidance on the # of connections to open be given? Also, isn't this worth a mention in the security considerations. [MSC] I am not sure if I fully understand how that attack works and how it = actually relates to MPTCP. In theory, MPTCP allows any number of subflows, = but their handling and authentication is handled internally in the MPTCP st= ack. I think subflows should be transparent to TLS (in legacy mode). For in= stance, MPTCP should determine itself whether a subflow is valid or not, be= fore TLS crypto gets involved. MPTCP has own internal security features for= that, in order to get a security level somehow similar to TCP. If MPTCP us= es crypto inside the stack, MPTCP can itself be attacked as described in F.= 5 of RFC 5246. However, this is independent of the API document, as far as = I can tell. Obviously, if TLS had to check whether a certificate exists for= each new subflow, this would result in a significant DoS issue. But this i= n fact yet another reason why TLS might want to stay away from caring about= MPTCP internals?=20 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) s3.1.1: The throughput assertion isn't always true -right? If you have one of the two links splitting what would have gone down one link go down then don't you have less than half the throughput of the original link - at least until the now combined subflow ramps back up? [MSC] I don't fully understand the scenario. It is clear that in the short-= term reaction to a network change the throughput can be worse, depending on= how the traffic is split, what the congestion control state is, etc. The s= hort-term dynamics of (MP)TCP are very complex. Furthermore, if the baselin= e TCP connection runs over the path that breaks, MPTCP will be tremendously= better than TCP ;) We could certainly mention dynamics more explicitly, bu= t long-term the text should be correct. 2) s3.1.1: Should you also point out that if all the subflows collapse in to one that the overhead actually lowers the throughput compared to regular TCP? [MSC] Yes, TCP option overhead reduces the throughput for a single subflow = compared to a TCP connection. This overhead depends on several paremeters, = but it should be small. Actually, this overhead is already explicitly menti= oned at the end of section 3.1.1. 3) s3.1.2: Wouldn't there also be a delay with the collapse of a subflow? [MSC] Again, yes, transport protocol dynamics can result in all kinds of sh= ort-term effects. But, imho, the order of magnitude should not be much diff= erent to what TCP does from time to time, e. g., if some packets get lost. = I think that these sections mainly talk on the macroscopic effects. We coul= d make this more explicit in the next version. _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp= From wes@mti-systems.com Sun Nov 25 17:57:29 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 A3F7C21F86A2 for ; Sun, 25 Nov 2012 17:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 NTPRlf0U6R6d for ; Sun, 25 Nov 2012 17:57:27 -0800 (PST) Received: from atl4mhob11.myregisteredsite.com (atl4mhob11.myregisteredsite.com [209.17.115.49]) by ietfa.amsl.com (Postfix) with ESMTP id 27F0A21F8661 for ; Sun, 25 Nov 2012 17:57:23 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob11.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAQ1vLak010214 for ; Sun, 25 Nov 2012 20:57:21 -0500 Received: (qmail 31198 invoked by uid 0); 26 Nov 2012 01:57:21 -0000 Received: from unknown (HELO ?192.168.1.112?) (wes@mti-systems.com@69.81.143.209) by 0 with ESMTPA; 26 Nov 2012 01:57:21 -0000 Message-ID: <50B2CC7F.1000404@mti-systems.com> Date: Sun, 25 Nov 2012 20:57:19 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Stephen Farrell References: <20121113171931.620.96985.idtracker@ietfa.amsl.com> <50A52667.2000006@mti-systems.com> <50ADF23A.8070905@cs.tcd.ie> In-Reply-To: <50ADF23A.8070905@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: multipathtcp , IESG Subject: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) 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, 26 Nov 2012 01:57:29 -0000 On 11/22/2012 4:36 AM, Stephen Farrell wrote: >> > >>> >> (2) In a similar vein, if TLS with an SNI with an IP address is >>> >> being used (rfc6066 says you can't, but who knows what's done >>> >> in the wild) and/or if a TLS certificate has IP addresses in >>> >> the SAN, then should something special be done to handle that >>> >> or could it cause an unexpected failure? Again, if text is >>> >> needed it should probably be checked with the TLS wg. This may >>> >> also affect TLS/MPTCP via a legacy API (not sure). >> > >> > The basic APIs utilize single IP address which is the IP address of first >> > subflow. >> > This might cause problems since there might be a situation where the IP >> > address is not accessible anymore while MPTCP is still running. >> > But, I'm not very sure if this will be a problem in this case. Could you >> > explain the cases where might cause failures? > I can well imagine that different TLS/MPTCP implementations > might react differently since there are different reasonable > things one might do here, and that could break interop. > > At one end of the spectrum, an implementer might conclude that > if IP addresses are in a TLS client or server cert then all > addresses for all subflows MUST be mentioned. This might be > called the 'strict' approach. > > At the other end, another implementer might conclude that > if any IP address of any subflow is mentioned in the cert > then its all ok. (Possibly even ignoring if that address is > for the 1st subflow or not I guess.) This might be called > the 'lax' approach. Doesn't what's "right" depend on the application (or TLS) and what policy it might want to enforce for address use? I would think that an MPTCP-aware TLS spec is out-of-scope for MPTCP to try to give guidance on, and that the TLS WG would maybe do that instead. TLS is an important upper layer to consider as an example, but I don't think we're going to fully specify or give guidance on particular upper layer protocols over MPTCP, beyond just saying what the default behavior is for legacy applications and what the API makes available to MPTCP-aware application code. -- Wes Eddy MTI Systems From stephen.farrell@cs.tcd.ie Sun Nov 25 18:09: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 22CAB21F862E; Sun, 25 Nov 2012 18:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.181 X-Spam-Level: X-Spam-Status: No, score=-98.181 tagged_above=-999 required=5 tests=[MIME_QP_LONG_LINE=1.819, 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 xEvPd19+swgI; Sun, 25 Nov 2012 18:09:34 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 257A621F86A3; Sun, 25 Nov 2012 18:09:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7221FBE25; Mon, 26 Nov 2012 02:09:09 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRUdcpLUHIg7; Mon, 26 Nov 2012 02:09:08 +0000 (GMT) Received: from [10.87.48.6] (unknown [86.44.68.23]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7142EBE1E; Mon, 26 Nov 2012 02:09:08 +0000 (GMT) References: <20121113171931.620.96985.idtracker@ietfa.amsl.com> <50A52667.2000006@mti-systems.com> <50ADF23A.8070905@cs.tcd.ie> <50B2CC7F.1000404@mti-systems.com> In-Reply-To: <50B2CC7F.1000404@mti-systems.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B206) From: Stephen Farrell Date: Mon, 26 Nov 2012 02:09:06 +0000 To: Wesley Eddy Cc: multipathtcp , IESG Subject: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) 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, 26 Nov 2012 02:09:35 -0000 Hi Wes=20 On 26 Nov 2012, at 01:57, Wesley Eddy wrote: > On 11/22/2012 4:36 AM, Stephen Farrell wrote: >>>>=20 >>>>>> (2) In a similar vein, if TLS with an SNI with an IP address is >>>>>> being used (rfc6066 says you can't, but who knows what's done >>>>>> in the wild) and/or if a TLS certificate has IP addresses in >>>>>> the SAN, then should something special be done to handle that >>>>>> or could it cause an unexpected failure? Again, if text is >>>>>> needed it should probably be checked with the TLS wg. This may >>>>>> also affect TLS/MPTCP via a legacy API (not sure). >>>>=20 >>>> The basic APIs utilize single IP address which is the IP address of fir= st >>>> subflow. >>>> This might cause problems since there might be a situation where the IP= >>>> address is not accessible anymore while MPTCP is still running. >>>> But, I'm not very sure if this will be a problem in this case. Could yo= u >>>> explain the cases where might cause failures? >> I can well imagine that different TLS/MPTCP implementations >> might react differently since there are different reasonable >> things one might do here, and that could break interop. >>=20 >> At one end of the spectrum, an implementer might conclude that >> if IP addresses are in a TLS client or server cert then all >> addresses for all subflows MUST be mentioned. This might be >> called the 'strict' approach. >>=20 >> At the other end, another implementer might conclude that >> if any IP address of any subflow is mentioned in the cert >> then its all ok. (Possibly even ignoring if that address is >> for the 1st subflow or not I guess.) This might be called >> the 'lax' approach. >=20 >=20 > Doesn't what's "right" depend on the application (or TLS) and > what policy it might want to enforce for address use? I would > think that an MPTCP-aware TLS spec is out-of-scope for MPTCP to > try to give guidance on, and that the TLS WG would maybe do that > instead. >=20 > TLS is an important upper layer to consider as an example, but > I don't think we're going to fully specify or give guidance on > particular upper layer protocols over MPTCP, beyond just saying > what the default behavior is for legacy applications and what > the API makes available to MPTCP-aware application code. >=20 Maybe you're right but I guess we don't want there to be N equally good non i= nteroperable ways to do TLS/MPTCP. Happy for that to not happen however is b= est. S > --=20 > Wes Eddy > MTI Systems >=20 From olivier.bonaventure@uclouvain.be Sun Nov 25 23:59:07 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 551E021F85B4; Sun, 25 Nov 2012 23:59:07 -0800 (PST) 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 j33bCf13a2Hj; Sun, 25 Nov 2012 23:59: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 D037121F8427; Sun, 25 Nov 2012 23:59:05 -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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id B874011F025; Mon, 26 Nov 2012 08:58:58 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be B874011F025 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1353916738; bh=fTsQuwjQRMdZluzX5Zq1wfEpgErGPAlClsqhouLTppI=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Gbe9xB3zOigWt3cG5gjw5rTc3BcUts2Ho7gvfMNN0hNXP0XXjVNHMpEckuFFFojSY csO7u0FtqSRNYTdIeLFUH10A42+On1NShOUSSZBmnDp78tuo0ePtZ8WUKjGZur1wuV 8UMBOJomaHNIMpkHDqAmd5eIkNd6ychQBp3x1Cws= Message-ID: <50B321EA.2060208@uclouvain.be> Date: Mon, 26 Nov 2012 09:01:46 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" References: <20121113171931.620.96985.idtracker@ietfa.amsl.com> <50A52667.2000006@mti-systems.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B3@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B3@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: B874011F025.A2FD0 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp , "iesg@ietf.org" , Stephen Farrell Subject: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 07:59:07 -0000 Hello, The current draft explains a basic MPTCP API whose purpose is to be as close as possible to the cassical socket API for applications. The current Linux implementation is already compatible with existing applications including those that are using TLS, but also skype and other more exotic applications. In the discussions, we have to decouple the basic MPTCP API that aims to be as close as possible to the socket API (and as a consequence hides most of MPTCP to the application) and a more advanced API that would expose additional information to the MPTCP-aware application. > > >> (2) In a similar vein, if TLS with an SNI with an IP address is >> being used (rfc6066 says you can't, but who knows what's done >> in the wild) and/or if a TLS certificate has IP addresses in >> the SAN, then should something special be done to handle that >> or could it cause an unexpected failure? Again, if text is >> needed it should probably be checked with the TLS wg. This may >> also affect TLS/MPTCP via a legacy API (not sure). > > The basic APIs utilize single IP address which is the IP address of > first subflow. > This might cause problems since there might be a situation where the IP > address is not accessible anymore while MPTCP is still running. > But, I'm not very sure if this will be a problem in this case. Could you > explain the cases where might cause failures? Hiding the changes to the IP addresses is a feature that MPTCP provides to the applications. If applications want to control this feature, this will require an advanced API. > [MSC] Use of addresses in TLS certificates is an interesting question > that I have not been aware of. Thanks for raising this. But I am not > sure if TLS would actually want to care about subflow addresses. I don't think that basic TLS should be concerned by this. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From michael.scharf@alcatel-lucent.com Mon Nov 26 01:56: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 A39E321F86AF; Mon, 26 Nov 2012 01:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 t2S+eV1GrWVj; Mon, 26 Nov 2012 01:56:28 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id C484C21F86AB; Mon, 26 Nov 2012 01:56:27 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qAQ9tlYo005677 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 26 Nov 2012 10:56:19 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Mon, 26 Nov 2012 10:56:00 +0100 From: "Scharf, Michael (Michael)" To: Stephen Farrell , Wesley Eddy Date: Mon, 26 Nov 2012 10:55:59 +0100 Thread-Topic: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) Thread-Index: Ac3Lexx6iNBIEOyrRSGQWwIStMaeoAAP9iMm Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B5@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <20121113171931.620.96985.idtracker@ietfa.amsl.com> <50A52667.2000006@mti-systems.com> <50ADF23A.8070905@cs.tcd.ie> <50B2CC7F.1000404@mti-systems.com>, In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: multipathtcp , IESG Subject: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) 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, 26 Nov 2012 09:56:28 -0000 Hi all, One comment inline ([MSC]). Thanks Michael ________________________________________ Von: multipathtcp-bounces@ietf.org [multipathtcp-bounces@ietf.org] im Auftr= ag von Stephen Farrell [stephen.farrell@cs.tcd.ie] Gesendet: Montag, 26. November 2012 03:09 An: Wesley Eddy Cc: multipathtcp; IESG Betreff: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-= mptcp-api-06: (with DISCUSS and COMMENT) [...] >> I can well imagine that different TLS/MPTCP implementations >> might react differently since there are different reasonable >> things one might do here, and that could break interop. >> >> At one end of the spectrum, an implementer might conclude that >> if IP addresses are in a TLS client or server cert then all >> addresses for all subflows MUST be mentioned. This might be >> called the 'strict' approach. >> >> At the other end, another implementer might conclude that >> if any IP address of any subflow is mentioned in the cert >> then its all ok. (Possibly even ignoring if that address is >> for the 1st subflow or not I guess.) This might be called >> the 'lax' approach. > > > Doesn't what's "right" depend on the application (or TLS) and > what policy it might want to enforce for address use? I would > think that an MPTCP-aware TLS spec is out-of-scope for MPTCP to > try to give guidance on, and that the TLS WG would maybe do that > instead. > > TLS is an important upper layer to consider as an example, but > I don't think we're going to fully specify or give guidance on > particular upper layer protocols over MPTCP, beyond just saying > what the default behavior is for legacy applications and what > the API makes available to MPTCP-aware application code. > Maybe you're right but I guess we don't want there to be N equally good non= interoperable ways to do TLS/MPTCP. Happy for that to not happen however i= s best. [MSC] I don't fully understand why different policies in the end system wou= ld not be interoperable. But, having said this, I think that there is an ad= ditional mechanism that helps here: If there is an IP address in a certific= ate, I'd assume that a server has to call bind() to this address, right? Ot= herwise, the TCP/IP stack is free to select any IP address and the certific= ate is less useful... However, if bind() with a specific address is used, t= he API document mandates that MPTCP must stick to this and never use other = addresses for subflows unless they are explicitly provided by the app (whic= h is not possible in legacy mode). In summary, if TLS uses a correct bind()= in legacy mode, is there anything left we have to care about?= From alanford@cisco.com Mon Nov 26 02:35:32 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 C62B921F842A; Mon, 26 Nov 2012 02:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 CweMhQdpDZPk; Mon, 26 Nov 2012 02:35:31 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8103E21F8425; Mon, 26 Nov 2012 02:35:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7862; q=dns/txt; s=iport; t=1353926131; x=1355135731; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=sb4TejmxBk7ufxe1J4d2ed9Dru/Pzg/swOhqs8A1+0Q=; b=Jwb+MTymZ5a4w4/Y4M5qOe+EbwDTZSaJjqtJGPojWE/siUOoNs7xLnaU xuzw53njjm9kPwAqqsloOdqnWoLFB8vnsrsiKxsTx764d+UT2/HBkX1hb OGuqylAwP3FHaiUmaqzff/lsiMKajXZ8FpI5Rh5Gw/bdKykDXXj1VMVho s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADVFs1CtJV2c/2dsb2JhbAA7CcAiFnOCHgEBAQQ6PxIBCBgKFAU9JQIEAQ0FCIgFvwCMNxIPgz9hA5JPk3aCb4FgHx4 X-IronPort-AV: E=McAfee;i="5400,1158,6907"; a="145897516" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 26 Nov 2012 10:35:31 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qAQAZUNL006550 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Nov 2012 10:35:30 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.130]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Mon, 26 Nov 2012 04:35:30 -0600 From: "Alan Ford (alanford)" To: "Scharf, Michael (Michael)" , "Wesley Eddy" , multipathtcp , Sean Turner Thread-Topic: [multipathtcp] Fwd: Sean Turner's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) Thread-Index: AQHNw1bvQoBXstKrFkyPxNrsNZP+hZf7qxiAgAC2ToA= Date: Mon, 26 Nov 2012 10:35:29 +0000 Message-ID: In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B4@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [10.147.93.127] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "iesg@ietf.org" Subject: Re: [multipathtcp] Fwd: Sean Turner's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) 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, 26 Nov 2012 10:35:32 -0000 Some further comments line.... Regards, Alan On 25/11/2012 23:42, "Scharf, Michael (Michael)" wrote: >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >1) s3.2.*: I'm keying here on the multiple IP bit, so if I'm >misunderstanding something just let me know: > >- There's got to be a logging/storage impact based on mptcp? If servers >were tracking source IP addresses and now instead of one coming from a >client there's two that means at least a double - right? > >[MSC] Valid point. We should mention that logging MPTCP results in >differences compared to TCP. Probably this is not only about storage. If >a logging wants to keep track of the subflow dynamics, it may even need >several log entries per connection. My suggestion would be to add a short >paragraph on the logging implications of MPTCP. > >- There's protocols that include things like IP addresses in the received >from header will it now need to include one for each subflow? > >[MSC] No, I don't think that an application will have to care of subflows >at all. It can always refer to the addresses of the initial subflow and >exchange them in an application protocol. This is the most reasonable >behavior as of now. If an application uses IP addresses in an application >protocol, the key question is whether 'fate-sharing' is required, as >explained in the document. This question requires further studies, as >also stated in the draft. In a draft revision, we could elaborate a bit >more on how the use of IP addresses in applications could interact with >MPTCP. But given the potential dynamics of subflows, this can become >arbitrarily complex for an app. Thus, my recommendation would be that >apps should stay away from that as far as possible. I think both this and the previous comment are pure application-level decisions. This document is specifying the API through which the relevant information can be acquired by an application. As well as the API content, this document is discussing application considerations. These are the kinds of things that an application certainly should consider - we should emphasise some of these fundamental "your higher layers might need to adapt to the presence of multiple addresses" in S3.2.2. > >- If certificates are used by an application and the certificates include >an IP address, how many need to be included in the certificate? Will the >application know how many subflows are going to get started? It's going >to have know which subflow to give which cert? > >[MSC] This question has also been raised in a similar way by Stephen (cf. >my response there). I currently assume that certificates do hot have to >change if the application uses the 'legacy API'. But it is a very valid >question and I'd be interested in further insights. If certificates have >to change, specifying that seems to be outside the scope of this >document. Also, feedback from the MPTCP working group suggested that the >basic API should not contain a tight control of subflow management. >Without that, an application will not know in advance how many subflows >will get started; this is left for further study. In summary, I think >that a legacy application will not and does not have to care about these >questions. But we probably have to explain more explicitly that >MPTCP-aware applications may need changes in the application protocols >running on top if they want indeed to handle subflow addresses. And again, this is essentially an application-layer decision. We are trying to present both a backwards-compatible API (with the same semantics as TCP) as well as the minimum extensions to acquire the additional information that provides completeness of the single-path semantics. The WG has had many long discussions about assumptions that can be made about IP addresses, and we reached the decision that once a MPTCP session is established with one particular IP address, that initial subflow provides an identity "anchor" for the remote host. If a user/system administrator does not trust this assumption, then the fate-sharing that we have mentioned in the document can be used. The upper layers (in this case, TLS) could use an extended API to find out additional IP addresses (and this would be a good use of Robert's suggested "push" API) and do its own analysis of the additional IP addresses. Maybe some X509 field could allow a certificate to have multiple IP address aliases listed. This kind of discussion is, however, out of scope for this API document. > >2) I echo Stephen's concerns wrt TLS. TLS explicitly discusses a DoS >attack based on an attacker who initiates a large number of TCP >connections (F.5 of RFC 5246). Are we now making lots of people >potential attackers? Should some guidance on the # of connections to >open be given? Also, isn't this worth a mention in the security >considerations. > >[MSC] I am not sure if I fully understand how that attack works and how >it actually relates to MPTCP. In theory, MPTCP allows any number of >subflows, but their handling and authentication is handled internally in >the MPTCP stack. I think subflows should be transparent to TLS (in legacy >mode). For instance, MPTCP should determine itself whether a subflow is >valid or not, before TLS crypto gets involved. MPTCP has own internal >security features for that, in order to get a security level somehow >similar to TCP. If MPTCP uses crypto inside the stack, MPTCP can itself >be attacked as described in F.5 of RFC 5246. However, this is independent >of the API document, as far as I can tell. Obviously, if TLS had to check >whether a certificate exists for each new subflow, this would result in a >significant DoS issue. But this in fact yet another reason why TLS might >want to stay away from caring about MPTCP internals? > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >1) s3.1.1: The throughput assertion isn't always true -right? If you have >one of the two links splitting what would have gone down one link go down >then don't you have less than half the throughput of the original link - >at least until the now combined subflow ramps back up? > >[MSC] I don't fully understand the scenario. It is clear that in the >short-term reaction to a network change the throughput can be worse, >depending on how the traffic is split, what the congestion control state >is, etc. The short-term dynamics of (MP)TCP are very complex. >Furthermore, if the baseline TCP connection runs over the path that >breaks, MPTCP will be tremendously better than TCP ;) We could certainly >mention dynamics more explicitly, but long-term the text should be >correct. > >2) s3.1.1: Should you also point out that if all the subflows collapse in >to one that the overhead actually lowers the throughput compared to >regular TCP? > >[MSC] Yes, TCP option overhead reduces the throughput for a single >subflow compared to a TCP connection. This overhead depends on several >paremeters, but it should be small. Actually, this overhead is already >explicitly mentioned at the end of section 3.1.1. > >3) s3.1.2: Wouldn't there also be a delay with the collapse of a subflow? > >[MSC] Again, yes, transport protocol dynamics can result in all kinds of >short-term effects. But, imho, the order of magnitude should not be much >different to what TCP does from time to time, e. g., if some packets get >lost. I think that these sections mainly talk on the macroscopic effects. >We could make this more explicit in the next version. From stephen.farrell@cs.tcd.ie Mon Nov 26 03:39:45 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 E94BE21F84DA; Mon, 26 Nov 2012 03:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_64=0.6, 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 QDdhZRxx8Vff; Mon, 26 Nov 2012 03:39:45 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0273F21F8482; Mon, 26 Nov 2012 03:39:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 60602BE3C; Mon, 26 Nov 2012 11:39:19 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AXvrk4+l+t3; Mon, 26 Nov 2012 11:39:18 +0000 (GMT) Received: from [IPv6:2001:770:10:203:898f:f0b5:218f:b6a5] (unknown [IPv6:2001:770:10:203:898f:f0b5:218f:b6a5]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EC5AEBE4D; Mon, 26 Nov 2012 11:39:17 +0000 (GMT) Message-ID: <50B354E6.30409@cs.tcd.ie> Date: Mon, 26 Nov 2012 11:39:18 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" References: <20121113171931.620.96985.idtracker@ietfa.amsl.com> <50A52667.2000006@mti-systems.com> <50ADF23A.8070905@cs.tcd.ie> <50B2CC7F.1000404@mti-systems.com>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B5@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B5@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: multipathtcp , IESG Subject: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) 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, 26 Nov 2012 11:39:46 -0000 Hiya, On 11/26/2012 09:55 AM, Scharf, Michael (Michael) wrote: > Hi all, > > One comment inline ([MSC]). > > Thanks > > Michael > > ________________________________________ > Von: multipathtcp-bounces@ietf.org [multipathtcp-bounces@ietf.org] im Auftrag von Stephen Farrell [stephen.farrell@cs.tcd.ie] > Gesendet: Montag, 26. November 2012 03:09 > An: Wesley Eddy > Cc: multipathtcp; IESG > Betreff: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) > > [...] > >>> I can well imagine that different TLS/MPTCP implementations >>> might react differently since there are different reasonable >>> things one might do here, and that could break interop. >>> >>> At one end of the spectrum, an implementer might conclude that >>> if IP addresses are in a TLS client or server cert then all >>> addresses for all subflows MUST be mentioned. This might be >>> called the 'strict' approach. >>> >>> At the other end, another implementer might conclude that >>> if any IP address of any subflow is mentioned in the cert >>> then its all ok. (Possibly even ignoring if that address is >>> for the 1st subflow or not I guess.) This might be called >>> the 'lax' approach. >> >> >> Doesn't what's "right" depend on the application (or TLS) and >> what policy it might want to enforce for address use? I would >> think that an MPTCP-aware TLS spec is out-of-scope for MPTCP to >> try to give guidance on, and that the TLS WG would maybe do that >> instead. >> >> TLS is an important upper layer to consider as an example, but >> I don't think we're going to fully specify or give guidance on >> particular upper layer protocols over MPTCP, beyond just saying >> what the default behavior is for legacy applications and what >> the API makes available to MPTCP-aware application code. >> > > Maybe you're right but I guess we don't want there to be N equally good non interoperable ways to do TLS/MPTCP. Happy for that to not happen however is best. > > [MSC] I don't fully understand why different policies in the end system would not be interoperable. But, having said this, I think that there is an additional mechanism that helps here: If there is an IP address in a certificate, I'd assume that a server has to call bind() to this address, right? Otherwise, the TCP/IP stack is free to select any IP address and the certificate is less useful... However, if bind() with a specific address is used, the API document mandates that MPTCP must stick to this and never use other addresses for subflows unless they are explicitly provided by the app (which is not possible in legacy mode). In summary, if TLS uses a correct bind() in legacy mode, is there anything left we have to care about? First, the "strict" and "lax" policies I mentioned before would not interoperate with some certificates and some subflows. If the strict side checks the set of addresses that are used after the first subflow, which the basic API allows, then it might see an address that doesn't match the other side's certificate and barf. I suspect that you're better off here saying that the TLS implementations using the basic API SHOULD|MUST NOT check 2nd and subsequent subflow addresses vs. certificates, and that's on the basis that MPTCP handles the security for relating the 1st and subsequent subflows. A consequence IMO is that MPTCP will need to have an option that makes it able to do as good a job as TLS for additional subflows, when we get to a standards-track version, so this isn't a free-lunch even if it is probably the easiest thing to do right now;-) Secondly, its a bit of a corner case, but TLS clients can also present certificates so everything here can happen on both sides. On bind() as a solution - I don't think you want that since it'd mean that TLS implementations couldn't make use of MPTCP (according to 4.2.1 of this draft) which'd be a bad outcome IMO. In any case, I do think that something needs to be stated here and this is not just an application layer thing. It might be properly called that from your perspective as developers of MTPCP, but people writing applications wouldn't agree I suspect since they tend to see TLS as a secure transport and often access it via sockets-like APIs. So all in all, I'd suggest the following: "Implementations of TLS [RFC5246] making use of the basic API that compare the addresses used by MPTCP against names or addresses present in X.509 certificates [RFC5280,RFC6125] MUST only consider the addresses used in the initial subflow since MPTCP itself handles the security of subsequent subflows. A need for finer-grained controls would imply a need to use an advanced API." But I also think that that needs to be checked with the TLS WG, just in case, once you MPTCP folk are happy with it. If you read rfc 6125 you'll see that there are a load of subtleties here, and even though 6125 is about names and not addresses, a lot of that is relevant to figuring out the right thing to do. S. From stephen.farrell@cs.tcd.ie Mon Nov 26 03:46: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 376ED21F8438; Mon, 26 Nov 2012 03:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=0.6, 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 ReCVK2zzMHDZ; Mon, 26 Nov 2012 03:46:04 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A687E21F8452; Mon, 26 Nov 2012 03:46:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 60A5ABE49; Mon, 26 Nov 2012 11:45:42 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mgch2jWC8OOk; Mon, 26 Nov 2012 11:45:41 +0000 (GMT) Received: from [IPv6:2001:770:10:203:898f:f0b5:218f:b6a5] (unknown [IPv6:2001:770:10:203:898f:f0b5:218f:b6a5]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 75037BE3C; Mon, 26 Nov 2012 11:45:41 +0000 (GMT) Message-ID: <50B35665.5040908@cs.tcd.ie> Date: Mon, 26 Nov 2012 11:45:41 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" References: <20121113171931.620.96985.idtracker@ietfa.amsl.com> <50A52667.2000006@mti-systems.com>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B3@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B3@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: multipathtcp , "iesg@ietf.org" Subject: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) 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, 26 Nov 2012 11:46:05 -0000 Hi, Just on the comment part of this... On 11/25/2012 10:56 PM, Scharf, Michael (Michael) wrote: >> ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > >> > - Would it be useful to add a security consideration to the >> > effect that applications may need to revisit some >> > assumptions about the sockets API that could impact on >> > security? Not sure what text precisely but I'd expect new >> > buffer problems might be likely here in practice if the >> > size of the return from getpeername() etc changes and >> > not all calling code is aware that MPTCP is in use. > As the basic APIs utilize single IP address, I think the size of the returned parameters will be the same as conventional APIs. > So, I think there's at least no buffer problem here. > Could you let us know if there're other security implications? (BTW, 4.4.3 describes some guidelines related to socket buffer size) > > [MSC] The data structures of the legacy API are the same, i. e., security should not be affected. The basic API is defined only in an abstract way without data structures, i.e., we can not mandate any type checks etc. We can certainly put a warning sign for implementors of the basic API. But it seems to me like a corner issue. The data structure is the same but the cardinality can now change with different calls as subflows change, and that's new, right? If so and some bit of code allocates enough space for the getpeername() return with the initial subflow, then some other bit of code might overrun that later with a struct copy from a later call to getpeername(). Yes, that'd be bad code. But it happens all the time still, and MPTCP creates a new way for it to happen, so I think it'd be good to mention that if I'm right that it can happen and is new. If I'm wrong and it can't happen or is not new, then I'd agree it doesn't need a mention. Cheers, S. From michael.scharf@alcatel-lucent.com Mon Nov 26 04:00:42 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 DFEFA21F844D; Mon, 26 Nov 2012 04:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.949 X-Spam-Level: X-Spam-Status: No, score=-7.949 tagged_above=-999 required=5 tests=[AWL=1.700, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_52=0.6, 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 V1ayYLP2q0Rq; Mon, 26 Nov 2012 04:00:42 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1472221F843D; Mon, 26 Nov 2012 04:00:41 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qAQBvTqr016137 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 26 Nov 2012 13:00:26 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 26 Nov 2012 12:59:29 +0100 From: "Scharf, Michael (Michael)" To: Stephen Farrell Date: Mon, 26 Nov 2012 12:59:27 +0100 Thread-Topic: AW: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) Thread-Index: Ac3Ly5SplRWuwHmtQXW2xeOigbVGDgAANHw1 Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B9@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <20121113171931.620.96985.idtracker@ietfa.amsl.com> <50A52667.2000006@mti-systems.com>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B3@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>, <50B35665.5040908@cs.tcd.ie> In-Reply-To: <50B35665.5040908@cs.tcd.ie> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: multipathtcp , "iesg@ietf.org" Subject: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) 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, 26 Nov 2012 12:00:43 -0000 Stephen, Maybe I miss something here, but our intention was that getpeername() alway= s returns exactly the same data. The statement in s4.2.2 is: This problem is addressed as follows: If used by a legacy application, the MPTCP stack MUST always return the addresses of the first subflow of an MPTCP connection, in all circumstances, even if that particular subflow is no longer in use. As a result, the app should not see any difference to TCP, as far as I can = tell. Specifically, the data structure sizes etc. are independent of the nu= mber of subflows, and memory allocation should continue to work as today. Right now, we have a MUST for legacy applications, and a SHOULD for MPTCP-a= ware applications, because it is for further study whether in future getpee= rname() could return something else if the stack knows that the app is MPTC= P-aware (e. g., by explicit enabling). I agree that in that case memory all= ocation is an issue if that should ever happen, and we could add this probl= em as an additional reason why even for MPTCP-aware applications the semant= ics of getpeername() should better not change. Thanks Michael ________________________________________ Von: Stephen Farrell [stephen.farrell@cs.tcd.ie] Gesendet: Montag, 26. November 2012 12:45 An: Scharf, Michael (Michael) Cc: Yoshifumi Nishida; multipathtcp; iesg@ietf.org Betreff: Re: AW: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-iet= f-mptcp-api-06: (with DISCUSS and COMMENT) Hi, Just on the comment part of this... On 11/25/2012 10:56 PM, Scharf, Michael (Michael) wrote: >> ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > >> > - Would it be useful to add a security consideration to the >> > effect that applications may need to revisit some >> > assumptions about the sockets API that could impact on >> > security? Not sure what text precisely but I'd expect new >> > buffer problems might be likely here in practice if the >> > size of the return from getpeername() etc changes and >> > not all calling code is aware that MPTCP is in use. > As the basic APIs utilize single IP address, I think the size of the retu= rned parameters will be the same as conventional APIs. > So, I think there's at least no buffer problem here. > Could you let us know if there're other security implications? (BTW, 4.4= .3 describes some guidelines related to socket buffer size) > > [MSC] The data structures of the legacy API are the same, i. e., security= should not be affected. The basic API is defined only in an abstract way w= ithout data structures, i.e., we can not mandate any type checks etc. We ca= n certainly put a warning sign for implementors of the basic API. But it se= ems to me like a corner issue. The data structure is the same but the cardinality can now change with different calls as subflows change, and that's new, right? If so and some bit of code allocates enough space for the getpeername() return with the initial subflow, then some other bit of code might overrun that later with a struct copy from a later call to getpeername(). Yes, that'd be bad code. But it happens all the time still, and MPTCP creates a new way for it to happen, so I think it'd be good to mention that if I'm right that it can happen and is new. If I'm wrong and it can't happen or is not new, then I'd agree it doesn't need a mention. Cheers, S. From stephen.farrell@cs.tcd.ie Mon Nov 26 04:08: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 79C8E21F8542; Mon, 26 Nov 2012 04:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=0.6, 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 cERVzbg-Ue2N; Mon, 26 Nov 2012 04:08:50 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7616621F8518; Mon, 26 Nov 2012 04:08:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6F7A5BE51; Mon, 26 Nov 2012 12:08:25 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07GXn7Brj-B6; Mon, 26 Nov 2012 12:08:24 +0000 (GMT) Received: from [IPv6:2001:770:10:203:898f:f0b5:218f:b6a5] (unknown [IPv6:2001:770:10:203:898f:f0b5:218f:b6a5]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 35169BE47; Mon, 26 Nov 2012 12:08:24 +0000 (GMT) Message-ID: <50B35BB8.9070209@cs.tcd.ie> Date: Mon, 26 Nov 2012 12:08:24 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" References: <20121113171931.620.96985.idtracker@ietfa.amsl.com> <50A52667.2000006@mti-systems.com>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B3@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>, <50B35665.5040908@cs.tcd.ie> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B9@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B9@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: multipathtcp , "iesg@ietf.org" Subject: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) 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, 26 Nov 2012 12:08:50 -0000 Hiya, Bear in mind this is a comment, so you can decide to just ignore this whenever you like and that's just fine. On 11/26/2012 11:59 AM, Scharf, Michael (Michael) wrote: > Stephen, > > Maybe I miss something here, but our intention was that getpeername() always returns exactly the same data. The statement in s4.2.2 is: > > This problem is addressed as follows: If used by a legacy > application, the MPTCP stack MUST always return the addresses of the > first subflow of an MPTCP connection, in all circumstances, even if > that particular subflow is no longer in use. > > As a result, the app should not see any difference to TCP, as far as I can tell. Specifically, the data structure sizes etc. are independent of the number of subflows, and memory allocation should continue to work as today. > > Right now, we have a MUST for legacy applications, and a SHOULD for MPTCP-aware applications, because it is for further study whether in future getpeername() could return something else if the stack knows that the app is MPTCP-aware (e. g., by explicit enabling). I agree that in that case memory allocation is an issue if that should ever happen, and we could add this problem as an additional reason why even for MPTCP-aware applications the semantics of getpeername() should better not change. I'm not trying to argue about the semantics of the API here at all, just wondering if some warning text would be useful. The kind of warning we're talking about would really be there in the (possibly forlorn) hope that someone implementing the MPTCP API would pass that on to folks using the API via some kind of documentation. If an existing application gets ported to the new MPTCP basic API, then some of its code will change, but maybe not all and if this draft said "watch out - your memory management assumptions might be changed by using the basic API" then that might just help someone. So, that's all I'm suggesting. getpeername() is just one possible example - you might be able to find a much better one. Cheers, S. > Thanks > > Michael > > ________________________________________ > Von: Stephen Farrell [stephen.farrell@cs.tcd.ie] > Gesendet: Montag, 26. November 2012 12:45 > An: Scharf, Michael (Michael) > Cc: Yoshifumi Nishida; multipathtcp; iesg@ietf.org > Betreff: Re: AW: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) > > Hi, > > Just on the comment part of this... > > On 11/25/2012 10:56 PM, Scharf, Michael (Michael) wrote: >>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> - Would it be useful to add a security consideration to the >>>> effect that applications may need to revisit some >>>> assumptions about the sockets API that could impact on >>>> security? Not sure what text precisely but I'd expect new >>>> buffer problems might be likely here in practice if the >>>> size of the return from getpeername() etc changes and >>>> not all calling code is aware that MPTCP is in use. >> As the basic APIs utilize single IP address, I think the size of the returned parameters will be the same as conventional APIs. >> So, I think there's at least no buffer problem here. >> Could you let us know if there're other security implications? (BTW, 4.4.3 describes some guidelines related to socket buffer size) >> >> [MSC] The data structures of the legacy API are the same, i. e., security should not be affected. The basic API is defined only in an abstract way without data structures, i.e., we can not mandate any type checks etc. We can certainly put a warning sign for implementors of the basic API. But it seems to me like a corner issue. > > The data structure is the same but the cardinality can > now change with different calls as subflows change, and > that's new, right? > > If so and some bit of code allocates enough space for the > getpeername() return with the initial subflow, then some > other bit of code might overrun that later with a > struct copy from a later call to getpeername(). > > Yes, that'd be bad code. But it happens all the time > still, and MPTCP creates a new way for it to happen, so > I think it'd be good to mention that if I'm right that > it can happen and is new. If I'm wrong and it can't > happen or is not new, then I'd agree it doesn't need > a mention. > > Cheers, > S. > From dwing@cisco.com Tue Nov 27 09:25:38 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 E7E9821F84C5; Tue, 27 Nov 2012 09:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-8, 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 wI+wzAf+tZXk; Tue, 27 Nov 2012 09:25:38 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2B54621F8452; Tue, 27 Nov 2012 09:25:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6822; q=dns/txt; s=iport; t=1354037138; x=1355246738; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=FyJ1+24YagVYJJCenwivvKuT+o/On0hSvdlP7EGt0G0=; b=jfaFkh25NTp9u/otKxd4si6iZOc4IjWuk8Sqm1kikSCpapqNrkY6D+lA 1WA0bPyAP/JaLQoYk8p+H6WtCR9ykG1bBm9yMn/1YOi6nh7w2uFNABF8V TxPqNKZ1ACmR3nFGc4ysvtt2vWrO+YbsgIBzjF84Y2iVP4dhd9p2f37VM o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFADn3tFCrRDoG/2dsb2JhbABFrX6SIIEJgh4BAQEDAQgCMBEBLQUHAQMCCRECAgEBASMEBxkMIQkIAgQTCwULh2wFsDyCBAGORow6AYRAA4hehRqICZBEgxGBQQcCFw X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="61935133" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 27 Nov 2012 17:25:35 +0000 Received: from DWINGWS01 ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qARHPYFm027483; Tue, 27 Nov 2012 17:25:34 GMT From: "Dan Wing" To: "'Stephen Farrell'" , "'Scharf, Michael \(Michael\)'" References: <20121113171931.620.96985.idtracker@ietfa.amsl.com> <50A52667.2000006@mti-systems.com> <50ADF23A.8070905@cs.tcd.ie> <50B2CC7F.1000404@mti-systems.com>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B5@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50B354E6.30409@cs.tcd.ie> In-Reply-To: <50B354E6.30409@cs.tcd.ie> Date: Tue, 27 Nov 2012 09:25:34 -0800 Message-ID: <0b0e01cdccc4$35b086b0$a1119410$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKdrXZvwaMRQdcr5wSOuBFVddXznwE5HIf7AwgDw4cCDaeXsQINp3vSAWRV5RwCYXjbMgGwT9iRle+XciA= Content-Language: en-us Cc: 'multipathtcp' , 'IESG' Subject: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) 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, 27 Nov 2012 17:25:39 -0000 > -----Original Message----- > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp- > bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: Monday, November 26, 2012 3:39 AM > To: Scharf, Michael (Michael) > Cc: multipathtcp; IESG > Subject: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft- > ietf-mptcp-api-06: (with DISCUSS and COMMENT) > > > Hiya, > > On 11/26/2012 09:55 AM, Scharf, Michael (Michael) wrote: > > Hi all, > > > > One comment inline ([MSC]). > > > > Thanks > > > > Michael > > > > ________________________________________ > > Von: multipathtcp-bounces@ietf.org [multipathtcp-bounces@ietf.org] im > > Auftrag von Stephen Farrell [stephen.farrell@cs.tcd.ie] > > Gesendet: Montag, 26. November 2012 03:09 > > An: Wesley Eddy > > Cc: multipathtcp; IESG > > Betreff: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft- > ietf-mptcp-api-06: (with DISCUSS and COMMENT) > > > > [...] > > > >>> I can well imagine that different TLS/MPTCP implementations might > >>> react differently since there are different reasonable things one > >>> might do here, and that could break interop. > >>> > >>> At one end of the spectrum, an implementer might conclude that if IP > >>> addresses are in a TLS client or server cert then all addresses for > >>> all subflows MUST be mentioned. This might be called the 'strict' > >>> approach. > >>> > >>> At the other end, another implementer might conclude that if any IP > >>> address of any subflow is mentioned in the cert then its all ok. > >>> (Possibly even ignoring if that address is for the 1st subflow or > >>> not I guess.) This might be called the 'lax' approach. > >> > >> > >> Doesn't what's "right" depend on the application (or TLS) and what > >> policy it might want to enforce for address use? I would think that > >> an MPTCP-aware TLS spec is out-of-scope for MPTCP to try to give > >> guidance on, and that the TLS WG would maybe do that instead. > >> > >> TLS is an important upper layer to consider as an example, but I > >> don't think we're going to fully specify or give guidance on > >> particular upper layer protocols over MPTCP, beyond just saying what > >> the default behavior is for legacy applications and what the API > >> makes available to MPTCP-aware application code. > >> > > > > Maybe you're right but I guess we don't want there to be N equally > good non interoperable ways to do TLS/MPTCP. Happy for that to not > happen however is best. > > > > [MSC] I don't fully understand why different policies in the end > system would not be interoperable. But, having said this, I think that > there is an additional mechanism that helps here: If there is an IP > address in a certificate, I'd assume that a server has to call bind() to > this address, right? Otherwise, the TCP/IP stack is free to select any > IP address and the certificate is less useful... However, if bind() with > a specific address is used, the API document mandates that MPTCP must > stick to this and never use other addresses for subflows unless they are > explicitly provided by the app (which is not possible in legacy mode). > In summary, if TLS uses a correct bind() in legacy mode, is there > anything left we have to care about? > > First, the "strict" and "lax" policies I mentioned before would not > interoperate with some certificates and some subflows. If the strict > side checks the set of addresses that are used after the first subflow, > which the basic API allows, then it might see an address that doesn't > match the other side's certificate and barf. > > I suspect that you're better off here saying that the TLS > implementations using the basic API SHOULD|MUST NOT check 2nd and > subsequent subflow addresses vs. certificates, Agreed. > and that's on the basis > that MPTCP handles the security for relating the 1st and subsequent > subflows. But security is not solely reliant on MPTCP; TLS also handles the security for the subsequent flows. > A consequence IMO is that MPTCP will need to have an option > that makes it able to do as good a job as TLS for additional subflows, > when we get to a standards-track version, so this isn't a free-lunch > even if it is probably the easiest thing to do right now;-) Let's generalize this problem a little but putting TLS aside for a moment, and consider how MPTCP would work with HTTP, specifically with a URL containing an IPv4 address literal, let's say http://192.0.2.1. When accessing that URL, the TCP stack will initially connect to 192.0.2.1 and the HTTP header will contain "Host: 192.0.2.1". MPTCP might bring up a separate flow, to a different IP address, let's say 192.0.2.2. MPTCP does not expect HTTP to send a new request, nor expect HTTP to react to the flow going over 192.0.2.2. This is because HTTP is an application and is generally unaware that MPTCP brought up a separate flow to 192.0.2.2. If you are saying TLS needs special handling for this case, would not HTTP also need special handling for that same case, and so would any other application protocol running over TCP that exchanges IP address literals or exchanges FQDN where the FQDN might not resolve to the IP addresses used by MPTCP? > Secondly, its a bit of a corner case, but TLS clients can also present > certificates so everything here can happen on both sides. > > On bind() as a solution - I don't think you want that since it'd mean > that TLS implementations couldn't make use of MPTCP (according to 4.2.1 > of this draft) which'd be a bad outcome IMO. > > In any case, I do think that something needs to be stated here and this > is not just an application layer thing. It might be properly called that > from your perspective as developers of MTPCP, but people writing > applications wouldn't agree I suspect since they tend to see TLS as a > secure transport and often access it via sockets-like APIs. > > So all in all, I'd suggest the following: > > "Implementations of TLS [RFC5246] making use of the basic API that > compare the addresses used by MPTCP against names or addresses present > in X.509 certificates [RFC5280,RFC6125] MUST only consider the addresses > used in the initial subflow since MPTCP itself handles the security of > subsequent subflows. A need for finer-grained controls would imply a > need to use an advanced API." Seems reasonable to me. > But I also think that that needs to be checked with the TLS WG, just in > case, once you MPTCP folk are happy with it. If you read rfc 6125 you'll > see that there are a load of subtleties here, and even though 6125 is > about names and not addresses, a lot of that is relevant to figuring out > the right thing to do. -d From stephen.farrell@cs.tcd.ie Tue Nov 27 11:16: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 638B621F85C0; Tue, 27 Nov 2012 11:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, NORMAL_HTTP_TO_IP=0.001, 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 40+5UB8m2558; Tue, 27 Nov 2012 11:16:16 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 397B621F85AB; Tue, 27 Nov 2012 11:16:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 01436BE62; Tue, 27 Nov 2012 19:15:53 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKNd+bGoSHQk; Tue, 27 Nov 2012 19:15:51 +0000 (GMT) Received: from [10.87.48.10] (unknown [86.46.27.45]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EA1C7BE58; Tue, 27 Nov 2012 19:15:50 +0000 (GMT) Message-ID: <50B51166.7020301@cs.tcd.ie> Date: Tue, 27 Nov 2012 19:15:50 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Dan Wing References: <20121113171931.620.96985.idtracker@ietfa.amsl.com> <50A52667.2000006@mti-systems.com> <50ADF23A.8070905@cs.tcd.ie> <50B2CC7F.1000404@mti-systems.com>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B5@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50B354E6.30409@cs.tcd.ie> <0b0e01cdccc4$35b086b0$a1119410$@cisco.com> In-Reply-To: <0b0e01cdccc4$35b086b0$a1119410$@cisco.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'multipathtcp' , 'IESG' Subject: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) 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, 27 Nov 2012 19:16:17 -0000 Hi Dan, On 11/27/2012 05:25 PM, Dan Wing wrote: >> -----Original Message----- >> From: multipathtcp-bounces@ietf.org [mailto:multipathtcp- >> bounces@ietf.org] On Behalf Of Stephen Farrell >> Sent: Monday, November 26, 2012 3:39 AM >> To: Scharf, Michael (Michael) >> Cc: multipathtcp; IESG >> Subject: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft- >> ietf-mptcp-api-06: (with DISCUSS and COMMENT) >> >> >> Hiya, >> >> On 11/26/2012 09:55 AM, Scharf, Michael (Michael) wrote: >>> Hi all, >>> >>> One comment inline ([MSC]). >>> >>> Thanks >>> >>> Michael >>> >>> ________________________________________ >>> Von: multipathtcp-bounces@ietf.org [multipathtcp-bounces@ietf.org] im >>> Auftrag von Stephen Farrell [stephen.farrell@cs.tcd.ie] >>> Gesendet: Montag, 26. November 2012 03:09 >>> An: Wesley Eddy >>> Cc: multipathtcp; IESG >>> Betreff: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft- >> ietf-mptcp-api-06: (with DISCUSS and COMMENT) >>> >>> [...] >>> >>>>> I can well imagine that different TLS/MPTCP implementations might >>>>> react differently since there are different reasonable things one >>>>> might do here, and that could break interop. >>>>> >>>>> At one end of the spectrum, an implementer might conclude that if IP >>>>> addresses are in a TLS client or server cert then all addresses for >>>>> all subflows MUST be mentioned. This might be called the 'strict' >>>>> approach. >>>>> >>>>> At the other end, another implementer might conclude that if any IP >>>>> address of any subflow is mentioned in the cert then its all ok. >>>>> (Possibly even ignoring if that address is for the 1st subflow or >>>>> not I guess.) This might be called the 'lax' approach. >>>> >>>> >>>> Doesn't what's "right" depend on the application (or TLS) and what >>>> policy it might want to enforce for address use? I would think that >>>> an MPTCP-aware TLS spec is out-of-scope for MPTCP to try to give >>>> guidance on, and that the TLS WG would maybe do that instead. >>>> >>>> TLS is an important upper layer to consider as an example, but I >>>> don't think we're going to fully specify or give guidance on >>>> particular upper layer protocols over MPTCP, beyond just saying what >>>> the default behavior is for legacy applications and what the API >>>> makes available to MPTCP-aware application code. >>>> >>> >>> Maybe you're right but I guess we don't want there to be N equally >> good non interoperable ways to do TLS/MPTCP. Happy for that to not >> happen however is best. >>> >>> [MSC] I don't fully understand why different policies in the end >> system would not be interoperable. But, having said this, I think that >> there is an additional mechanism that helps here: If there is an IP >> address in a certificate, I'd assume that a server has to call bind() to >> this address, right? Otherwise, the TCP/IP stack is free to select any >> IP address and the certificate is less useful... However, if bind() with >> a specific address is used, the API document mandates that MPTCP must >> stick to this and never use other addresses for subflows unless they are >> explicitly provided by the app (which is not possible in legacy mode). >> In summary, if TLS uses a correct bind() in legacy mode, is there >> anything left we have to care about? >> >> First, the "strict" and "lax" policies I mentioned before would not >> interoperate with some certificates and some subflows. If the strict >> side checks the set of addresses that are used after the first subflow, >> which the basic API allows, then it might see an address that doesn't >> match the other side's certificate and barf. >> >> I suspect that you're better off here saying that the TLS >> implementations using the basic API SHOULD|MUST NOT check 2nd and >> subsequent subflow addresses vs. certificates, > > Agreed. > >> and that's on the basis >> that MPTCP handles the security for relating the 1st and subsequent >> subflows. > > But security is not solely reliant on MPTCP; TLS also handles the > security for the subsequent flows. Sure. > >> A consequence IMO is that MPTCP will need to have an option >> that makes it able to do as good a job as TLS for additional subflows, >> when we get to a standards-track version, so this isn't a free-lunch >> even if it is probably the easiest thing to do right now;-) Lemme correct my text above a bit. With my suggested handling of addresses in public key certs, a standards-track MPTCP will need to do a good enough job in associating subflows so that it does not create any new security issues for TLS. > > Let's generalize this problem a little but putting TLS aside for a moment, > and consider how MPTCP would work with HTTP, specifically with a URL > containing an IPv4 address literal, let's say http://192.0.2.1. When > accessing that URL, the TCP stack will initially connect to 192.0.2.1 > and the HTTP header will contain "Host: 192.0.2.1". > > MPTCP might bring up a separate flow, to a different IP address, > let's say 192.0.2.2. > > MPTCP does not expect HTTP to send a new request, nor expect HTTP to > react to the flow going over 192.0.2.2. This is because HTTP is > an application and is generally unaware that MPTCP brought up a > separate flow to 192.0.2.2. > > If you are saying TLS needs special handling for this case, would > not HTTP also need special handling for that same case, and so > would any other application protocol running over TCP that exchanges > IP address literals or exchanges FQDN where the FQDN might not > resolve to the IP addresses used by MPTCP? My concern is e.g. that if MPTCP security were not ok, then that might create new MITM problems for TLS. I don't think this is a hard thing to avoid though, but it is a hard thing to check that you've avoided. >> Secondly, its a bit of a corner case, but TLS clients can also present >> certificates so everything here can happen on both sides. >> >> On bind() as a solution - I don't think you want that since it'd mean >> that TLS implementations couldn't make use of MPTCP (according to 4.2.1 >> of this draft) which'd be a bad outcome IMO. >> >> In any case, I do think that something needs to be stated here and this >> is not just an application layer thing. It might be properly called that >> from your perspective as developers of MTPCP, but people writing >> applications wouldn't agree I suspect since they tend to see TLS as a >> secure transport and often access it via sockets-like APIs. >> >> So all in all, I'd suggest the following: >> >> "Implementations of TLS [RFC5246] making use of the basic API that >> compare the addresses used by MPTCP against names or addresses present >> in X.509 certificates [RFC5280,RFC6125] MUST only consider the addresses >> used in the initial subflow since MPTCP itself handles the security of >> subsequent subflows. A need for finer-grained controls would imply a >> need to use an advanced API." > > Seems reasonable to me. Ok. I already updated my discuss to say that. Sean's gonna send that to the TLS WG to give 'em a chance to check it. S > >> But I also think that that needs to be checked with the TLS WG, just in >> case, once you MPTCP folk are happy with it. If you read rfc 6125 you'll >> see that there are a load of subtleties here, and even though 6125 is >> about names and not addresses, a lot of that is relevant to figuring out >> the right thing to do. > > -d > > From turners@ieca.com Tue Nov 27 12:32:51 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 9E3C721F87ED for ; Tue, 27 Nov 2012 12:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.953 X-Spam-Level: X-Spam-Status: No, score=-101.953 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6, NORMAL_HTTP_TO_IP=0.001, 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 rr67+OGW7xjW for ; Tue, 27 Nov 2012 12:32:50 -0800 (PST) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [67.18.80.19]) by ietfa.amsl.com (Postfix) with ESMTP id 054BB21F85CC for ; Tue, 27 Nov 2012 12:32:39 -0800 (PST) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id F26F8918DC13E; Tue, 27 Nov 2012 14:32:38 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id DF970918DC0BC for ; Tue, 27 Nov 2012 14:32:38 -0600 (CST) Received: from [108.45.19.185] (port=56556 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TdRpe-0005fT-Bj; Tue, 27 Nov 2012 14:32:38 -0600 Message-ID: <50B52365.30503@ieca.com> Date: Tue, 27 Nov 2012 15:32:37 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Stephen Farrell References: <20121113171931.620.96985.idtracker@ietfa.amsl.com> <50A52667.2000006@mti-systems.com> <50ADF23A.8070905@cs.tcd.ie> <50B2CC7F.1000404@mti-systems.com>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B5@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50B354E6.30409@cs.tcd.ie> <0b0e01cdccc4$35b086b0$a1119410$@cisco.com> <50B51166.7020301@cs.tcd.ie> In-Reply-To: <50B51166.7020301@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.19.185]:56556 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: 'multipathtcp' , 'IESG' Subject: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) 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, 27 Nov 2012 20:32:51 -0000 On 11/27/12 2:15 PM, Stephen Farrell wrote: > > Hi Dan, > > On 11/27/2012 05:25 PM, Dan Wing wrote: >>> -----Original Message----- >>> From: multipathtcp-bounces@ietf.org [mailto:multipathtcp- >>> bounces@ietf.org] On Behalf Of Stephen Farrell >>> Sent: Monday, November 26, 2012 3:39 AM >>> To: Scharf, Michael (Michael) >>> Cc: multipathtcp; IESG >>> Subject: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft- >>> ietf-mptcp-api-06: (with DISCUSS and COMMENT) >>> >>> >>> Hiya, >>> >>> On 11/26/2012 09:55 AM, Scharf, Michael (Michael) wrote: >>>> Hi all, >>>> >>>> One comment inline ([MSC]). >>>> >>>> Thanks >>>> >>>> Michael >>>> >>>> ________________________________________ >>>> Von: multipathtcp-bounces@ietf.org [multipathtcp-bounces@ietf.org] im >>>> Auftrag von Stephen Farrell [stephen.farrell@cs.tcd.ie] >>>> Gesendet: Montag, 26. November 2012 03:09 >>>> An: Wesley Eddy >>>> Cc: multipathtcp; IESG >>>> Betreff: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft- >>> ietf-mptcp-api-06: (with DISCUSS and COMMENT) >>>> >>>> [...] >>>> >>>>>> I can well imagine that different TLS/MPTCP implementations might >>>>>> react differently since there are different reasonable things one >>>>>> might do here, and that could break interop. >>>>>> >>>>>> At one end of the spectrum, an implementer might conclude that if IP >>>>>> addresses are in a TLS client or server cert then all addresses for >>>>>> all subflows MUST be mentioned. This might be called the 'strict' >>>>>> approach. >>>>>> >>>>>> At the other end, another implementer might conclude that if any IP >>>>>> address of any subflow is mentioned in the cert then its all ok. >>>>>> (Possibly even ignoring if that address is for the 1st subflow or >>>>>> not I guess.) This might be called the 'lax' approach. >>>>> >>>>> >>>>> Doesn't what's "right" depend on the application (or TLS) and what >>>>> policy it might want to enforce for address use? I would think that >>>>> an MPTCP-aware TLS spec is out-of-scope for MPTCP to try to give >>>>> guidance on, and that the TLS WG would maybe do that instead. >>>>> >>>>> TLS is an important upper layer to consider as an example, but I >>>>> don't think we're going to fully specify or give guidance on >>>>> particular upper layer protocols over MPTCP, beyond just saying what >>>>> the default behavior is for legacy applications and what the API >>>>> makes available to MPTCP-aware application code. >>>>> >>>> >>>> Maybe you're right but I guess we don't want there to be N equally >>> good non interoperable ways to do TLS/MPTCP. Happy for that to not >>> happen however is best. >>>> >>>> [MSC] I don't fully understand why different policies in the end >>> system would not be interoperable. But, having said this, I think that >>> there is an additional mechanism that helps here: If there is an IP >>> address in a certificate, I'd assume that a server has to call bind() to >>> this address, right? Otherwise, the TCP/IP stack is free to select any >>> IP address and the certificate is less useful... However, if bind() with >>> a specific address is used, the API document mandates that MPTCP must >>> stick to this and never use other addresses for subflows unless they are >>> explicitly provided by the app (which is not possible in legacy mode). >>> In summary, if TLS uses a correct bind() in legacy mode, is there >>> anything left we have to care about? >>> >>> First, the "strict" and "lax" policies I mentioned before would not >>> interoperate with some certificates and some subflows. If the strict >>> side checks the set of addresses that are used after the first subflow, >>> which the basic API allows, then it might see an address that doesn't >>> match the other side's certificate and barf. >>> >>> I suspect that you're better off here saying that the TLS >>> implementations using the basic API SHOULD|MUST NOT check 2nd and >>> subsequent subflow addresses vs. certificates, >> >> Agreed. >> >>> and that's on the basis >>> that MPTCP handles the security for relating the 1st and subsequent >>> subflows. >> >> But security is not solely reliant on MPTCP; TLS also handles the >> security for the subsequent flows. > > Sure. > >> >>> A consequence IMO is that MPTCP will need to have an option >>> that makes it able to do as good a job as TLS for additional subflows, >>> when we get to a standards-track version, so this isn't a free-lunch >>> even if it is probably the easiest thing to do right now;-) > > Lemme correct my text above a bit. With my suggested handling of > addresses in public key certs, a standards-track MPTCP will need > to do a good enough job in associating subflows so that it does > not create any new security issues for TLS. > >> >> Let's generalize this problem a little but putting TLS aside for a moment, >> and consider how MPTCP would work with HTTP, specifically with a URL >> containing an IPv4 address literal, let's say http://192.0.2.1. When >> accessing that URL, the TCP stack will initially connect to 192.0.2.1 >> and the HTTP header will contain "Host: 192.0.2.1". >> >> MPTCP might bring up a separate flow, to a different IP address, >> let's say 192.0.2.2. >> >> MPTCP does not expect HTTP to send a new request, nor expect HTTP to >> react to the flow going over 192.0.2.2. This is because HTTP is >> an application and is generally unaware that MPTCP brought up a >> separate flow to 192.0.2.2. >> >> If you are saying TLS needs special handling for this case, would >> not HTTP also need special handling for that same case, and so >> would any other application protocol running over TCP that exchanges >> IP address literals or exchanges FQDN where the FQDN might not >> resolve to the IP addresses used by MPTCP? > > My concern is e.g. that if MPTCP security were not ok, then that > might create new MITM problems for TLS. > > I don't think this is a hard thing to avoid though, but it is a > hard thing to check that you've avoided. > >>> Secondly, its a bit of a corner case, but TLS clients can also present >>> certificates so everything here can happen on both sides. >>> >>> On bind() as a solution - I don't think you want that since it'd mean >>> that TLS implementations couldn't make use of MPTCP (according to 4.2.1 >>> of this draft) which'd be a bad outcome IMO. >>> >>> In any case, I do think that something needs to be stated here and this >>> is not just an application layer thing. It might be properly called that >>> from your perspective as developers of MTPCP, but people writing >>> applications wouldn't agree I suspect since they tend to see TLS as a >>> secure transport and often access it via sockets-like APIs. >>> >>> So all in all, I'd suggest the following: >>> >>> "Implementations of TLS [RFC5246] making use of the basic API that >>> compare the addresses used by MPTCP against names or addresses present >>> in X.509 certificates [RFC5280,RFC6125] MUST only consider the addresses >>> used in the initial subflow since MPTCP itself handles the security of >>> subsequent subflows. A need for finer-grained controls would imply a >>> need to use an advanced API." >> >> Seems reasonable to me. > > Ok. I already updated my discuss to say that. Sean's gonna send that > to the TLS WG to give 'em a chance to check it. FYI - already sent spt From stephen.farrell@cs.tcd.ie Wed Nov 28 07:33:42 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 2005721F8855; Wed, 28 Nov 2012 07:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, NORMAL_HTTP_TO_IP=0.001, 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 lgAt8XNAf3Zx; Wed, 28 Nov 2012 07:33:40 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 24B0D21F88C2; Wed, 28 Nov 2012 07:33:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 89BFCBE62; Wed, 28 Nov 2012 15:33:17 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rz6P9YijW2rx; Wed, 28 Nov 2012 15:33:12 +0000 (GMT) Received: from [IPv6:2001:770:10:203:9999:53ef:87e7:8281] (unknown [IPv6:2001:770:10:203:9999:53ef:87e7:8281]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 76DE2BE4D; Wed, 28 Nov 2012 15:33:12 +0000 (GMT) Message-ID: <50B62EB8.5020301@cs.tcd.ie> Date: Wed, 28 Nov 2012 15:33:12 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Dan Wing References: <20121113171931.620.96985.idtracker@ietfa.amsl.com> <50A52667.2000006@mti-systems.com> <50ADF23A.8070905@cs.tcd.ie> <50B2CC7F.1000404@mti-systems.com>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B5@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50B354E6.30409@cs.tcd.ie> <0b0e01cdccc4$35b086b0$a1119410$@cisco.com> In-Reply-To: <0b0e01cdccc4$35b086b0$a1119410$@cisco.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'multipathtcp' , 'IESG' Subject: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) 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, 28 Nov 2012 15:33:42 -0000 Hi Dan, I'm really sorry about this, but in the process of asking the TLS wg about the suggested, I belated recalled that RFC 5280 has name constraints which can be expressed as IP addresses and can specify excluded subtrees, so its possible for a cert to say: "this is not for <> IP address(es)". I really doubt anyone cares about or uses this, since I don't think its actually used, but it might mean that we need to re-think the lax vs strict thing. Or at least explain that being lax means you might do what the CA considers the wrong thing. Sorry again for not coming up with this earlier, Cheers, S. PS: Yes, I'm an author of 5280 so I really have no good excuse for not remembering it;-) On 11/27/2012 05:25 PM, Dan Wing wrote: >> -----Original Message----- >> From: multipathtcp-bounces@ietf.org [mailto:multipathtcp- >> bounces@ietf.org] On Behalf Of Stephen Farrell >> Sent: Monday, November 26, 2012 3:39 AM >> To: Scharf, Michael (Michael) >> Cc: multipathtcp; IESG >> Subject: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft- >> ietf-mptcp-api-06: (with DISCUSS and COMMENT) >> >> >> Hiya, >> >> On 11/26/2012 09:55 AM, Scharf, Michael (Michael) wrote: >>> Hi all, >>> >>> One comment inline ([MSC]). >>> >>> Thanks >>> >>> Michael >>> >>> ________________________________________ >>> Von: multipathtcp-bounces@ietf.org [multipathtcp-bounces@ietf.org] im >>> Auftrag von Stephen Farrell [stephen.farrell@cs.tcd.ie] >>> Gesendet: Montag, 26. November 2012 03:09 >>> An: Wesley Eddy >>> Cc: multipathtcp; IESG >>> Betreff: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft- >> ietf-mptcp-api-06: (with DISCUSS and COMMENT) >>> >>> [...] >>> >>>>> I can well imagine that different TLS/MPTCP implementations might >>>>> react differently since there are different reasonable things one >>>>> might do here, and that could break interop. >>>>> >>>>> At one end of the spectrum, an implementer might conclude that if IP >>>>> addresses are in a TLS client or server cert then all addresses for >>>>> all subflows MUST be mentioned. This might be called the 'strict' >>>>> approach. >>>>> >>>>> At the other end, another implementer might conclude that if any IP >>>>> address of any subflow is mentioned in the cert then its all ok. >>>>> (Possibly even ignoring if that address is for the 1st subflow or >>>>> not I guess.) This might be called the 'lax' approach. >>>> >>>> >>>> Doesn't what's "right" depend on the application (or TLS) and what >>>> policy it might want to enforce for address use? I would think that >>>> an MPTCP-aware TLS spec is out-of-scope for MPTCP to try to give >>>> guidance on, and that the TLS WG would maybe do that instead. >>>> >>>> TLS is an important upper layer to consider as an example, but I >>>> don't think we're going to fully specify or give guidance on >>>> particular upper layer protocols over MPTCP, beyond just saying what >>>> the default behavior is for legacy applications and what the API >>>> makes available to MPTCP-aware application code. >>>> >>> >>> Maybe you're right but I guess we don't want there to be N equally >> good non interoperable ways to do TLS/MPTCP. Happy for that to not >> happen however is best. >>> >>> [MSC] I don't fully understand why different policies in the end >> system would not be interoperable. But, having said this, I think that >> there is an additional mechanism that helps here: If there is an IP >> address in a certificate, I'd assume that a server has to call bind() to >> this address, right? Otherwise, the TCP/IP stack is free to select any >> IP address and the certificate is less useful... However, if bind() with >> a specific address is used, the API document mandates that MPTCP must >> stick to this and never use other addresses for subflows unless they are >> explicitly provided by the app (which is not possible in legacy mode). >> In summary, if TLS uses a correct bind() in legacy mode, is there >> anything left we have to care about? >> >> First, the "strict" and "lax" policies I mentioned before would not >> interoperate with some certificates and some subflows. If the strict >> side checks the set of addresses that are used after the first subflow, >> which the basic API allows, then it might see an address that doesn't >> match the other side's certificate and barf. >> >> I suspect that you're better off here saying that the TLS >> implementations using the basic API SHOULD|MUST NOT check 2nd and >> subsequent subflow addresses vs. certificates, > > Agreed. > >> and that's on the basis >> that MPTCP handles the security for relating the 1st and subsequent >> subflows. > > But security is not solely reliant on MPTCP; TLS also handles the > security for the subsequent flows. > >> A consequence IMO is that MPTCP will need to have an option >> that makes it able to do as good a job as TLS for additional subflows, >> when we get to a standards-track version, so this isn't a free-lunch >> even if it is probably the easiest thing to do right now;-) > > Let's generalize this problem a little but putting TLS aside for a moment, > and consider how MPTCP would work with HTTP, specifically with a URL > containing an IPv4 address literal, let's say http://192.0.2.1. When > accessing that URL, the TCP stack will initially connect to 192.0.2.1 > and the HTTP header will contain "Host: 192.0.2.1". > > MPTCP might bring up a separate flow, to a different IP address, > let's say 192.0.2.2. > > MPTCP does not expect HTTP to send a new request, nor expect HTTP to > react to the flow going over 192.0.2.2. This is because HTTP is > an application and is generally unaware that MPTCP brought up a > separate flow to 192.0.2.2. > > If you are saying TLS needs special handling for this case, would > not HTTP also need special handling for that same case, and so > would any other application protocol running over TCP that exchanges > IP address literals or exchanges FQDN where the FQDN might not > resolve to the IP addresses used by MPTCP? > > >> Secondly, its a bit of a corner case, but TLS clients can also present >> certificates so everything here can happen on both sides. >> >> On bind() as a solution - I don't think you want that since it'd mean >> that TLS implementations couldn't make use of MPTCP (according to 4.2.1 >> of this draft) which'd be a bad outcome IMO. >> >> In any case, I do think that something needs to be stated here and this >> is not just an application layer thing. It might be properly called that >> from your perspective as developers of MTPCP, but people writing >> applications wouldn't agree I suspect since they tend to see TLS as a >> secure transport and often access it via sockets-like APIs. >> >> So all in all, I'd suggest the following: >> >> "Implementations of TLS [RFC5246] making use of the basic API that >> compare the addresses used by MPTCP against names or addresses present >> in X.509 certificates [RFC5280,RFC6125] MUST only consider the addresses >> used in the initial subflow since MPTCP itself handles the security of >> subsequent subflows. A need for finer-grained controls would imply a >> need to use an advanced API." > > Seems reasonable to me. > >> But I also think that that needs to be checked with the TLS WG, just in >> case, once you MPTCP folk are happy with it. If you read rfc 6125 you'll >> see that there are a load of subtleties here, and even though 6125 is >> about names and not addresses, a lot of that is relevant to figuring out >> the right thing to do. > > -d > > From dwing@cisco.com Wed Nov 28 07:56:41 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 A1EB421F88EB; Wed, 28 Nov 2012 07:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.498 X-Spam-Level: X-Spam-Status: No, score=-110.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-8, 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 XQ561tzIXZT4; Wed, 28 Nov 2012 07:56:39 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 81FCF21F88E8; Wed, 28 Nov 2012 07:56:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3672; q=dns/txt; s=iport; t=1354118199; x=1355327799; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=amlwpoGsk8v7SDXvKuPaK6ZBETZr8rakPlskzMpu3Zs=; b=LpgRopO00GxLMEdh/UufW5QbVB/48+2xM0tbMvUEiHz80LRdsUUw2YCU Oqun/f35oas47xDuHJN6FlnJSNYetAi19czTHPzhR4Ib3QK2VVq7cfNB7 yI2gUGx8+C++Ex1m5aEAEKz8k88r1ReR2KE82u9E7JVLw0yJ0j2j/2ug7 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFADUztlCrRDoG/2dsb2JhbABFrX+SFhZzgh4BAQEDAQgCMBEBLQUIAwIJEygLGQwyAgQeBQuHbgWwXgGONoxAhEADiF6FGogJkESDEYFCBwIX X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="65125189" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 28 Nov 2012 15:56:36 +0000 Received: from DWINGWS01 ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qASFuYSt020332; Wed, 28 Nov 2012 15:56:34 GMT From: "Dan Wing" To: "'Stephen Farrell'" References: <20121113171931.620.96985.idtracker@ietfa.amsl.com> <50A52667.2000006@mti-systems.com> <50ADF23A.8070905@cs.tcd.ie> <50B2CC7F.1000404@mti-systems.com>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B5@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50B354E6.30409@cs.tcd.ie> <0b0e01cdccc4$35b086b0$a1119410$@cisco.com> <50B51166.7020301@cs.tcd.ie> In-Reply-To: <50B51166.7020301@cs.tcd.ie> Date: Wed, 28 Nov 2012 07:56:32 -0800 Message-ID: <0c8401cdcd80$f06807f0$d13817d0$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKdrXZvwaMRQdcr5wSOuBFVddXznwE5HIf7AwgDw4cCDaeXsQINp3vSAWRV5RwCYXjbMgGwT9iRAL/3cJ0CtwrxOJXVWEow Content-Language: en-us Cc: 'multipathtcp' , 'IESG' Subject: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) 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, 28 Nov 2012 15:56:41 -0000 > >> A consequence IMO is that MPTCP will need to have an option that > >> makes it able to do as good a job as TLS for additional subflows, > >> when we get to a standards-track version, so this isn't a free-lunch > >> even if it is probably the easiest thing to do right now;-) > > Lemme correct my text above a bit. With my suggested handling of > addresses in public key certs, a standards-track MPTCP will need to do a > good enough job in associating subflows so that it does not create any > new security issues for TLS. Thanks for that clarification. > > Let's generalize this problem a little but putting TLS aside for a > > moment, and consider how MPTCP would work with HTTP, specifically with > > a URL containing an IPv4 address literal, let's say http://192.0.2.1. > > When accessing that URL, the TCP stack will initially connect to > > 192.0.2.1 and the HTTP header will contain "Host: 192.0.2.1". > > > > MPTCP might bring up a separate flow, to a different IP address, let's > > say 192.0.2.2. > > > > MPTCP does not expect HTTP to send a new request, nor expect HTTP to > > react to the flow going over 192.0.2.2. This is because HTTP is an > > application and is generally unaware that MPTCP brought up a separate > > flow to 192.0.2.2. > > > > If you are saying TLS needs special handling for this case, would not > > HTTP also need special handling for that same case, and so would any > > other application protocol running over TCP that exchanges IP address > > literals or exchanges FQDN where the FQDN might not resolve to the IP > > addresses used by MPTCP? > > My concern is e.g. that if MPTCP security were not ok, then that might > create new MITM problems for TLS. I expect everyone agrees we do not want new attacks against TLS. > I don't think this is a hard thing to avoid though, but it is a hard > thing to check that you've avoided. -d > >> Secondly, its a bit of a corner case, but TLS clients can also > >> present certificates so everything here can happen on both sides. > >> > >> On bind() as a solution - I don't think you want that since it'd mean > >> that TLS implementations couldn't make use of MPTCP (according to > >> 4.2.1 of this draft) which'd be a bad outcome IMO. > >> > >> In any case, I do think that something needs to be stated here and > >> this is not just an application layer thing. It might be properly > >> called that from your perspective as developers of MTPCP, but people > >> writing applications wouldn't agree I suspect since they tend to see > >> TLS as a secure transport and often access it via sockets-like APIs. > >> > >> So all in all, I'd suggest the following: > >> > >> "Implementations of TLS [RFC5246] making use of the basic API that > >> compare the addresses used by MPTCP against names or addresses > >> present in X.509 certificates [RFC5280,RFC6125] MUST only consider > >> the addresses used in the initial subflow since MPTCP itself handles > >> the security of subsequent subflows. A need for finer-grained > >> controls would imply a need to use an advanced API." > > > > Seems reasonable to me. > > Ok. I already updated my discuss to say that. Sean's gonna send that to > the TLS WG to give 'em a chance to check it. > > S > > > > >> But I also think that that needs to be checked with the TLS WG, just > >> in case, once you MPTCP folk are happy with it. If you read rfc 6125 > >> you'll see that there are a load of subtleties here, and even though > >> 6125 is about names and not addresses, a lot of that is relevant to > >> figuring out the right thing to do. > > > > -d > > > > From stephen.farrell@cs.tcd.ie Wed Nov 28 15:37:24 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 C49BA21F881A; Wed, 28 Nov 2012 15:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, NORMAL_HTTP_TO_IP=0.001, 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 aW1k6jNnzZVb; Wed, 28 Nov 2012 15:37:23 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9502A21F880C; Wed, 28 Nov 2012 15:37:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B0F4EBE5C; Wed, 28 Nov 2012 23:37:01 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uUNCl6aOn2S; Wed, 28 Nov 2012 23:36:59 +0000 (GMT) Received: from [10.87.48.10] (unknown [86.44.77.127]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BCFC8BE4D; Wed, 28 Nov 2012 23:36:59 +0000 (GMT) Message-ID: <50B6A01B.5080703@cs.tcd.ie> Date: Wed, 28 Nov 2012 23:36:59 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Dan Wing References: <20121113171931.620.96985.idtracker@ietfa.amsl.com> <50A52667.2000006@mti-systems.com> <50ADF23A.8070905@cs.tcd.ie> <50B2CC7F.1000404@mti-systems.com>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B5@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50B354E6.30409@cs.tcd.ie> <0b0e01cdccc4$35b086b0$a1119410$@cisco.com> <50B62EB8.5020301@cs.tcd.ie> In-Reply-To: <50B62EB8.5020301@cs.tcd.ie> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'multipathtcp' , 'IESG' Subject: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT) 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, 28 Nov 2012 23:37:24 -0000 Update on that. I think we can get away with saying that if you care about excludedSubtrees then you need to use the advanced API. I can't figure how to make it work with the basic API at all but that's ok since nobody does excludedSubtrees that I know. I'll give the TLS WG another day or so and then propose some text if nobody else comes up with any new points. Cheers, S. On 11/28/2012 03:33 PM, Stephen Farrell wrote: > > Hi Dan, > > I'm really sorry about this, but in the process of asking > the TLS wg about the suggested, I belated recalled that > RFC 5280 has name constraints which can be expressed as > IP addresses and can specify excluded subtrees, so its > possible for a cert to say: > > "this is not for <> IP address(es)". > > I really doubt anyone cares about or uses this, since > I don't think its actually used, but it might mean > that we need to re-think the lax vs strict thing. > Or at least explain that being lax means you might > do what the CA considers the wrong thing. > > Sorry again for not coming up with this earlier, > Cheers, > S. > > PS: Yes, I'm an author of 5280 so I really have no > good excuse for not remembering it;-) > > On 11/27/2012 05:25 PM, Dan Wing wrote: >>> -----Original Message----- >>> From: multipathtcp-bounces@ietf.org [mailto:multipathtcp- >>> bounces@ietf.org] On Behalf Of Stephen Farrell >>> Sent: Monday, November 26, 2012 3:39 AM >>> To: Scharf, Michael (Michael) >>> Cc: multipathtcp; IESG >>> Subject: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft- >>> ietf-mptcp-api-06: (with DISCUSS and COMMENT) >>> >>> >>> Hiya, >>> >>> On 11/26/2012 09:55 AM, Scharf, Michael (Michael) wrote: >>>> Hi all, >>>> >>>> One comment inline ([MSC]). >>>> >>>> Thanks >>>> >>>> Michael >>>> >>>> ________________________________________ >>>> Von: multipathtcp-bounces@ietf.org [multipathtcp-bounces@ietf.org] im >>>> Auftrag von Stephen Farrell [stephen.farrell@cs.tcd.ie] >>>> Gesendet: Montag, 26. November 2012 03:09 >>>> An: Wesley Eddy >>>> Cc: multipathtcp; IESG >>>> Betreff: Re: [multipathtcp] Fwd: Stephen Farrell's Discuss on draft- >>> ietf-mptcp-api-06: (with DISCUSS and COMMENT) >>>> >>>> [...] >>>> >>>>>> I can well imagine that different TLS/MPTCP implementations might >>>>>> react differently since there are different reasonable things one >>>>>> might do here, and that could break interop. >>>>>> >>>>>> At one end of the spectrum, an implementer might conclude that if IP >>>>>> addresses are in a TLS client or server cert then all addresses for >>>>>> all subflows MUST be mentioned. This might be called the 'strict' >>>>>> approach. >>>>>> >>>>>> At the other end, another implementer might conclude that if any IP >>>>>> address of any subflow is mentioned in the cert then its all ok. >>>>>> (Possibly even ignoring if that address is for the 1st subflow or >>>>>> not I guess.) This might be called the 'lax' approach. >>>>> >>>>> >>>>> Doesn't what's "right" depend on the application (or TLS) and what >>>>> policy it might want to enforce for address use? I would think that >>>>> an MPTCP-aware TLS spec is out-of-scope for MPTCP to try to give >>>>> guidance on, and that the TLS WG would maybe do that instead. >>>>> >>>>> TLS is an important upper layer to consider as an example, but I >>>>> don't think we're going to fully specify or give guidance on >>>>> particular upper layer protocols over MPTCP, beyond just saying what >>>>> the default behavior is for legacy applications and what the API >>>>> makes available to MPTCP-aware application code. >>>>> >>>> >>>> Maybe you're right but I guess we don't want there to be N equally >>> good non interoperable ways to do TLS/MPTCP. Happy for that to not >>> happen however is best. >>>> >>>> [MSC] I don't fully understand why different policies in the end >>> system would not be interoperable. But, having said this, I think that >>> there is an additional mechanism that helps here: If there is an IP >>> address in a certificate, I'd assume that a server has to call bind() to >>> this address, right? Otherwise, the TCP/IP stack is free to select any >>> IP address and the certificate is less useful... However, if bind() with >>> a specific address is used, the API document mandates that MPTCP must >>> stick to this and never use other addresses for subflows unless they are >>> explicitly provided by the app (which is not possible in legacy mode). >>> In summary, if TLS uses a correct bind() in legacy mode, is there >>> anything left we have to care about? >>> >>> First, the "strict" and "lax" policies I mentioned before would not >>> interoperate with some certificates and some subflows. If the strict >>> side checks the set of addresses that are used after the first subflow, >>> which the basic API allows, then it might see an address that doesn't >>> match the other side's certificate and barf. >>> >>> I suspect that you're better off here saying that the TLS >>> implementations using the basic API SHOULD|MUST NOT check 2nd and >>> subsequent subflow addresses vs. certificates, >> >> Agreed. >> >>> and that's on the basis >>> that MPTCP handles the security for relating the 1st and subsequent >>> subflows. >> >> But security is not solely reliant on MPTCP; TLS also handles the >> security for the subsequent flows. >> >>> A consequence IMO is that MPTCP will need to have an option >>> that makes it able to do as good a job as TLS for additional subflows, >>> when we get to a standards-track version, so this isn't a free-lunch >>> even if it is probably the easiest thing to do right now;-) >> >> Let's generalize this problem a little but putting TLS aside for a moment, >> and consider how MPTCP would work with HTTP, specifically with a URL >> containing an IPv4 address literal, let's say http://192.0.2.1. When >> accessing that URL, the TCP stack will initially connect to 192.0.2.1 >> and the HTTP header will contain "Host: 192.0.2.1". >> >> MPTCP might bring up a separate flow, to a different IP address, >> let's say 192.0.2.2. >> >> MPTCP does not expect HTTP to send a new request, nor expect HTTP to >> react to the flow going over 192.0.2.2. This is because HTTP is >> an application and is generally unaware that MPTCP brought up a >> separate flow to 192.0.2.2. >> >> If you are saying TLS needs special handling for this case, would >> not HTTP also need special handling for that same case, and so >> would any other application protocol running over TCP that exchanges >> IP address literals or exchanges FQDN where the FQDN might not >> resolve to the IP addresses used by MPTCP? >> >> >>> Secondly, its a bit of a corner case, but TLS clients can also present >>> certificates so everything here can happen on both sides. >>> >>> On bind() as a solution - I don't think you want that since it'd mean >>> that TLS implementations couldn't make use of MPTCP (according to 4.2.1 >>> of this draft) which'd be a bad outcome IMO. >>> >>> In any case, I do think that something needs to be stated here and this >>> is not just an application layer thing. It might be properly called that >>> from your perspective as developers of MTPCP, but people writing >>> applications wouldn't agree I suspect since they tend to see TLS as a >>> secure transport and often access it via sockets-like APIs. >>> >>> So all in all, I'd suggest the following: >>> >>> "Implementations of TLS [RFC5246] making use of the basic API that >>> compare the addresses used by MPTCP against names or addresses present >>> in X.509 certificates [RFC5280,RFC6125] MUST only consider the addresses >>> used in the initial subflow since MPTCP itself handles the security of >>> subsequent subflows. A need for finer-grained controls would imply a >>> need to use an advanced API." >> >> Seems reasonable to me. >> >>> But I also think that that needs to be checked with the TLS WG, just in >>> case, once you MPTCP folk are happy with it. If you read rfc 6125 you'll >>> see that there are a load of subtleties here, and even though 6125 is >>> about names and not addresses, a lot of that is relevant to figuring out >>> the right thing to do. >> >> -d >> >>