Hi All,

Short question: Is it possible to have different MPTCP schedulers in the cl= ient and in the server that could lead to asymmetric use of uplink and down= link resources? E.g. the client could send most uplink data on path#1 while= the server could send most downlink data on path#2.

Thanks,

Apostolis

---

Motorola Mobility UK Ltd.

S= ystem Design Group - Wireless Systems Research and Standardization
Registered Office: Redwood, Crockford Lane, Chineham Business Park, Basings= toke, RG24 8WQ
Reg. No: 6969556 =C2=A0- England
VAT No. GB984328092Limited Liability Company=C2=A0

--089e010d7efca7b02904f2db6ad0-- From nobody Fri Feb 21 00:28:46 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6098D1A0006 for ; Fri, 21 Feb 2014 00:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.463 X-Spam-Level: * X-Spam-Status: No, score=1.463 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPEa-zXBr14w for ; Fri, 21 Feb 2014 00:28:43 -0800 (PST) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id F2A5D1A04E1 for ; Fri, 21 Feb 2014 00:28:42 -0800 (PST) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id C1AEB27821D for ; Fri, 21 Feb 2014 17:28:37 +0900 (JST) Received: by mail-lb0-f176.google.com with SMTP id w7so2107750lbi.35 for ; Fri, 21 Feb 2014 00:28:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:content-type; bh=TF85U2nqY0jFCtUge3lSwWUUeFY9ZDRGO5J+SlZd+9M=; b=jiK0iSacpzVxAI0HceGW1lhevfrWb7aZBDAzIdvmlPVq+gz3liPfykFgcctPZNGbnU WxRRcNofUGV1d6YlDM7u/AdKoqTdgR5fmb3MnhdQPPP8s6Znk133B4HggYnpyKps74D0 bQsj1DsX+rzajdk9+ZN4OAvc3O9QkX00WniQG5fbVUznJXsBTnfYEbrjZ2BFJgz28Ffb utQ1g831E36Cou/DIA97JTa5BYcUbfmV0IDcq9s0TnewvzOVy7rauRkC9HYdccstRAC6 CKuBnsqmQ6VGpFR6q1JM1Ob7znGKfE5YJWUmkqfvq9asP3SEuKlexeoK0B2DOh7LzMSf Rxjg== MIME-Version: 1.0 X-Received: by 10.112.77.138 with SMTP id s10mr3346521lbw.59.1392971314976; Fri, 21 Feb 2014 00:28:34 -0800 (PST) Received: by 10.114.93.3 with HTTP; Fri, 21 Feb 2014 00:28:34 -0800 (PST) Date: Fri, 21 Feb 2014 00:28:34 -0800 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: multipart/alternative; boundary=001a11c3d072695ed704f2e66876 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/uRnYtCUzBk485qP77deFZcAOJHE Subject: [multipathtcp] draft agenda for London meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 08:28:45 -0000 --001a11c3d072695ed704f2e66876 Content-Type: text/plain; charset=ISO-8859-1 The draft agenda for London meeting has been uploaded. Please check the following URL. https://datatracker.ietf.org/meeting/89/agenda/mptcp/ Also, we are currently thinking about running WGLC for draft-ietf-mptcp-attacks after the meeting as it seems to be good shape. If you have comments or questions on the draft, please send them to the ML or speak up in the meeting. Thanks, -- Yoshi & Phil --001a11c3d072695ed704f2e66876 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

The draft agenda for London meeting has been u= ploaded.=A0

Please check the following URL.

https://datat= racker.ietf.org/meeting/89/agenda/mptcp/

Also, we are currently thinking abo= ut running WGLC for draft-ietf-mptcp-attacks after the meeting as it seems = to be good shape.

If you have comments or questions on the draft, please send the= m to the ML or speak up in the meeting.

Thanks,

Yoshi & Phil

--001a11c3d072695ed704f2e66876-- From nobody Fri Feb 21 18:14:30 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291A71A0354 for ; Fri, 21 Feb 2014 18:14:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Gh61Hp6L0F8 for ; Fri, 21 Feb 2014 18:14:27 -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 E4EF11A036A for ; Fri, 21 Feb 2014 18:14:26 -0800 (PST) Received: from localhost (unknown [216.9.110.9]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 86579198012; Sat, 22 Feb 2014 03:14:15 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 86579198012 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1393035256; bh=zeI4i5N+RtcPxzdeGaSc87n7i/5wEwksyU/uQkNnMjM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=eGL08skLL5+corI/ZfS7duZnWFGkMcijvhaLs7GiNSQXXgR5ZAPvJATxjfU0c2tb+ lAbXhklmxyjRPC/B6MGQfCp0buNFEbnqHZTbcG05u6yFcYYmEa8Zl+b27cNwTWrubr 3LTpFZ0qbxbTv8ErWjoVS3KcxqYqpi+R0EbzOeZ0= Date: Sat, 22 Feb 2014 03:14:09 +0100 From: Christoph Paasch To: Apostolis Salkintzis Message-ID: <20140222021409.GD5255@cpaasch-mac> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 86579198012.ABD37 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/NuMESU-eVNlnukB8mgVADQqFVqc Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Asymmetric scheduling X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 02:14:29 -0000 Hello, On 20/02/14 - 21:21:47, Apostolis Salkintzis wrote: > Short question: Is it possible to have different MPTCP schedulers in the > client and in the server that could lead to asymmetric use of uplink and > downlink resources? E.g. the client could send most uplink data on path#1 > while the server could send most downlink data on path#2. yes, each end-host is free to use his own heuristics when scheduling the traffic among the different subflows. Cheers, Christoph From nobody Mon Feb 24 09:06:12 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15091A0202 for ; Mon, 24 Feb 2014 09:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWZ6-oQEPwE0 for ; Mon, 24 Feb 2014 09:06:05 -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 9871C1A01FD for ; Mon, 24 Feb 2014 09:06:05 -0800 (PST) Received: from mbpobo.dhcp.info.ucl.ac.be (unknown [172.17.0.12]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 9658F19805F for ; Mon, 24 Feb 2014 18:05:57 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 9658F19805F DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1393261557; bh=ZNlBYDkx30OkKiHF2qLcA+dHqiixBokhCIln/Tqq4PQ=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding; b=pm6eYsELxa912JMQjSq6DOgR/aF1JQJIxUDvhRhqlkjlWPd+VmLh+XNdLTV27XJc9 uU9Wpllt0B6/XnKNl01ig8+3Rzf0gYUEYE0tJZfQJ0ta5g1d3vIYDcpgvHGdyjXAOG 2wkmt7Q87cDaN48hpA4Qvf0YNJHVMOr0KSRUs3ew= Message-ID: <530B7BF5.5090901@uclouvain.be> Date: Mon, 24 Feb 2014 18:05:57 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: multipathtcp Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 9658F19805F.A133F X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/f7PWkjUeoWPicHgQ_9EIiFukbkM Subject: [multipathtcp] Operational experience with Multipath TCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 17:06:08 -0000 Hello, The charter of the MPTCP working group contains the following objective : > Prior to publishing a Standards Track specification, the working > group will document experimental results and operational experiences to-date. > This should consider not just experience with well-connected fat-pipe > networks and long-lived flows, but also consider a broader links and > types of applications; particularly looking for cases where MPTCP > could be detrimental in some way. We know from interactions on this mailing list and also based on personnal contacts that there are several operationnal deployments of Multipath TCP that use our implementation in the Linux kernel and even wider deployments on iOS7 devices. In order to prepare the above objective of the MPTCP charter, we are seeking input from all MPTCP users and experimenters. If you use MPTCP in production, could you send a message on this list (or privately if you prefer to remain anonymous) indicating your use case and the lessons that you've learned by using Multipath TCP. All operationnal experience is welcome and will help us to document how Multipath TCP is used, the benefits that it provides and the possible operationnal drawbacks that it has. If you have written a paper or blog post that describes measurement results of lessons based on operationnal experience, let us know. Thanks Olivier Bonaventure From nobody Mon Feb 24 17:01:19 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BEA1A02F8 for ; Mon, 24 Feb 2014 17:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVDKQ1V7lycZ for ; Mon, 24 Feb 2014 17:01:16 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4C40C1A028A for ; Mon, 24 Feb 2014 17:01:15 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBL89724; Tue, 25 Feb 2014 01:01:13 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Feb 2014 01:01:06 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Feb 2014 01:01:11 +0000 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.209]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Tue, 25 Feb 2014 09:01:08 +0800 From: "Xiongchunshan (Sam)" To: "multipathtcp@ietf.org" Thread-Topic: [MPTCP] draft-deng-mptcp-mobile-network-proxy-00 Thread-Index: AQHPMcUQCcA/D77dAEK5uAzkbuJ1mw== Date: Tue, 25 Feb 2014 01:01:07 +0000 Message-ID: <6B53974F43BA3C40A96CA7FDE0C9BBD04112607C@nkgeml507-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.64.75] Content-Type: multipart/alternative; boundary="_000_6B53974F43BA3C40A96CA7FDE0C9BBD04112607Cnkgeml507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/9sLAnjNX_aipUeHudxG-DGiwJ_A Subject: [multipathtcp] [MPTCP] draft-deng-mptcp-mobile-network-proxy-00 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 01:01:18 -0000 --_000_6B53974F43BA3C40A96CA7FDE0C9BBD04112607Cnkgeml507mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gZm9sa3MsDQoNCkhlcmUgSSBoYXZlIHNvbWUgY29tbWVudHMgb24gdGhpcyBkb2N1bWVu dDoNCg0KMSkNCjUuMiAgVHJhZmZpYyBtZWRpYXRpb24NCiAgIChhKSBBbmNob3Jpbmcgb2Ygc3Vi LWZsb3cgdHJhZmZpYzogT24gb25lIGhhbmQsIGl0IGlzIG5vdCBhbHdheXMNCiAgIHBvc3NpYmxl IGZvciBhIHNpbmdsZSBHVyBiZSBzaXR0aW5nIG9uIHRoZSBwYXRoIG9mIGV2ZXJ5IHN1Yi1mbG93 DQogICBmcm9tIGEgTVBUQ1Agc2Vzc2lvbiwgaGVuY2UgZXhwbGljaXQgdHJhZmZpYyBhbmNob3Jp bmcgdG8gZW5hYmxlIGENCiAgIHNpbmdsZSBwb2ludCBvZiBnZW5lcmFsIGNvbnRyb2wgb3ZlciBN UFRDUCBzdWItZmxvd3Mgc2hvdWxkIGJlDQogICBjb25zaWRlcmVkLg0KICAgKGIpIE1lZGlhdGlv biBvZiBzdWItZmxvdyB0cmFmZmljOiBPbiB0aGUgb3RoZXIgaGFuZCwgZm9yIGZpbmUtDQogICBn cmFpbmVkIG1lZGlhdGlvbiBvZiBzdWItZmxvdyB0cmFmZmljLCBib3RoIHN0YXRpYyBhbmQgZHlu YW1pYw0KICAgc2VsZWN0aW9uL29mZmxvYWRpbmcvcG9vbGluZyBwb2xpY2llcyBzaG91bGQgYmUg YWxsb3dlZC4gRm9yDQogICBpbnN0YW5jZSwgImFsd2F5cyBwcmVmZXIgV2ktRmkgb3ZlciAzR1BQ IiBjb3VsZCBiZSBhIHN0YXRpYyBwb2xpY3kNCiAgIGZvciBidWxrIGRhdGEgdHJhbnNmZXIgc2Vy dmljZXMsIHdoaWxlICJ1c2UgM0dQUCBvbmx5IGZvciBiYWNrdXANCiAgIHVubGVzcyBXaS1GaSBp cyBjb25nZXN0ZWQiIGNvdWxkIGJlIGEgZHluYW1pYyBvZmZsb2FkaW5nIHBvbGljeSBmb3IgYQ0K ICAgdW4tcHJpb3JpdGl6ZWQgVm9JUCBzZXJ2aWNlLg0KW3hjc11RdWVzdGlvbiBmb3IgY2xhcmlm aWNhdGlvbjogSG93IGRvZXMgdGhlIE1QVENQIHByb3h5IGtub3cgdGhlIGJpbmRpbmcgaW5mb3Jt YXRpb24gYmV0d2VlbiB0aGUgSVAgYW5kIFJBVCA/ICBUaGUgbW9iaWxlIG5vZGUga25vd3Mgd2hp Y2ggSVAgaXMgYWxsb2NhdGVkIGZyb20gd2hpY2ggUkFULCBidXQgaXQgaXMgdmVyeSBoYXJkIGZv ciB0aGUgTVBUQ1AgUHJveHkgaW4gdGhlIGNvcmUgbmV0d29yayB0byBrbm93IHRoZXNlIG1hcHBp bmcgaW5mb3JtYXRpb24uDQpPbmUgcG9zc2libGUgc29sdXRpb24gaXMgdGhlIFBDUkYgKGRlZmlu ZWQgaW4gdGhlIDNHUFApIHRvIHByb3ZpZGUgdGhlc2UgYmluZGluZyBpbmZvcm1hdGlvbiB0byB0 aGUgTVBUQ1AgcHJveHkgaWYgdGhlIE1QVENQIHByb3h5IHBlcmZvcm1hbmNlIHRoZSB0cmFmZmlj IG1lZGlhdGlvbiBvciBsZXQgdGhlIG1vYmlsZSB0byBkbyB0aGUgdHJhZmZpYyBtZWRpYXRpb24u DQoNCkFub3RoZXIgcXVlc3Rpb24gaXMgaG93IHRoZSBydWxlcyAoZS5nLiAiYWx3YXlzIHByZWZl ciBXaS1GaSBvdmVyIDNHUFAiKSBhcmUgcHJvdmlkZWQgdG8gdGhlIE1QVENQIFByb3h5IG9yIHRo ZSBtb2JpbGUgPyBGb3IgdGhlIE1QVENQIHByb3h5LCBpdCBpcyBhZ2FpbiB0aGUgUENSRjsgZm9y IHRoZSBtb2JpbGUgLCBpdCBpcyB0aGUgQU5EU0YgPw0KDQoNCjIpDQo0LjIgUmVzb3VyY2UgcG9v bGluZyBmb3IgcmVkdWNlZCBleHBlbnNlDQogICBEdWUgdG8gaXRzIGxvdyBjb25zdHJ1Y3Rpb24g YW5kIG9wZXJhdGlvbiBleHBlbnNlcywgV2ktRmkgaGFzIGJlZW4NCiAgIGFkb3B0ZWQgYnkgbW9i aWxlIG9wZXJhdG9ycyBhcyBhIGNvbXBsZW1lbnRhcnkgUkFUIGZvciB0aGVpcg0KICAgdHJhZGl0 aW9uYWwgM0dQUCBuZXR3b3Jrcy4gSG93ZXZlciwgZGlmZmVyZW50IGNvbnN0cnVjdGlvbiBhbmQN CiAgIG9wZXJhdGlvbiBleHBlbnNlcyBvZiB2YXJpb3VzIHJhZGlvIG5ldHdvcmtzIHJlc3VsdCBp biBkaWZmZXJlbmNlcyBpbg0KICAgY2hhcmdpbmcgcmF0ZXMvcG9saWNpZXMgZm9yIGRpZmZlcmVu dCBSQVRzLg0KICAgRm9yIGluc3RhbmNlLCBXaS1GaSBhY2Nlc3MgbWF5IGJlIGNoYXJnZWQgYnkg dGhlIGFjY2VzcyBkdXJhdGlvbiwNCiAgIHdoaWxlIHRoZSAzR1BQIGFjY2VzcyBtYXkgYmUgY2hh cmdlZCBieSB0aGUgY29uc3VtZWQgZGF0YSB2b2x1bWUuDQogICBFdmVuIGlmIHVzaW5nIHRoZSBz YW1lIHBvbGljeSwgV2ktRmkgc2VydmljZSBpcyBleHBlY3RlZCB0byBiZSBtdWNoDQogICBjaGVh cGVyIHRoYW4gM0dQUCBkYXRhIHNlcnZpY2UuDQogICBNb3Jlb3ZlciwgZGlmZmVyZW50IHN1YnNj cmlwdGlvbiBwYWNrYWdlcyBtYXkgb2ZmZXIgdmFyaW91cyBkYXRhDQogICBwbGFucyBmb3IgdmFy aW91cyBSQVRzLiBGb3IgaW5zdGFuY2UsIGEgYmFzaWMgNEcgcGFja2FnZSBtYXkgY29udGFpbg0K ICAgZnJlZSBkYXRhIHZvbHVtZSBhcyB3ZWxsIGZyZWUgV2ktRmkgYWNjZXNzIHRvby4NCiAgIEJ5 IGVuYWJsaW5nIE1QVENQIHNlc3Npb24gYmV0d2VlbiBVRSBhbmQgbmV0d29yayBwcm94eSwgdmlh IG1lZGlhdGluZw0KICAgc3ViLWZsb3cgZGF0YSB0cmFmZmljIGJhc2VkIG9uIHRoZWlyIFJhZGlv IGFjY2VzcyB0eXBlcyBhbmQgdGhlDQogICB1c2Vy4oCZcyBzdWJzY3JpcHRpb24gcGFja2FnZSwg aXQgaXMgcG9zc2libGUgdG8gZnVydGhlciByZWR1Y2UgdGhlDQogICB1c2FnZSBleHBlbnNlcyBm cm9tIGJvdGggc2lkZXMgb2YgdGhlIG5ldHdvcmsgYW5kIHVzZXIuDQoNClt4Y3NdIGl0IHdpbGwg YmVuZWZpdCB0aGUgdXNlciBpZiB0aGUgdXNlcuKAmXMgZXhwZW5zZSBvZiBkYXRhIHVzYWdlIGlz IHJlZHVjZWQsIGlmIHRoZSBXaUZpIGNvbm5lY3Rpb24gaXMgYXZhaWxhYmxlIGFuZCBjaGFyZ2lu ZyBmZWUgaXMgdmVyeSBsb3csIG1heWJlIGFsbCB0aGUgdHJhZmZpYyBmcm9tIHRoZSA0RyBhcmUg bW92ZWQgdG8gdGhlIFdpRmkgYnkgdGhlIE1QVENQIHByb3h5LCBhbmQgdGhlIG1vYmlsaXR5IGFu ZCBRb1Mgb2YgdGhlIHNlcnZpY2UgbWF5YmUgYXJlbuKAmXQgZW5zdXJlZCwgc28gaXQgaXMgcHJv cG9zZWQgdG8gYWRkaW5nIHRoZSBmb2xsb3dpbmcgc2VudGVuY2UgdG8gdGhlIGVuZCBvZiB0aGlz IGNoYXB0ZXI6DQpUaGUgUW9TL1FvRS9TZXJ2aWNlIGNvbnRpbnVpdHkgb2YgdGhlIGN1cnJlbnQg ZGF0YSBzZXJ2aWNlcyBhcmUgc3RpbGwga2VwdCB3aGVuIHRoZSBNUFRDUCBwcm94eSBpcyB1c2Vk IHRvIHJlZHVjZSB0aGUgdXNlcuKAmXMgdXNhZ2UgZXhwZW5zZXMuDQoNCkEgYXNzdW1wdGlvbiBm b3IgcmVkdWNpbmcgdXNlciBleHBlbnNlIGlzIHRoYXQgdGhlIFdpRmkgY29ubmVjdGlvbiBpcyBh Y3RpdmF0ZWQgYmVmb3JlaGFuZCwgYnV0IHNvbWV0aW1lcyB0aGUgV2lGaSBjb25uZWN0aW9uIGlz buKAmXQgYWN0aXZhdGVkIG9yIGEgd3JvbmcgV2lGaSBBUCBpcyBzZWxlY3RlZCBieSB0aGUgdXNl ciggdGhhdCBNUFRDUCBQcm94eSBjYW7igJl0IGFjY2VzcyB0aGUgV2lGaSBJUCBmbG93KSwgdGhh dCBpcywgb25lIGhhbmQsIHRoZSBuZXR3b3JrIG5lZWQgdG8gY29udHJvbCB0aGUgTVBUQ1AgUHJv eHkgdG8gbWVkaWF0ZSB0aGUgSVAgZmxvd3MsIGFub3RoZXIgaGFuZCwgdGhlIG5ldHdvcmsgc2hv dWxkIHRlbGwgdGhlIG1vYmlsZSB0byBvcGVuIHdoaWNoIFJBVC9XaUZpIHRvIG1ha2UgdGhlIE1Q VENQIFByb3h5IHdvcmsuICBpLmUuIHRoZSBuZXR3b3JrIHNob3VsZCBwcm92aWRlIHNvbWUgaW5m b3JtYXRpb24gdG8gdGhlIFVFICwgdG8gZ3VpZGUgdGhlIFVFIHRvIHNlbGVjdCBhbmQgb3BlbiBh bm90aGVyIFJBVCB0byBlbmFibGUgdGhlIE1QVENQLg0KDQoNCjMpDQo0LjEgRHluYW1pYyB0cmFm ZmljIG9mZmxvYWRpbmcgYmFzZWQgb24gbmV0d29yayBpbmZvcm1hdGlvbg0KICAgRm9yIHJlYWwt dGltZSBpbnRlcmFjdGl2ZSBzZXJ2aWNlcyB3aXRoIGhpZ2hlciBRb1MgcmVxdWlyZW1lbnRzIGl0 IGlzDQogICBleHBlY3RlZCB0aGF0IDNHUFAgbmV0d29yayBjYW4gcHJvdmlkZSBiZXR0ZXIgZ3Vh cmFudGVlcyBvbiB0aGUNCiAgIGF2ZXJhZ2UgY2FzZS4gRm9yIGJ1bGsgZGF0YSB0cmFuc2ZlciB3 aG8gaXMgc2F0aXNmaWVkIHdpdGggYmVzdC0NCiAgIGVmZm9ydCBkZWxpdmVyeSwgV2ktRmkgd291 bGQgYmUgYSBncmVhdCBjaG9pY2UuIEJ1dCB0aGUgdmVydGljYWwNCiAgIHBhcnRpdGlvbiBkb2Vz IG5vdCBmaXQgZXZlcnl3aGVyZSBmb3IgdGhlIHdpcmVsZXNzIGNvbmRpdGlvbiBpdHNlbGYNCiAg IGlzIHF1aXRlIGR5bmFtaWMgYW5kIGhhcmQgdG8gcHJlZGljdC4gSXQgaXMgaW1wb3J0YW50IHRv IGltcGxlbWVudA0KICAgYWRhcHRpdmUgb2ZmbG9hZGluZyBtZWNoYW5pc21zIGluIG9yZGVyIHRv IGFjaGlldmUgaGlnaGVyIHJlc291cmNlDQogICB1dGlsaXR5IHdpdGggZXZlciBjaGFuZ2luZyBy YWRpbyBlbnZpcm9ubWVudCBmb3IgYSBwb3NzaWJseSBtb3ZpbmcNCiAgIHRlcm1pbmFsIGJhc2Vk IG9uIG5ldHdvcmsgc3RhdHVzLCBlLmcuIGNlbGwgbG9hZCwgQVDigJlzIHNpZ25hbA0KICAgaW50 ZW5zaXR5LCB1c2Vy4oCZcyBzdWJzY3JpcHRpb24gdHlwZSwgZXRjLg0KW3hjc11UaGUgc2FtZSBx dWVzdGlvbiBmcm9tIDEpOiAgSG93IGRvZXMgdGhlIE1QVENQIFByb3h5L1VFIGtub3cgdGhlIG5l dHdvcmsgc3RhdHVzID8gVGhlIFBDUkYvQU5EU0YgcHJvdmlkZXMgdGhlc2UgaW5mb3JtYXRpb24g dG8gdGhlIE1QVENQIFByb3h5L1VFID8NCg0KDQoNCkJScw0KQ2h1bnNoYW4gWGlvbmcNCkh1YXdl aSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQoNCg0K --_000_6B53974F43BA3C40A96CA7FDE0C9BBD04112607Cnkgeml507mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuWNjuaWh+e7hum7kTsNCglwYW5vc2UtMToyIDEgNiAwIDQgMSAxIDEgMSAxO30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6IlxA5Y2O5paH57uG6buRIjsNCglwYW5vc2UtMToyIDEgNiAwIDQg MSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJ bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5 Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCnNwYW4uSFRNTENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTo rr7moLzlvI8iOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5DaGFyDQoJe21z by1zdHlsZS1uYW1lOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOuaJueazqOahhuaWh+acrDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIu MHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBz dHlsZT0idGV4dC1qdXN0aWZ5LXRyaW06cHVuY3R1YXRpb24iPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IZWxsbyBm b2xrcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhlcmUgSSBoYXZlIHNvbWUgY29tbWVudHMgb24gdGhp cyBkb2N1bWVudDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjEpPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjUuMiZuYnNwOyBUcmFmZmlj IG1lZGlhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgKGEpIEFuY2hvcmluZyBvZiBzdWItZmxvdyB0 cmFmZmljOiBPbiBvbmUgaGFuZCwgaXQgaXMgbm90IGFsd2F5czxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsg cG9zc2libGUgZm9yIGEgc2luZ2xlIEdXIGJlIHNpdHRpbmcgb24gdGhlIHBhdGggb2YgZXZlcnkg c3ViLWZsb3c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IGZyb20gYSBNUFRDUCBzZXNzaW9uLCBoZW5jZSBl eHBsaWNpdCB0cmFmZmljIGFuY2hvcmluZyB0byBlbmFibGUgYTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsg c2luZ2xlIHBvaW50IG9mIGdlbmVyYWwgY29udHJvbCBvdmVyIE1QVENQIHN1Yi1mbG93cyBzaG91 bGQgYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IGNvbnNpZGVyZWQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyAo YikgTWVkaWF0aW9uIG9mIHN1Yi1mbG93IHRyYWZmaWM6IE9uIHRoZSBvdGhlciBoYW5kLCBmb3Ig ZmluZS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO2dyYWluZWQgbWVkaWF0aW9uIG9mIHN1Yi1mbG93IHRy YWZmaWMsIGJvdGggc3RhdGljIGFuZCBkeW5hbWljPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBzZWxlY3Rp b24vb2ZmbG9hZGluZy9wb29saW5nIHBvbGljaWVzIHNob3VsZCBiZSBhbGxvd2VkLiBGb3I8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7Jm5ic3A7IGluc3RhbmNlLCAmcXVvdDthbHdheXMgcHJlZmVyIFdpLUZpIG92ZXIg M0dQUCZxdW90OyBjb3VsZCBiZSBhIHN0YXRpYyBwb2xpY3k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IGZv ciBidWxrIGRhdGEgdHJhbnNmZXIgc2VydmljZXMsIHdoaWxlICZxdW90O3VzZSAzR1BQIG9ubHkg Zm9yIGJhY2t1cDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgdW5sZXNzIFdpLUZpIGlzIGNvbmdlc3RlZCZx dW90OyBjb3VsZCBiZSBhIGR5bmFtaWMgb2ZmbG9hZGluZyBwb2xpY3kgZm9yIGE8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7Jm5ic3A7IHVuLXByaW9yaXRpemVkIFZvSVAgc2VydmljZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+W3hjc11RdWVzdGlv biBmb3IgY2xhcmlmaWNhdGlvbjogSG93IGRvZXMgdGhlIE1QVENQIHByb3h5IGtub3cgdGhlIGJp bmRpbmcgaW5mb3JtYXRpb24gYmV0d2VlbiB0aGUgSVAgYW5kIFJBVCA/ICZuYnNwO1RoZSBtb2Jp bGUgbm9kZSBrbm93cyB3aGljaCBJUCBpcyBhbGxvY2F0ZWQgZnJvbSB3aGljaCBSQVQsIGJ1dCBp dCBpcyB2ZXJ5IGhhcmQgZm9yIHRoZSBNUFRDUCBQcm94eSBpbiB0aGUNCiBjb3JlIG5ldHdvcmsg dG8ga25vdyB0aGVzZSBtYXBwaW5nIGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbmUgcG9zc2libGUgc29s dXRpb24gaXMgdGhlIFBDUkYgKGRlZmluZWQgaW4gdGhlIDNHUFApIHRvIHByb3ZpZGUgdGhlc2Ug YmluZGluZyBpbmZvcm1hdGlvbiB0byB0aGUgTVBUQ1AgcHJveHkgaWYgdGhlIE1QVENQIHByb3h5 IHBlcmZvcm1hbmNlIHRoZSB0cmFmZmljIG1lZGlhdGlvbiBvciBsZXQgdGhlIG1vYmlsZSB0byBk byB0aGUgdHJhZmZpYyBtZWRpYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Bbm90aGVyIHF1ZXN0 aW9uIGlzIGhvdyB0aGUgcnVsZXMgKGUuZy4gJnF1b3Q7YWx3YXlzIHByZWZlciBXaS1GaSBvdmVy IDNHUFAmcXVvdDspIGFyZSBwcm92aWRlZCB0byB0aGUgTVBUQ1AgUHJveHkgb3IgdGhlIG1vYmls ZSA/IEZvciB0aGUgTVBUQ1AgcHJveHksIGl0IGlzIGFnYWluIHRoZSBQQ1JGOyBmb3IgdGhlIG1v YmlsZSAsIGl0IGlzIHRoZSBBTkRTRiA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Mik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+NC4yIFJlc291cmNlIHBvb2xpbmcgZm9yIHJlZHVjZWQgZXhwZW5zZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDsmbmJzcDsgRHVlIHRvIGl0cyBsb3cgY29uc3RydWN0aW9uIGFuZCBvcGVyYXRpb24gZXhw ZW5zZXMsIFdpLUZpIGhhcyBiZWVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBhZG9wdGVkIGJ5IG1vYmls ZSBvcGVyYXRvcnMgYXMgYSBjb21wbGVtZW50YXJ5IFJBVCBmb3IgdGhlaXI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 Jm5ic3A7IHRyYWRpdGlvbmFsIDNHUFAgbmV0d29ya3MuIEhvd2V2ZXIsIGRpZmZlcmVudCBjb25z dHJ1Y3Rpb24gYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBvcGVyYXRpb24gZXhwZW5zZXMgb2YgdmFy aW91cyByYWRpbyBuZXR3b3JrcyByZXN1bHQgaW4gZGlmZmVyZW5jZXMgaW48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 Jm5ic3A7IGNoYXJnaW5nIHJhdGVzL3BvbGljaWVzIGZvciBkaWZmZXJlbnQgUkFUcy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7Jm5ic3A7IEZvciBpbnN0YW5jZSwgV2ktRmkgYWNjZXNzIG1heSBiZSBjaGFyZ2VkIGJ5 IHRoZSBhY2Nlc3MgZHVyYXRpb24sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyB3aGlsZSB0aGUgM0dQUCBh Y2Nlc3MgbWF5IGJlIGNoYXJnZWQgYnkgdGhlIGNvbnN1bWVkIGRhdGEgdm9sdW1lLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDsmbmJzcDsgRXZlbiBpZiB1c2luZyB0aGUgc2FtZSBwb2xpY3ksIFdpLUZpIHNlcnZpY2Ug aXMgZXhwZWN0ZWQgdG8gYmUgbXVjaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgY2hlYXBlciB0aGFuIDNH UFAgZGF0YSBzZXJ2aWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgTW9yZW92ZXIsIGRpZmZlcmVudCBz dWJzY3JpcHRpb24gcGFja2FnZXMgbWF5IG9mZmVyIHZhcmlvdXMgZGF0YTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsm bmJzcDsgcGxhbnMgZm9yIHZhcmlvdXMgUkFUcy4gRm9yIGluc3RhbmNlLCBhIGJhc2ljIDRHIHBh Y2thZ2UgbWF5IGNvbnRhaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IGZyZWUgZGF0YSB2b2x1bWUgYXMg d2VsbCBmcmVlIFdpLUZpIGFjY2VzcyB0b28uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBCeSBlbmFibGlu ZyBNUFRDUCBzZXNzaW9uIGJldHdlZW4gVUUgYW5kIG5ldHdvcmsgcHJveHksIHZpYSBtZWRpYXRp bmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IHN1Yi1mbG93IGRhdGEgdHJhZmZpYyBiYXNlZCBvbiB0aGVp ciBSYWRpbyBhY2Nlc3MgdHlwZXMgYW5kIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgdXNlcuKAmXMg c3Vic2NyaXB0aW9uIHBhY2thZ2UsIGl0IGlzIHBvc3NpYmxlIHRvIGZ1cnRoZXIgcmVkdWNlIHRo ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDsmbmJzcDsgdXNhZ2UgZXhwZW5zZXMgZnJvbSBib3RoIHNpZGVzIG9mIHRo ZSBuZXR3b3JrIGFuZCB1c2VyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+W3hjc10gaXQgd2lsbCBiZW5l Zml0IHRoZSB1c2VyIGlmIHRoZSB1c2Vy4oCZcyBleHBlbnNlIG9mIGRhdGEgdXNhZ2UgaXMgcmVk dWNlZCwgaWYgdGhlIFdpRmkgY29ubmVjdGlvbiBpcyBhdmFpbGFibGUgYW5kIGNoYXJnaW5nIGZl ZSBpcyB2ZXJ5IGxvdywgbWF5YmUgYWxsIHRoZSB0cmFmZmljIGZyb20gdGhlIDRHIGFyZSBtb3Zl ZCB0byB0aGUgV2lGaSBieSB0aGUgTVBUQ1AgcHJveHksDQogYW5kIHRoZSBtb2JpbGl0eSBhbmQg UW9TIG9mIHRoZSBzZXJ2aWNlIG1heWJlIGFyZW7igJl0IGVuc3VyZWQsIHNvIGl0IGlzIHByb3Bv c2VkIHRvIGFkZGluZyB0aGUgZm9sbG93aW5nIHNlbnRlbmNlIHRvIHRoZSBlbmQgb2YgdGhpcyBj aGFwdGVyOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJ0ZXh0LWluZGVudDo0Mi4xNXB0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIFFvUy9Rb0Uv U2VydmljZSBjb250aW51aXR5IG9mIHRoZSBjdXJyZW50IGRhdGEgc2VydmljZXMgYXJlIHN0aWxs IGtlcHQgd2hlbiB0aGUgTVBUQ1AgcHJveHkgaXMgdXNlZCB0byByZWR1Y2UgdGhlIHVzZXLigJlz IHVzYWdlIGV4cGVuc2VzLjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+QSBhc3N1bXB0aW9uIGZvciByZWR1Y2luZyB1c2VyIGV4cGVuc2UgaXMgdGhhdCB0 aGUgV2lGaSBjb25uZWN0aW9uIGlzIGFjdGl2YXRlZCBiZWZvcmVoYW5kLCBidXQgc29tZXRpbWVz IHRoZSBXaUZpIGNvbm5lY3Rpb24gaXNu4oCZdCBhY3RpdmF0ZWQgb3IgYSB3cm9uZyBXaUZpIEFQ IGlzIHNlbGVjdGVkIGJ5IHRoZSB1c2VyKCB0aGF0IE1QVENQIFByb3h5IGNhbuKAmXQgYWNjZXNz IHRoZQ0KIFdpRmkgSVAgZmxvdyksIHRoYXQgaXMsIG9uZSBoYW5kLCB0aGUgbmV0d29yayBuZWVk IHRvIGNvbnRyb2wgdGhlIE1QVENQIFByb3h5IHRvIG1lZGlhdGUgdGhlIElQIGZsb3dzLCBhbm90 aGVyIGhhbmQsIHRoZSBuZXR3b3JrIHNob3VsZCB0ZWxsIHRoZSBtb2JpbGUgdG8gb3BlbiB3aGlj aCBSQVQvV2lGaSB0byBtYWtlIHRoZSBNUFRDUCBQcm94eSB3b3JrLiAmbmJzcDtpLmUuIHRoZSBu ZXR3b3JrIHNob3VsZCBwcm92aWRlIHNvbWUgaW5mb3JtYXRpb24gdG8NCiB0aGUgVUUgLCB0byBn dWlkZSB0aGUgVUUgdG8gc2VsZWN0IGFuZCBvcGVuIGFub3RoZXIgUkFUIHRvIGVuYWJsZSB0aGUg TVBUQ1AuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Myk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+NC4xIER5bmFt aWMgdHJhZmZpYyBvZmZsb2FkaW5nIGJhc2VkIG9uIG5ldHdvcmsgaW5mb3JtYXRpb248bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7Jm5ic3A7IEZvciByZWFsLXRpbWUgaW50ZXJhY3RpdmUgc2VydmljZXMgd2l0aCBoaWdo ZXIgUW9TIHJlcXVpcmVtZW50cyBpdCBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgZXhwZWN0ZWQgdGhh dCAzR1BQIG5ldHdvcmsgY2FuIHByb3ZpZGUgYmV0dGVyIGd1YXJhbnRlZXMgb24gdGhlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOyZuYnNwOyBhdmVyYWdlIGNhc2UuIEZvciBidWxrIGRhdGEgdHJhbnNmZXIgd2hvIGlz IHNhdGlzZmllZCB3aXRoIGJlc3QtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBlZmZvcnQgZGVsaXZlcnks IFdpLUZpIHdvdWxkIGJlIGEgZ3JlYXQgY2hvaWNlLiBCdXQgdGhlIHZlcnRpY2FsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOyZuYnNwOyBwYXJ0aXRpb24gZG9lcyBub3QgZml0IGV2ZXJ5d2hlcmUgZm9yIHRoZSB3aXJl bGVzcyBjb25kaXRpb24gaXRzZWxmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBpcyBxdWl0ZSBkeW5hbWlj IGFuZCBoYXJkIHRvIHByZWRpY3QuIEl0IGlzIGltcG9ydGFudCB0byBpbXBsZW1lbnQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7Jm5ic3A7IGFkYXB0aXZlIG9mZmxvYWRpbmcgbWVjaGFuaXNtcyBpbiBvcmRlciB0byBh Y2hpZXZlIGhpZ2hlciByZXNvdXJjZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgdXRpbGl0eSB3aXRoIGV2 ZXIgY2hhbmdpbmcgcmFkaW8gZW52aXJvbm1lbnQgZm9yIGEgcG9zc2libHkgbW92aW5nPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOyZuYnNwOyB0ZXJtaW5hbCBiYXNlZCBvbiBuZXR3b3JrIHN0YXR1cywgZS5nLiBjZWxs IGxvYWQsIEFQ4oCZcyBzaWduYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IGludGVuc2l0eSwgdXNlcuKA mXMgc3Vic2NyaXB0aW9uIHR5cGUsIGV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+W3hjc11UaGUgc2FtZSBxdWVzdGlvbiBm cm9tIDEpOiAmbmJzcDtIb3cgZG9lcyB0aGUgTVBUQ1AgUHJveHkvVUUga25vdyB0aGUgbmV0d29y ayBzdGF0dXMgPyBUaGUgUENSRi9BTkRTRiBwcm92aWRlcyB0aGVzZSBpbmZvcm1hdGlvbiB0byB0 aGUgTVBUQ1AgUHJveHkvVUUgPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5CUnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Q2h1bnNoYW4gWGlvbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk65Y2O5paH57uG6buRO2NvbG9yOmJsYWNrIj5IdWF3ZWkgVGVjaG5v bG9naWVzIENvLiwgTHRkLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6B53974F43BA3C40A96CA7FDE0C9BBD04112607Cnkgeml507mbschi_-- From nobody Tue Feb 25 08:56:14 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A161A017B for ; Tue, 25 Feb 2014 08:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vh7ldbR1rZN4 for ; Tue, 25 Feb 2014 08:56:10 -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 130D41A0183 for ; Tue, 25 Feb 2014 08:56:09 -0800 (PST) Received: from wifi-eduroam-016.sri.ucl.ac.be (wifi-eduroam-016.sri.ucl.ac.be [192.135.167.16]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 36D2F198055 for ; Tue, 25 Feb 2014 17:56:04 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 36D2F198055 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1393347364; bh=gJxJw+dkjBDnQIsSuz1dzjwnBVtE9cY1W3oY9g+KLaU=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding; b=MUDp3+4FKDvnMMewgV0xK7EBsKv6ntWzWA6t3MWQsFzfTCCc9CZWNmJCFpCGbx6Yv bbaQRsMjfdP78RGxkkyayEBZ45mU5FQGXRUZODuP0zAfM+F7zs8qiJ8gsz9dCsLDtT hO2xAOc1h5XPyCF+ES/k0LM569QkokuHdHH57hSQ= Message-ID: <530CCB23.9060300@uclouvain.be> Date: Tue, 25 Feb 2014 17:56:03 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 36D2F198055.A1AC9 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/ZyyZV2bzfSD-qcw7GmBhJ5P4ZdQ Subject: [multipathtcp] Extending draft-paasch-mptcp-ssl-00 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 16:56:13 -0000 Hello, In RFC6824, the subflows are authenticated by relying on the keys that are exchanged in clear during the three way handshake of the initial subflow. From a security viewpoint, exchanging short keys in clear is not the best option. In draft-paasch-mptcp-ssl-00, we proposed to allow an application to provide its chosen authentication key to Multipath TCP in order to use it to authenticate the establishment of subflows. This draft used SSL/TLS as a motivation but we did not specify in details how the authentication keys would be derived from the SSL/TLS session keys. I spent some time to look at TLS1.2 to see how this idea of using keys from the application for Multipath TCP could be applied to this version of TLS. TLS1.2 exchanges a master secret during the TLS handshake and random numbers from the client and the server. This information is then combined as follows (RFC5246) : key_block = PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random); until enough output has been generated. Then, the key_block is partitioned as follows: client_write_MAC_key[SecurityParameters.mac_key_length] server_write_MAC_key[SecurityParameters.mac_key_length] client_write_key[SecurityParameters.enc_key_length] server_write_key[SecurityParameters.enc_key_length] client_write_IV[SecurityParameters.fixed_iv_length] server_write_IV[SecurityParameters.fixed_iv_length] The PRF is currently P_SHA256. Some TLS profiles only generate MAC and write keys but no write IVs from this PRF. To use these keys to authenticate the establishment of the Multipath TCP subflows, there are several options that probably have different security properties : a- Use the client_write_MAC_key/server_write_MAC_key as is b- Derive a new client_write_MPTCP/server_write_MPTCP keypair by using the PRF c- Use a hash of some keys (e.g. client_write_MAC_key||server_write_MAC_key on the client) If Multipath TCP is implemented in the kernel and requires the key to accept/reject subflows, then leaking a copy of the key to the kernel (option a) is not a good option from a security viewpoint. This solution might work if the Multipath TCP implementation can do an upcall to TLS upon the arrival of a new subflow to compute the HMAC required for the authentication, but this would add complexity to the Multipath TCP implementations. Option b (generating a new Multipath TCP specific key) is more secure, but for each combinaison of crypto functions in TLS we need to define a profile that includes the generation of the Multipath TCP key. It might be difficult to deploy such a solution. Option c seems easier since the same hash can be used for all TLS profiles, but I'm wondering what are the security implications of leaking a hash of the MAC_keys to the Multipath TCP kernel. Any idea on this ? Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From nobody Tue Feb 25 13:19:21 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F8F1A030C for ; Tue, 25 Feb 2014 13:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NP7AVr_2U9aN for ; Tue, 25 Feb 2014 13:19:11 -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 850211A02A7 for ; Tue, 25 Feb 2014 13:19:05 -0800 (PST) Received: from mbpobo.local (host-212-68-230-69.brutele.be [212.68.230.69]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id A0AD71C541B for ; Tue, 25 Feb 2014 22:18:51 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be A0AD71C541B DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1393363131; bh=bKi3fZg6RqW2dxXbdPp4RXA3g1uAeFoiNf50IerurEg=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding; b=WiJx3brjjjoRZIAuxKOdxQqXNYpgUaDsHypc6IAE4r0VFeYnFJInJtIQX8RDzkTL3 0UG+IwkfzY2evhy0j+hda6mHOigVIWY3IOEx6/cuOiXMt8pr8EnFrAijZyGsIRHI5C cRqKH6dJNjqQ0Swd5O+vW7jDul2c42Dd3YNzCk24= Message-ID: <530D08BB.9080004@uclouvain.be> Date: Tue, 25 Feb 2014 22:18:51 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: A0AD71C541B.A1EE7 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/qI0DpGjDAfJtyfMxDP23k-1baF0 Subject: [multipathtcp] Hash function usage in Multipath TCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 21:19:15 -0000 Hello, Multipath TCP, as defined in RFC6824, currently uses the SHA-1 hash function for three purposes : - derive the Token from the keys exchanged in clear during the three-way-handshake - derive the Initial Data Sequence Number from the keys exchanged in clear during the three-way-handshake - authenticate the establishment of the subflows by using a HMAC computed over the keys exchanged in clear and random nonces Most of the protocols that rely on hash functions include a method to negotiate the hash function that is used for a particular invocation of the protocol. In Multipath TCP, it seems a bit difficult to easily add the support for another has function in a secure manner. The current version of RFC6824 contains the following statement concerning the flags in the MP_CAPABLE option in the SYN segment > C through H: The remaining bits, labeled "C" through "H", are used > for crypto algorithm negotiation. Currently only the rightmost > bit, labeled "H", is assigned. Bit "H" indicates the use of HMAC- > SHA1 (as defined in Section 3.2). An implementation that only > supports this method MUST set bit "H" to 1, and bits "C" through > "G" to 0. Setting bit H to 1 is the current default in Multipath TCP. By using bits C, D, E, F and G, we could define other hash functions in case SHA-1 is broken and considered to be insecure for Multipath TCP. Later, RFC6824 notes : > For crypto negotiation, the responder has the choice. The initiator > creates a proposal setting a bit for each algorithm it supports to 1 > (in this version of the specification, there is only one proposal, so > bit "H" will be always set to 1). The responder responds with only 1 > bit set -- this is the chosen algorithm. The rationale for this > behavior is that the responder will typically be a server with > potentially many thousands of connections, so it may wish to choose > an algorithm with minimal computational complexity, depending on the > load. If a responder does not support (or does not want to support) > any of the initiator's proposals, it can respond without an > MP_CAPABLE option, thus forcing a fallback to regular TCP. If we replace SHA-1 with another hash function, we thus need to define a new bit to propose this new hash function. According to the above texte, the client could propose the new hash and SHA-1 (by setting the H bit) or only the new hash. From a security viewpoint, doing this negotiation of the has functions in clear may lead to downgrading attacks where an attacker resets the bit corresponding to the hash that he/she does not want to support. Given that the SYN is only "protected" by a standard checksum, this attack is simple. However, this does not seem to be very severe since if the attacker is able to change the content of the SYN, he/she can already read the authentication keys... Should we already define a new hash functions inside RFC6824bis ? If yes, then we probably need to structure the Multipath TCP RFCs as for TCP-AO, i.e. : - a first document defines the protocol with abstract crypto functions, basically most of the current RFC6824 - a second document specifies the crypto algorithms can be used with all their requirements parameters If we go in the direction, are there strong preferences for a second hash function for Multipath TCP ? Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From nobody Tue Feb 25 14:34:00 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329E11A079D for ; Tue, 25 Feb 2014 14:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URdV1DNCwMG5 for ; Tue, 25 Feb 2014 14:33:49 -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 5306C1A07A3 for ; Tue, 25 Feb 2014 14:33:48 -0800 (PST) Received: from mbpobo.local (host-212-68-230-69.brutele.be [212.68.230.69]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 6D0811833E2; Tue, 25 Feb 2014 23:33:36 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 6D0811833E2 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1393367616; bh=QSebj5vT7OTlyAac1xkD0RCjMMsbv2Bhf58edmFU5rU=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=KXSPkC8zSr8Jf0VcdfQD0N5u9rknU3A1PVI9O4Zge5UWvN3lwM5tNeplBS7IdNj8H NHM0qndU9qwy/940SPAREVm/GDz+8z9MEh8NrGjTPzNxn+/d6EOCXoLdSZGdabX+e1 1AlkB08s7VIi/CtrGrdUTCMjtiOcuBEb+89S9NvE= Message-ID: <530D1A40.4050708@uclouvain.be> Date: Tue, 25 Feb 2014 23:33:36 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: lingli deng , multipathtcp@ietf.org References: <20140214160043.25045.90052.idtracker@ietfa.amsl.com> <2afb52fe3cd3acc-0000a.Richmail.00009030405128129702@chinamobile.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 6D0811833E2.A06B7 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/u6UR7AwXmUvI3RGbuou4hwuBRew Subject: Re: [multipathtcp] Fwd: Fw:New Version Notification fordraft-deng-mptcp-mobile-network-proxy-00.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 22:33:55 -0000 Hello, > http://www.ietf.org/internet-drafts/draft-deng-mptcp-mobile-network-proxy-00.txt > > Please find below some first comments on your draft. >3 Considerations for MPTCP Proxy An important motivation that is missing from the draft is that nowadays, although there are hundred of millions of MPTCP enabled smartphones, there are very few servers that support MPTCP. In the past, measurements have shown that TCP extensions (RFC1323, SACK, ...) have been deployed first on clients and that it took many years to enable these TCP extensions on the server side. The main reasons for the slow evolution on the server side appears to be : - the need to upgrade the load balancers, firewalls and other middelboxes in front of the servers - the desire of system administrators to only use very stable operating system releases On the server side, we may have to wait several years until Multipath TCP becomes widely deployed. In the mean time, a proxy-based solution that supports all TCP connections would enable clients such as smartphones to benefit from Multipath TCP. > 4.1 Dynamic traffic offloading based on network information > For bulk data transfer who is satisfied with best- > effort delivery, Wi-Fi would be a great choice. But the vertical > partition does not fit everywhere for the wireless condition itself > is quite dynamic and hard to predict. It is important to implement > adaptive offloading mechanisms in order to achieve higher resource > utility with ever changing radio environment for a possibly moving > terminal based on network status, e.g. cell load, AP's signal > intensity, user's subscription type, etc. Our experience with Multipath TCP on smartphones shows that the main benefit of MPTCP compared to other solutions where the network would favor WiFi over 3G or the opposite is that MPTCP has all the information about the current quality of the WiFi and 3G links. We've seen WiFI access points that provide a very good SNR, but are attached to a crappy and overload ADSL link. We've also seen areas where 3G does not work efficiently while WiFi works and the opposite. Sometimes, by moving a few meters, the smartphone gets connectivity or no connectivity from one wireless network. It seems unlikely that a static solution that would say always prefer 3G for chat and always prefer WiFi for video would always work. There are many situations where you need both WiFi and 3G at the same time, e.g. to perform a seamless handover during a few seconds while moving. > 4.2 Resource pooling for reduced expense There are many WiFi networks to which the user has credentials and that he/she wants to use that are not controlled by 3G operators. See for example campus networks covering schools, some city-wide networks being deployed, community networks like FON that aggregate millions of access points in Europe. Users expect to be able to use all these networks more efficiently thanks to Multipath TCP. > 5.1 Protocol transition > > To allow a MPCTP-enabled UE to make full use of the multiple radio > interfaces even if it is communicating with a non-MPTCP server, the > proxy should support > > (a) Detection of UE's MPTCP capability; > > (b) Negotiation with MPTCP UE on behalf of non-MPTCP SP; > > (c) Translation/Mapping between TCP and MPTCP sessions. For points a and b, do you have any requirements beyond the utilization of the standard MP_CAPABLE option that allows to perfor this negotiation ? (c) requires the ability to support MPTCP upstream of the proxy and TCP downstream of the proxy. In contrast with application level proxies such as HTTP proxies, an MPTCP proxy should be application agnostic and should support any type of application that runs on top of TCP. > 5.2 Traffic mediation > > (a) Anchoring of sub-flow traffic: On one hand, it is not always > possible for a single GW be sitting on the path of every sub-flow > from a MPTCP session, hence explicit traffic anchoring to enable a > single point of general control over MPTCP sub-flows should be > considered. This can be achieved by providing to the smartphone the addresses of the proxies so that the smartphone uses them as relays when creating new MPTCP connections. Implicit proxies with in-network redirection like WCCP are possible as well, but as you note, it is difficult to ensure that all traffic will always flow through a given part of the network, especially if the transport connections are long lived > (b) Mediation of sub-flow traffic: On the other hand, for fine- > grained mediation of sub-flow traffic, both static and dynamic > selection/offloading/pooling policies should be allowed. I'm not sure I completely understand what you mean by subflow traffic > For > instance, "always prefer Wi-Fi over 3GPP" could be a static policy > for bulk data transfer services, while "use 3GPP only for backup > unless Wi-Fi is congested" could be a dynamic offloading policy for a > un-prioritized VoIP service. Do you foresee more complex policies than the ones allowed by using the backup bit defined in Multipath TCP ? Would these policies be imposed by the network operator, configured on the client devices ? Best regards, Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From nobody Tue Feb 25 21:20:52 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5121A1A0416 for ; Tue, 25 Feb 2014 21:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.151 X-Spam-Level: *** X-Spam-Status: No, score=3.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2pcOvcQpOpo for ; Tue, 25 Feb 2014 21:20:41 -0800 (PST) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 83C251A02D5 for ; Tue, 25 Feb 2014 21:20:41 -0800 (PST) Received: by mail-ve0-f175.google.com with SMTP id oy12so1623342veb.20 for ; Tue, 25 Feb 2014 21:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xsWN4DkNgOZ0xN6PGUjBijRANzVtv4cJOlbZuFnv4Jg=; b=GLNgMLf/Jooe1CJ3d+IKWGwManvaiphXRiEtXglP8L07lDSZXV99ETxYAPl0B9rDZ/ 1rU54UlEGW/1/F21uxZD7U8SeonWGSZLxVCbRbcUpw4yZKlynEPlP7bxb3v4DCLzdZGz XsQr23N+r1NIS+cVgvWz6N3fWa3BZOe5FVg+4aNl9BfIHtfEdOI5KppMms5mt/oNCcmm ypF/Nwe4dMi3d0t4jyW8liwRmc1nSUpICn56BILS1v2s2pAJc+Wc2wMbOMdTH8fPr6PT b8VLGysMS9pZOBCDHDmpBfbcrwNWo7oW2VlW1cam0LuqB65DvIwmNkowzOFEwGhu1qwq SobQ== MIME-Version: 1.0 X-Received: by 10.58.37.232 with SMTP id b8mr4274123vek.27.1393392040200; Tue, 25 Feb 2014 21:20:40 -0800 (PST) Received: by 10.58.100.212 with HTTP; Tue, 25 Feb 2014 21:20:40 -0800 (PST) In-Reply-To: <6B53974F43BA3C40A96CA7FDE0C9BBD04112607C@nkgeml507-mbs.china.huawei.com> References: <6B53974F43BA3C40A96CA7FDE0C9BBD04112607C@nkgeml507-mbs.china.huawei.com> Date: Wed, 26 Feb 2014 13:20:40 +0800 Message-ID: From: lingli deng To: "Xiongchunshan (Sam)" Content-Type: multipart/alternative; boundary=089e01176de596ccea04f3485d17 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/aKe6SkZ3oQQmqMTzCtLkJNkDuS4 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] [MPTCP] draft-deng-mptcp-mobile-network-proxy-00 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 05:20:48 -0000 --089e01176de596ccea04f3485d17 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Sam, Thanks for your review and comments. Plz see some initial comments inline: Lingli 2014-02-25 9:01 GMT+08:00 Xiongchunshan (Sam) : > Hello folks, > > > > Here I have some comments on this document: > > > > 1) > > 5.2 Traffic mediation > > (a) Anchoring of sub-flow traffic: On one hand, it is not always > > possible for a single GW be sitting on the path of every sub-flow > > from a MPTCP session, hence explicit traffic anchoring to enable a > > single point of general control over MPTCP sub-flows should be > > considered. > > (b) Mediation of sub-flow traffic: On the other hand, for fine- > > grained mediation of sub-flow traffic, both static and dynamic > > selection/offloading/pooling policies should be allowed. For > > instance, "always prefer Wi-Fi over 3GPP" could be a static policy > > for bulk data transfer services, while "use 3GPP only for backup > > unless Wi-Fi is congested" could be a dynamic offloading policy for a > > un-prioritized VoIP service. > > [xcs]Question for clarification: How does the MPTCP proxy know the bindin= g > information between the IP and RAT ? The mobile node knows which IP is > allocated from which RAT, but it is very hard for the MPTCP Proxy in the > core network to know these mapping information. > *[dll] For 3GPP access networks, the core knows the RAT type as the time of PDP connection setup. For WLAN, there has been interworking standards via PDG (packet data gateway) which does the IP binding. So the core network knows the mapping, and there is a need to integrate MPTCP proxy with existing architecture to get this information.* > One possible solution is the PCRF (defined in the 3GPP) to provide these > binding information to the MPTCP proxy if the MPTCP proxy performance the > traffic mediation or let the mobile to do the traffic mediation. > *[dll] I agree that interface with PCRF could be a solution to provide binding information from the network side, as well as acquiring mediation policy.* > > > Another question is how the rules (e.g. "always prefer Wi-Fi over 3GPP") > are provided to the MPTCP Proxy or the mobile ? For the MPTCP proxy, it i= s > again the PCRF; for the mobile , it is the ANDSF ? > > > *[dll] Yes, PCRF would be a candidate in the case of proxy mediation and ANDSF has been proposed to be used by 3GPP for network selection. However, just for discussion, I personally prefer proxy-based mediation, as it may not always be proper to rely on the terminal for network-driven policy enforcement. Therefore, I would suggest we **currently **focuse on proxy-mediation case. Would you agree?* > > 2) > > 4.2 Resource pooling for reduced expense > > Due to its low construction and operation expenses, Wi-Fi has been > > adopted by mobile operators as a complementary RAT for their > > traditional 3GPP networks. However, different construction and > > operation expenses of various radio networks result in differences in > > charging rates/policies for different RATs. > > For instance, Wi-Fi access may be charged by the access duration, > > while the 3GPP access may be charged by the consumed data volume. > > Even if using the same policy, Wi-Fi service is expected to be much > > cheaper than 3GPP data service. > > Moreover, different subscription packages may offer various data > > plans for various RATs. For instance, a basic 4G package may contain > > free data volume as well free Wi-Fi access too. > > By enabling MPTCP session between UE and network proxy, via mediating > > sub-flow data traffic based on their Radio access types and the > > user=A1=AFs subscription package, it is possible to further reduce the > > usage expenses from both sides of the network and user. > > > > [xcs] it will benefit the user if the user=A1=AFs expense of data usage i= s > reduced, if the WiFi connection is available and charging fee is very low= , > maybe all the traffic from the 4G are moved to the WiFi by the MPTCP prox= y, > and the mobility and QoS of the service maybe aren=A1=AFt ensured, so it = is > proposed to adding the following sentence to the end of this chapter: > > *The QoS/QoE/Service continuity of the current data services are still > kept when the MPTCP proxy is used to reduce the user=A1=AFs usage expense= s.* > *[dll] Good point. I agree.* > > > A assumption for reducing user expense is that the WiFi connection is > activated beforehand, but sometimes the WiFi connection isn=A1=AFt activa= ted or > a wrong WiFi AP is selected by the user( that MPTCP Proxy can=A1=AFt acce= ss the > WiFi IP flow), that is, one hand, the network need to control the MPTCP > Proxy to mediate the IP flows, another hand, the network should tell the > mobile to open which RAT/WiFi to make the MPTCP Proxy work. i.e. the > network should provide some information to the UE , to guide the UE to > select and open another RAT to enable the MPTCP. > > > *[dll] I agree that it is of great value for mobile terminals to be more intelligent in enabling multiple interfaces based on network provided information. But how it is done seems to be out of scope of a MPTCP proxy discussion.* > > > 3) > > 4.1 Dynamic traffic offloading based on network information > > For real-time interactive services with higher QoS requirements it is > > expected that 3GPP network can provide better guarantees on the > > average case. For bulk data transfer who is satisfied with best- > > effort delivery, Wi-Fi would be a great choice. But the vertical > > partition does not fit everywhere for the wireless condition itself > > is quite dynamic and hard to predict. It is important to implement > > adaptive offloading mechanisms in order to achieve higher resource > > utility with ever changing radio environment for a possibly moving > > terminal based on network status, e.g. cell load, AP=A1=AFs signal > > intensity, user=A1=AFs subscription type, etc. > > [xcs]The same question from 1): How does the MPTCP Proxy/UE know the > network status ? The PCRF/ANDSF provides these information to the MPTCP > Proxy/UE ? > *[dll] Plz refer to the above comments^^* > > > BRs > > Chunshan Xiong > > Huawei Technologies Co., Ltd. > > > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > --=20 =B5=CB=C1=E9=C0=F2/Lingli Deng =D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/China Mobile Researc= h Institute e-mail: denglingli@chinamobile.com tel: 15801696688-3367 mobile: 13810597148 --089e01176de596ccea04f3485d17 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

Hi Sam,

Thanks for your review and comm= ents.

Plz see some initial comments inline:

<= div>Lingli

2014-02-25 9:01 GMT+08:00 Xiongchunshan (Sam) <sam.xiongchunsha= n@huawei.com>:

Hello folks,

Here I have some comments on th= is document:

1)

5.2 Traffic mediation<= /u>

   (a) Anchoring of s= ub-flow traffic: On one hand, it is not always

   possible for a sin= gle GW be sitting on the path of every sub-flow

   from a MPTCP sessi= on, hence explicit traffic anchoring to enable a

   single point of ge= neral control over MPTCP sub-flows should be

   considered.=

   (b) Mediation of s= ub-flow traffic: On the other hand, for fine-

grained mediation = of sub-flow traffic, both static and dynamic

   selection/offloadi= ng/pooling policies should be allowed. For

   instance, "al= ways prefer Wi-Fi over 3GPP" could be a static policy

   for bulk data tran= sfer services, while "use 3GPP only for backup
   unless Wi-Fi is co= ngested" could be a dynamic offloading policy for a

   un-prioritized VoI= P service.

[xcs]Question for clarification= : How does the MPTCP proxy know the binding information between the IP and = RAT ? The mobile node knows which IP is allocated from which RAT, but= it is very hard for the MPTCP Proxy in the core network to know these mapping information.

[dll] For 3GPP access networks, the core knows the RAT type= as the time of PDP connection setup. For WLAN, there has been interworking= standards via PDG (packet data gateway) which does the IP binding. So the = core network knows the mapping, and there is a need to integrate MPTCP prox= y with existing architecture to get this information.

One possible solution is the PC= RF (defined in the 3GPP) to provide these binding information to the MPTCP = proxy if the MPTCP proxy performance the traffic mediation or let the mobil= e to do the traffic mediation.

[dll] I agree that interface with PCRF coul= d be a solution to provide binding information from the network side, as we= ll as acquiring mediation policy.

Another question is how the rul= es (e.g. "always prefer Wi-Fi over 3GPP") are provided to the MPT= CP Proxy or the mobile ? For the MPTCP proxy, it is again the PCRF; for the= mobile , it is the ANDSF ?

[dll] Yes, PCRF would be a candidate in the case of proxy= mediation and ANDSF has been proposed to be used by 3GPP for network selec= tion. However, just for discussion, I personally prefer proxy-based mediati= on, as it may not always be proper to rely on the terminal for network-driv= en policy enforcement. Therefore, I would suggest we currently focuse on = proxy-mediation case. Would you agree?

2)

4.2 Resource pooling for reduce= d expense

   Due to its low con= struction and operation expenses, Wi-Fi has been

   adopted by mobile = operators as a complementary RAT for their

   traditional 3GPP n= etworks. However, different construction and

   operation expenses= of various radio networks result in differences in
   charging rates/pol= icies for different RATs.

   For instance, Wi-F= i access may be charged by the access duration,

   while the 3GPP acc= ess may be charged by the consumed data volume.

   Even if using the = same policy, Wi-Fi service is expected to be much

   cheaper than 3GPP = data service.

   Moreover, differen= t subscription packages may offer various data

   plans for various = RATs. For instance, a basic 4G package may contain

   free data volume a= s well free Wi-Fi access too.

   By enabling MPTCP = session between UE and network proxy, via mediating
   sub-flow data traf= fic based on their Radio access types and the

   user’s subsc= ription package, it is possible to further reduce the<= /p>
   usage expenses fro= m both sides of the network and user.

[xcs] it will benefit the user = if the user’s expense of data usage is reduced, if the WiFi connectio= n is available and charging fee is very low, maybe all the traffic from the= 4G are moved to the WiFi by the MPTCP proxy, and the mobility and QoS of the service maybe aren’t ensured, so it = is proposed to adding the following sentence to the end of this chapter:=

The QoS/QoE/Service continuity of the current data services are still kep= t when the MPTCP proxy is used to reduce the user’s usage expenses.

[dll] Good point. I agree.

A assumption for reducing user = expense is that the WiFi connection is activated beforehand, but sometimes = the WiFi connection isn’t activated or a wrong WiFi AP is selected by= the user( that MPTCP Proxy can’t access the WiFi IP flow), that is, one hand, the network need to control the MPTCP Pr= oxy to mediate the IP flows, another hand, the network should tell the mobi= le to open which RAT/WiFi to make the MPTCP Proxy work. i.e. the netw= ork should provide some information to the UE , to guide the UE to select and open another RAT to enable the MPTC= P.

[dll] I agree that it is of great value for mobile terminals to be = more intelligent in enabling multiple interfaces based on network provided = information. But how it is done seems to be out of scope of a MPTCP proxy d= iscussion.

3)

4.1 Dynamic traffic offloading = based on network information

   For real-time inte= ractive services with higher QoS requirements it is
   expected that 3GPP= network can provide better guarantees on the

   average case. For = bulk data transfer who is satisfied with best-

   effort delivery, W= i-Fi would be a great choice. But the vertical

   partition does not= fit everywhere for the wireless condition itself

   is quite dynamic a= nd hard to predict. It is important to implement

   adaptive offloadin= g mechanisms in order to achieve higher resource

   utility with ever = changing radio environment for a possibly moving

   terminal based on = network status, e.g. cell load, AP’s signal

   intensity, user&rs= quo;s subscription type, etc.

[xcs]The same question from 1):= How does the MPTCP Proxy/UE know the network status ? The PCRF/ANDSF= provides these information to the MPTCP Proxy/UE ?

[dll] Plz refer to the above comments^^
=

BRs

Chunshan Xiong

Huawei Technologies Co., Ltd.

=

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

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

--089e01176de596ccea04f3485d17-- From nobody Wed Feb 26 03:52:41 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3DA51A02BE for ; Wed, 26 Feb 2014 03:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwSYpxLo7_QR for ; Wed, 26 Feb 2014 03:52:27 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 707D41A02B6 for ; Wed, 26 Feb 2014 03:52:26 -0800 (PST) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Wed, 26 Feb 2014 11:51:16 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.168]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Wed, 26 Feb 2014 11:52:12 +0000 From: To: , Date: Wed, 26 Feb 2014 11:52:12 +0000 Thread-Topic: [multipathtcp] draft agenda for London meeting Thread-Index: Ac8u3vC1bXYCLV1iQJOQsu7B9092sQECeUfA Message-ID: References: In-Reply-To: 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_A2E337CDB7BC4145B018B9BEE8EB3E0D40AD0EBF51EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/kwc4AVlBXh6nClABteNv9DhHCgQ Subject: Re: [multipathtcp] draft agenda for London meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 11:52:29 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AD0EBF51EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please could presenters send me their slides by the end of Sunday. A couple of volunteers to take notes of the meeting would be fantastic. I re-ordered the agenda slightly (to minimise the awkwardness of the clash = with ippm) Thanks phil From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Yosh= ifumi Nishida Sent: 21 February 2014 08:29 To: multipathtcp Subject: [multipathtcp] draft agenda for London meeting The draft agenda for London meeting has been uploaded. Please check the following URL. https://datatracker.ietf.org/meeting/89/agenda/mptcp/ Also, we are currently thinking about running WGLC for draft-ietf-mptcp-att= acks after the meeting as it seems to be good shape. If you have comments or questions on the draft, please send them to the ML = or speak up in the meeting. Thanks, -- Yoshi & Phil --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AD0EBF51EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Please could presenters send me= their slides by the end of Sunday.
A couple of= volunteers to take notes of the meeting would be fantastic.

I re-ordered the agenda sl= ightly (to minimise the awkwardness of the clash with ippm)

Thanks
<= p class=3DMsoNormal>phil

From: multipathtcp = [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Yoshifumi Nishid= a
Sent: 21 February 2014 08:29
To: multipathtcp
S= ubject: [multipathtcp] draft agenda for London meeting

The draft agend= a for London meeting has been uploaded.
Please= check the following URL.

https= ://datatracker.ietf.org/meeting/89/agenda/mptcp/
<= /div>

Also, we are currently thinking about runnin= g WGLC for draft-ietf-mptcp-attacks after the meeting as it seems to be goo= d shape.
If you have comments or questions on the = draft, please send them to the ML or speak up in the meeting.

Thanks,
=
--
Yoshi & Phil
= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AD0EBF51EMV67UKRDdoma_-- From nobody Thu Feb 27 00:45:55 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08741A07C1 for ; Thu, 27 Feb 2014 00:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaWtT4Q0ckYE for ; Thu, 27 Feb 2014 00:45:41 -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 43C351A066A for ; Thu, 27 Feb 2014 00:45:40 -0800 (PST) Received: from mbpobo.local (host-212-68-230-69.brutele.be [212.68.230.69]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 9F3CD19809C; Thu, 27 Feb 2014 09:45:32 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 9F3CD19809C DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1393490732; bh=Sw8uEfAhx69mZJxMMtImCv0cplmV9NA8si2aDzuHlfM=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Ol5f9duePG/0eit85kA2+VoM2YB41LxD7RFmmBcWs/Vu3vEAiwGX8M3/UpGQMXi3o uqVXJewCsUmA/0qUKNJqDpHZwBh2QjtyZ+pLVYb9JWTgFzEKpEcL2HuPEjHO1wd4Sg pJhuDAzwsuJkF0hK2N0iTgNjlQmKH9TfcsKYYy5g= Message-ID: <530EFB2C.2090200@uclouvain.be> Date: Thu, 27 Feb 2014 09:45:32 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: lingli deng , "Xiongchunshan (Sam)" References: <6B53974F43BA3C40A96CA7FDE0C9BBD04112607C@nkgeml507-mbs.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 9F3CD19809C.A4B6A X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/T9EXYV3EBfqTYaWdFT1mcpdhdek Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] [MPTCP] draft-deng-mptcp-mobile-network-proxy-00 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 08:45:49 -0000 Hello, > > [xcs]Question for clarification: How does the MPTCP proxy know the > binding information between the IP and RAT ? The mobile node knows > which IP is allocated from which RAT, but it is very hard for the > MPTCP Proxy in the core network to know these mapping information. > > > *[dll] For 3GPP access networks, the core knows the RAT type as the time > of PDP connection setup. For WLAN, there has been interworking standards > via PDG (packet data gateway) which does the IP binding. So the core > network knows the mapping, and there is a need to integrate MPTCP proxy > with existing architecture to get this information.* For MPTCP, the client gets several IP addresses, say one from the WLAN and one from the 3G network. A proxy solution should allow the client to start the MPTCP connection through the proxy either via the WLAN interface or via the 3G interface. It should not be bound to a specific network (say 3G) and force the client to always start over this network. There are mobility scenarios where only one network is available when a connection starts and this connection must pass through the proxy to benefit from mptcp in the future. > ____ > > One possible solution is the PCRF (defined in the 3GPP) to provide > these binding information to the MPTCP proxy if the MPTCP proxy > performance the traffic mediation or let the mobile to do the > traffic mediation. > > > *[dll] I agree that interface with PCRF could be a solution to provide > binding information from the network side, as well as acquiring > mediation policy.* An MPTCP proxy should not be restricted to a given technology. The client should be able to learn the address of the proxy that it needs to use (e.g. based on its location, subscription information or the network that it is currently connected to, ...). There could be some way to distribute this information from the 3GPP network, but it should not be the only way > ____ > > ____ > > Another question is how the rules (e.g. "always prefer Wi-Fi over > 3GPP") are provided to the MPTCP Proxy or the mobile ? For the MPTCP > proxy, it is again the PCRF; for the mobile , it is the ANDSF ?____ > > > *[dll] Yes, PCRF would be a candidate in the case of proxy mediation and > ANDSF has been proposed to be used by 3GPP for network selection. > However, just for discussion, I personally prefer proxy-based mediation, > as it may not always be proper to rely on the terminal for > network-driven policy enforcement. Therefore, I would suggest we > **currently **focuse on proxy-mediation case. Would you agree?* > In the case of WLANs, and in particular WLANs that are not controlled by the network operator, the terminal has often more information about the quality of the network (both WLAN and 3G) than the network itself. We should exploit this information and not only rely on the network. > [xcs] it will benefit the user if the user’s expense of data usage > is reduced, if the WiFi connection is available and charging fee is > very low, maybe all the traffic from the 4G are moved to the WiFi by > the MPTCP proxy, and the mobility and QoS of the service maybe > aren’t ensured, so it is proposed to adding the following sentence > to the end of this chapter:____ > > *The QoS/QoE/Service continuity of the current data services are > still kept when the MPTCP proxy is used to reduce the user’s usage > expenses.* > > > *[dll] Good point. I agree.* Reducing the user expenses (assuming that WiFi is cheaper than 3G) is one use case for an MPTCP proxy, but this is by far not the only one. Other use cases include : - improving performance by using simultaneously WiFi and 3G - improving quality of experience by allowing the terminal to use either WiFi or 3G automatically without asking the user to manually switch between the two interfaces - avoid being stuck with "open" WiFi networks that provide an IP address but use a captive portal where the user has to log in. Today, many users of smartphones are frustrated when their smartphone stops 3G to attach to such a WiFi network that they cannot use (but the smartphone tries sometimes for several minutes) - ... > ____ > > ____ > > A assumption for reducing user expense is that the WiFi connection > is activated beforehand, but sometimes the WiFi connection isn’t > activated or a wrong WiFi AP is selected by the user( that MPTCP > Proxy can’t access the WiFi IP flow), that is, one hand, the network > need to control the MPTCP Proxy to mediate the IP flows, another > hand, the network should tell the mobile to open which RAT/WiFi to > make the MPTCP Proxy work. i.e. the network should provide some > information to the UE , to guide the UE to select and open another > RAT to enable the MPTCP.____ > > *[dll] I agree that it is of great value for mobile terminals to be more > intelligent in enabling multiple interfaces based on network provided > information. But how it is done seems to be out of scope of a MPTCP > proxy discussion.* A proxy should not be limited to some specific networks that are controlled by the network operator. Users expected to be able to use whatever WiFi for which they have the necessary credentials and MPTCP is able to use whatever WiFi has long as it provides a reachable IP address. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From nobody Thu Feb 27 01:24:34 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20821A003B for ; Thu, 27 Feb 2014 01:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.464 X-Spam-Level: * X-Spam-Status: No, score=1.464 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHBzRgZSRZpd for ; Thu, 27 Feb 2014 01:24:29 -0800 (PST) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 49FEF1A0137 for ; Thu, 27 Feb 2014 01:24:27 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id D6DAD2780E6 for ; Thu, 27 Feb 2014 18:24:23 +0900 (JST) Received: by mail-la0-f54.google.com with SMTP id mc6so1517394lab.27 for ; Thu, 27 Feb 2014 01:24:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=koImmoBHMnxMG1i6xgXeIGD00QtzY4CoRUz/J61zoDM=; b=Ff1F/aMzPoZTQHaxLCouRrv3ogLupRqKg+rexo73K5Xm8LFbeJWuL9BfVsYlXMuA+K Cs3zdJ8dUZaWyx+FU/kKgAJyapz7je0LvMbs/s5qINU3VvR1u+1Tpj09W+rqwLA6POBX 9c/YwotN9DR/bfCxBZ9KdhliM4e+hMRkYsN0ddHs2C+lH887jkdyPXRdZiNm+2l2yYCi PUnhSHEYZ0ru2H0hY1NRxuMzNeiJRt5XtsjdgbbmDUqaBYp9DXdHdaEpN3VlG1CE2WVq b0Qh0Xj/HnPMQRSfneTWPUEhcEOuQ/wTWWhJuqWIGm9u0lTp+jZmOkQtisQBzRVTSEhF EF2A== MIME-Version: 1.0 X-Received: by 10.152.203.193 with SMTP id ks1mr5973292lac.0.1393493061034; Thu, 27 Feb 2014 01:24:21 -0800 (PST) Received: by 10.114.93.3 with HTTP; Thu, 27 Feb 2014 01:24:20 -0800 (PST) In-Reply-To: <530D08BB.9080004@uclouvain.be> References: <530D08BB.9080004@uclouvain.be> Date: Thu, 27 Feb 2014 01:24:20 -0800 Message-ID: From: Yoshifumi Nishida To: Olivier Bonaventure Content-Type: multipart/alternative; boundary=001a113470d2e6682704f35fe271 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/HHBUL7HUlFr7WbFyKnfqJuJE6Ik Cc: multipathtcp Subject: Re: [multipathtcp] Hash function usage in Multipath TCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 09:24:32 -0000 --001a113470d2e6682704f35fe271 Content-Type: text/plain; charset=ISO-8859-1 Hi Olivier, On Tue, Feb 25, 2014 at 1:18 PM, Olivier Bonaventure < Olivier.Bonaventure@uclouvain.be> wrote: > > > If we replace SHA-1 with another hash function, we thus need to define a > new bit to propose this new hash function. According to the above texte, > the client could propose the new hash and SHA-1 (by setting the H bit) or > only the new hash. > > From a security viewpoint, doing this negotiation of the has functions in > clear may lead to downgrading attacks where an attacker resets the bit > corresponding to the hash that he/she does not want to support. Given that > the SYN is only "protected" by a standard checksum, this attack is simple. > However, this does not seem to be very severe since if the attacker is able > to change the content of the SYN, he/she can already read the > authentication keys... > I don't see strong benefits for protecting downgrading attacks as you mentioned. Also, if they don't want to downgrade, I guess they should set only the bit for the hash they want. > > Should we already define a new hash functions inside RFC6824bis ? > > If yes, then we probably need to structure the Multipath TCP RFCs as for > TCP-AO, i.e. : > > - a first document defines the protocol with abstract crypto functions, > basically most of the current RFC6824 > - a second document specifies the crypto algorithms can be used with all > their requirements parameters > > If we go in the direction, are there strong preferences for a second hash > function for Multipath TCP ? > > Hmm. I see your point. But, how many hashes we want to specify now? If we just add one more hash to the current spec, the second doc will be thin, it might not be a problem, though.. -- Yoshifumi --001a113470d2e6682704f35fe271 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Olivier,

On Tue, Feb 25, 2014 at 1:18 PM, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> wrote:

If we replace SHA-1 with another hash function, we thus need to define a ne= w bit to propose this new hash function. According to the above texte, the = client could propose the new hash and SHA-1 (by setting the H bit) or only = the new hash.

>From a security viewpoint, doing this negotiation of the has functions in c= lear may lead to downgrading attacks where an attacker resets the bit corre= sponding to the hash that he/she does not want to support. Given that the S= YN is only "protected" by a standard checksum, this attack is sim= ple. However, this does not seem to be very severe since if the attacker is= able to change the content of the SYN, he/she can already read the authent= ication keys...

I don't see strong benefits for protec= ting downgrading attacks as you mentioned.
Also, if they don'= t want to downgrade, I guess they should set only the bit for the hash they= want.

Should we already define a new hash functions inside RFC6824bis ?

If yes, then we probably need to structure the Multipath TCP RFCs as for TC= P-AO, i.e. :

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

If we go in the direction, are there strong preferences for a second hash f= unction for Multipath TCP ?

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

--
Yoshifumi
--001a113470d2e6682704f35fe271-- From nobody Thu Feb 27 02:05:07 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50C71A07F8 for ; Thu, 27 Feb 2014 02:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvsnZEKfWYIU for ; Thu, 27 Feb 2014 02:05:03 -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 582ED1A0188 for ; Thu, 27 Feb 2014 02:05:03 -0800 (PST) Received: from mbpobo.local (host-212-68-230-69.brutele.be [212.68.230.69]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 6A56911E5C9; Thu, 27 Feb 2014 11:04:55 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 6A56911E5C9 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1393495495; bh=83m+8z3091vFu6ZSJ2e7JgmryIohVhBZfrvBTmf6nAU=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=wSMgHaVFaHbESLdSBAt0SA23VbmWn4Mu8KnY8kOuRZDjgPX617ksTDlV1Ls8WePwH qWgpRzBPmYzxWSVH8XenQTyS7Rd1CJDeGqa8Z8OetBf9DcarelZZUFciqE/qwfESCq RtTGvgGJ/k5UcB1VqFUoVor+uVX791vGLql9ZcPk= Message-ID: <530F0DC7.3060707@uclouvain.be> Date: Thu, 27 Feb 2014 11:04:55 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Yoshifumi Nishida References: <530D08BB.9080004@uclouvain.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 6A56911E5C9.A3772 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/0WDNnBFnLAEm_J6xsMC3DZrEa8E Cc: multipathtcp Subject: Re: [multipathtcp] Hash function usage in Multipath TCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 10:05:06 -0000 Yoshifumi, > > > If we replace SHA-1 with another hash function, we thus need to > define a new bit to propose this new hash function. According to the > above texte, the client could propose the new hash and SHA-1 (by > setting the H bit) or only the new hash. > > >From a security viewpoint, doing this negotiation of the has > functions in clear may lead to downgrading attacks where an attacker > resets the bit corresponding to the hash that he/she does not want > to support. Given that the SYN is only "protected" by a standard > checksum, this attack is simple. However, this does not seem to be > very severe since if the attacker is able to change the content of > the SYN, he/she can already read the authentication keys... > > > I don't see strong benefits for protecting downgrading attacks as you > mentioned. > Also, if they don't want to downgrade, I guess they should set only the > bit for the hash they want. What I meant is the following client sends SYN with MP_CAPABLE indicating HASH1+HASH2 attacker removes HASH2 from SYN server replies with HASH1 in SYN+ACK If client sends SYN with MP_CAPABLE and only HASH2, it should reply with RST if it receives HASH1 in SYN+ACK > > Should we already define a new hash functions inside RFC6824bis ? > > If yes, then we probably need to structure the Multipath TCP RFCs as > for TCP-AO, i.e. : > > - a first document defines the protocol with abstract crypto > functions, basically most of the current RFC6824 > - a second document specifies the crypto algorithms can be used > with all their requirements parameters > > If we go in the direction, are there strong preferences for a second > hash function for Multipath TCP ? > > Hmm. I see your point. But, how many hashes we want to specify now? > If we just add one more hash to the current spec, the second doc will be > thin, it might not be a problem, though.. The second document could even only contain a single hash (SHA-1 today). If we need to expand the hash functions without chaning MPTCP, we simply need to update this second document. We might want to reserve some bits (e.g. 3) in the MP_CAPABLE option for the selection of the hash functions that are to be defined in the second document Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be