From nobody Sun May 1 00:22:14 2016 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8ED12D14C for ; Sun, 1 May 2016 00:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ptJKQqRCQ1br for ; Sun, 1 May 2016 00:22:11 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DCDE12B048 for ; Sun, 1 May 2016 00:22:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,560,1455004800"; d="asc'?scan'208,217";a="111965773" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx143-out.netapp.com with ESMTP; 01 May 2016 00:17:06 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Sun, 1 May 2016 00:17:03 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::c07c:8fcd:f7e4:f32b%21]) with mapi id 15.00.1156.000; Sun, 1 May 2016 00:17:03 -0700 From: "Eggert, Lars" To: "maprg@irtf.org" Thread-Topic: [gaia] Ethics in Networked Systems Thread-Index: AQHRogBIDxNRzYZQIkyqXrLjtZP5iw== Date: Sun, 1 May 2016 07:17:02 +0000 Message-ID: <8637489F-11C4-4B1B-98ED-19B6D5C73794@netapp.com> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.120.60.36] Content-Type: multipart/signed; boundary="Apple-Mail=_B9D555C7-B183-4FBF-A061-ACD2280B0D1E"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: [Maprg] Fwd: [gaia] Ethics in Networked Systems X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 07:22:13 -0000 --Apple-Mail=_B9D555C7-B183-4FBF-A061-ACD2280B0D1E Content-Type: multipart/alternative; boundary="Apple-Mail=_956912A9-4C22-4415-B763-C0B7D5049B35" --Apple-Mail=_956912A9-4C22-4415-B763-C0B7D5049B35 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The followup discussion of this post on the GAIA list has some relevant = stuff for MAPRG in it: = https://mailarchive.ietf.org/arch/search/?email_list=3Dgaia&gbt=3D1&index=3D= H54dAG4euBr5Uh_bAaLEDp9YJoc = > Begin forwarded message: >=20 > From: Arjuna Sathiaseelan > Subject: [gaia] Ethics in Networked Systems > Date: April 29, 2016 at 12:16:58 GMT+2 > To: gaia >=20 > this will be of v.high relevance to GAIA: >=20 > http://networkedsystemsethics.net/ = >=20 > -- > Arjuna Sathiaseelan > Personal: http://www.cl.cam.ac.uk/~as2330/ = > N4D Lab: http://www.cl.cam.ac.uk/~as2330/n4d = _____________________________________= __________ > gaia mailing list > gaia@irtf.org > https://www.irtf.org/mailman/listinfo/gaia --Apple-Mail=_956912A9-4C22-4415-B763-C0B7D5049B35 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The followup discussion of this post on the GAIA list has = some relevant stuff for MAPRG in it:
https://mailarchive.ietf.org/arch/search/?email_list=3Dgaia&= ;gbt=3D1&index=3DH54dAG4euBr5Uh_bAaLEDp9YJoc

Begin forwarded message:

From: = Arjuna Sathiaseelan <arjuna.sathiaseelan@cl.cam.ac.uk>
Subject: = [gaia] Ethics in = Networked Systems
Date: April 29, 2016 at 12:16:58 GMT+2
To: = gaia <gaia@irtf.org>

this will be of v.high relevance = to GAIA: 

http://networkedsystemsethics.net/

--
Arjuna Sathiaseelan
Personal: = http://www.cl.cam.ac.uk/~as2330/
N4D Lab: = http://www.cl.cam.ac.uk/~as2330/n4d
_______________________________________________
gaia = mailing list
gaia@irtf.org
https://www.irtf.org/mailman/listinfo/gaia

= --Apple-Mail=_956912A9-4C22-4415-B763-C0B7D5049B35-- --Apple-Mail=_B9D555C7-B183-4FBF-A061-ACD2280B0D1E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXJa1xAAoJEFS1wwm/cMFXPD0QAN6zdLrh5xdcNP6hBtxuW3My uxGVZZzyDI2OIyNxyMYkkbmS7ATsdbA3sharlLBmKZsP3jRYi5O0FhY+AOH6c7Z9 N9A2E/QCTzVVd2+feGLN+9lekTBFeAksw2fA27KSM6sStYtn3VhfQ8vcxps20rLU 2FVeGgDDgok1P2welCKgQzQuh4iWPRKlraSfLJ4lPxA4d28MojYhZBSo6JqKbnTG bhWcNMuZgICpNcAY9P2v+yO03MFrZW7vxdkefXN6Ne4ol4+Ug60rIb6F27bhsD6d 6ojeqsntHc1xplcQuAiPs25ycG75YzSSE9rrOB8BsNC94uN089PQv6ZPZ9p5tIuL I+9PECudPxM4+uVLKlRExlOjdjE3HyGX7+Vdm0+6wOL2UaHDIV3twb/Y/pFfkVqL B+WAjqbiMu8wm7fRGOxfP2njEwyCkSydkPds342SqUncbL0IBuE8XmK3zVeP7cCq eXiGEvkEwQjaEXH5inZGBeIkGYQHwnkQq8mIlMywpQGgqA0SZsAZYZlqQRWG48HT kug5Kjof9heEODO1cSwIa1Lq6TLDLkaaKcErsw3Wh10E+p3bJbUkf+J62Ca0GonT 32rstg8EkG3YdGOCToh4LxLD5XDeAnutiu1hIJBBkuKE7DXelf4HccbJ3Ma5MaUv TnwrDfqv9ZSXU2qfL7mT =MXfo -----END PGP SIGNATURE----- --Apple-Mail=_B9D555C7-B183-4FBF-A061-ACD2280B0D1E-- From nobody Sun May 1 03:05:22 2016 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E700612B00A for ; Sun, 1 May 2016 03:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 bbbWF5xFspyQ for ; Sun, 1 May 2016 03:05:18 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6842E126FDC for ; Sun, 1 May 2016 03:05:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 099D5D9315; Sun, 1 May 2016 12:05:16 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VYByXOOQa2cO; Sun, 1 May 2016 12:05:15 +0200 (MEST) Received: from [192.168.75.72] (p5DCECCB5.dip0.t-ipconnect.de [93.206.204.181]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id ADA53D9314; Sun, 1 May 2016 12:05:15 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <8637489F-11C4-4B1B-98ED-19B6D5C73794@netapp.com> Date: Sun, 1 May 2016 12:05:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <673B252E-C2E6-422B-96DF-1C6BFF2FF228@tik.ee.ethz.ch> References: <8637489F-11C4-4B1B-98ED-19B6D5C73794@netapp.com> To: "Eggert, Lars" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "maprg@irtf.org" Subject: Re: [Maprg] [gaia] Ethics in Networked Systems X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 10:05:21 -0000 Hi Lars, you mean apply ethics on Internet measurement? Mirja > Am 01.05.2016 um 09:17 schrieb Eggert, Lars : >=20 > The followup discussion of this post on the GAIA list has some = relevant stuff for MAPRG in it: > = https://mailarchive.ietf.org/arch/search/?email_list=3Dgaia&gbt=3D1&index=3D= H54dAG4euBr5Uh_bAaLEDp9YJoc >=20 >> Begin forwarded message: >>=20 >> From: Arjuna Sathiaseelan >> Subject: [gaia] Ethics in Networked Systems >> Date: April 29, 2016 at 12:16:58 GMT+2 >> To: gaia >>=20 >> this will be of v.high relevance to GAIA:=20 >>=20 >> http://networkedsystemsethics.net/ >>=20 >> --=20 >> Arjuna Sathiaseelan=20 >> Personal: http://www.cl.cam.ac.uk/~as2330/=20 >> N4D Lab: http://www.cl.cam.ac.uk/~as2330/n4d >> _______________________________________________ >> gaia mailing list >> gaia@irtf.org >> https://www.irtf.org/mailman/listinfo/gaia >=20 > _______________________________________________ > Maprg mailing list > Maprg@irtf.org > https://www.irtf.org/mailman/listinfo/maprg From nobody Wed May 4 01:14:21 2016 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC3512D09F for ; Wed, 4 May 2016 01:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=unavailable autolearn_force=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 8rIR_gjknY85 for ; Wed, 4 May 2016 01:14:15 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A447112B030 for ; Wed, 4 May 2016 01:14:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id AFB02D9304; Wed, 4 May 2016 10:14:13 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id o9JpzUb8xANL; Wed, 4 May 2016 10:14:13 +0200 (MEST) Received: from [192.168.178.33] (p5DEC2412.dip0.t-ipconnect.de [93.236.36.18]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 55992D9303; Wed, 4 May 2016 10:14:13 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= Date: Wed, 4 May 2016 10:14:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7067A730-5036-4CAC-9510-806EC0F18CD6@tik.ee.ethz.ch> References: <87twih5ot6.fsf@ta.scs.stanford.edu> To: maprg@irtf.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: tcpinc Subject: [Maprg] Fwd: [tcpinc] TCP-ENO draft issues X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 08:14:19 -0000 Hi maprg, there is an on-going thread about tcp option stripping on the tcpinc = mailing list (see below). Two problem cases have been identified: 1) Strip of non-SYN option while SYN-options pass correctly 2) Reflection of SYN options in the SYN/ACK (by load-balancers/proxies) Does anybody have further data here? Mirja > Anfang der weitergeleiteten Nachricht: >=20 > Von: David Mazieres > Betreff: Aw: [tcpinc] TCP-ENO draft issues > Datum: 2. Mai 2016 um 01:41:25 MESZ > An: Christoph Paasch , tcpinc@ietf.org > Kopie: draft-ietf-tcpinc-tcpeno@ietf.org > Antwort an: David Mazieres expires 2016-07-30 PDT = >=20 > Christoph Paasch writes: >=20 >> Hello, >>=20 >> I have read through the TCP-ENO draft and have a few comments: >>=20 >>=20 >> First, am wondering whether there might be an issue when the third = ACK >> gets lost. >>=20 >> Specifically, the draft says that a host MUST disable ENO if the >> following condition is met: >>=20 >> 4. The first ACK segment received by a host does not contain an = ENO >> option. >>=20 >> So, if this ACK gets lost, and the client goes on with sending >> (encrypted) data, the server won't be able to know whether ENO has >> been successfully negotiated or not and how to interpret the data. >>=20 >> To overcome this, one possible way would be to include the ENO-option >> in every data-segment that a host is sending after the 3-way = handshake >> until successful use of ENO has been confirmed by the receiver. >=20 > Indeed, this is a good point. The idea is really that you MUST = include > the ENO option whenever you ACK a SYN segment. The problem is that = the > ACK might be cumulative. So we would like flows to look like this: >=20 > A -> B: SYN ENO > B -> A: SYN-ACK ENO > A -> B: ACK ENO (lost) > A -> B: ACK ENO* data >=20 > The draft is not at all clear about the need for the ENO marked by *. > Your suggestion is one way to fix this. >=20 >> But even then, there might be a middlebox that removes the ENO-option >> from non-SYN segments (assuming that we want to support such kind of >> middleboxes). The sender will thus send encrypted data with the >> ENO-option. The receiver receives this encrypted data without the >> ENO-option (due to the middlebox stripping the option) and thus will >> assume that the data is unencrypted. (for the background, this kind = of >> behavior is the reason why MPTCP makes sure to only send in-order = data >> in the first few segments, until middlebox-support has been confirmed >> as it allows to fallback to regular TCP) >=20 > This is one reason we would love to collaborate with someone who has > very concrete middlebox experience (hint hint), at the very least on a > TCP-ENO Middlebox Probing document, if not on ENO itself. We have not > observed stripping from SYN but not non-SYN segments, and agree it = would > be annoying. >=20 > Currently we would deal with this in the same as DPI--probe the > middlebox at DHCP lease time and disable ENO if the middlebox is not > compatible. However, if such middleboxes are common enough, then we > might need to support them. Such middleboxes are kind of pernicious, > since a lot of options are first negotiated in SYN segments then used > later. Hence, if they exist but are not too common, I would be okay > with disabling encryption, so long as connections don't fail entirely = or > get garbled. >=20 >> This kind of means that we would need to do a 4-way handshake where >> data can only be sent after it has been confirmed on non-SYN segments >> that ENO is enabled. Maybe there is a better solution to it? >=20 > There are other solutions, though it's not clear if they are better. > The 4-way handshake could be compressed by sending a SYN-ACK and plain > ACK back-to-back (so at least it doesn't incur an extra 1/2 round trip > in the common case). Or we could do it probabilistically, including = 4-8 > bytes of randomness in the ENO options that then get hashed along with > some magic number and included in the TCP payload data. That's kind = of > yucky. >=20 >> Second, there are loadbalancers out there (used by baidu.com >> in particular) that echo unknown TCP options. As >> far as I can tell, TCP-ENO won't be able to handle this situation >> gracefully, as an active opener will interpret the ECHO'd option as >> valid. The P-bit seems to allow to resolve this situation as the >> client would receive a TCP-ENO option with the P-bit set on a SYN/ACK >> segment. But, the P-bit is currently not part of the option thus I >> think it would be good to include it. >=20 > That's another very useful point we didn't know about. The p-bit is > currently implicit, but we could get rid of it and rely entirely on = the > explicit b bit. That would have the added advantage of simplifying = role > negotiation at the cost of sometimes consuming an extra byte of option > space in the SYN-ACK segments. >=20 > Thanks for the useful feedback. >=20 > David >=20 > _______________________________________________ > Tcpinc mailing list > Tcpinc@ietf.org > https://www.ietf.org/mailman/listinfo/tcpinc From nobody Wed May 4 07:06:40 2016 Return-Path: X-Original-To: maprg@irtf.org Delivered-To: maprg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 300C312D696; Wed, 4 May 2016 07:06:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504140634.8340.65495.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 07:06:34 -0700 Archived-At: Cc: maprg@irtf.org, maprg-chairs@ietf.org, ietf@kuehlewind.net, irtf-chair@irtf.org Subject: [Maprg] maprg - New Meeting Session Request for IETF 96 X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.17 List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 14:06:35 -0000 A new meeting session request has just been submitted by Mirja Kuehlewind, a Chair of the maprg working group. --------------------------------------------------------- Working Group Name: Proposed Measurement and Analysis for Protocols Research Group Area Name: IRTF Session Requester: Mirja Kühlewind Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: tsvwg rmcat taps aqm tcpm iccrg ippm tcpinc mptcp tsvarea alto Second Priority: appsawg apparea intarea 6man dnsop v6ops httpbis uta rtcweb Third Priority: irtfopen lmap Special Requests: --------------------------------------------------------- From nobody Wed May 4 09:13:24 2016 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A49512DD86 for ; Wed, 4 May 2016 09:13:22 -0700 (PDT) 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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be 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 ZQ1ZJzTL2hJ4 for ; Wed, 4 May 2016 09:13:19 -0700 (PDT) Received: from smtp3.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id E16AF12DC31 for ; Wed, 4 May 2016 09:04:28 -0700 (PDT) Received: from mbpobo.local (unknown [130.104.228.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 9063F67D9FA; Wed, 4 May 2016 18:04:20 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp3.sgsi.ucl.ac.be 9063F67D9FA DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1462377861; bh=+9q3kX9svCzUvJR602s0xOZh++KmhjACMjWo9sX/byw=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=vKMLXBDyZeiBaUjVcxLlBSlqc5CwySM6Jrw8xsvTFhSovkZA+F1eH04nUtvjOuwjG nT1meL5z41IAmjajpwqkWzeCg8FxrWh3y/xK0ZrK8lIMLzJLpnBimnCSki1bSH6uYx u2N6BO8XkyK7BlcTrXjQqJFoZkAfN2/F8YMMNmO0= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99 at smtp-3 References: <87twih5ot6.fsf@ta.scs.stanford.edu> <7067A730-5036-4CAC-9510-806EC0F18CD6@tik.ee.ethz.ch> To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , maprg@irtf.org From: Olivier Bonaventure Message-ID: <572A1D83.6060804@uclouvain.be> Date: Wed, 4 May 2016 18:04:19 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <7067A730-5036-4CAC-9510-806EC0F18CD6@tik.ee.ethz.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-Information: X-SGSI-MailScanner-ID: 9063F67D9FA.A4567 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Cc: Olivier Mehani Subject: Re: [Maprg] [tcpinc] Fwd: TCP-ENO draft issues X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 16:13:22 -0000 Mirja, > > there is an on-going thread about tcp option stripping on the tcpinc mailing list (see below). Two problem cases have been identified: > > 1) Strip of non-SYN option while SYN-options pass correctly tracebox (http://www.tracebox.org) could be used to program such tests, but I don't think that someone has done this analysis Micchio's paper ( http://conferences.sigcomm.org/imc/2011/docs/p181.pdf ) notes : All the paths which passed unknown options in the SYN also passed both known and unknown options in data segments. In the tables, the “Removed” rows in- dicate that packets on that path arrive with the option removed from the packet. For the unknown options in the SYN packet, this was the only anomaly we found; no path modified the option or failed to deliver the packet due to its presence. In addition, all the paths which passed the unknown option in the SYN also passed un- known options in data segments. This bodes well for deployability of new TCP options - testing in the SYN and SYN/ACK is sufficient to determine that new op- tions are safe to use throughout the connection. Our test did not distinguish between middleboxes that stripped options from SYNs and those that stripped options from SYN/ACKs. With hindsight, this was an unfortunate limitation of our methodology that uses a stateless responder. However it is clear that any extension using TCP options to negotiate functional- ity should be robust to stripped unknown options in SYN/ACK packets, even if they are passed in SYNs. If it is crucial that the server knows whether or not the client received the option in the SYN/ACK, the proto- col must take this into account. For example, TcpCrypt requires that the first non-SYN packet from the client contains the INIT1 option - if this is missing, TcpCrypt moves to the disabled state and falls back to regular TCP behavior. > > 2) Reflection of SYN options in the SYN/ACK (by load-balancers/proxies) > > Does anybody have further data here? For point 2, there is some data concerning MPTCP, but this applies to ENO as well. https://academic-network-security.research.nicta.com.au/mptcp/deployment/ Olivier Mehani and his colleagues probe the Alexa top 1M on a regular basis to verify the deployment of MPTCP servers. On the plot, you can see two parts : - before September 2015 where they report the number of servers that replied to their SYN+MPCAPABLE with a SYN+ACK+MPCAPABLE - after September 2015 where they checked whether the returned MPCAPABLE option was a mirror of the one sent in the SYN segment. The vast majority of the servers that return the MPCAPABLE option are middleboxes that simply mirror this option. The geolocation of these servers points to China... I guess that Olivier could provide more information about their tests Olivier From nobody Thu May 5 04:24:13 2016 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E1112D149 for ; Thu, 5 May 2016 04:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=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 BNi__dFazBrz for ; Thu, 5 May 2016 04:24:10 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id E1A0B12D141 for ; Thu, 5 May 2016 04:24:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CQCgDsLCtXPN/WLHlegzhTfbs0JoUgRAQCAoEuTQEBAQEBAQcBAQEBQkBBEgGDbgEBBFYPFBALGAkTEg8FJQoaE4gpD752AQEBAQEBBAEBAQEBEwQEhiCETIJghQqCLgWYGlCBBYQniBMKiUSFT480hF8qMAEBgmWFcwEBAQ Received: from ppp121-44-214-223.lns20.syd7.internode.on.net (HELO cancey.narf.ssji.net) ([121.44.214.223]) by ipmail05.adl6.internode.on.net with ESMTP; 05 May 2016 20:54:06 +0930 Received: by cancey.narf.ssji.net (sSMTP sendmail emulation); Thu, 05 May 2016 21:24:04 +1000 Date: Thu, 5 May 2016 21:24:04 +1000 From: Olivier Mehani To: Olivier Bonaventure Message-ID: <20160505112404.GD1946@cancey.fritz.box> References: <87twih5ot6.fsf@ta.scs.stanford.edu> <7067A730-5036-4CAC-9510-806EC0F18CD6@tik.ee.ethz.ch> <572A1D83.6060804@uclouvain.be> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="J5MfuwkIyy7RmF4Q" Content-Disposition: inline In-Reply-To: <572A1D83.6060804@uclouvain.be> X-Accept-Language: fr, en, es OpenPGP: id=4435CF6A7C8DDD9BE2DEF5F9F012A6E298C66655; preference=signencrypt; url=https://olivier.mehani.name/olivier.mehani.pgp.asc User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: maprg@irtf.org, Simone Ferlin-Oliveira , Mirja =?iso-8859-15?Q?K=FChlewind?= , Ralph Holz Subject: Re: [Maprg] [tcpinc] Fwd: TCP-ENO draft issues X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 11:24:12 -0000 --J5MfuwkIyy7RmF4Q Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Mirja, Olivier, On Wed, May 04, 2016 at 06:04:19PM +0200, Olivier Bonaventure wrote: > >2) Reflection of SYN options in the SYN/ACK (by load-balancers/proxies) > >Does anybody have further data here? > For point 2, there is some data concerning MPTCP, but this applies to ENO= as > well. > https://academic-network-security.research.nicta.com.au/mptcp/deployment/ > I guess that Olivier could provide more information about their tests Yes. Essentially, we get Alexa dumps, resolve them with team Cymru's APIs, scan them with a patch version of zmap them to see if they support MPTCP. This step essentially creates a TCP packet from scratch, and our patch add the MP_CAPABLE option, and check for its presence on return packets. For all those IPs for which we received an MP_CAPABLE option back, we then wget the default HTTP page from a different machine. This machine runs an MPTCP-enabled kernel (unlike the scanning one above, as zmap does the packet building), so the wget session allows to have a full transaction, which allows us to capture other MPTCP options from the remote hosts. Since Olivier pointed out the problem of mirroring middle boxes, we started inspecting the value of the sender's key, which should be different when coming from the remote host. In the case of mirroring middle-boxes, this is obviusly not the case. The second bit is a pretty ad-hoc, so I don't think it will work as well as tracebox, but for Internet-wide (IPv4) scans, zmap is a pretty good bet to do some coarse filtering. Adding new options there is relatively straightforward [1]; we implemented a separate synscan probe module to be able to merge upstream changes more easily, but you could otherwise do it straight into the upstream synscan. [0] https://ext.npc.nicta.com.au/projects/mptcpscan/repository/zmap [1] https://ext.npc.nicta.com.au/projects/mptcpscan/repository/zmap/revisio= ns/mptcpscan/entry/src/probe_modules/module_mptcp_synscan.c --=20 Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Confidentiality cannot be guaranteed on emails sent or received unencrypted. --J5MfuwkIyy7RmF4Q Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJXKy1UXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQyQkQxRkUwMkM5ODdENDM4QTMzNkZEMkFB RENGNzJFMDZEQkMzMDU3AAoJEK3PcuBtvDBXKggH/3a+lzfMLwW/Y1VdSKzFdKbQ n2KgIZ6bSmX7IXGzuuvITFtmgzYTV7EptKGHjOQRwSGvCVhtmSyC0BIGDgiRmeyE nHF0IFT4EdcFlP9gaX2/wpI4auyZlsPDM2Jwn9sfrcehmQQAIG+Q3lllADPfJ13s 8vnb2yRPCwGEWD87btFsGJ3g+Q5nJ+VwKu6VFFQM3U3inSAMIIZwvxUOYPVU3X0/ +EndJ4d7QSrsKlWWVk+nCNPS1C2q01q7Njh7Fs/dSNTYWSuLXpoilozD5xyyNM3+ fFvJVPfyeqr2LVOZyUIrOVSVa8gv3hSZS2odyQY+Ms5/HI8ZTf5kNjiYXROKX2g= =oKyJ -----END PGP SIGNATURE----- --J5MfuwkIyy7RmF4Q-- From nobody Thu May 12 07:06:00 2016 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2948912D6AE for ; Thu, 12 May 2016 07:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 53eGvdLljc-G for ; Thu, 12 May 2016 07:05:56 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 842DB12D688 for ; Thu, 12 May 2016 07:05:40 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D2ACA1260 for ; Thu, 12 May 2016 16:05:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id dFzw7ZYjXiWW for ; Thu, 12 May 2016 16:05:21 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 12 May 2016 16:05:38 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 196E62004E for ; Thu, 12 May 2016 16:05:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id H1omaozf1u7z for ; Thu, 12 May 2016 16:05:37 +0200 (CEST) Received: from exchange.jacobs-university.de (shubcas01.jacobs.jacobs-university.de [10.70.0.122]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 15CE620047 for ; Thu, 12 May 2016 16:05:37 +0200 (CEST) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS01.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0279.002; Thu, 12 May 2016 16:05:36 +0200 From: "Bajpai, Vaibhav" To: "maprg@irtf.org" Thread-Topic: [dagstuhl seminar]: global measurements: practice and experience Thread-Index: AQHRrFdbIKnxhM0ZCEaQsv2UaPFcXA== Date: Thu, 12 May 2016 14:05:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.50.203.30] Content-Type: multipart/signed; boundary="Apple-Mail=_FC7E896C-CB6C-4AD0-8153-E448A35D1936"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Cc: "Bajpai, Vaibhav" Subject: [Maprg] [dagstuhl seminar]: global measurements: practice and experience X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 14:05:59 -0000 --Apple-Mail=_FC7E896C-CB6C-4AD0-8153-E448A35D1936 X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear MAPRG, -- sorry for cross-posting. A SIGCOMM CCR article summarising the Dagstuhl seminar on =E2=80=98Global = Measurements: Practice and Experience=E2=80=99 just came online [a]. Thought to share = it with you: [a] = http://www.sigcomm.org/sites/default/files/ccr/papers/2016/April/0000000-0= 000004.pdf Background: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We recently helped organise a Dagstuhl seminar on Global Measurements: Practice and Experience [b] from January 04 =E2=80=93 07, 2016. This was = a followup of the seminar on Global Measurement Framework [c] which focused on the = development of global Internet measurement platforms and associated metrics. [b] http://www.dagstuhl.de/16012 [c] http://www.dagstuhl.de/13472 The second seminar aimed at discussing the practical experience gained = with building global measurement platforms. It brought together people who = are actively involved in the design and maintenance of global measurement = systems, who do research on the data delivered by global measurement systems, and = who use data derived from global measurement systems in order to manage = networks or services or as input for regulatory decisions. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Best, Vaibhav =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Vaibhav Bajpai www.vaibhavbajpai.com Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --Apple-Mail=_FC7E896C-CB6C-4AD0-8153-E448A35D1936 X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXNI2vAAoJEHR3XKwTWKOZVSoH+gJ9/3jZwyciwV7djvVxvW0y hbF/dmkf6/oxAmYgRVVx2xJDR0umJMqbb/pktwvLuZIBMBdySX+nTzOfNkEC9GMO RABMNygliCNi1g2HChirHxUJzWvIEZ9V6auu7ihRVNb1cAUh/44xhYy9b8Z8TavL Wr36HhnzkixMEwltiJaOXDcbfhIWwvOPJWtF2uzpF7BWlf3FUYsXvxEJUyhIRrdR KX+kVUtCaNDKEwIHxS3QyTXPyF+4NQGheVmv7D8KpMbcxcbS9bHus53ypHSlkAwX 5vZxDSWl56F8vbGAoGF1Gs7LU6av4Pz1BQay0HNOUq8zGOGKXcaYHg4hM9esuk0= =VvKc -----END PGP SIGNATURE----- --Apple-Mail=_FC7E896C-CB6C-4AD0-8153-E448A35D1936-- From nobody Mon May 23 13:06:59 2016 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF56112D1B6 for ; Mon, 23 May 2016 13:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7b-HR6IK0LM5 for ; Mon, 23 May 2016 13:06:55 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52DE112DB30 for ; Mon, 23 May 2016 13:06:55 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id y126so80930968qke.1 for ; Mon, 23 May 2016 13:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version; bh=H1ZmE4r5fWX6f2sb5NmZZp6z/+lILCubKJ18OnnQTjU=; b=zMgz7SnmqUenY1dB8AyUfwDneXbHAwGE9IeZ1t4Kg8WixwmZc2va66cz8RWWOpeMc+ 82qEO6DA04ktz6K0rZqr2LCQOQRXR0fCuQAzz4vI1yVTXvjagl+6OdnpUV0CKizKQ/6P YFYZDTRTaMoRBr4doHOCVGVI15jSotYIlZLj1TALpt2SPLdx6M1hfxX1zPOlpPc8q9Gs q3NO5Ci9TUfuAEQmcz425dbXhZs05DtzFXdfud4O5RN+mbDd7EYYOIlc15/SqU1S3jgu pJG4v72fWJkTevfLkUgfy4hRMZ6mHRfsh+xBbAjtF2fDkIn0JyYHnKgNpHftc7I/4Jcn aulw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version; bh=H1ZmE4r5fWX6f2sb5NmZZp6z/+lILCubKJ18OnnQTjU=; b=KU700Pn4OBuHXRXYaGWKIitbSgmf4hKvuyCQpwwmxPGjp7KVA405s0XToQezIehPME v0xRPJuDzhd/+ir21FAiPXWTT/Oqz43r+WsCdwPDq85d5m5jykCbg57Hw1yiLnuonGEL 77BsUje0j7L4BvM0KeFzdIOWpGYgeBNOM52yLNzu90v0khcENiN+AieULAcb1FTkrL7S vdUEcbsA1f4m1dSmKkS31R34nBuxun6jb+pQH0TjCkcmkW9WqVCU1jLYQvB5GT5wK8D7 UzCQEcAIJm8tnS79CgEqB3I1iCReRUJbankY+LG2WeUnTWUZ328iVb9Nz3VAruL8oJzZ Sv7g== X-Gm-Message-State: ALyK8tLX82xpaBAVX1RCEd7ZfUTXpD+WIcT4+h/Xe2Yu3oH4vMY3bb1WH7rAY6sAUWh0Pw== X-Received: by 10.200.47.183 with SMTP id l52mr728369qta.24.1464034014284; Mon, 23 May 2016 13:06:54 -0700 (PDT) Received: from [172.28.13.142] ([2001:4878:8000:60:e4a3:69f4:d0db:65df]) by smtp.gmail.com with ESMTPSA id 39sm14114944qgg.8.2016.05.23.13.06.53 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 May 2016 13:06:53 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.16.0.160506 Date: Mon, 23 May 2016 16:06:51 -0400 From: Aaron Falk To: Message-ID: <8EBBDE7D-C6A9-446B-84B2-67459257F591@gmail.com> Thread-Topic: Is UDP a trash heap? Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3546864412_1095812073" Archived-At: Subject: [Maprg] Is UDP a trash heap? X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 20:06:58 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3546864412_1095812073 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable See thread and cited draft below.=C2=A0 I=E2=80=99ve heard =E2=80=9CUDP is a trash heap=E2=80=9D = invoked multiple times.=C2=A0 Are there any broad based measurements of UDP loss= rates for ports other than 53?=C2=A0 Is IPv6 different than IPv4 in this regard= ? =20 --aaron =20 From: Spud on behalf of Ca By Date: Monday, May 23, 2016 at 11:51 AM To: Tom Herbert Cc: Toerless Eckert , Michael Welzl ,= Joe Touch , "Scharf, Michael (Nokia - DE)" , "spud@ietf.org" , Jana Iyengar , C= hristian Huitema Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transpo= rts-over-udp-00.txt =20 On Monday, May 23, 2016, Tom Herbert wrote: On Sun, May 22, 2016 at 1:06 PM, Ca By wrote: > >> >> Now all this being said, I also don=E2=80=99t fully get why some folks have su= ch a >> big problem with running stuff over UDP. I=E2=80=99m not against doing that, i= f only >> as a temporary solution that would serve to convince people that the >> transport (option, ..) is useful. >> In a TAPS world, it=E2=80=99s just another option to try=E2=80=A6 >> > > The fact that udp is mostly (by volume) internet attack traffic is my > concern with udp. > > If legitimate traffic starts using udp in volume, it will make distiguish= ing > and thwarting voulmetric attacks very difficult at scale. Without current= ly > curbing n * 100g blasts of udp traffic with blanket policers, i would not= be > able to keep my network up... This is a daily issue. For example, my usu= al > udp volume is about 1%. If it goes to 10% suddenly, it is likely smart to > drop 11% and onwards as a 10x increase in udp is 100% certainly not legit= . > > My request to quic and spud is simply use a different transport protocol > number so that their interesting and innovative traffic does not run up > against the many network policers that are required to enforce well known > baselines of good normal udp traffic. The quic folks say that they cannot= do > that since 10 year old cpe only passes udp and tcp, then they rant about > ossified stacks and how we need to put everything on udp to make progess = ... > Seems like they are just choosing to ossify on udp ... And udp is alread= y > considered trash (reflection attacks) ...So we agree to disagree, i guess > Isn't any other protocol besides TCP also considered trash right now? =20 My network only "manages" udp. Ymmv.=20 =20 UDP based transport protocols would use well know port numbers. A=20 firewall can allow UDP port X that carries a=20 =20 A "firewall" is a enterprise solution that does not scale for large nationa= l internet providers in the usa=20 =20 Yes, the bulk of the trash is less than 20 source ports (chargen, ntp, snmp= , ntp, dns, ....). But we also get very large bot swarms doing straight pack= et attacks with udp. Even a novice like me can write to udp sockets in pyth= on on any port and stuff data through it.=20 =20 properly congestion controlled protocols not subject to reflection attacks, but disallow other UDP ports. Tom > https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 > > > >> Cheers, >> Michael >> > _______________________________________________ Spud mailing list Spud@ietf= .org https://www.ietf.org/mailman/listinfo/spud=20 --B_3546864412_1095812073 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

See thread and cited draft below.=C2=A0 I’ve heard “U= DP is a trash heap” invoked multiple times.=C2=A0 Are there any broad base= d measurements of UDP loss rates for ports other than 53?=C2=A0 Is IPv6 differen= t than IPv4 in this regard?

 

--aaron

 

From: Spud <spud-bounces@ietf.org> on behalf of Ca = By <cb.list6@gmail.com>
Date: Monday, May 23, 2016 at 11:51 = AM
To: Tom Herbert <tom@herbertland.com>
Cc: Toerl= ess Eckert <eckert@cisco.com>, Michael Welzl <michawe@ifi.uio.no>= ;, Joe Touch <touch@isi.edu>, "Scharf, Michael (Nokia - DE)"= <michael.scharf@nokia.com>, "spud@ietf.org" <spud@ietf.o= rg>, Jana Iyengar <jri@google.com>, Christian Huitema <huitema@m= icrosoft.com>
Subject: Re: [Spud] Fwd: New Version Notification= for draft-herbert-transports-over-udp-00.txt

 



On Monday, May 23, 2016, Tom Herbert <tom@herbertland.com> wrote:

On Sun, May 22, 2016 at 1:06 PM, Ca By <c= b.list6@gmail.com> wrote:
>
>>
>> Now all thi= s being said, I also don’t fully get why some folks have such a
>> big problem with running stuf= f over UDP. I’m not against doing that, if only
>> as a temporary solution that would serve to c= onvince people that the
>> transport (option, ..) is useful.
>= ;> In a TAPS world, it’s just another option to try…
>>
>
> The fact = that udp is mostly (by volume) internet attack traffic  is my
> concern with udp.
>
&= gt; If legitimate traffic starts using udp in volume, it will make distiguis= hing
> and thwarting voulmetric attacks very difficult at scale. Witho= ut currently
> curbing n * 100g blasts of udp traffic with blanket pol= icers, i would not be
> able to keep my network up... This is a daily = issue.  For example, my usual
> udp volume is about 1%. If it goe= s to 10% suddenly, it is likely smart to
> drop 11% and onwards as a 1= 0x increase in udp is 100% certainly not legit.
>
> My request t= o quic and spud is simply use a different transport protocol
> number = so that their interesting and innovative traffic does not run up
> aga= inst the many network policers that are required to enforce well known
&g= t; baselines of good normal udp traffic. The quic folks say that they cannot= do
> that since 10 year old cpe only passes udp and tcp, then they ra= nt about
> ossified stacks and how we need to put everything on udp to= make progess ...
> Seems like they are just choosing to ossify on udp= ...  And udp is already
> considered trash (reflection attacks) = ...So we agree to disagree, i guess
>
Isn't any other protocol besi= des TCP also considered trash right now?

 

My networ= k only "manages" udp.  Ymmv. 

<= div>

 

UDP based transport protocols woul= d use well know port numbers. A 

firewall can allow = UDP port X that carries a 

 

A "firewall&q= uot; is a enterprise solution that does not scale for large national interne= t providers in the usa 

 

Yes, the bulk of the trash i= s less than 20 source ports (chargen, ntp, snmp, ntp, dns, ....). But we als= o get very large bot swarms doing straight packet attacks with udp.  Ev= en a novice like me can write to udp sockets in python on any port and stuff= data through it. 

 

properly congestion

controlled protocols not s= ubject to reflection attacks, but disallow
other UDP ports.

Tom
> https://tools.ietf.org/html/draft-byrne-opsec-udp-advi= sory-00
>
>
>
>> Cheers,
>> Michael<= br>>>
>

__________= _____________________________________ Spud mailing list Spud@ietf.org https:= //www.ietf.org/mailman/listinfo/spud

--B_3546864412_1095812073-- From nobody Tue May 24 01:50:51 2016 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3E112D09D for ; Tue, 24 May 2016 01:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 3K_eSRZZhsnD for ; Tue, 24 May 2016 01:50:44 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3553B12D0EB for ; Tue, 24 May 2016 01:50:44 -0700 (PDT) Received: from [IPv6:2001:67c:64:42:552e:8a9f:18db:58c6] (unknown [IPv6:2001:67c:64:42:552e:8a9f:18db:58c6]) by trammell.ch (Postfix) with ESMTPSA id C49C51A13C3; Tue, 24 May 2016 10:50:11 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_ADECA1F8-3C8C-4BF2-B88D-A9A201B9FB54"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: <8EBBDE7D-C6A9-446B-84B2-67459257F591@gmail.com> Date: Tue, 24 May 2016 10:50:10 +0200 Message-Id: <0F1C206A-FF46-4AC1-ACD4-0AE89194036C@trammell.ch> References: <8EBBDE7D-C6A9-446B-84B2-67459257F591@gmail.com> To: Aaron Falk X-Mailer: Apple Mail (2.3124) Archived-At: Cc: maprg@irtf.org Subject: Re: [Maprg] Is UDP a trash heap? X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 08:50:47 -0000 --Apple-Mail=_ADECA1F8-3C8C-4BF2-B88D-A9A201B9FB54 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Aaron, "Is UDP a trash heap" is, I think, really two questions: one of = connectivity, and one of traffic quality. Your second question goes to = connectivity, so let's look at that one first. I don't know of a lot of data for connectivity, blocking, and impairment = other than for port 53, either in raw or aggregate form. Our talk at the = last maprg meeting looked into RIPE Atlas based UDP differential = connectivity and incidence of complete blocking on networks with RIPE = Atlas probes on them, and we're presently working on measuring = differential treatment between UDP and TCP at relatively low (single = flow) data rates, and hope to have something we can share on this = shortly. (As an aside, searching for related work for the paper under = submission on this was an enlightening activity. Academia seems to find = this question uninteresting.) As noted over on the spud@ietf.org list, there are other questions about = UDP vs TCP treatment that we need answers to as well: distribution of = NAT timers on UDP NAT, prevalence and distribution of UDP rate limiting. = (The second question is of course hard to answer with active measurement = unless you're willing to run DoS attacks.) As to traffic quality, that's an entirely separate question, answerable = only by passive measurement, with all the caveats associated therewith. = A simple number "n% of UDP is crap" is useless without knowing how much = productive UDP traffic there is on a given network, and different links = and different networks look wildly different in this respect. I don't = have a lot of answers here, but will think about how to get them. Thanks, cheers, Brian > On 23 May 2016, at 22:06, Aaron Falk wrote: >=20 > See thread and cited draft below. I=E2=80=99ve heard =E2=80=9CUDP is = a trash heap=E2=80=9D invoked multiple times. Are there any broad based = measurements of UDP loss rates for ports other than 53? Is IPv6 = different than IPv4 in this regard? >=20 > --aaron >=20 > From: Spud on behalf of Ca By = > Date: Monday, May 23, 2016 at 11:51 AM > To: Tom Herbert > Cc: Toerless Eckert , Michael Welzl = , Joe Touch , "Scharf, Michael (Nokia = - DE)" , "spud@ietf.org" , Jana = Iyengar , Christian Huitema > Subject: Re: [Spud] Fwd: New Version Notification for = draft-herbert-transports-over-udp-00.txt >=20 >>=20 >>=20 >> On Monday, May 23, 2016, Tom Herbert wrote: >>> On Sun, May 22, 2016 at 1:06 PM, Ca By wrote: >>> > >>> >> >>> >> Now all this being said, I also don=E2=80=99t fully get why some = folks have such a >>> >> big problem with running stuff over UDP. I=E2=80=99m not against = doing that, if only >>> >> as a temporary solution that would serve to convince people that = the >>> >> transport (option, ..) is useful. >>> >> In a TAPS world, it=E2=80=99s just another option to try=E2=80=A6 >>> >> >>> > >>> > The fact that udp is mostly (by volume) internet attack traffic = is my >>> > concern with udp. >>> > >>> > If legitimate traffic starts using udp in volume, it will make = distiguishing >>> > and thwarting voulmetric attacks very difficult at scale. Without = currently >>> > curbing n * 100g blasts of udp traffic with blanket policers, i = would not be >>> > able to keep my network up... This is a daily issue. For example, = my usual >>> > udp volume is about 1%. If it goes to 10% suddenly, it is likely = smart to >>> > drop 11% and onwards as a 10x increase in udp is 100% certainly = not legit. >>> > >>> > My request to quic and spud is simply use a different transport = protocol >>> > number so that their interesting and innovative traffic does not = run up >>> > against the many network policers that are required to enforce = well known >>> > baselines of good normal udp traffic. The quic folks say that they = cannot do >>> > that since 10 year old cpe only passes udp and tcp, then they rant = about >>> > ossified stacks and how we need to put everything on udp to make = progess ... >>> > Seems like they are just choosing to ossify on udp ... And udp is = already >>> > considered trash (reflection attacks) ...So we agree to disagree, = i guess >>> > >>> Isn't any other protocol besides TCP also considered trash right = now? >>>=20 >>=20 >> My network only "manages" udp. Ymmv. >>=20 >>> UDP based transport protocols would use well know port numbers. A >>> firewall can allow UDP port X that carries a >>=20 >> A "firewall" is a enterprise solution that does not scale for large = national internet providers in the usa >>=20 >> Yes, the bulk of the trash is less than 20 source ports (chargen, = ntp, snmp, ntp, dns, ....). But we also get very large bot swarms doing = straight packet attacks with udp. Even a novice like me can write to = udp sockets in python on any port and stuff data through it. >>=20 >>> properly congestion >>> controlled protocols not subject to reflection attacks, but disallow >>> other UDP ports. >>>=20 >>> Tom >>>=20 >>> > https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 >>> > >>> > >>> > >>> >> Cheers, >>> >> Michael >>> >> >>> > >> _______________________________________________ Spud mailing list = Spud@ietf.orghttps://www.ietf.org/mailman/listinfo/spud > _______________________________________________ > Maprg mailing list > Maprg@irtf.org > https://www.irtf.org/mailman/listinfo/maprg --Apple-Mail=_ADECA1F8-3C8C-4BF2-B88D-A9A201B9FB54 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXRBXDAAoJEIoSt78L6kajdpwP/2m3G4+Wk0x3SJqAnPp4iVG5 goHWcf9saWxyWep4VHrtq04mezhcEjBeFs0BVccHQBnCMhDZsAy09Izjvc2JoYbU NMbaaWug18wfWsYxRl4cJlDqAXtfJ+3xifnoNzD/2ty7Ns0nkFvMN8Ef7P33R6Xb dX4qp3kPzR/jE40mjJOBTstW2L3m8cGCQ8h2R0EFadpaWf1jxnRhHnnnmg61t9/4 7fUOiSR/uN/cUcO04XhHJj91WHy9VRRNLV1StBCghwjPlIEhhpyPHIIitprZr+NT RHMyfatCQ/7bzkcrK0WRGY7U9POgdTUxqWyFbk+d5j8Y/msSCU+1QruU8tz0YUOD gk/J4I4vbemnpxokywcgpLTsn3h+nixOHzSQPUr5lXRwr5ABtLuWw8ChpIsTXazu t15I777WdEt5dBwnIXlg5bGwzNaeaKc8iO2LE7HrnpBRPL2yIud85jfleHCk86yB Q7t3IE3Ld9O56+i4Z9F/ggZze2DOfvSQ8jp/JHZjB7Izj6KoQo70Ey9nY+hCwtfX frWvfan+3+c7NDF1Gx0qwFr2hmLNrZwNhyLAHIga+jaCB/Y1lJCRscSmwelT0DTO SrufWk7d+Kt/uV45H3GwR5Pd5bc148b9cjdOVQC5KMkdYi+RFgxWII3Y1CcPm26b iNPi+dRvdCSp3Gp5Od8I =t5FO -----END PGP SIGNATURE----- --Apple-Mail=_ADECA1F8-3C8C-4BF2-B88D-A9A201B9FB54-- From nobody Tue May 24 01:58:33 2016 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D171712D1EB for ; Tue, 24 May 2016 01:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.347 X-Spam-Level: X-Spam-Status: No, score=-8.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 BJdzcOFX40FT for ; Tue, 24 May 2016 01:58:30 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74D2512D0EB for ; Tue, 24 May 2016 01:58:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.26,359,1459839600"; d="asc'?scan'208";a="112795432" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx142-out.netapp.com with ESMTP; 24 May 2016 01:58:11 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 24 May 2016 01:58:01 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::7db0:a96:265e:db5e%21]) with mapi id 15.00.1156.000; Tue, 24 May 2016 01:58:01 -0700 From: "Eggert, Lars" To: Brian Trammell Thread-Topic: [Maprg] Is UDP a trash heap? Thread-Index: AQHRtS6pyf4ATQ5qmkSSWHNzhh7PJZ/IPYkAgAACOgA= Date: Tue, 24 May 2016 08:58:01 +0000 Message-ID: References: <8EBBDE7D-C6A9-446B-84B2-67459257F591@gmail.com> <0F1C206A-FF46-4AC1-ACD4-0AE89194036C@trammell.ch> In-Reply-To: <0F1C206A-FF46-4AC1-ACD4-0AE89194036C@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_AF2240DD-72DE-4CF2-A434-76BBB74B5844"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: Aaron Falk , "maprg@irtf.org" Subject: Re: [Maprg] Is UDP a trash heap? X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 08:58:32 -0000 --Apple-Mail=_AF2240DD-72DE-4CF2-A434-76BBB74B5844 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2016-05-24, at 10:50, Brian Trammell wrote: > As noted over on the spud@ietf.org list, there are other questions = about UDP vs TCP treatment that we need answers to as well: distribution = of NAT timers on UDP NAT, prevalence and distribution of UDP rate = limiting. (The second question is of course hard to answer with active = measurement unless you're willing to run DoS attacks.) There is some (now old) data on this in our IMC paper: = http://conferences.sigcomm.org/imc/2010/papers/p260.pdf NAT timers are shorter, and rate limiting more prevalent. Lars --Apple-Mail=_AF2240DD-72DE-4CF2-A434-76BBB74B5844 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXRBehAAoJEFS1wwm/cMFXdmkP/3+RBTlqasBCdyzbuk45NEGf C0G/M7klArVRo2jS7VudwfQnasiSx/N1mHlqKe5Kp2i8/eMdvWjTpTgCVMzNI48v 5SkSA/LL85iVxqHVlylFFhU3pxf6NYlPMgQiXed6tXhcxcnsJXDL1cTxAcPukTgz yrRKSB+0L5hTYbx1JT88phKqMee3QO8sfd4dCcg8SQxQ45S1Q4j9ta4vGpcRENnV A1xtlorn9YvnszS9K1ujl4qyPLyego/R1AtCc4do0D2LgvIlkojl8K/Nj0XJvr/f 6UawjE3+ynGhXLGvZdulmPpfbBR4ypWoYA/XcjHOoYNE1g/Slq/lueGK/GrbCgz4 TnEIkeCSflXAonduadNir/deCJrfiozcWvbqD0v0wQjl6wtc9w7e377TPxzN8ctT Ue0kRuvpm567Txwz33Bhi2dqPivOCwcaVl5wIuOfG3enRVjJ1g7QIwvnsNos2jc2 f9KCeuJH18LIYWF5ZuK4OZUZ8PvuuBrVvqlINSkFNjeifwz/JL1fyp/cEmRXWu/U upRqVb55abRQE0XzSK59mGRHw02CRj2Owid0zelLu3qdonn41XC4XnFoXmtNOS8k TI8MHLjjt6/0a71IhAp9HB+IlQLUaX6RhuQfgrsyj/OxWupEMDMGXNmSkc+he7D9 G4qpRG6sRmXPZ6twRMON =LNyW -----END PGP SIGNATURE----- --Apple-Mail=_AF2240DD-72DE-4CF2-A434-76BBB74B5844-- From nobody Tue May 24 02:11:23 2016 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E1D12D1EB for ; Tue, 24 May 2016 02:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 wFGe6FO9fBaP for ; Tue, 24 May 2016 02:11:21 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id DA14C12D1A5 for ; Tue, 24 May 2016 02:11:20 -0700 (PDT) Received: from [IPv6:2001:67c:64:42:2c53:6307:dcc9:5f34] (unknown [IPv6:2001:67c:64:42:2c53:6307:dcc9:5f34]) by trammell.ch (Postfix) with ESMTPSA id 9F22E1A03C3; Tue, 24 May 2016 11:11:19 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_67C7B154-1BEB-4655-94AB-88C9F35C1BAB"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Tue, 24 May 2016 11:11:18 +0200 Message-Id: References: <8EBBDE7D-C6A9-446B-84B2-67459257F591@gmail.com> <0F1C206A-FF46-4AC1-ACD4-0AE89194036C@trammell.ch> To: "Eggert, Lars" , Paul Hoffman X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Aaron Falk , "maprg@irtf.org" Subject: Re: [Maprg] Is UDP a trash heap? X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 09:11:22 -0000 --Apple-Mail=_67C7B154-1BEB-4655-94AB-88C9F35C1BAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Lars, thanks for the link! had am (admittedly vague) memory of this paper. = Rerunning these experiments on a modern zoo of middleboxes (copying Paul = Hoffman, who might know where we could find such a thing ;) ) would be a = worthwhile activity, to see if there's been any change here in the = intervening six years. Cheers, Brian > On 24 May 2016, at 10:58, Eggert, Lars wrote: >=20 > On 2016-05-24, at 10:50, Brian Trammell wrote: >> As noted over on the spud@ietf.org list, there are other questions = about UDP vs TCP treatment that we need answers to as well: distribution = of NAT timers on UDP NAT, prevalence and distribution of UDP rate = limiting. (The second question is of course hard to answer with active = measurement unless you're willing to run DoS attacks.) >=20 > There is some (now old) data on this in our IMC paper: = http://conferences.sigcomm.org/imc/2010/papers/p260.pdf >=20 > NAT timers are shorter, and rate limiting more prevalent. >=20 > Lars --Apple-Mail=_67C7B154-1BEB-4655-94AB-88C9F35C1BAB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXRBq2AAoJEIoSt78L6kajTjAP/0HxgnxEiH6Qphcibv7xxIiJ PqVT4+aYn00VeBO3qrXMNfHcl3uZkvR+svijKI1J4/gcp5eKojoi4vT6ORqOl/Yh 7jB2OL+mGLXDVDvzB+HCHE/kmYE3g9o/ZD1w3F4NM1GgswxmoBLt9P+upOR6Gojl QyfxlbgShhR7ng+fpck1p5BQ1JNMzsbKt/jABf8D7zCKZAj9K/YV7TmPpt2jNKR7 X4g3Y6hr8A20+AIdyTIkSuRk02zaVfcigrxRStQ/0TSrsZoVo6OedmLWTPqek3xf WrQtUWtTnm7nYU1VgxfCEAjhwEqbdLAKRz+fq8FsRH8JIDReUvyVcViW/jX3//qP tuc9zYCPG7XHTm5tXReHnYiRRIG0hUvDRbdgEcGqhf82dIyaEmPxLgyqefD6j6Uj HrafRSVIjCx2HFVS3uanoU+9xG/wB46QT1VNhgEGgKw5rX1dhu9KK8occWie6Uyh b8Wd78ABOPmB82cCptzYM6C7gCn75jNCKAL0gwtTtg06t+UxwQCw7J5rjC/yB2HJ 4QrGB0KlNb20IWnkB/AE5n9ZpPgRgWrZIgkVKzEY9bHCxNyLFAUKJ2ptmb05fgbX 2t51yXpSwsHgQMwoDL7pocMCXsNWApgviWhBpE2HTVpKcY/gzhuvvAKtd42i4FD2 W+dVUpzuokQ9gO4OvUZs =a7SK -----END PGP SIGNATURE----- --Apple-Mail=_67C7B154-1BEB-4655-94AB-88C9F35C1BAB-- From nobody Tue May 24 02:40:11 2016 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9DD12D0CE for ; Tue, 24 May 2016 02:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.347 X-Spam-Level: X-Spam-Status: No, score=-8.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 MhnsTjAenc9y for ; Tue, 24 May 2016 02:40:09 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2CBF12D64C for ; Tue, 24 May 2016 02:40:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.26,359,1459839600"; d="asc'?scan'208";a="112800657" Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx142-out.netapp.com with ESMTP; 24 May 2016 02:39:51 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 24 May 2016 02:39:42 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::7db0:a96:265e:db5e%21]) with mapi id 15.00.1156.000; Tue, 24 May 2016 02:39:42 -0700 From: "Eggert, Lars" To: Brian Trammell Thread-Topic: [Maprg] Is UDP a trash heap? Thread-Index: AQHRtS6pyf4ATQ5qmkSSWHNzhh7PJZ/IPYkAgAACOgCAAAOuAIAAB/iA Date: Tue, 24 May 2016 09:39:41 +0000 Message-ID: References: <8EBBDE7D-C6A9-446B-84B2-67459257F591@gmail.com> <0F1C206A-FF46-4AC1-ACD4-0AE89194036C@trammell.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_4BA8ABF3-52E2-4E68-ADEC-31CE292718A7"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: Aaron Falk , "maprg@irtf.org" , Paul Hoffman , "Markku.Kojo@cs.Helsinki.FI" Subject: Re: [Maprg] Is UDP a trash heap? X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 09:40:10 -0000 --Apple-Mail=_4BA8ABF3-52E2-4E68-ADEC-31CE292718A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Glad you found the paper useful. And I realized that we never published = the throughput measurements for UDP. CC'ing Markku, in case there has = been a later publication or preprint that has that data. > On 2016-05-24, at 11:11, Brian Trammell wrote: >=20 > hi Lars, >=20 > thanks for the link! had am (admittedly vague) memory of this paper. = Rerunning these experiments on a modern zoo of middleboxes (copying Paul = Hoffman, who might know where we could find such a thing ;) ) would be a = worthwhile activity, to see if there's been any change here in the = intervening six years. >=20 > Cheers, >=20 > Brian >=20 >> On 24 May 2016, at 10:58, Eggert, Lars wrote: >>=20 >> On 2016-05-24, at 10:50, Brian Trammell wrote: >>> As noted over on the spud@ietf.org list, there are other questions = about UDP vs TCP treatment that we need answers to as well: distribution = of NAT timers on UDP NAT, prevalence and distribution of UDP rate = limiting. (The second question is of course hard to answer with active = measurement unless you're willing to run DoS attacks.) >>=20 >> There is some (now old) data on this in our IMC paper: = http://conferences.sigcomm.org/imc/2010/papers/p260.pdf >>=20 >> NAT timers are shorter, and rate limiting more prevalent. >>=20 >> Lars >=20 --Apple-Mail=_4BA8ABF3-52E2-4E68-ADEC-31CE292718A7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXRCFmAAoJEFS1wwm/cMFXbVMP/3GJVX/IXBHC0tCoDNLNI1zF 3VtTSo+DEif/X0w751JCv2aMB6bXCoBmxz56R8avdFnWJLlAPSw6lM1jguZ/X8C0 7iKM0wuH8F6dzVAscLB9ILFE9aR7V9kBTeAynXcsUThPposOX/xGRWuMtzTb7k8V 3n3pFucrtFQHfugFXW8xJTaxS5FG5NX7fik6pH3kEiB8+ezBG8GnyYKFAxiHrC0Q mhDQle+Cmnd8gPsavaZfMRfSZLvldaDOm8BrIjdP+uMubz4DMTqvFNno3EvBoiaa TmqKz73loM6RQBQn0iZE8vk7Hy8ssgKteaiKxu39tL/j6U9Oz2+BlRaFuAslRKSV Q0kmYWVAfkZwFdbjzUU9tXhRPKRtBwLv8I/jrqF5YKx1occ+Aof1EhPCTFVomBZE 4GCIWAcgo3ssFkwMmVPp0/9s08lUKK+6JCccR8Cp6WBPN9U21LyoxBbRvWdHWlfX lxf3WDduA/7H7De2g04mWiTXvbekU+VyodRMFP5RCYaB/G8iGboOMHCOT6YveuiW 9BuRTlNU7EbLLWPOVofCUQ46XylRJMl6jS0acPPYZ30WQJ7FXsCR5ax6q+dAzM3C KQiC9RD9D5jsNUsU06B0cTu7yk7J4+mQ451Prw/cAOJlA/dmjMTix1nsqzJ+h4je h6ADe6PBXY5N4O/Pkgxc =zIng -----END PGP SIGNATURE----- --Apple-Mail=_4BA8ABF3-52E2-4E68-ADEC-31CE292718A7-- From nobody Tue May 24 17:38:29 2016 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA4F12D1B5 for ; Tue, 24 May 2016 17:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 H2MQEMnbJiuD for ; Tue, 24 May 2016 17:38:25 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [58.251.152.64]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6623A12D154 for ; Tue, 24 May 2016 17:38:24 -0700 (PDT) Received: from 172.24.1.36 (EHLO SZXEMI404-HUB.china.huawei.com) ([172.24.1.36]) by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLC66469; Wed, 25 May 2016 08:38:19 +0800 (CST) Received: from SZXEMI506-MBX.china.huawei.com ([169.254.5.40]) by SZXEMI404-HUB.china.huawei.com ([10.82.75.40]) with mapi id 14.03.0235.001; Wed, 25 May 2016 08:38:17 +0800 From: "Caozhen (zcao)" To: Aaron Falk , "maprg@irtf.org" Thread-Topic: Is UDP a trash heap? Thread-Index: AQHRtS6tU/bQZgfKo0+1FFrImHB3qp/Iy8vQ Date: Wed, 25 May 2016 00:38:17 +0000 Message-ID: <0ADB5996A09C254EB300AB612DA815082151F4A3@SZXEMI506-MBX.china.huawei.com> References: <8EBBDE7D-C6A9-446B-84B2-67459257F591@gmail.com> In-Reply-To: <8EBBDE7D-C6A9-446B-84B2-67459257F591@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.152.94] Content-Type: multipart/alternative; boundary="_000_0ADB5996A09C254EB300AB612DA815082151F4A3SZXEMI506MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0203.5744F3FC.0055, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.40, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a62d659262d8248122ee4c786aa33b9f Archived-At: Subject: Re: [Maprg] Is UDP a trash heap? X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 00:38:28 -0000 --_000_0ADB5996A09C254EB300AB612DA815082151F4A3SZXEMI506MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgd2FzIHNvbWUgbWVhc3VyZW1lbnQgc3R1ZHkgb2YgdGhlIFVEUCBmbG93cyBpbiB0aGlz IHdvcms6IGh0dHA6Ly9pZWVleHBsb3JlLmllZWUub3JnL3hwbHMvYWJzX2FsbC5qc3A/YXJudW1i ZXI9NzM0OTU4MSZ0YWc9MQ0KDQpUaGlzIHdhcyBhIHN0dWR5IG9mIHRoZSB3ZWNoYXQgKHRoZSBt b3N0IGZhbW91cyBJTSBhcHAgaW4gQ2hpbmEpIFZvSVAgY2FsbHMgYW5kIHZpZGVvIHRyYWZmaWMg KGJvdGggdXNlIFVEUCBiZWFyZXIpLiAgSSBmaW5kIGl0IHVzZWZ1bCBiZWNhdXNlIGl0IHVuY292 ZXJzIG1hbnkgYXNwZWN0cyBvZiB0aGUgVURQIGZsb3dzLCBzdWNoIGFzIHRoZSB1c2Ugb2YgSVNQ LWF3YXJlIHBhdGhzLCBhZ2dyZXNzaXZlIHJldHJhbnNtaXNzaW9uLCBhbmQgYm90aCBkb21lc3Rp YyYgaW50ZXItY29udGluZW50YWwgcGFja2V0IGxvc3MgcmF0ZSwgaG9wcyBhbmQgZGVsYXkuDQoN CkNoZWVycywNClpoZW4NCkZyb206IE1hcHJnIFttYWlsdG86bWFwcmctYm91bmNlc0BpcnRmLm9y Z10gT24gQmVoYWxmIE9mIEFhcm9uIEZhbGsNClNlbnQ6IFR1ZXNkYXksIE1heSAyNCwgMjAxNiA0 OjA3IEFNDQpUbzogbWFwcmdAaXJ0Zi5vcmcNClN1YmplY3Q6IFtNYXByZ10gSXMgVURQIGEgdHJh c2ggaGVhcD8NCg0KU2VlIHRocmVhZCBhbmQgY2l0ZWQgZHJhZnQgYmVsb3cuICBJ4oCZdmUgaGVh cmQg4oCcVURQIGlzIGEgdHJhc2ggaGVhcOKAnSBpbnZva2VkIG11bHRpcGxlIHRpbWVzLiAgQXJl IHRoZXJlIGFueSBicm9hZCBiYXNlZCBtZWFzdXJlbWVudHMgb2YgVURQIGxvc3MgcmF0ZXMgZm9y IHBvcnRzIG90aGVyIHRoYW4gNTM/ICBJcyBJUHY2IGRpZmZlcmVudCB0aGFuIElQdjQgaW4gdGhp cyByZWdhcmQ/DQoNCi0tYWFyb24NCg0KRnJvbTogU3B1ZCA8c3B1ZC1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpzcHVkLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgQ2EgQnkgPGNiLmxp c3Q2QGdtYWlsLmNvbTxtYWlsdG86Y2IubGlzdDZAZ21haWwuY29tPj4NCkRhdGU6IE1vbmRheSwg TWF5IDIzLCAyMDE2IGF0IDExOjUxIEFNDQpUbzogVG9tIEhlcmJlcnQgPHRvbUBoZXJiZXJ0bGFu ZC5jb208bWFpbHRvOnRvbUBoZXJiZXJ0bGFuZC5jb20+Pg0KQ2M6IFRvZXJsZXNzIEVja2VydCA8 ZWNrZXJ0QGNpc2NvLmNvbTxtYWlsdG86ZWNrZXJ0QGNpc2NvLmNvbT4+LCBNaWNoYWVsIFdlbHps IDxtaWNoYXdlQGlmaS51aW8ubm88bWFpbHRvOm1pY2hhd2VAaWZpLnVpby5ubz4+LCBKb2UgVG91 Y2ggPHRvdWNoQGlzaS5lZHU8bWFpbHRvOnRvdWNoQGlzaS5lZHU+PiwgIlNjaGFyZiwgTWljaGFl bCAoTm9raWEgLSBERSkiIDxtaWNoYWVsLnNjaGFyZkBub2tpYS5jb208bWFpbHRvOm1pY2hhZWwu c2NoYXJmQG5va2lhLmNvbT4+LCAic3B1ZEBpZXRmLm9yZzxtYWlsdG86c3B1ZEBpZXRmLm9yZz4i IDxzcHVkQGlldGYub3JnPG1haWx0bzpzcHVkQGlldGYub3JnPj4sIEphbmEgSXllbmdhciA8anJp QGdvb2dsZS5jb208bWFpbHRvOmpyaUBnb29nbGUuY29tPj4sIENocmlzdGlhbiBIdWl0ZW1hIDxo dWl0ZW1hQG1pY3Jvc29mdC5jb208bWFpbHRvOmh1aXRlbWFAbWljcm9zb2Z0LmNvbT4+DQpTdWJq ZWN0OiBSZTogW1NwdWRdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1o ZXJiZXJ0LXRyYW5zcG9ydHMtb3Zlci11ZHAtMDAudHh0DQoNCg0KDQpPbiBNb25kYXksIE1heSAy MywgMjAxNiwgVG9tIEhlcmJlcnQgPHRvbUBoZXJiZXJ0bGFuZC5jb208bWFpbHRvOnRvbUBoZXJi ZXJ0bGFuZC5jb20+PiB3cm90ZToNCk9uIFN1biwgTWF5IDIyLCAyMDE2IGF0IDE6MDYgUE0sIENh IEJ5IDxjYi5saXN0NkBnbWFpbC5jb208amF2YXNjcmlwdDo7Pj4gd3JvdGU6DQo+DQo+Pg0KPj4g Tm93IGFsbCB0aGlzIGJlaW5nIHNhaWQsIEkgYWxzbyBkb27igJl0IGZ1bGx5IGdldCB3aHkgc29t ZSBmb2xrcyBoYXZlIHN1Y2ggYQ0KPj4gYmlnIHByb2JsZW0gd2l0aCBydW5uaW5nIHN0dWZmIG92 ZXIgVURQLiBJ4oCZbSBub3QgYWdhaW5zdCBkb2luZyB0aGF0LCBpZiBvbmx5DQo+PiBhcyBhIHRl bXBvcmFyeSBzb2x1dGlvbiB0aGF0IHdvdWxkIHNlcnZlIHRvIGNvbnZpbmNlIHBlb3BsZSB0aGF0 IHRoZQ0KPj4gdHJhbnNwb3J0IChvcHRpb24sIC4uKSBpcyB1c2VmdWwuDQo+PiBJbiBhIFRBUFMg d29ybGQsIGl04oCZcyBqdXN0IGFub3RoZXIgb3B0aW9uIHRvIHRyeeKApg0KPj4NCj4NCj4gVGhl IGZhY3QgdGhhdCB1ZHAgaXMgbW9zdGx5IChieSB2b2x1bWUpIGludGVybmV0IGF0dGFjayB0cmFm ZmljICBpcyBteQ0KPiBjb25jZXJuIHdpdGggdWRwLg0KPg0KPiBJZiBsZWdpdGltYXRlIHRyYWZm aWMgc3RhcnRzIHVzaW5nIHVkcCBpbiB2b2x1bWUsIGl0IHdpbGwgbWFrZSBkaXN0aWd1aXNoaW5n DQo+IGFuZCB0aHdhcnRpbmcgdm91bG1ldHJpYyBhdHRhY2tzIHZlcnkgZGlmZmljdWx0IGF0IHNj YWxlLiBXaXRob3V0IGN1cnJlbnRseQ0KPiBjdXJiaW5nIG4gKiAxMDBnIGJsYXN0cyBvZiB1ZHAg dHJhZmZpYyB3aXRoIGJsYW5rZXQgcG9saWNlcnMsIGkgd291bGQgbm90IGJlDQo+IGFibGUgdG8g a2VlcCBteSBuZXR3b3JrIHVwLi4uIFRoaXMgaXMgYSBkYWlseSBpc3N1ZS4gIEZvciBleGFtcGxl LCBteSB1c3VhbA0KPiB1ZHAgdm9sdW1lIGlzIGFib3V0IDElLiBJZiBpdCBnb2VzIHRvIDEwJSBz dWRkZW5seSwgaXQgaXMgbGlrZWx5IHNtYXJ0IHRvDQo+IGRyb3AgMTElIGFuZCBvbndhcmRzIGFz IGEgMTB4IGluY3JlYXNlIGluIHVkcCBpcyAxMDAlIGNlcnRhaW5seSBub3QgbGVnaXQuDQo+DQo+ IE15IHJlcXVlc3QgdG8gcXVpYyBhbmQgc3B1ZCBpcyBzaW1wbHkgdXNlIGEgZGlmZmVyZW50IHRy YW5zcG9ydCBwcm90b2NvbA0KPiBudW1iZXIgc28gdGhhdCB0aGVpciBpbnRlcmVzdGluZyBhbmQg aW5ub3ZhdGl2ZSB0cmFmZmljIGRvZXMgbm90IHJ1biB1cA0KPiBhZ2FpbnN0IHRoZSBtYW55IG5l dHdvcmsgcG9saWNlcnMgdGhhdCBhcmUgcmVxdWlyZWQgdG8gZW5mb3JjZSB3ZWxsIGtub3duDQo+ IGJhc2VsaW5lcyBvZiBnb29kIG5vcm1hbCB1ZHAgdHJhZmZpYy4gVGhlIHF1aWMgZm9sa3Mgc2F5 IHRoYXQgdGhleSBjYW5ub3QgZG8NCj4gdGhhdCBzaW5jZSAxMCB5ZWFyIG9sZCBjcGUgb25seSBw YXNzZXMgdWRwIGFuZCB0Y3AsIHRoZW4gdGhleSByYW50IGFib3V0DQo+IG9zc2lmaWVkIHN0YWNr cyBhbmQgaG93IHdlIG5lZWQgdG8gcHV0IGV2ZXJ5dGhpbmcgb24gdWRwIHRvIG1ha2UgcHJvZ2Vz cyAuLi4NCj4gU2VlbXMgbGlrZSB0aGV5IGFyZSBqdXN0IGNob29zaW5nIHRvIG9zc2lmeSBvbiB1 ZHAgLi4uICBBbmQgdWRwIGlzIGFscmVhZHkNCj4gY29uc2lkZXJlZCB0cmFzaCAocmVmbGVjdGlv biBhdHRhY2tzKSAuLi5TbyB3ZSBhZ3JlZSB0byBkaXNhZ3JlZSwgaSBndWVzcw0KPg0KSXNuJ3Qg YW55IG90aGVyIHByb3RvY29sIGJlc2lkZXMgVENQIGFsc28gY29uc2lkZXJlZCB0cmFzaCByaWdo dCBub3c/DQoNCk15IG5ldHdvcmsgb25seSAibWFuYWdlcyIgdWRwLiAgWW1tdi4NCg0KVURQIGJh c2VkIHRyYW5zcG9ydCBwcm90b2NvbHMgd291bGQgdXNlIHdlbGwga25vdyBwb3J0IG51bWJlcnMu IEENCmZpcmV3YWxsIGNhbiBhbGxvdyBVRFAgcG9ydCBYIHRoYXQgY2FycmllcyBhDQoNCkEgImZp cmV3YWxsIiBpcyBhIGVudGVycHJpc2Ugc29sdXRpb24gdGhhdCBkb2VzIG5vdCBzY2FsZSBmb3Ig bGFyZ2UgbmF0aW9uYWwgaW50ZXJuZXQgcHJvdmlkZXJzIGluIHRoZSB1c2ENCg0KWWVzLCB0aGUg YnVsayBvZiB0aGUgdHJhc2ggaXMgbGVzcyB0aGFuIDIwIHNvdXJjZSBwb3J0cyAoY2hhcmdlbiwg bnRwLCBzbm1wLCBudHAsIGRucywgLi4uLikuIEJ1dCB3ZSBhbHNvIGdldCB2ZXJ5IGxhcmdlIGJv dCBzd2FybXMgZG9pbmcgc3RyYWlnaHQgcGFja2V0IGF0dGFja3Mgd2l0aCB1ZHAuICBFdmVuIGEg bm92aWNlIGxpa2UgbWUgY2FuIHdyaXRlIHRvIHVkcCBzb2NrZXRzIGluIHB5dGhvbiBvbiBhbnkg cG9ydCBhbmQgc3R1ZmYgZGF0YSB0aHJvdWdoIGl0Lg0KDQpwcm9wZXJseSBjb25nZXN0aW9uDQpj b250cm9sbGVkIHByb3RvY29scyBub3Qgc3ViamVjdCB0byByZWZsZWN0aW9uIGF0dGFja3MsIGJ1 dCBkaXNhbGxvdw0Kb3RoZXIgVURQIHBvcnRzLg0KDQpUb20NCg0KPiBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtYnlybmUtb3BzZWMtdWRwLWFkdmlzb3J5LTAwDQo+DQo+DQo+DQo+ PiBDaGVlcnMsDQo+PiBNaWNoYWVsDQo+Pg0KPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18gU3B1ZCBtYWlsaW5nIGxpc3QgU3B1ZEBpZXRmLm9yZzxtYWls dG86U3B1ZEBpZXRmLm9yZz4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z cHVkDQo= --_000_0ADB5996A09C254EB300AB612DA815082151F4A3SZXEMI506MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpNaW5nTGlVOw0KCXBhbm9zZS0xOjIgMiA1IDkgMCAwIDAgMCAwIDA7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAz IDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5v c2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJcQE1pbmdMaVUiOw0KCXBhbm9zZS0xOjIgMiA1IDkgMCAwIDAgMCAwIDA7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt Y29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9y PSJ3aGl0ZSIgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlcmUgd2FzIHNvbWUgbWVhc3VyZW1lbnQg c3R1ZHkgb2YgdGhlIFVEUCBmbG93cyBpbiB0aGlzIHdvcms6DQo8YSBocmVmPSJodHRwOi8vaWVl ZXhwbG9yZS5pZWVlLm9yZy94cGxzL2Fic19hbGwuanNwP2FybnVtYmVyPTczNDk1ODEmYW1wO3Rh Zz0xIj5odHRwOi8vaWVlZXhwbG9yZS5pZWVlLm9yZy94cGxzL2Fic19hbGwuanNwP2FybnVtYmVy PTczNDk1ODEmYW1wO3RhZz0xPC9hPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoaXMgd2FzIGEgc3R1ZHkgb2Yg dGhlIHdlY2hhdCAodGhlIG1vc3QgZmFtb3VzIElNIGFwcCBpbiBDaGluYSkgVm9JUCBjYWxscyBh bmQgdmlkZW8gdHJhZmZpYyAoYm90aCB1c2UgVURQIGJlYXJlcikuJm5ic3A7IEkgZmluZCBpdCB1 c2VmdWwgYmVjYXVzZSBpdA0KIHVuY292ZXJzIG1hbnkgYXNwZWN0cyBvZiB0aGUgVURQIGZsb3dz LCBzdWNoIGFzIHRoZSB1c2Ugb2YgSVNQLWF3YXJlIHBhdGhzLCBhZ2dyZXNzaXZlIHJldHJhbnNt aXNzaW9uLCBhbmQgYm90aCBkb21lc3RpYyZhbXA7IGludGVyLWNvbnRpbmVudGFsIHBhY2tldCBs b3NzIHJhdGUsIGhvcHMgYW5kIGRlbGF5LiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlpoZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiBNYXByZyBbbWFpbHRvOm1hcHJnLWJvdW5jZXNAaXJ0Zi5vcmdd DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFhcm9uIEZhbGs8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2Rh eSwgTWF5IDI0LCAyMDE2IDQ6MDcgQU08YnI+DQo8Yj5Ubzo8L2I+IG1hcHJnQGlydGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFtNYXByZ10gSXMgVURQIGEgdHJhc2ggaGVhcD88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNlZSB0aHJlYWQgYW5kIGNpdGVk IGRyYWZ0IGJlbG93LiZuYnNwOyBJ4oCZdmUgaGVhcmQg4oCcVURQIGlzIGEgdHJhc2ggaGVhcOKA nSBpbnZva2VkIG11bHRpcGxlIHRpbWVzLiZuYnNwOyBBcmUgdGhlcmUgYW55IGJyb2FkIGJhc2Vk IG1lYXN1cmVtZW50cyBvZiBVRFAgbG9zcyByYXRlcyBmb3IgcG9ydHMNCiBvdGhlciB0aGFuIDUz PyZuYnNwOyBJcyBJUHY2IGRpZmZlcmVudCB0aGFuIElQdjQgaW4gdGhpcyByZWdhcmQ/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+LS1hYXJvbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Gcm9t Og0KPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+U3B1ZCAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNwdWQtYm91bmNlc0BpZXRmLm9yZyI+c3B1ZC1ib3VuY2VzQGlldGYub3JnPC9hPiZn dDsgb24gYmVoYWxmIG9mIENhIEJ5ICZsdDs8YSBocmVmPSJtYWlsdG86Y2IubGlzdDZAZ21haWwu Y29tIj5jYi5saXN0NkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXks IE1heSAyMywgMjAxNiBhdCAxMTo1MSBBTTxicj4NCjxiPlRvOiA8L2I+VG9tIEhlcmJlcnQgJmx0 OzxhIGhyZWY9Im1haWx0bzp0b21AaGVyYmVydGxhbmQuY29tIj50b21AaGVyYmVydGxhbmQuY29t PC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPlRvZXJsZXNzIEVja2VydCAmbHQ7PGEgaHJlZj0ibWFp bHRvOmVja2VydEBjaXNjby5jb20iPmVja2VydEBjaXNjby5jb208L2E+Jmd0OywgTWljaGFlbCBX ZWx6bCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pY2hhd2VAaWZpLnVpby5ubyI+bWljaGF3ZUBpZmku dWlvLm5vPC9hPiZndDssIEpvZSBUb3VjaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvdWNoQGlzaS5l ZHUiPnRvdWNoQGlzaS5lZHU8L2E+Jmd0OywgJnF1b3Q7U2NoYXJmLCBNaWNoYWVsIChOb2tpYSAt IERFKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbSI+ bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPC9hPiZndDssDQogJnF1b3Q7PGEgaHJlZj0ibWFpbHRv OnNwdWRAaWV0Zi5vcmciPnNwdWRAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86c3B1ZEBpZXRmLm9yZyI+c3B1ZEBpZXRmLm9yZzwvYT4mZ3Q7LCBKYW5hIEl5ZW5nYXIgJmx0 OzxhIGhyZWY9Im1haWx0bzpqcmlAZ29vZ2xlLmNvbSI+anJpQGdvb2dsZS5jb208L2E+Jmd0Oywg Q2hyaXN0aWFuIEh1aXRlbWEgJmx0OzxhIGhyZWY9Im1haWx0bzpodWl0ZW1hQG1pY3Jvc29mdC5j b20iPmh1aXRlbWFAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJl OiBbU3B1ZF0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhlcmJlcnQt dHJhbnNwb3J0cy1vdmVyLXVkcC0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQu MHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207 bWFyZ2luLWJvdHRvbTo1LjBwdCIgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVP VEUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4N Ck9uIE1vbmRheSwgTWF5IDIzLCAyMDE2LCBUb20gSGVyYmVydCAmbHQ7PGEgaHJlZj0ibWFpbHRv OnRvbUBoZXJiZXJ0bGFuZC5jb20iPnRvbUBoZXJiZXJ0bGFuZC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFN1biwgTWF5IDIyLCAyMDE2IGF0IDE6MDYg UE0sIENhIEJ5ICZsdDs8YSBocmVmPSJqYXZhc2NyaXB0OjsiPmNiLmxpc3Q2QGdtYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE5vdyBh bGwgdGhpcyBiZWluZyBzYWlkLCBJIGFsc28gZG9u4oCZdCBmdWxseSBnZXQgd2h5IHNvbWUgZm9s a3MgaGF2ZSBzdWNoIGE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTpNaW5nTGlVIj48YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsmZ3Q7IGJpZyBw cm9ibGVtIHdpdGggcnVubmluZyBzdHVmZiBvdmVyIFVEUC4gSeKAmW0gbm90IGFnYWluc3QgZG9p bmcgdGhhdCwgaWYgb25seTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5Ok1pbmdMaVUiPjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyZndDsgYXMg YSB0ZW1wb3Jhcnkgc29sdXRpb24gdGhhdCB3b3VsZCBzZXJ2ZSB0byBjb252aW5jZSBwZW9wbGUg dGhhdCB0aGU8YnI+DQomZ3Q7Jmd0OyB0cmFuc3BvcnQgKG9wdGlvbiwgLi4pIGlzIHVzZWZ1bC48 YnI+DQomZ3Q7Jmd0OyBJbiBhIFRBUFMgd29ybGQsIGl04oCZcyBqdXN0IGFub3RoZXIgb3B0aW9u IHRvIHRyeeKApjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5Ok1p bmdMaVUiPjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyZndDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTpNaW5nTGlVIj48YnI+DQo8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPiZndDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTpNaW5nTGlVIj48YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg VGhlIGZhY3QgdGhhdCB1ZHAgaXMgbW9zdGx5IChieSB2b2x1bWUpIGludGVybmV0IGF0dGFjayB0 cmFmZmljJm5ic3A7IGlzIG15PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6TWluZ0xpVSI+PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IGNvbmNl cm4gd2l0aCB1ZHAuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 TWluZ0xpVSI+PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6TWluZ0xpVSI+PGJyPg0KPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IElmIGxlZ2l0aW1hdGUgdHJhZmZpYyBzdGFydHMgdXNpbmcg dWRwIGluIHZvbHVtZSwgaXQgd2lsbCBtYWtlIGRpc3RpZ3Vpc2hpbmc8YnI+DQomZ3Q7IGFuZCB0 aHdhcnRpbmcgdm91bG1ldHJpYyBhdHRhY2tzIHZlcnkgZGlmZmljdWx0IGF0IHNjYWxlLiBXaXRo b3V0IGN1cnJlbnRseTxicj4NCiZndDsgY3VyYmluZyBuICogMTAwZyBibGFzdHMgb2YgdWRwIHRy YWZmaWMgd2l0aCBibGFua2V0IHBvbGljZXJzLCBpIHdvdWxkIG5vdCBiZTxicj4NCiZndDsgYWJs ZSB0byBrZWVwIG15IG5ldHdvcmsgdXAuLi4gVGhpcyBpcyBhIGRhaWx5IGlzc3VlLiZuYnNwOyBG b3IgZXhhbXBsZSwgbXkgdXN1YWw8YnI+DQomZ3Q7IHVkcCB2b2x1bWUgaXMgYWJvdXQgMSUuIElm IGl0IGdvZXMgdG8gMTAlIHN1ZGRlbmx5LCBpdCBpcyBsaWtlbHkgc21hcnQgdG88YnI+DQomZ3Q7 IGRyb3AgMTElIGFuZCBvbndhcmRzIGFzIGEgMTB4IGluY3JlYXNlIGluIHVkcCBpcyAxMDAlIGNl cnRhaW5seSBub3QgbGVnaXQuPGJyPg0KJmd0Ozxicj4NCiZndDsgTXkgcmVxdWVzdCB0byBxdWlj IGFuZCBzcHVkIGlzIHNpbXBseSB1c2UgYSBkaWZmZXJlbnQgdHJhbnNwb3J0IHByb3RvY29sPGJy Pg0KJmd0OyBudW1iZXIgc28gdGhhdCB0aGVpciBpbnRlcmVzdGluZyBhbmQgaW5ub3ZhdGl2ZSB0 cmFmZmljIGRvZXMgbm90IHJ1biB1cDxicj4NCiZndDsgYWdhaW5zdCB0aGUgbWFueSBuZXR3b3Jr IHBvbGljZXJzIHRoYXQgYXJlIHJlcXVpcmVkIHRvIGVuZm9yY2Ugd2VsbCBrbm93bjxicj4NCiZn dDsgYmFzZWxpbmVzIG9mIGdvb2Qgbm9ybWFsIHVkcCB0cmFmZmljLiBUaGUgcXVpYyBmb2xrcyBz YXkgdGhhdCB0aGV5IGNhbm5vdCBkbzxicj4NCiZndDsgdGhhdCBzaW5jZSAxMCB5ZWFyIG9sZCBj cGUgb25seSBwYXNzZXMgdWRwIGFuZCB0Y3AsIHRoZW4gdGhleSByYW50IGFib3V0PGJyPg0KJmd0 OyBvc3NpZmllZCBzdGFja3MgYW5kIGhvdyB3ZSBuZWVkIHRvIHB1dCBldmVyeXRoaW5nIG9uIHVk cCB0byBtYWtlIHByb2dlc3MgLi4uPGJyPg0KJmd0OyBTZWVtcyBsaWtlIHRoZXkgYXJlIGp1c3Qg Y2hvb3NpbmcgdG8gb3NzaWZ5IG9uIHVkcCAuLi4mbmJzcDsgQW5kIHVkcCBpcyBhbHJlYWR5PGJy Pg0KJmd0OyBjb25zaWRlcmVkIHRyYXNoIChyZWZsZWN0aW9uIGF0dGFja3MpIC4uLlNvIHdlIGFn cmVlIHRvIGRpc2FncmVlLCBpIGd1ZXNzPGJyPg0KJmd0Ozxicj4NCklzbid0IGFueSBvdGhlciBw cm90b2NvbCBiZXNpZGVzIFRDUCBhbHNvIGNvbnNpZGVyZWQgdHJhc2ggcmlnaHQgbm93PzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk15IG5l dHdvcmsgb25seSAmcXVvdDttYW5hZ2VzJnF1b3Q7IHVkcC4mbmJzcDsmbmJzcDtZbW12LiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlVEUCBiYXNlZCB0cmFuc3BvcnQg cHJvdG9jb2xzIHdvdWxkIHVzZSB3ZWxsIGtub3cgcG9ydCBudW1iZXJzLiBBJm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow Y207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+ZmlyZXdhbGwgY2FuIGFsbG93IFVEUCBwb3J0IFggdGhhdCBjYXJyaWVzIGEmbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5BICZxdW90O2ZpcmV3YWxsJnF1b3Q7IGlzIGEgZW50ZXJwcmlzZSBzb2x1dGlvbiB0aGF0IGRv ZXMgbm90IHNjYWxlIGZvciBsYXJnZSBuYXRpb25hbCBpbnRlcm5ldCBwcm92aWRlcnMgaW4gdGhl IHVzYSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+WWVzLCB0aGUgYnVsayBvZiB0aGUgdHJhc2ggaXMgbGVzcyB0aGFuIDIwIHNvdXJjZSBwb3J0 cyAoY2hhcmdlbiwgbnRwLCBzbm1wLCBudHAsIGRucywgLi4uLikuIEJ1dCB3ZSBhbHNvIGdldCB2 ZXJ5IGxhcmdlIGJvdCBzd2FybXMgZG9pbmcgc3RyYWlnaHQgcGFja2V0IGF0dGFja3Mgd2l0aCB1 ZHAuJm5ic3A7IEV2ZW4gYSBub3ZpY2UgbGlrZSBtZSBjYW4gd3JpdGUgdG8gdWRwIHNvY2tldHMN CiBpbiBweXRob24gb24gYW55IHBvcnQgYW5kIHN0dWZmIGRhdGEgdGhyb3VnaCBpdC4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5wcm9wZXJseSBjb25nZXN0aW9uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+Y29udHJvbGxlZCBwcm90b2NvbHMgbm90IHN1YmplY3QgdG8gcmVmbGVjdGlv biBhdHRhY2tzLCBidXQgZGlzYWxsb3c8YnI+DQpvdGhlciBVRFAgcG9ydHMuPGJyPg0KPGJyPg0K VG9tPGJyPg0KPGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtYnlybmUtb3BzZWMtdWRwLWFkdmlzb3J5LTAwIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnlybmUtb3BzZWMtdWRwLWFkdmlzb3J5LTAw PC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IENoZWVycyw8 YnI+DQomZ3Q7Jmd0OyBNaWNoYWVsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f IFNwdWQgbWFpbGluZyBsaXN0DQo8YSBocmVmPSJtYWlsdG86U3B1ZEBpZXRmLm9yZyI+U3B1ZEBp ZXRmLm9yZzwvYT4gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zcHVkIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3B1ZDwvYT4g PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_0ADB5996A09C254EB300AB612DA815082151F4A3SZXEMI506MBXchi_--