From nobody Sun Feb 1 01:45:43 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075321A8799 for ; Sun, 1 Feb 2015 01:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qw8uPO2Fydb7 for ; Sun, 1 Feb 2015 01:45:39 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 827E51A8798 for ; Sun, 1 Feb 2015 01:45:39 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id fb4so9902137wid.2 for ; Sun, 01 Feb 2015 01:45:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=l10GLxKDSovJjzaNako0hmHGZv8xhpX8twqhNPZVgtM=; b=t+ynfsnjyL3N0l19iTdY/ZqvfKi//hQTtiGRBl67ssiz8CWnCbyzqkuS0CCAFQ7Ts5 kd+PqXcalyWbcswYeZhm83wfeEDQ7lwJnA6gdF8T5TvYkbQQUxVAJKjuZlVqjfUrXopW CJpQw5SFsGWzlY9/Aqrp/Qjzl5hfFpzi7oPBdhmNqJwQ4HozFtgk0CYK3zeRGaOGu4UG C4wXL7JqUjaGKBYpZI1AXGLTjvlZso2Xdz4kmphexttLaqFkoOb2OE6dnfHJOYpwkGlr sl1dTkbrKwiDBSFmsVmJUmx+ZLzSjERTsVvdfcxYVMgM/SUcB2v3H7nWoce8m0DybnS9 nXgw== X-Received: by 10.180.19.228 with SMTP id i4mr3470515wie.13.1422783938300; Sun, 01 Feb 2015 01:45:38 -0800 (PST) Received: from [172.24.251.208] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id u7sm14640043wiy.18.2015.02.01.01.45.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Feb 2015 01:45:37 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Sun, 1 Feb 2015 11:45:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: IPsecME WG , Valery Smyslov Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 09:45:41 -0000 > On Jan 31, 2015, at 12:35 AM, Yoav Nir wrote: >=20 >=20 >> On Jan 30, 2015, at 3:37 PM, Yaron Sheffer = wrote: >>=20 >> What I would suggest is: we give the client a single puzzle, and ask = it to return 16 different solutions. Indeed each puzzle then should be = 16X easier. The nice thing is, the server should only check *one* of = them, at random. The client would still need to solve all of them = because it doesn't want to risk the exchange being rejected because some = solutions are invalid (the game theory is probably more complex than = that, but I think what I'm saying is still close to the truth). >>=20 >> So: the client does the same amount of work, the server does the same = amount of work, but the client run-time is still much more = deterministic. > Note that these are still single core results, and most laptops can do = twice or four times as much. Now, I know that what I SHOULD be doing is = to randomly generate 100 =E2=80=9Ccookies=E2=80=9D and then calculate = the times for different bit lengths for each of them, and then calculate = mean and standard deviation. But just by looking, it looks like it=E2=80=99= s much closer to what we want. 16 bits would be a fine puzzle level for = my laptop. No idea about a phone, although I could try to compile this = and run it on an ARM-based appliance, which should match phones. OK. Now I have done it right. See attached. The data suggests that 15 or = 16 bits is the level of puzzle that for this kind of hardware is = challenging but not too onerous. Add another bit if we assume (probably = correctly) that the vast majority of laptops have dual cores at least. I would like to run a similar test on an ARM processor, though. The = capabilities of phones and tablets are all over the place, what with = different versions of ARM processors and devices having anything from = dual to octo-core, but it would be nice to get ballpark figures. Yoav From nobody Sun Feb 1 01:46:38 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2951A879B for ; Sun, 1 Feb 2015 01:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2o_Au_TYuEtN for ; Sun, 1 Feb 2015 01:46:34 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (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 3AA3B1A7003 for ; Sun, 1 Feb 2015 01:46:34 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id h11so10337283wiw.0 for ; Sun, 01 Feb 2015 01:46:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=UbLH5b+/p1r4FNcmZFg1MkHhi6Nyo3IfpLIqY6J8fHw=; b=EOH1mtJUnD1Rf9oczRXgWDBZYl3XzoIP7fWnG0Xm1gh+CZNIV8I7JwGHUXuOXfibEL zgb1uWtunfi878+vecGJSs6kglJW4q421IDulz1kiDVYiwQwl723XWm8P2wYbwB1DntR Bu5Fsr7Szi1TFKFzBNVLsPMa9Kn+/hAzBlmLdPyVXt+CEsaR+GbTxUDd1FCyGznnPxnS aQamMldOtyILINFZo4KscFx1Ho3TETVF7K6aOqF/2Amtof/pa5aOSQ/YzVwhSsTqkzE7 kL3VuzaAtquZQM114378YuOB1Q8vJlkA4GmJ1I2Mi5k/9CO4kYt367W+QiRo9xORpTQg 847g== X-Received: by 10.180.12.166 with SMTP id z6mr12532275wib.65.1422783993092; Sun, 01 Feb 2015 01:46:33 -0800 (PST) Received: from [172.24.251.208] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id u7sm14640043wiy.18.2015.02.01.01.46.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Feb 2015 01:46:32 -0800 (PST) Content-Type: multipart/mixed; boundary="Apple-Mail=_56DF6124-70BB-42C7-81C8-3AB5C8090F6F" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> Date: Sun, 1 Feb 2015 11:46:31 +0200 Message-Id: <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: IPsecME WG , Valery Smyslov Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 09:46:36 -0000 --Apple-Mail=_56DF6124-70BB-42C7-81C8-3AB5C8090F6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 And now it=E2=80=99s really attached. --Apple-Mail=_56DF6124-70BB-42C7-81C8-3AB5C8090F6F Content-Disposition: attachment; filename=data.xlsx Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="data.xlsx" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQBIZhxhaAEAABAFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACs lNFOwyAUhu9NfIeGW9OyeWGMWbeLqZe6xPkACKcrGQXCYXN7e0/ZXIxZWhd7U9LC+f+PU34ms11j si0E1M6WbFyMWAZWOqXtqmTvy+f8nmUYhVXCOAsl2wOy2fT6arLce8CMqi2WrI7RP3COsoZGYOE8 WJqpXGhEpNew4l7ItVgBvx2N7rh0NoKNeWw12HTyCJXYmJg97ejzgYTKWTY/rGutSia8N1qKSKC8 neVn6wIY7CjcWvWLLj+SFVSZxLHWHm+ODq/UmqAVZAsR4otoiIPvDP90Yf3h3Lroxjzj5qpKS1BO bhrqQIE+gFBYA8TGFGksGqHtH/zTYuRpGA8M0u4vCfdwRPrfwNPz/whJpscQ494ADrzbg2ifcy0C qLcYKBmDA/zU7uGQwsh5TUdk4CacdLv86dwugvNICQ5wOcB31Nrq3JMQhKihM2wnR4r/5Ya/0gbt /aJAnfHm6T6bfgEAAP//AwBQSwMEFAAGAAgAAAAhAFB8TsH2AAAATAIAAAsACAJfcmVscy8ucmVs cyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAACMks9KAzEQh++C7xDm3s22gog024sIvYnUBxiT2T/sbiYk07p9e4OguLDWHpPMfPPN j2x30zioE8XUsTewLkpQ5C27zjcG3g7PqwdQSdA7HNiTgTMl2FW3N9tXGlByU2q7kFSm+GSgFQmP Wifb0oip4EA+v9QcR5R8jI0OaHtsSG/K8l7H3wyoZky1dwbi3q1BHc4hT/6fzXXdWXpiexzJy8II Pa/IZIwNiYFp0B8c+3fmvsjCoJddNte7/L2nHknQoaC2HGkVYk4pSpdz/dFxbF/ydfqquCR0d73Q fPWlcGgS8o7cZSUM4dtIz/5A9QkAAP//AwBQSwMEFAAGAAgAAAAhAJbV+XMCAQAAPwMAABoACAF4 bC9fcmVscy93b3JrYm9vay54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAKyS3WqEMBCF7wt9hzD3Nbr9oZSNe9FS2NvWPkCIo5HVRDLTH9++wYK6sNgbbwJnhpzzzTD7 w0/Xii8M1HinIEtSEOiMLxtXK/goXm8eQRBrV+rWO1QwIMEhv77av2GrOX4i2/QkoosjBZa5f5KS jMVOU+J7dLFT+dBpjjLUstfmpGuUuzR9kGHpAfmZpziWCsKxvAVRDH1M/t/bV1Vj8MWbzw4dX4iQ xEMbBxCFDjWygj+dREaQl+PvNo23OmD5ziFud0mxLK/B3G8JY3Rrnq1u3LyOqbQGkW0J8e3DiSwi zxBTieTYydZgdlvCcLxanEFGKcd3YpBnZ5//AgAA//8DAFBLAwQUAAYACAAAACEAJKffsN8BAAAE AwAADwAAAHhsL3dvcmtib29rLnhtbIxSTW/bMAy9D9h/EHR37Dh22gWxiywfWIBhKIauPasyEwuR REOSZxfD/vtoe+k67LKTKFJ6fO+R67veaPYdnFdoCz6fJZyBlVgpey74t4dDdMuZD8JWQqOFgr+A 53fl+3frDt3lGfHCCMD6gtchNKs49rIGI/wMG7BUOaEzItDVnWPfOBCVrwGC0XGaJMvYCGX5hLBy /4OBp5OSsEPZGrBhAnGgRSD6vlaN5+X6pDQ8ToqYaJovwhDvXnOmhQ/7SgWoCp7TFTv4K+Ha5mOr NFXTfDG/4XH5qvLesUoEmH9IMnKJLKmxO9rLxloMY/OCk3OiDbhFQzq9v1cytBQMBQIarHpU0Pk/ mMOV9U/KVtiN31/exN2YflJVqAc6y4Tgp9wnUOc6EIs8W1IyiOevAwOSRG+oU/ym1Wg2tRxPZkcn jjaAZipnnmasIZLoYBBEYzmSdBLnVooCd6zmI94VRAotyYfhGB9mSZLQa4lWts7ROLZU+S0X+vDZ h3JNJ2udKviPmzxd7PPdIkrzwyLa5Pskmi8XabTMDmmebdM0y9Of110w/T/LYJR06PEUZhJNPO0B 7Y+MoZcwrtPttE7l2vSrjZP1cccOWpxpAumog7iQO1dm8XWBy18AAAD//wMAUEsDBBQABgAIAAAA IQCxaD8GMxcAAIIwAAAUAAAAeGwvc2hhcmVkU3RyaW5ncy54bWyUm0uPXMlxhfcG/B8ueiVBIpnv x4BDQaAhjxcDC54x4G0+IsmG+kF3FUea+fX6orgY4yYXY0ELsbpu3czIiBPnnEi9/dM/Hh+On+Tl cv/89O2dfW3uDnkaz/P+6cO3d//9419elbvjcm1Psz08P8m3dz/L5e5P7/71X95eLteDZ58u3959 vF4/ffPmzWV8lMd2ef38SZ74y3p+eWxX/vny4c3l04u0efkocn18eOOMSW8e2/3T3TGePz9dv70L Lt8dn5/u//ezvP/yibP17t3by/27t9d375+f/3Yvb99c3719o598+dT6V/3+un0avvpp/Oqn6auf 5q9+Wr76af3ap8589VP7tU/tWsvatKIzPU9To5uxj+pGsmH6nEdItRTvz/u8Pl/bw0GMj6tcrt+c /yw15Ti6bSH5ZcxsxZUZelwhTOeWNUFWi2MLavW1zppaD6PV7LPtrsW4WIDJbtpslws++e0552QE X/psq/XRpi9lSarOGd987VmkpDjM9px3SeYsw/jeeXSultyKJVQ/bLGzpGrnMGOc92eN1GC8L7PO nofEmlNbJvcSRu81luVbkLyFLddlQq5+tRX69KPE6FafwSSbZlmx5yzRhXp+nzc9Ou9tnCGa4sS5 sJIrwzmfx0q9dKLTRz8/J7lk3/May6yRZ6s+DO99iBJLzdFHO1yzMZ2f8ym46HKe1cyUmpvFhuFC rGVwsKu2bpod2Z2fK4Ovp1WEk/Msjf/2kvXQ8uA9jfWnWLo5P+dzG6ZEl7oj4jLTTDH2Ga0t3to1 ksiMLW3nx3kPk+rMXVqZUVhTJQ62lEbSdZdI5VZNOL/PTGubIcOHmNE58tjFLuLRHIkmi5yJw9l1 fi6bkqUYGZZcmYOcXoPMy7MbVyv/QzxP521/3abWiLhJkkmSnkz0bs3mQ8hRSo+NJdc09/fVam2o nYP2htOrhDVZ1lq8i9ZYK7WtueXLonokZaECOe2yEmdMfFdYle2N3qLwhbnF08Vg2BLpbWenZPos urmwpuleUqEeq7MSz+uMyRefCiGYJiRbecN07LJa10mFMMYKk8w7P0d+ivXODCe+hjaWI1KusSXC E0xrY04797qdM7pqLLGcIXMUxK6BLlIyOeusyZOtF7fFxTdNxiS1WNZGxRYTSLDqlg+JhXfwztaw 1UNx/Fp2q7VUTe0gmvD4HD0GogNiWT+9GXueUV9gSggcg2VbsYNSZpRWq5+LNzVZo1R7jovJuRJO H4GTNkhkgsSjs3oxsbrYq5RQUjs/F1opNgN6gNasWq4BpBJwbZXgSpqsHNjK5+ecKcHMXEfqwxD9 DkJ1A1rn1fxkf+A3TWLL6zg4uR4C2WtEXAQFc6vB+WGMLp8MjEDJlmej8WvT5BJHHJok05DloSUS upReaEk1trrVQ2Undd126Mbi5ex03SBxmbgUXLTpzO0cbLQVGHeNJA3dBV7tkp4aHYWgTI6uAqcb zpvsY8ydUhNHYLzYDrwPMExAnDRpZd6FtsXTmh7oKt1QCYSOQIAQZXgKz5VMyoXoKYitjgJg5Yox DhgLZqzaQyy5p+A5eIovVMsa7BbPnLp3o5Brrg+xidwZdXVi6QnkjLyqz+r2dXrgRdZKY9ohtGmq W5sDbwclpg+LMIe4xYWqzTTaMMJqISezHODEu1bhn3TAaKKQaNv7RhdXAykdug+ZEgD5wAfaoi3G Vpt7zUHi1sciG6Emshde7GW6QSa47K1ZqbYS7Yyedr3hC0cspXZAxVCswBDf8yZNdhxoai1rHzVm O4di+syrkiPSqihWR1p1JddzI9OjJwVsrxu+tNpTEWU6I+eVMsVjcqhzQD9LW0BNFlJhWye931Uw b6RA25omsdbaJQLhw3o61KSD5rrldZEihkbSTeC1YDwtujavNKusXMsqHH3v23P0m+xsZy9Bgq+G kM5gBwe5Roi9mUgvW7LVH3yAWm28woGTfQwfvFm0hRZzyACbduxZN1wiv4KBTUXtR3AdZRaThpsE VtYbwYSQ0CLOuGSrp9kl8JxjTgAvLSXYBZtQ6IeUEFG+sOGSxlw7OWVNRyJRMm+bgybsjRXoHYxB z+L8PloRPE5CTN34oWBT63LAgzSgLWXC3HvyG+/xjZzn0Oj/AN9oNBmAOjrHcVSBCBbXPQE7v48W Bu4ml6KpwCahMJG9UR4VttAXLccOKOL5OTomIKu5BJFZgb4lcVoHBLOxkgKc2YFU2/tqNTHcltQm 1JAiKiZaNyFcbST2WviBlrd6Rw6VKDT1kqjgTvlFk8gg0kR7C/zJ95rWdu5w6hUoN6/QLpEuBDJa EkxIO1LcQX0gJNs5RFm1zEGVsQltKV3maK60ZoBBsAIWTUcq57jwkyVYmdD5EIaZMcMTBlidi2mc 4Uo0bdrg+TnYoEgMkECh11Jo5JkTKDnJx19IGnPrh+fnCn2/kJQIHTgEYKm4mTzsGOyPMZWZoOd+ 7+8C3aC2R/cAnjYhKiOQn8BUSLAtmKIy6fP7EpKhwTqiWbQzISUTcgoUoGfTM13IvbWet3NnMT6l YCu/nNF22rdMi6A3sgclQ2NR/bM954oEKsdMuiRHD91BBPBi1TxIkVp8A3Rk2x9xid26QJcgw9GS 4DtajAqmXSILPAJrdtnqFqDzHQY9IPJx0dM77KItJEiBQhmIyEAK7fgJ5KG+IlovmkFM4GmSKccK 8tcpqgostbLVkTZmKD/FAl4MzosWlKhCDt9Ri/wDfu6aO5+Dag1yUBxEHgEopCXq2bUEmpUGmFNG s9mtHiqYBI2w0OUF6lKxFJYVEjWiIOhKC2KPJjm/D6qo8SaOphF0D5QKzRbSyr7pmdr2oWxbH7NT mX+YMFCkkKKt46Xes0g7gXoYmI+j7OfeoaVp5Zip3DZNUZ8A+mkJqyoSJAfJvusHuFeZDgSrge7R aA+JympuUYTQkYQ0HrxwyxePQhkwCgVzOG9SsuMtlNXCaHEMyKeVfd1wIjsoFcSMYidq4r2CZYwt cPbElXybsOG09duk8KhirjkUSAigG6/KCwpJnSClZ4aWhi1fQKSM+IVnTRyKlAbNBAGDGhBnoXf0 D35hbOdHO6geblzRChPQrGBZAFFS9WS26iSwmDeezx0PgsosnZYFjGKApMYpFggIrKQDpbnSL8bO syo92tKN4YRCE5nkT0F/OzQR5AAKawGpnV93Tz5XdW/o41FYnEv0mQgLgWgNG5HblRZ3Xmfl3CvM bnLWxaFUEQSLvlY4D+NIwh4pw7zxEMgO8bwRnAVLo+I4fzY7zaosMAuA5ozdcBD5MOFFiFi0WKZH uEZ26drhnY7Wv4gScHNeZ1/zxgWoOlr5ArQBaLieSt6hjxLdJHard0wZLIpq+N3GokpYgeQaiD4q rCSkLoq6jy1fmoK70wJc8OkRM10d8Qe1t4OmOBCxniTa1on9gZQZsRXkLKVOkEhO59EqIjRpct6R Ahu+jAicRYhY5pzZVQc0yT1KNyPSeqmcvXKnc1yAJeShw+wSWDSor+BAcRVfhhBlM6ELYrZ10t1x CSlr4ByY5lhAfeAMIEa+YzmklGF52/nNOTsGFrFHpKIwFi8P9LQbc1WFC+rPmrd4oqo4AlpJdNFY IhmRR7plfog3I+gnWdo3/gI0YIKgtOlDLHlQ8ix6IK1x/1A7tHq6g9/wE+Os6Z+JA/KSxivUHDVg cRso3lHo9mTsli9q1C3qDVav8QBGOYZ5a0OTHwwkKqJTtnrwriEbs+jW1PMpk1O20LxVUDC0F6gI vtUWF1vETwClq3xWquboSQAUIA7OYegGrDcg+HzugI9g9lbInJJjaLaZPQ2glgwPBFkzj02fn/PQ Dk8eQQYWjgptkg6B94WNNzA61BQV2tyWZ+CnMTRcREo2ZCg7ZMGoJE85Yx4KpB4Q33CwQVD40cVX oGO4n+hwvKy04K4jc6S4Daub7Tk1Vg2c0CrJxnrDlF3UjooiTFOKP5O86Kbz/qBfw9D5QLRkoHj4 x+j2xn/QHHi4+E3g2tjqjwpwqixc6COnGmD3ZJzgiy1UBVY6rA7+u537iDDcAIogrIQEoGuC9HaC pxAGvBsxqIO41R/ktDW4lnZNylYhsQFHmN8ZfkLnoI3Syrd1ou3tsBhliRdi7dExMYhxGfCo6sqo XDWG+5bXMJ5M7A15Ad/BhYQO0MOyMqXkIxoeLMccOceTffBIwVogGVPGzo0Bf6dRPnblUQa4QRfd zk8lXBlFo0F94ms5DPuUEPEWv1WZtfL8uq0TZbuUD8Adbzof0tksXKR2sCbAmLtl1JE2nEBYYnpk JJHDuINfG8g8duJNjo00ADqs7d1fEmgqLcFFzAWEPzgGt16QxIZSgvhgozaM+w1fkFKcE47ccAhO Gjx9SRY+LY2NGgKtIVp99z8NrUggcVQnuVjnZNm1aVOpuISRvCNAdNTzOfiEu6d/gC9XZAtdNBEp 8hXQICCAKkLAb/oIEY2lo+tkREGxI5Ki58zUFeEMEBN4HhCg8/sQpfgkOM3MQzS/o9oUSILSteDh UFiZOexzIFg8u1DqD76bvLALCp68oSGCtowyol3k/ZZnMGPVlXg6iV+fJEAh77ybjIRqxCNmtuDy jks0EbzW25AEGAK4BsyHSCgzW0gqUImBSN/wLOAh44EBB5gM4uhOMK4ZIVuuZiSAjrDgydtzGdZC aUdaAM2A+QxOa+JhFm8EWkrFg79mOwdKBgmPLcBMDBzDFZmgdsAJ1ePAMMyo+r7jPLlkmGwVfB9l 8yhLMhzDBwTm+1A9lECDo5/PD81Bw6V3oe0tvnHCgAT+qEWGKpw84cEzsNs6YUuU0Vjq3WPRd/ih X6ycescnRPFzKLT3Tb/TggeCscHJY4dBwoOapYsJVggb9XgzXoc053XCG5NX4U9sBPeMFxr8sFxp MIMNMr7A4Up7/WF2kJJ4PRgY2srJUmhOxCwOYBQtlBLB0ju/D7eFjIREozYxIsQzemi8CDWiMwXI NQIylO05UIyBQy1Cqx6tObKUGR5Nk1kcfjl5ZgThuz1HwBd8p6v3CQfH/sei4mlcCuQwwwmyTN2j 8zojkhFLVt1IzFYMrYJUMcAGFhFeQ+C3LMR060cJsuQjMy0qCE8Lhp6tYT5ZkdJQWQwWeCxDzvP7 1HPDP4G+8b1g4T0l4EVCOomRK6Ww/9R3fxezEkLbEKf48uY2J2O/sCYAo05mmKT5Yu/n9zHcQtvy u+E22coROWQIBwP9pRIQA4KZYNvi6TnYjJkCfcdwGTTtURa+V0NZZQgPcYGjh60edEYAlkFzaNWk M4CIB05wIGXINItVRe/YcZ5uRyV5nGMMH8wC8DKynwxNpytQ6B1bjZo/72/0hbRhodBJCBWDZfWU GdJjWUBhmeAhezms83NkGQIOmwxpDF0CMy3OOdOmIYx6oJF4DaWkrd8yH7IoEp1sEIqEz4NuFXwq 9DXEi864Bse0rZOpFswRhooTgk1PH4EZo9wQWeC8q7B7NfC256IgGLEF0NNkOD0FCkOZl8XUeGjf py/pjOi8P34MvMX2xvCk0WVawWLcSPNiVGMzKohyxyQ7P0cQDcNdTGT6pxRsLXofEwE2yFm6VBh1 0z13vEbtFagq312TMECUCLDBs9apesNuhN7lXad6VsKcBJcVeGX4x6CDgS2/xPCvMcArWOFxlg3P aA2wOcgUxZscozAsh8yQFQ8Nv5W+hAaBjG78BaReOPL0VM4PggaZ9BwGirViEgHGlLXMvOULPRYc Yl006QUEcxuB1oIFA+wyBkZloUvgT+d48qN8mQsTCH2ODaGCPkHh4IFi2uMZ9WLo9Xs8DWN7lDCt n90TPOxs+nVaTHkCSENL5fT7du5M47pODkFlFBu6n7GBpAgbL7YCphlxgc7ZcIJQTJpzpPkz91aX GLVPkwJwCG9dC3cRR2Wrd3oBfIwZL3UI+qnwR1ExZsQZIT+Zx9+8zW1/OAIwHKx1iLzeTWDICYqq tY95Ui3akTsK2JTneOI+MYihwapDg2Ck/tCt4klO8oRi8Yy4235+Wma4ewZLKi4QiGk6p4iOHggt HDSjDhAgfn6fMEv1SuvoXkgrlXJMDpRkM44CwGktyu63OmICgAmB6sCIxJSPpAvjGbaLC41ywIJg fM/s9/w+5jwY37QVBpUY81ie3PIpFCG7wkjBZ+IijelbfnpQFs9MYPyUOX6Wumlc3aDJUv8O6YCb gBN9fh9jTUNlcnrYhACQDuDggDpfgbtw/YUJNPbEli+UEScB28/4jpGqoQWR6IWEBhEt1EULcb8n oJ0AUEDjIcdotVgSlBaBZ3ABoEExGX9xIud14potYkZedDzLxanBKDApIuYsoC8cDC/efQZ43NDJ fGUWWTrDObCykGuIh0g/K4yI4JH7OrHjBoXGtA8HC9mPjqD4aLPqWzPtpIMqjm5xEVaPqMTvWjgi qYIViBSs04V1R4UUYK3RgM/7I5dJetgbtzkQXrQz4AnVjwbgzR007yD+rscQwGhn7EOP74ljw4WZ xR47iQ1TYpV4YNTHpovhKrBwQBb4YwxL0jABAjSmTzAnbomooQerPK8T9NDdsfPBXQ0SDXnNXRJG GJOKoKGqcYFwPT/H6agQBmVpJTAyaDm/gl6EkTCKhSxQHWufj3ExDZxTQQoKqedJYkHQ9NYGJ0if ahA3bzb+AvcH7lSawgK5vIdWp3xqRFXho2QmgjlhzmznAC1AezHDZVqAeOauCIyTa0RcSgGPKD1G RMR2q1vudHHxhwNmXsHMALceletg3LQMgB9pXWnVsvFB7gxxzKhS7mMNftcMri3p3QmIIMQFCsVH zBHP8dRLXNBppj+jYpKS25gSyqFwO7B8aIj0D2TZ+TmMAu7r0ddp0BB7JgdKTKBJmEB6jJBLaG3Z 6q9y34uU19yFUSDGOk4rN+MwXbTlco2D9kDMzu/j/gLX6yCojkqkExWShnEn5iDYQTxhe5Tj3PIM qg91WTzIuJ3RMHdRIr4CRsPg63Q5zwpQVuf3MSUAHVXD0w7Ue0OMNWwjrAygBwxhIMDFkQ3nmfXj 1zGaR6rCbpULJG4+oJB1hl+4loEIRJRu7wuFiydYF4zW+H0MOjTK0PEK9JjCwMeEosbtfcy72YJl /ENjQqrcHkH2sGSuBzA8FIwWbpid36czZBQjbjCeKaKd6RVXMShCpJYDkCcmP6bhxnuY2IGqlAss kNLDzHXIRHCe/NNId2a4XAYN5/fBzxbQrvdxaOlDr0+pBOC/7JO10yHI2rXxAr2zkEEeblJ2pizk GkCaut6FAUFACfQovvmGE+rfY/kvGuDtymkE/LhHRPnAetgvkw9uKrWtjgKDSqEt4NKRFUybSOtJ znFZiJbCIJVhYGAUct7fXz//8suDvPrh+eEnblQfP3JX9/QVvUT9zeVTG1yu/vQiF3n5Se7e/XCd /yY/fXP8pi9/L+3pN371ka/+wf8/vvzqN3/5/jevof1jW8C7Hz+y9aO9yHH9KAdx+PxwvRzP62iH XnA+/v5R+BuC5njhMvrz43E3brfCL3fH3/UvH+RJXtpV5h8P/n77kU8vzx9e2qM+wL9fnj9/+Hg8 8rP3nx7k+Jv8fOHG+fX+4bDpy08sbp7P4/J5fOTr7Xr89b/+8ru//fHLa35/fGyTm/G3H/lFXp4P 7p5fDr6ly5Wn+fpgB/rIsT4/jSu36Y/PF5nH/eX47vs/v3/1w3d/hh/d1tYeHrj3rlfaL6e1H+3C Fl/1n9nylx/UveOc6M+040IKsfT/eLrKw3Efj/fPbPzl89OTphZLca/D8e/f/fJrBO4f2eqjPF3b bUFE8/+uhd/Uxb9//91jG7/7/a8Lv386Hu77Dz9frvKoR/B9G8d//nD8z+tDM+34w5tXhz++ZKgu 7MP9T/J0dBmNHev39VcJuMiry/2Hx8YSWfXt88+P/fWvKf2G/w/Bu38KAAAA//8DAFBLAwQUAAYA CAAAACEAMA+IaxEHAADeHQAAEwAAAHhsL3RoZW1lL3RoZW1lMS54bWzsWU9vG0UUvyPxHUZ7b2Mn dhpHdarYsVto00axW9TjeD32TjO7s5oZJ/ENtUckJERBXJC4cUBApVbiUj5NoAiK1K/Am5nd9U48 bpwSQEBzaL2zv/fmvd/7M3/26rXjmKFDIiTlSTOoXq4EiCQhH9Jk3Azu9ruXNgIkFU6GmPGENIMp kcG1rXffuYo3VURigkA+kZu4GURKpZsrKzKEYSwv85Qk8G7ERYwVPIrxylDgI9Abs5XVSmV9JcY0 CVCCY1B7ZzSiIUF9rTLYypV3GDwmSuqBkImeVk0cCYMdHlQ1Qk5lmwl0iFkzgHmG/KhPjlWAGJYK XjSDivkLVrauruDNTIipBbIlua75y+QygeHBqplTjAfFpNVurXFlp9BvAEzN4zqdTrtTLfQZAA5D 8NTaUtZZ625UW7nOEsj+nNfdrtQrNRdf0r82Z3Oj1WrVG5ktVqkB2Z+1OfxGZb22vergDcji63P4 Wmu73V538AZk8etz+O6VxnrNxRtQxGhyMIfWAe12M+0FZMTZDS98A+AblQw+Q0E2FNmlpxjxRC3K tRg/4KILAA1kWNEEqWlKRjiELG7jeCAo1hPgTYJLb+xQKOeG9FxIhoKmqhm8n2KoiJm+V8+/ffX8 KXr1/MnJw2cnD384efTo5OH3VpcjeAMn47Lgy68/+f3LD9FvT796+fgzP16W8T9/99FPP37qB0IF zSx68fmTX549efHFx79+89gD3xZ4UIb3aUwkuk2O0D6PwTdDjGs5GYjzSfQjTB0JHIFuj+qOihzg 7SlmPlyLuOTdE9A8fMDrkweOrb1ITBT1zHwzih3gLuesxYWXgJt6rhLD/Uky9k8uJmXcPsaHvrnb OHFC25mk0DXzpHS4b0fEMXOP4UThMUmIQvodPyDE4919Sh1ed2kouOQjhe5T1MLUS0mfDpxEmgnd oDHEZerzGULtcLN7D7U483m9Qw5dJBQEZh7j+4Q5NF7HE4Vjn8o+jlmZ8FtYRT4je1MRlnEdqSDS Y8I46gyJlD6ZOwL8LQX9JoZ+5Q37LpvGLlIoeuDTeQtzXkbu8IN2hOPUh+3RJCpj35MHkKIY7XHl g+9yt0L0M8QBJwvDfY8SJ9xnN4K7dOyYNEsQ/WYiPLG8TriTv70pG2Fiugy0dKdTxzR5XdtmFPq2 neFt224G27CI+YrnxqlmvQj3L2zRO3iS7BGoivkl6m2Hftuhg/98h15Uyxffl2etGLq03pDYvbbZ eccLN94jylhPTRm5Jc3eW8ICNOzCoJYzh05SHMTSCH7qSoYJHNxYYCODBFcfUBX1IpzCvr0aaCVj makeS5RyCedFM+zVrfGw91f2tFnX5xDbOSRWu3xoh9f0cH7cKNQYq8bmTJtPtKYVLDvZ2pVMKfj2 JpNVtVFLz1Y1ppmm6MxWuKwpNudyoLxwDQYLNmFng2A/BCyvw7FfTw3nHczIUPNuY5SHxUThrwlR 5rV1JMJDYkPkDJfYrJrY5Sk05592z+bI+dgsWAPSzjbCpMXi/FmS5FzBjGQQPF1NLCnXFkvQUTNo 1FfrAQpx2gxGcNKFn3EKQZN6L4jZGK6LQiVs1p5Zi6ZIZx43/FlVhcuLBQXjlHEqpNrBMrIxNK+y ULFEz2TtX63XdLJdjAOeZrKcFWsbkCL/mBUQaje0ZDQioSoHuzSiubOPWSfkE0VELxoeoQGbiH0M 4QdOtT9DKuHCwhS0foDbNc22eeX21qzTlO+0DM6OY5ZGOOuW+nYmrzgLN/2ksME8lcwD37y2G+fO 74qu+ItypZzG/zNX9HIANwhrQx2BEC53BUa6UpoBFyri0IXSiIZdAeu+6R2QLXBDC6+BfLhiNv8L cqj/tzVndZiyhoOg2qdjJCgsJyoShOxBWzLZd4ayarb0WJUsU2QyqmSuTK3ZA3JIWF/3wHXdgwMU QaqbbpK1AYM7nX/uc1ZBg7Heo5TrzelkxdJpa+Dv3rjYYganTu0ldP7m/BcmFqv7bPWz8kY8XyPL jugXs11SLa8KZ/FrNLKp3tCEZRbg0lprO9acx6v13DiI4rzHMFjsZ1K4B0L6H1j/qAiZ/V6hF9Q+ 34feiuDzg+UPQVZf0l0NMkg3SPtrAPseO2iTSauy1GY7H81avlhf8Ea1mPcU2dqyZeJ9TrKLTZQ7 nVOLF0l2xrDDtR1bSDVE9nSJwtAoP4eYwJgPXeVvUXzwAAK9A7f+E2a/TskUnkwdpHvCZNeAD6fZ TybtgmuzTp9hNJIl+2SE6PA4P38UTNgSsl9I8i2yQWsxnWiF4Jrv0OAKZngtalfLQnj1bOFCwswM LbsQNhdqPgXwfSxr3PpoB3jbZK3XurhypljyZyhbwng/Zd6Tz7KU2YPiawP1BpSp49dTljEF5M0n HnzhFBiOXj3Tf2HRsZluUnbrDwAAAP//AwBQSwMEFAAGAAgAAAAhAMSn4laKAwAArxEAAA0AAAB4 bC9zdHlsZXMueG1s7Fhbb9owFH6ftP9g+b0EWNsVFFJtldD6sGpSmbRXJ3GCVV8ixynQX79jO4RQ SoHCLg99Ad/O53Pz5+OE13PB0SPVJVNyhHudLkZUJiplMh/hn5Px2RVGpSEyJVxJOsILWuLr6OOH sDQLTu+nlBoEELIc4akxxTAIymRKBSk7qqASZjKlBTHQ1XlQFpqStLRCggf9bvcyEIRJ7BGGItkH RBD9UBVniRIFMSxmnJmFw8JIJMPbXCpNYg6qznvnJFliu84GvGCJVqXKTAfgApVlLKGbWg6CQQBI USgrMRamRImqpAFvNUPIz9ymMHh5jpE3+kaloEa30+12cRCFQS0ehZmSKxRwsFNu+CDVTI7tlIe2 q6KwfEKPhMNI32IkiiuNDHgYkHt2RBJB/YobwlmsmR3MiGB84YednAtKvU4wcJFTyO/gfysQe20v Z8Lf2uyklr1klc7jER6PITJ1cE5lWbzDjc9CpirNqEZ3dLYRkDWkczu9Z/B3x3ob9H5eORD/6kSq BzZPS8htxnlzBPtwBO1AFAIZGKrlGDqobk8WBZwSCbxlVQj8uh2rc00Wvf5FS8DJwb6x0inwZPvw +6Eo5DQzsINm+dT+G1XAb6yMAVKJwpSRXEnCoRksJeoGwCaU83vLpb+yBnsAVs2zFqkAK1vrLb/Y JthYNz2e7wD+NqHeViFEioIv7ioRUz12VO22cKPWl6veV2f/qv+Fs1wKaokQdHICP7QyNDHuKnF8 sU2f/n+mz7t/IIbv+fPmfH7PH58/QZvNPLe1aK1nC6ZtlLCd19A820lwn7YTylLaU9QYaLSunI7Q ZB3L91p8aO2EYsynk62uDUtsDQcXA0YzTYoJnS+1CObZUU75c5vbOvblm6aJyLofnhMIxLu5tvYG W7+KAMFfRbvDdnGsujYD60v28l9i7YjoVGn2BHrahHIVh6tVNrKofof4omHv4/Fm738+1GMHWJlA kUH9i8Wa6UgGaKVVO61VTg0HIVvUQ5mvOFczmqJvUA9qzuQDvLgcpUAZEleMGyYtwQwwmrI0pfYd bH26Pw4k90lwIO1OggNPygNwNtwCh64lDmCvumVDHJLtGHE4x8eIQyIeIH5nS16+zAdggJasf7Q3 WQD5ls5XNbqbNfZLg6vemwwEjJRmpOJm0kyO8Kr9naasEpBr9aof7FEZBzHCq7Zf5V59wepLS/Qb AAD//wMAUEsDBBQABgAIAAAAIQBOy3vwoG0AAAOgAQAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDEu eG1sjJ1rsxw3kp6/O8L/QcFPazvmsOterZC0MX2p6ovscOyux/7KoY5GjCFFLcnRzPx7P1lI3BKn q1hSiFThbdwyE0i8SKC++9d/fHj/ze/Pnz6/+/jr96+qp92rb55/ffvxp3e//uX7V//nP6Y/jK++ +fzlza8/vXn/8dfn71/98/nzq3/94b/+l+/+/vHTXz//8vz85Rty+PXz969++fLlt29fv/789pfn D28+P3387flXUn7++OnDmy/876e/vP7826fnNz8tP/rw/nW92/WvP7x59+srl8O3n74mj48///zu 7fPp49u/fXj+9YvL5NPz+zdfqP/nX9799tnn9uHt12T34c2nv/7ttz+8/fjhN7L487v37778c8n0 1Tcf3n57/cuvHz+9+fN72v2Pqn3z1ue9/E+R/Yd3bz99/Pzx5y9PZPfaVbRs8/71/jU5/fDdT+9o gXT7N5+ef/7+1R+rb3+sq+HV6x++W3roT++e//45+fs3X978+d+f3z+//fL8E4J69Y0I4M8fP/5V gFde7cjz8wKQPN+8/fLu9+fj8/v337+6g/78n0spd0qpdu3YDb2U9DoUlf7dFzstsvvfn77585vP z8eP7//vu5++/ELZ6MhPzz+/+dv7L//28e+X53d/+eULbzt6Rzrp25/+eXr+/BbpSJ0o5O3H9+TI f7/58E50jK598w/XBJdhVz01Tb1rqpo83v7t85ePH3xR+nv9ZfhpTfPdb6nLL+9++unZZVz++LUr fWnn6c2XNz989+nj379B1aRPfnsjilt9W5GftKFu6MO3kvpHSSaJ7Hn/mde//1BX1Xevf6ej3iro EEDSSvnZsXhzKt6cizdT8WYu3lyKN9fizS1985p2hsbSvrSxvpHymlZnbRxNGx2mWQSxNNG+ONkX Z/tisi9m++JiX1zti1vyImta83LT5PX3r2K1D/bF0b442Rdn+2KyL2b74mJfXO2LW/Iia0f7cjvk ddYO++JoX5zsi7N9MdkXs31xsS+u9sUteZG1AxNOVW2xq2oMdiXJYnzeYg7uxZDooLGyY4mocx09 lYgmR5xLRJsjphLR5Yi5RPQ54lIihhxxLRHG3m4lYp/ncXeI2IU/Ji8yUfTropDk718xvycjnOm3 g8PsEd/PP/zxT+d/++N8/pdD1X97qKvuv333+mcZF3dPVT8OTV+Ne31Mm45JLkthv7z59PzTKzfv Hftvb5L+bpnBfBlHyjhmZTRtPVZMETv3VEZ+pwdluHzRNqln349V37WDVrMzrT1v58FM1Q5DW+3r ztXDqOK0nUX91I/7tmt7bYrJYd7OoXtqOubLXddpQ0xfXLazqGjIvq3qtulcQ0wW1+0s6vppt981 3dgaQ1nE+f2rRWlScSeiaNunrmv2ddWMrbRhMMXfXfGJjicvMh1n4FgbbiTZ6rjp8IPDOB3/9/84 nf9UaHj7VA1VVdV927R0W1315z+YXI5JLmmjF6/rOHx7k3R0vHr1gyvDavj4hAFJ/lWDlu6HpinK OD0ow+WrOl6NTT0O/b4aml0/jL3V8a/Jo+lb8caqYY/VmYZOX5MBGt7t6v2IreyHuh1NJebtPNDP ej/sxg5TG6rdUBslu2xnUT9R9L4a64GBqRtqMypdt3Ponqpd3w5UYGyGZkQ4+VC8CPWBpi+6+/sP GFq976oeOxtRoqYxM8Ld1SLR9ORFpumyELMOazKxSrJoephY3Yt9eHG0L072xdm+mOyL2b642BdX ++JmX9zdi6TFyYusxfv1FkuytW0zjhwcxtn2of8f/9L898MQ561634z9vuv3Deo+Yt65eI/Jr0ub 3n97k3Rsun71w3HJ+5jk3e8w5L5qGWV3bcd/87xPD/J2+S22jOZU464eu06MgJHWaN95O4v6ifFq RPeGkZz6fmdaOG1n0T4N3bBHf4e2aRhVbCfN21nsmTTrpu6ramAKZ/Q0Hs1lO4tq/9T14zjsK/4Z sUfjel23s2iGp3a3HwZ6oWNs63bGEhdpPjDmWqzo9x+GUfqTaXPXYdP0rOnOu6tFotrJi0y1ZWG5 Zs1LulVuMwQeFOS1+w+ZdrdPTY/yMIDtmU+Gpn1hzkozKBW82n17WxCoOAvjYy8FRBWnL+p+hwvQ MdjTs3VZwOlRAaLly9ps8R4ZXXd1CyuxE0XrjaWcvyqTuuv6lqG+kqmzJbvc3KavygSXDM+s7/l3 R1696fD5KzJh3mLyHHCqMF7mXzN7Xr4iiwa73zeMS1h/VY/1zur6V+TRPw0DbWEObscBH6s39XCC faDtKplqcZjbZsf8C2O0t5Z/13ok6p6+yfVdqImV2aty1EUyfembZP4q3pyKN+fizVS8mYs3l+LN tXhzK97c9U3afCVgZLTImy/sxVrzHbvBRJisxYzYD8JSMeE5c/+f1/9VuKnjU1e3beE2HtMfvmDm NWYuWWOT7asfJGPrm7LC69AmU6HTo3xdTsuIucON6xkpddXGH4V1J61KK5dl0uPKhqUfmZiZcPqK mjCbosS7NtTEVGT+ijzqp3rY7/Z2+vqKXzZPI6udsGBjyZOPT9evyGN8YnzEgdRFX5GHk+IDm27d DFbTDQxNfhXNX/N63LUeqVI7AS1vcqUWKmtNqR3VlSu1mXQPlQOpUv/x/xVKLRq0a3ZVbLXx449p FqkGuaVX1aDeUgjq3aHeFFGqd191+BbxMUWcHhXhMvXe2n7s7Dh7/opf4qS1DPXolX9ymUxfkUf7 tK9HjMTnsDf9PH9FHvunfoc/3AQLMdPf5SvygBRgxVjvaI57jJVdvyKPZnxiEh+YvfQxOurE+UDP O6fn+x6yB44l1MP4A3etR6rnThNf0HOhOhM99+x55SjQmMWheHMs3pyKN+fizVS8mYs3l+LNtXhz K97cizc/pm9y8xZaMWm2ZXJlw4fpCGImzFm7XHEPL0CMPhxfgBhxn16AmPH//ALECHx6AWL0e34B Yqa8ywsQY2nXFyBmOLm9AInzQS4E4b0KIfSBTq8cL4YmBiFUhRQEvjjaHYTbwrfpMJGLi2FRgSwW 4CrCWLI39T8FIE5mwwogPEZ0ZwVWT93AwsvIftLU9gl3neE35GKkOwdct9/1yfhkSrv40pim+4GV QN68qyY31dMIIdRUvjyDuymu2z3tWfU2YQgxuDu4pNdN6o++MrseqrOr9755EZcLWmifNUE7WigT tGn/gd1jFfS+bvFU4pP3xDEAaV9f9xFndPkUgC3S25vyziF10z1zFUMudQ0X5jveOh+zZihLV/yc qKmFFbr8qp4Mu7pRKr7wLa+aX908tRXbB4/KvflyGyHWKTt0SN5vd3BrEne12gtvUw21F/guDjO5 xIX2WpO4o8UyiRvLOCz832La6PtgpHcMqc0IixQatS/tWfbnJBu41s7vbEhvmUH0rDliz6yR7dp2 0tQWqdD44VF3z4rrnvZCKUUxm2Hm4ktDfPvdaGt91eS6e4Ifa2M2cShd9uRvvjg2XuAXjBLfSV2T qesZFsBP+6qDztNGPbJi4XvWZOr4oEympo8PlfjCIgwhyqIzVmj3MQDbqmtZpocnVm7pgFMAdmOy SSf6kOv3OQB7PNkqcUiNZk0KbJ4Qc594nUaCs+LYP4FPqcOIa9dvF8XBWlTCloaWmL65Kq4an6T2 u5ChafHN1699grRnC0LQy5M3+A5uTfhOEr1wjx3klK9W7I3MoOsXOb04Vy/pssZOioxjwyKqAxgd wsdxjFNPKfwAxIRw/H3VigXdSYFEdvV9HZpQZHgOuD2rzDB2FbhJcQyV7DHBhoYn79pZcd1TD33d hq1ha8UXXy5eAOJsTIdcNbmGi6KhZvy7aSrbiewxsfGV1+FOctLXRkl+1B8zXg8tHoE37YQXzsX7 IoWViNeRP3jF0RUzExe75l687I/t0yE5rzlb334QGNphTHo56p6z7QBs2euyE+o5pDIByJIqPnl5 kwLrJ6EbjdXNmtizTl02EbyyGWlcFMeWF2QhG28eZzr+6gurIOTZETNSu2lyWz31jGxhyLXM0R1c 0tWmEGLplh4cUUBIsTg6xsbl0hWWY2Xkrh0LkhmvkcUBjBjvHoolZXr2+5KSUyjkBnNzLotTSBvo 7oSqSRyJRfZnBaK/465Q/klTYZPbGmHkhcyaigfFDj5C94/pxosvo3ray67LIwW6Kq7GjFvY8zh3 5OXefK32kFnQ3MHojC7dwa0J1/X0OMB47oYhDhq5TGVFvyZTt+LPZGr66VBLSOAyG7PtkxqQmTuP AdjuWMs8Nu1TAA6EXsRVSDHSnhWIOynrNlYQ/sm7dFIczMuA15mUnONmxQ2sjpiM45Rhuv7iy+0l rgf3Os/m6otjzJX4DzPE3TS5ZcAekcwjRbiDWxOw6/Z9IzE7bED4pj+SNDJclbSkm6nXCPBQQ34v kq72fZe4DNZLOgZgg2BwPeOT99QpALue0IFoY4VbrUAWpk3VtmZYmTSV1dNuaJJB3KjqrDgMnrXa kMwZebUuAbdBSftaCT/JtljwHcwQcfP5SfV3DRt5+hjcHdyaxF33d7JcZt8rmFrsjdy2X2SnktnY sVNpkbUlRgg3Vomzw0WfxSfvsWMAEq7EE3FGBKcAHIj26KPuWzr2HIGgmLnDY8xpUiDCZyfP9Ois iWIkjKTRxzKqfVEcIUYYZOhZgmLydl4VV7HYGdDD2PXLfHPzxQ3MWoxdj7zvO7g1Qbtex6ve1c0Y tCrxXXJBbzBgdcmA1aafDmBU0PQik2V4DPAYgISD7FKgGQRPAchET45BfLZLzwHI0nokFCQ8JsdJ gRibBItE1TEqNisOMxkr9rPCY7yIi+JYuzAlYJj+if7PItSrL5eIPFn1GdW5aTJmyWg+DmEQM9nc wa3J3Amg2hEzSK1ZW7on9n8u8w0yrC7JMBumdgDjZQ7HlcyepoXHCNzjCJnuPoXUvicSLJlcjaGe FVg9sYLt4oRlZ49JcSyd99lq3BQ8K66jwzINM+VefLkSMAebEhtqbdv1B+wnAxOjuVdZU+7Nlytx Pz3y9jjTbXdwawJXhm5H0E2fRfzkgt7gwOqSA7P+yAGMCrrtCX30el74U8cAlDmqT8Zc07RTAMpg 3zyeF84KZG1NfNZohstJU4V2ko3n0JGmuFlx3dPg9soDMJfgxZdG+G/Ttp0R3NUX1z8tJ2nyH998 IXhthC0JAa5PjruDWxOrp8NYN+BDJtaSi3WDBqtLGswG7BzAqFgb6C3T2GNMHRBl0remc08B2OPA sF0RHjNenhWIGe0a+td3T2m/rl41bgoxbbEfTQ1nzQ9ykgC+RIcM7uLLRfz7PQHZvoJxaNRxWstl gpAA4VjBXIA3zY9NVAiRsTfF3Ulek68rhHXVrmap74fpZOWZybnZYLyW9NzttnG8BzAqZwQU3T76 P2/YMQBZhqXyscBTADZMWDb1HFKFXksnZDOjTQpk+UXwr632rKk1nhLiML+9+N82CHUkhvmRUH0u OFx9C4+aN/mmyS2BPQTRRNffChXcilA1F9ZSrPWJEPKqHWeSXKgbPFfjeK7Ms45ZLcp6AOONFz8x zklWGscAhAahG30/lTRmABIYL/GC4TF+1FmBQoownj5cBU2Ka/CPyljQWVM7SPhGRg7/FIJ2DSVU TuYUS25eNZsavprBogr5GOO+Ka4nTAiqmfroYwapO7g1QWtl8N8J40DzgjrlAt6gupqS6qrN3HYA owKWFbCRwTGm4uO0wWcspuRTAHZN27GTHJ5Y9UWhzgrEeYF0Ds1a0iZNk7BJIZ5831m+cFaceM5Q WaEouza7+LJ2qBDBLMYor5oM04VLzyAZMsqrdVNcu8cDwnqDTI3s7+DWZKqcIiMyE1OkFWMH5bLd oLyakvJKJnE13kB5EebsTylJr5qaH8nMKUFNfJZNPYVUxjXiz4NYkoWeytZlgxcFKxVtxGY4aYaw xi07Y0YjZ01lofxSiJ6mQs3K2auoI7Ebl7pcfS47IhbYxX0sXFdnYspr5vdIupla3clvTbgul0Fm kT1b2V6VYi65cIXFWuEzG0k3063R3gMYlRmzWhINaXv7GICtnHoK2ltowSkAOReHtedWcNZUuHx2 MezuzqSpbDsMFGP0a9ZUPKMdESlh3tqb2ebiy2DMZ7TemypcfSGNDMKYvu9l0zU3xfWEH7CpFqcO U9wd3JpMXQdzXOyJAHL4otAhuSw3+Kum5K8ay1+BUVnueo6NhYIWVT6GVCLrmYRDq63lnAIQI+1T 3tAYx1mB4iKjBrFhS3mTpsqeMCc1Hpr7rDjmqDGd6uywcFGcbBRIOGGovyn36muFmrBBIXsP7jHa dPP1Yw4hBqU4cUjymlSVtGLygDlvwuzxyFI3SKumJK0aU98DGJ1iGyahWJBK16d2hKwktpFM+gvw FLIZ2f2vjS6fNRXzJHQ1pUBzZZoUV7Oo4AxNokw5blYcWwcsnS2ZdPGlEfnBTsVgNPbqC5GNh5ZS HkrStX1xi2WJ41XD9NGd/NZEGjkpNjLGXXAVQ5Nyg93gpJqSk7I7mwcwIlJ4WKg2X2v5s9wgVCh+ ZcP5q7Xh1/Nc7BBV7BiGx/iO55CjlN3F0dRqzKRAzLxiOo5ToBkvZ8Wx40eAW+KRG0W+KG5geyCd Ku1a4OrLJQ5ZiKfHzrJrcYcyyqgQ3EtT7p381sSvslgsmp0Q329xeMnFv8FUNSVT1Rj9PoBRiybK ym4CHUMq52aZN3x9XlgK+WwkiDE6DQWdf9Yc2Y7v5BhryNF01BRwQ8voFnXN4GbFQSFRLDSnf0w7 Lz4/Rtp24Oirx5n8roqrB1bJnPsKBRvNvflyWUUtQG85hb2vcleayx5Pmg6OE2IcEnOBb3BYTclh NVF3lrH3AEYn6HpouliQDuE+FV4Zisv30gsC90AoaELmfPOLOL6zlifxFzApZvqeNBVnEwow2TNf ajNraiebfTjzsZAwHC64iy9DvAA5OZsnX30huyecCaJ+fauM7G+KI3Jn5BKCOLsXMl3lqzSXcVy2 x+LaL5aWybTd4KuW9NyBti7rAYwaMdFPsd70V94TxwBktYIRxA41cjkFIAfNOSDre6zwtM8KRLzE Dllmb9JUiEnosWSJY6xpVhz7PdwTYDT24ovg7DzOVGOqevVlSIgnh4pN1jdNZmTu267jlgz/5F1z B7cyMmsuexbOhO7FKS3aTy7UDb6qLfkqG7RwAKNC5Yxxk07Nec2PASiUoGX8TyGVw6OJk8j9Fnk2 ZwWyYw6s8KQ1FaZ3j0sehkW7RJsVh8nudmkMjxHLRXEDJCOro6iJhXSVP2KhxAhhFfqm2bRQ2rQ9 rh2jsS0jxB3cmnRdIRylJtQ6MqOPou7aDbJqSTcma3r7ACZIt7IBwMeQysA3pvOuadcpAKFqZQYJ jxkDzwqEOaa3LTc8aWr9BC+65l4pDv+Ew2kJDWNKuyhuhDoUhijUymjB1dcKP4x4ooSTzXXzpriG qALOOjKS6GN69Q5uTcyuzwdWFkTDJQuUUFpuxBu8VVvyVnZwOoBRMeM+VSa24RhShWfuCtn63wrb G53BF8ZgD2QvuOaEfXhMd09aHnwUNwUkG0DG6GbFyaYeT8jOGvtFcdAK7CdxviX042J0V18cy2+C l+KgYRp688Wxr0yMhzWGO8lrQnWNZ2Rm/ynGfySubC7UDb6qLfmqxsyiBzAqVCg/62AdQyrDMY3x qsqfefecAnBPeGK6F2uAZwUyxw5Q6Kb3Jk0l+JmbFTjn7x+DmxWHUGsmwuAEJR3lnClfmhwZwbUL vKTJ76o4oqDhUhlTHpR7UxwrYznfhB7oY/K7g1sTs+vzPdM4F0dE6jaqeC7mDSqrLams1lJZYLzt sgn6WJDHAKzlcp9kcWoEeQpAllrcp+R7ojg7fg5A/GmikSPQjCCTAnGwaiLpk6JzXZsVx7TMkjwJ AjMme1FchclWVWfqf/WlNU8Vt2PY4eymyfjPhIZy15KvdpSRTsartJbmsueAP0Nm5N6jvuSS3qC1 2pLWsqTuAYyXdBKDSvVjmUvNjwEom+zJ6tUCTwHITizm5nuiPL2kQKYk2eKPY7cpeVIcG0r4cY91 cVbcIFMcBHUYfcwQf/HlQljg4sfQm0Lkrms4rsbKnhN3IcNcwW6aXys7WTAvoYam3Du4NSt3pclJ aUjz2M6YSy77Df6rLfmv1ijjAYyTPfrMfQ6hfXa4Pgag1IwJLTyxcouSnAKQ7eMkXqFYQ58ViNeF 2x630WzJk+KwOk482gjIWVMJscFkiRL2T1ya6Liu5BLD8L6LbLEt7eprxYRCdtHJMxp5U1yHSrLF EY/KGl/wDm5N4q5We1bLcswvjIlxoMslvkF5tSXlZS9IO4DxEuc+unS5nOv0MQAbCcKLqm+77BSA cpA0DaqOrVhkcFagHHwigm7F2l0VMc5eaC0vUlvwrPkx4MqVYXHuNzK4KA6Sl53vZD1h6ndVHDdy cBIi2fcsZO/qR0A9s0nFVqs+BncnvzXZu1xYdrFwTa8UykW+QXq1JemVbHAt/X4A4wd4JpXY73bc PkagMA3GhE4hlYgVWU6Hx1AWZwXisUGfJAd9TP9MisOECNyKF0PYas2K4xKKVq4eDPpghp6LL5ft QrnrMBLquWZfFSeHkAnuYAXunxx3U1xHfjh4cZVuZok7uDU5u94nBlVW+2zChFIyQXcbTNiSni+r 7TWfBzBe0HJmOhS0qMExpLKTWkRhnUIqkueWSN8lJVOiQBxkuU7yYa9MiiO+mLuqEnUxWjArTgJ7 mAWisxD7yY3gvly2pmGEWtO6qy+OOAGmpzgMmeJuimvAQexxfu6B8YJbEarmMqBCMA/RMYgeZS7c DUasKxkxe7fTAYwKl7NllqE6hlQCjlkm+VYVTtwpAFl0Ue9cR86aKrFaXNUSVjXWJCfFEU2HTeIO +8f09qw4PO+hL0q7+NKYbDkRV6ygffIAMUOonRnWb74OBMLzWxtkcCd5TYBKehGNzzHoqMaPBLhB enWSbqwzZuWGYTAqQIJzRtPzx5CKG0Agby6XU0glUJi+8N1delUBCK/IZv5D4KRAzFN89LBasZKe FbfEwSGDkKGR9EVxFRwpUV+dafzVJ3NHYSsHaPP23XwpbDwR32dp3DvJa7JUZgsnUHit4ATGCSw3 xg1mqyuZLRvtfADjjTG7l8X6KMcAhNtH0R4Oq6cAlPDVZJKzm0ZnBWKiUMwFH6KpSAGL4mZO/5gO nxXXymHwuB9YrNAuvjTkz87hGFcIuQCvimvYy5LbTY123zSZSB44gioOLGaQv4NbE7Trde4KhQyq dsnNvbmAN1iurmS57HRyAOMETBQpZ/d8N/Jn3vBjABIEHu4gFysxBnIKQByw7BoJM66dA1Bu447h 5wVPMikQTcCDjBOnLXlWHPtLnDJZoT8Uh0PK2eXknKhp8tWXS3wPzq/durlpci2XzI64Gn7IMB1y B7cmayeAXpboCOAFZy6X+Qbl1ZWUV2cpLzAqcwZoezfSMaaOcBVhqfaCoH023I1LlPhD1TlrjoRP YllWAydNlTuzJYwkV7tZU5lYWX1G+rHgM30ZkNTc+GFDmq6+ELmWgxtpvKisCt0U1xJdyeZBPKxi hvk7uDWZup7Zc5KJZdhLJ6NymW6QW11JbtlthAMYHaiZNm180zGkEguQbbGbdp0CkEAQucA3PGYN eVYg3jH3PbGs849R/klx4szCR5hcZk2FrebIdtzXs2K5+NJgoQkM3plB/uoLwb9iZyF6qQZ388Vx +QHHZMeg26bSd3Br0lX6ilp3nJoOdh/7MpfuBn3VlfRVZ9yiAxiVLix8smGpCx6fykENtp+CzOzm 7ylkA2MVBxrwRi5nBQqDwXowToZmhJwCTq4YTXhIg5sVJ4dNWEglNcyt/eLzgyiVfc7ghRkBXT2O HUUoRMv93DSZjUQW0rh9eSl3ktfE63qT0GhOe3CRstfsR17WBlfVlVyVvU79AEbFC8HvvkuhQsxr fgxAzokRyRclbTr8FIAIBfvMszlrKuKV+FYzL0+aSvvhSiO/b8NkZ8XBBeOoY5X+McK6KA7uD+Iv meBMuVdfK+wKGs66ojdNbpgKaryF2Pa8cXdwa9J1Xc0ZcAmjiB5hnHdy492gpbqSlupiVroe8rSU TDwpwWiGpyOZOTVgXc986vvzhZlXqRbh77hp/VFXnDVDAqZEkfN+mkIincCuUp46a6qMqIRTJZN7 jrv4XKAZ6E8beHj12bDTxHFWu4t602QCO/AMOF7lW2Jqcwe3JlPXHcTX8akALgv0uURBZDLtNxio JT1f43bGgg5g1GIl8jUODW5ADql4jbIEDo+R+EmBEq8BQ2fGqbOmyhpn9ZZexREOK1Gu0RBj+5dq zYpj+ciNVgk/ag1WcULYMjrEicIarOI49MXFAeyU5apx88Ux2xJnaGetO8krMtUfI1M2iJiuvDFE QeQy3SCe+pJ4slGRBzBepkscW5CaGVyPAYjCwshHXCFenyNhL5ybjkCj32fNEUPlssHK6MGkqWyK s+cGDxWevMNnxRElK3cyBjMoTq340mRpLft4eTZXn0xcD6yXHfZvvhSCsQj2JHxdH1PrO7g1+bqu kUuysFhZw7sn9kwu3w1eqi95KUvNHMCofJkSCxc5pLLo4bRq3ienkAqlAx/s21zyUgpkasXzSB3o PMNJccIIdsXdD7OmwhXLZSdR4maguSiOiDa5DCRy1EYRr4qre769RYZBZsbyb75c+fwQoUzB/49S WUaSO7g12bqOhpTjfju2DGOtc5lu8FN9yU/ZqwcOYJxM4eIIpc87+RhS6Rk+RhGlZtp9CkAujyOj PJuzprJ+hXKPqmopkklxjNdkEjvZWtCsOLxT4uaiC2JxF1+u3HfFGTVTrasvjtvxKKwOHKjphZsv Dm1CRWRMd4/phDu4NaG6nh5Z0+IXxoinWKtcuBvcVO+4qXQZbcm0Axg/IHOPRS6UY0iENYC58o0q 3NlTAHJfKL5Sns1ZUyUelg0hPwrxZ46bFMdUx55EcuFRbL7Osa7OuCJcmhT5A8tuXny5wuUyvT/a nrkqjpMKxE6yOvA1NOXeFEcAtHxyJ97bWFjuKhnlayWxfg2fK4wqkgt3g4TqSxKqtyQUGBUuxGNc ihfO7jEA2dPGCnwHFCI6BSDxkdQ+F+BZU93hgXKKdbWRuDNxU2MheS6z5sJ+EIfq5W5tfYw4Lr40 Od7GUGpco6smMx7jNCP8B9ncfHFL4LMETvgnr9Yd3JrpusaN7IHgSMWLr2Ktculu0FF9SUdZEvEA RqUL7W53344hlWNZQfPFgs3QdQpAOcadBlgZV/SsQIlmHGF+w2gQFXgxz0lxy3ZmMl9a85wVx3lA 2R+MShensiW/i+I4KsohosTlMsPH1dePbbiBTajQaNPgm+JYEBH/3EQFK8x4laHSXEZZmnMffVDn qKW5wDcYqr5kqOxa5QBGBc5JXrutdwyp7m71IB7LPZwCkKv4CIqPwMKcXXn4WRzutp+anDQbKAwY jiRayohlVpxclQMvHEuLlqFi1tJwAQiIj6HuRr2uvtwdSzGOYAeHLHb8kt9NcQ1LNvnETCjZ5HcH t2bXylQJfSpzja9/7KtczBtMVV8yVbZjD2CcmOEd+GqaH474Mx+RjgHYCB8dGlgM76cA5AR1xkrG Vix9dlYgMxOkntW/SVMx7IH9/LwysybKLYRUpbBh1yZZxgrhZ1py1R9z2TtLMw55hzbnhdx8DVBJ okDsiHgneU2Urg5YLMdKkxsv4/iQi3KDlupLWsrej3AAoxaL4xzLWTr7GBKlQ+Jw9YJ35XNhAcKh PK+ChZzPIUcY/GTVWOzETgrk2l+21JIpz8hlVhzOMeFuSfS0saGL4iD8cFqtalx9acIkE/v0eGB2 7cQPk5MpMY7AlHYnvzUxu1y4bYcdfOIpS13KxDxsMFVLes5U2S8HHsComAnhyz41levvMQBrVpJ2 i+UUUuGN6kjUlWFTAbhn6om3LPPN6Ly8SYHEu8LmQiD7xxqv4qAIZUcgdpk1Y8URmCF7yQ+jFa+K W27RYS87LJuMJG++fkwiXHFhL4C/k7wiaP3xyEQgF/DF+SSX7wZrNZSsVW+afQDj5Qv1Z1KPIVWu CktXwMaBOgUgHZJ8vKq04wCE0hvTM6NmCJkUiB1jLfFyDLu3NysOyoGT98mtj6YpF58f3wqhoYVL rcl8BoywjMce4E1xDdFUyCX6lKZD7uDW5Ot6feA8kkR5xIVjUPJc0Bv01VDSV5avP4BRQXP+JC4Y CwkdA5CpNzulb5zIUwCyskh8zb0lDM8KlGgUghSMgU6aCu1BcuJFGYOaFcf5r+UD4aGnnIvly+D4 Nv5jwrLkuKvHMRDLdaJGbDdfiNuVSjzyPJs7uDXxur5mA59pjXiX8ONcqhsE1lASWJZbOoBRqe45 1hVo7hek6oFQRq3dHDuFbIhUTX0U65edFSjhcNx5FReUsYmLOCbFsdBlcyiNCwpdseBmxTF9sjhP 7uKII56K11W/goTCQ7OTwdVXiwMokBzxgJ/RoZviOkYLqAB7zONO8ppUtQ47InYw2Thg5VLdYK4G x1ylPEqiIEtrD2BUqowN1pKPIZUjGnyGwk98xa0KpwBkcYlvGp2rWPWlvHMAsmQSkis8xuQnBTJI ykVmYWFYrH8VR9gcoZDJKG/M7aI49na5XDk5V2PKvSqOj2kPDDUxLq6Qr+s4wuvgKhNf24w5d/Jb E7TLhU1ejmbCB/gnTim5xDforKGkswZLZ4ERicsXOFDv+HTlBTsKlSAUuectYk3nngIQfxNuMgJN r50VyK0nlJ6c8iqM2rNccoVCsnozvTtrfvIBE1ZTgXO0g8nFlwvpyMogOWSTDxJXj2PM5nKQh5Fy N8XJ99JRzodRWndwa9J3rRy4LJ5rJlil6vNI+ht011DSXQkvqvbu6S4iX5OQkRdGcQ8kCo1+9VUr mS9KdSMIJAKxMBEYW6Gm74DCa8pNfnnPT5qNbEmwsxiX4QY3Kw6JQ6cktxqb0i6Kk1tH2Wu2B+Gv Ppmux1eP9JVRsJviCLNj9CNQ2jfPVOsObk3QrunsIbLJlARyxtJyM9+guQZHc6W6Ze8ZOYDxA3u9 dkLzGIAyisWbRF4QtCeyCIJNT5UVNu5xLKqqxycRJi1YGE72KcJ61lKrs+LwxhhbkkNJRgQXxbGs 4uwCl6V6UZn6XRUnB8Xl03phWWXyuykO0fPhLO539PmZwe8Obk30rjc4KC6nCJKAqlziG4zXUDJe dl/4AEYlTtBEEoBq1zHHAGzZpbHLk1NIZY1GjJdvdUGonBUoTDYBmNFiTX9PipMj3PgGMXA7Kv8y PsyKY9tOhsLQ3VYfLr5cxnK5OjcATblXxUGE4ECmNx/kI89NcRwclU9tRQrd1O8Obk3Oys3tcESJ VAgRgbFWucA3eLGh5MVsxPEBjDfxHYdokydv4TEA2cWAzokijZVbRHAKQHYSCBWPOZq+OCuQdRYc ZmQmrKpNiiNkWmjr6MWZ+X5WnIQRLMsCX0VTwYsvl8MP3JnNDTv6GNxVcayd4TfZ4PS4wsaV5sLF kYOMoRNNe+/ktyZ7l4ucgqgIn6miT5nJfNwgyZb0nCSzAZEHMCpzWcobOcdEeAV7XO0UUuXcSOyS Yuo/K5AdQTxl60FMmoqay8dOfMcWucyKIz6dEJZksW3XW7402dFkHo59t6jkVZMZrfEtU5cxb/vN V4vzLEz3McjTSPwObkWSmsvIoEbccYyMiJRgLtENWmwsabHBOCoHMCpRTtB0QQOxvbyFxwCsuS6f a4fikwNPAYjbI6cBw2P69qxAuYOQ+2iNYKaQOsJv2yu+Z01lG4DrmxLH25Rx8blI2CWnbcPgYy1W cbBig4zpsR/yxt0UJ99O456q5Ha5HHcHtybnENTFNUHJHBL7IJfzBis2lqyYvRfhAMbJmU1Vgo0e Gs4xAJnZYLEeAk8BuNwkFxch9sjJWYGi1HKiN+RoZDApTm5vkfibR7hZcUJ0EzWad/zFF8Z9Kdml Tkadr4rj2C8BT1yVmWdz02Qub+H6N0YzXxmDu4Nbk7PSY53c/MWa0z+P5LzBk40lT2YPTh7AqD1D k8lt+/4xNT8GIPEZ6e1X1vBPAShf6E6WPHasPCuQfT1mUeOmTpqIcInMjHECBaGiOL6Nwu5g7DG7 z3LxhXE3Cv7x3rTu6ovj+CFjy8Oj/zfF8SV5bmMiMuFBb93BrcnZE2Y0j5VLMsjmdrzBmI0lY2Y/ OHIAo/KV26+CZ1FMgMcArFmoJoyT7fFTAEInc79/GK5L+bqisWMYjMcbjpNmyHc7mHiTS2iNjGbF cZqbawbj0FyatJaLSbOjmPiFuc1eNT8+PY0UuZ8ntCTH3Xz9WNIhq+gbFHP1Knfma09oEtRlcrI2 lJbLfoM7G0vubLTcGRiVPSusUMziqBxDWs0pk7haLNfRAYhSZEeVjdN5DkCOLXLrireMciNagRJR J/ejhW43Q+6sOAmv5OBhHJpMv18Ux61bEkDy8DqOq+JkCCeWJpJEJr+b4vjMB0cekntXjT7ewa3Z uOt8ThnjeopuBQHkct5gycaSJbMfjTyA0bmaFXDszrRMFboHElFAFGUUUXQY3coq5IizRMx7zNP4 S2cFSjieXCEdcjR9NSmO8Y4TSHbGnzUVSXONf3KCzpR2URwB9JBbyYE8g7v60ogWlbCw0PNL426a 2rInQlRivBjZ5HIHtyZf15d8a5xL62Qo1Cd2ZS7nDZJsdCRZOoTYz0gfwKg9c6ozbsS/MJZ7INvw fP/BV+0F4/ZAvo0ZUfwttmLps7MWzckG9iLtp7MmTcX5gV+OsbSJzi+5zIrjejVxmWO9on+z4C6+ NNlngNaO+pdL8qo4Qoig5/ES8uSbTyabRg6mejU2I9cd3JqgXR9xIzWBLoT5+1xipXNBb3BjY8mN 2RiIAxgVdA1jEUp8waA9EJI6uYSkiB45hRwJm+Xkpm9DeUJVgRKQR6RdUnTet1PASdROMtgbw58V h2lLdEHsMxW0q79wltxFEck2Y4pXXxrbQPRHcvIrr9XNl7aDHOMam7B2MLW6g1uTuKuVBI2h7PEg QZxDc4lvkGNjSY7Z1esBjJc437w0zT+GVHcpVbRU065TAMo906mYTY5nBSJm/Njo0lhfalIcwUSs uRM/Ve3Z1VroLfitaM+mWhfNBUdLpogVMbv8IKbkOJA9mnDTbKC4l73HMOSa4u7g1qTrCkG6vUR+ h1EhDnmZdPcbNNiSntNgtuIHMCpdblhPVzNmxDoGIJcWszeZa/cppBLYnnajddHPCmRWlpgyI/tJ U+UTVbLvEMYCMyzOipMjF3zvNDr6hhK6+NLYoWDNCtnjn7z6V18uXAi3qwXK2ercTXHyJS6I4rhw MO24g1sRs+YCNyY3m8e9+0di3uDG9iU3Zi+4O4BRMbPsXfvwZQBC2yWjVDGRnwKQ0EG+OJB36Dmk wmtg8L7bizijSYEEpzBSr1yIqDjmcRyjSC/befyiOCJ7MXu5O90/eQWvvlyoF/HXgothDPbmy5VQ J6gT0847yWuCVnIMd31P28Jc9EjQG+TYviTH7HVSBzAqaK74TFYmVpWPASiL6jg+lo5YAOJe4Ufn /XjWVFbS8vWERNA5blIc3Sh2HS22sGxXf+LbWZjEbYli78qXC9tBOH38fpoZtq4ehx/GLn38YnMh Z1cuVw3AFLLa92pTWPYqS6alcRE9ofJ8qMjnEp2LfADfYMn2JUtmo5kPYETgnAeF0SojTzSZzXvu jYwxzC+I2bNt0Nwc4MnFd9ZshBAb2Znx7bLmNwUcW+Cc0QjugOnuWXEwDlBo8ai3ta+Lzw/vHsYk sfu8flePY/5Ftx4SKzfF8cHigZidGCtYiHmVJNNcuN+Ui7q4Ocw3M7YyF/MGWbYvyTJ7aPEAxs/T cqt8FIBR+GMAEhPL/pSv2gsC9zly9/ByR4vP0/TFWXOUXSz50ErIMbZ2cbkmxbGQlttyY8lmkTsr jkBLvtpmvyR48aUxgBOlEKMZTGlXj5OruNjuCaZmBpSbrxUHfuC/411iJr87uLWR3HVWL3fdp2cy 43yQS3yDIts7iixlafaWIgPjp2x8qljQ0tnHkMoOnQQ/xye3jJMCsVz2ObmmPzw57hxwcGTpwSjT T5PikDJuvL1FaNZURlG+AhYXpNYNvCiORZNwd5GciQPl0syrrxXrHbmdK1S+kLLrLLap2UpNmCaD u5PfmpRdLgMxkFh1nM1irXIpbxBk+5Igs+z+AYyTMmFk6elEO7IeA5BQILosWKGd2E8BSKCpfFE4 PMXU7Ypm05II4nQpn2vGpBkydRMYnFBgZuSZFSc3oI24fKGGRnUviuPAMfvQ7GfkxV19cXLxF07T C4Proho3xclttzgmSWBrnt8d3JrIXSdw9RMMP7eF+t6Klc5FvsGV7UuuLAk6Xip+AKOGzZnl1PUy pnYMQFy0RPepYt7EUwBCyfDpb9+GAnhW4OKeQB/n2UyaCvst3NxDX25WHEbOeR97Ld3Fl0F4IlvC D/efr4prlhDWx58PufnSiEDhkHd0os20cge3JmfX6QyAxEX2y8e7FwWNfZ7LeYMq25dUmb3E9wBG 5Sx3Y0d7sBZ7DECa18NshSdWbtGcUwCyzYk3FHA2x3MAci8A5+Ij0HTapEA5kcVCLbKZRjVmxXEg EhbVtvSiqUT6s2/CxT+5Xl19IViqkJ3BxkwhN8X1rIvlwKBJvpO8JmDX25zNYdzg1Gbw4ENlcgFv MGP7khlLjnSpIQdmrGLLwrjMR3LQkV3uxzUT0SmkMovK6aXwGAmdFcgCGR41Hhu2C6Ip4DjjxN1D cQwI7V8qPSuOXWm8adlr0sfo2kVxcraO8Ha7ILj6ZG4ikRBR8+ubr4342XxBKuznGNwd3JpMXRey nCLwiQWVr2vUjEymGMT6N8sdIGfErAtzEJCfkrmxOfaQVchjRPLxHcLe8p4+xeSeaJF04jSqcvZI hCx3FkcDiQ1dhDd5oIT6yiZ/6BADnD2Qm/NkJRa0y/qRFw9cgn0JAzd6eg3pBPKzNRKP+xhJ3jyQ cxx8yoT9CF+mAd4FuCJznw/3zzN0cXTAtzHWzAh9gx5jG624wNwed0PogSDDcYUDjE8uVYTukbKb tDZaRySLRGwoZmmkhfxdnnIZGIcEou/hpe6SxRTZPIiVi13ibNvnwwFpuSE9LsGMDJC6FogPxicM kvbmrUX8WjTeH76FpZuQukvn3k0Wh0lGZhGJ1FeZMp/PwCE+bqyP2zYPXG9Gwi1TL8kyGwaC1ANb Jt9ONHVG1D6ZrZ3i/gHs2ydjscw4Ub5GLsjXI9kdZmUUkWYkwMAdElHz1fhIDduxBwN3QJYqsk0Q LdwoD6J2QPlEDMA409hZ2gPlIiDuVHw4ZiNzl6NEK0i8OhbrHqNlyHyVLPP59JBTbLJFTzjmYyx9 gy5ju6i0dCMLZO6JLvn+WrzUir7JdR/xeyTLlGQbvWCB0QSPFI4qTlPF8T40wSGxdHjz5JBIbLO3 eQ9k/xtiNa8b4nfJ+OAyuSSTVA5E/JoP+45cT2c3ojFwTedD6CSbOQxZu2SJOGHH3i7WEPEqUeZ/ Pu65XGqAkS9VxYh4gyrjpHopYiM4ROypLXZpmLSiuRkkIvZIQvk48O+rV7JlEdnD/6xd7OiRMC4I LsYGWScdW3eFy4TJmcs46xuVRdgOyNegmJzSmxgKYTsgVw6xE52cgjTqg9QdkMAkzvvhVYYuynNE /g6IrfNRd6KnfA8ZRUERVvkzn4/ced9AYIRuifkYRdhg0PB+CkVgIMqrjyZEEo24nFL8PpkDPLg2 oRfsWICFeyQbOSnBZJktLNwhkWrNd6uTPPO6IX4PZK0DBZMnI3SXzITITDCEvWDrumDhDsiWF0Fw BADnGSFrLQcRQnA8DEJD1g4IOc4pMrYJ84wQ8Sp55n/O7vUOmjiGxsSJxoh4gz5jbnlBxKZWiNgz aNCWVRpYUErbI3EwiBjwqvzSeO6R8IAsWB8ikbZDwqjI11dNkcjYJ7MMYnjNexQZu2Q2pyqKiTUq J3HNZyHhGfHzjJCxSyfciP21JAArmtcyrSBjB2xhXSCL7GFHZLzKlvmfj3Jcl6+FB62MQ5aR8QZf hl/8goxNrZFxoMwImiu+/hWTIR+gbaO4TD9hxkoDSVQWppl3I9J0ydgu53qiOIrFdgTCcTMihxJN gUjY5ch31rgRpQj99smsvhgCuKsorxBy1frK9QXy0cYwQuVA5KrlsKNGAEPcoTMjPwJepcl8PkzY +CfJVX1RI42AN4gybp59QcAxt0UtEXDgyqh9/GQVzc0byoztkbSTEJk8GQH7ZK7FjrMM8jE6haw9 kgMNBKAHEdoAQ4zYIbE99MtUCAm7VOG+5FxmyMeoAuO0A7KFJHc6B0rE+gUI3QE5wcMBrPTr6Xlj EboDyplq9lCj4pvuReir1JnPhzhCvrgip0T0iXOSEfoGeQbL+oLQY25e6JEhY4x9bG4I3SNhINY+ MIT8PZJvJQzpCc1S/g7Jakf2NSM9a+SG+B2QGG4ispJqmhzRBAfkohK5/Tz65MYG0QQtmrIZ9WPD TdFoggPKR3pBJd9X9KO5Vo1Pj3GxRMIM5JqCAqzybL4cmborTmIEVzQuT3MFqLaItgWQE23YRl6r AxHOniHnNrfk/p/S6gNSWAi7iDnFjOQrramDbKz17JFQzHih7cOBe/JA2Qxhvz34vdZaZw9k51Hu DIv+nhmaLh7IhSgw6BxjyXvj6tNrOFP2au1Ac/PpYu3EKNtInLukr/Fq2oWM8Nz4IIdZ/FwS6mFk vMWrVSWvhn8QclMjB6VsKkze6sgekHy2kNnOD0LF0I24fZ7i6cQgjiK2GHE7pMStEKoRuESrYIjb AeFduLwNCt0/RoqI2wG5NoMtxyTKwdgu4taiubyMm/ntKUbErSXKaXmkbUZHxO3SiUgiEIJLLB/U CLmvM2uaD/eWMUGxg+b7NRZo5L7FrFUls4ZSFXJ3JBEnnejR6I/Qihx5ZNzyGgLZnm6FmC5F7h7J CVh2eHxLyjMBHinRutx4Fd0mUzhyd1lCb8rdSNHTN2Ujdwdkd5tVfbKHZRQEuTsgNNrAzptJRuya zP3BJMcZyhSI/B2QWFMODSfWUEzuAFft3uXD3TjSFTHWIkrMyH+LZatKlg0PIpcqY7sjjpA/pUZd W0YFZO5TuV+jiKZG0D6Z41BFH2LV/5+xs+uR7DbO8F9Z6Cq5sHenp2d6WrAMeL+/jBgQklxv5JG1 iKRd7I4TwUH+e546VcUiX54+J31hyWINycO3iiy+LBa92CIXyODe8W1jJ0A3BaEXCX5LE1IdBF0X tO0TzqB0F0y92GKN4MpLnWS2A91oEPcZV+HcYBNfAXRdkA0bWRWm2QGj3ubV4s/JKoo94xKlKZRy CKh7vNrVzKsxW4zjCajOBplR81BxeTg6oACckni6540TaLBOSSL8hmddBQVgd0lg51/VoQdsL2bz hpfYHWmIagK2C3JKwnrdh0uMnwvs0SApPblrMTMr2SLPfEMfXbzTAdpe0Q0ONte+ivYVowf2bRat dcjeZ7f7TIF71SOw77FoVyss2tXEoiGVkQw46oILWGcxu5DNdP0leUOA0MZUD9ZeJ3suKC32hPmr L11mElB3QXuclbmg9v4iCOouaKFpsH2luzUPLjWCejTtrt/Fy7cYezTNDE34hB6dgrqXw52zxcAH uPANoL5NrGWHnrCcsbfvjE3Q3iPUrlYINc0XgJE7RYSR38CC1NCr6wvwKYnuQ27U9CoTB0aekndM dj1JJzMowLskDjonG32g62icAO+Cy/sNnNiOxcDtxR7K1+2xRBC4o0F8xMOS7XuyqUUvgNsFOeC2 NFtVZc25iyC4uyAZK+1V6TpiEk0D922yLXtGzBIfSOLa9o2C+x7JdrVCsulRD7g7hcTUYtEW8lWA ncWc8xLx0fqyfDQIZzGHwP3sq4euIOyS5pPPF27B1YuxPgzm8r4chF2QrL7wkJ3LLsMMwtEg0zR5 Oy5uAkA4mgZhjnvrdqrMJSDsgjDlrINQ7mnZMmggvM22RT3su3nrFuc86ymrEKT32LarFbZNQ6xB 2nkjLPx0Jtljtjpd8gH0lCTyuwvGniTBPyXtkKE/cyutXTQF/F2SZRwS/vLyiya4IL45cdtt/zMd qqIJLmgZi5bHYvODREnRBBckJSmZf8owuxk1bT2atrbJqjcrgJezOePKKnReTn3ia6AA28xbdIiw Bzu6qc3ZRQXYY96uVpi3KxkHFMB5IxTADr2qseXrQT2LSZA03e0C6ixmvceccrQnpQBql+R0hHxp HXUm4wnULming3izW6u4C1rS4FuseZyFADgaxII5cOlyhYyCmHo0iANNqpCLDWLqLmivh9qJQfP9 Z6S3Kbbsmb05ATXZbZhHEz/sUWuLgFBrV2JkTzmoTZeN+bi2tRNGz0qS+37dVDBJPi9JPE/OWQp3 mfZepCRsCs+837bpUT2IlylIghWOx+oizbycx/dwzYk1tSPPp8k+BC2ezYJpBaY3rUVomVsLVMuv EJV8m4JcBmCnc1eXTKXFdya4tf/ODtnLL9yZKJqzqaQowB7vdljh3a7EElAAp48WL+7QRcfrXIcC pCS+CpeAcyqb5lkUICVvSd3Q3bLQOlEAl7QUtYTwNaNRQRTABe3RWXBt86gKvkpBjlm4nqtpCV5n sQUv0bHaBwis4B89I5TZ7js3OkwEwT96xmk480gxgjLS4L/Nv0U98C9cm+b94Uuw79FuhxXaTS9Q A7uzPQa7PdDdGouZvRWDib1i0H7iFoN1VsSXa/Qy+GYpm/tKHEptMowA7JLsyof4GhUEYBeEDkWy kpaoIFC7IAGpnPZWZkHdlwJ1NA0TRyxdRYTL7gSoXfAGV5J1ink+fvIxQL1NtUU9Z8LpiRjbd+cO e1TbIqBzvUxpYO5ckrlz+D+dAcuHYuopyYwAqzhqB5hnMaswM1UOwxQgAf4uiQ/3hGuetWzIiAG/ C1o84xPi0luVIgj8Lggpw2OG3QVOmW6BP5q2N8PZdTcWWGoE/mia0DUSROiOBdS9nPcTsUq2+dk3 qQjUt7m47NATvHgYpe6dKpnY9zi4wwoHp2ddoO1cklm4BYhmryfTA+2UtNRgdTq8cqDSJJmiIOtH vQDtrAi7tBz97ScaBNwuacdrmLv4BYDsxXjNHNRd7jogu+DygDyLTVuTavYMRz0bPJIygnfvx56D sddDuIudmdW1brEMMN4m3qIegtJtI14BH6WdgvUe8XZYId4OE/GGVBBvrMv6YDsAZzHJlnmnbPx4 zDmLLVFW7WYn/AHYJWHbiAXUikDVi9mSE0TXJemX4QZfF7Sc8syVRczLlAW+0SAmcyb8rRyE8Rsw 4mia+yq8YNClZBsFQdoFLZiYR0JAO36igyC9TbZlz67oGnfgukdFBeE9su3gZNvQ2kHmFqzZuSKb u7l82C3IIgnYKcn3dXKT3YN7SgLVNRuY+o2DBu4uaVQMznDJiXmgASnISjoFEYO7FxOByFM0mk8d tL2YEyi2A93r6WU9ac3RDActXFyrPHgyGKDtgqQkxwNgcc+ui6KB9jbFFvUQlkp6gQpZ7EgrQX2P ajusUG36RAOoO38E6gx7W8HQWPlQUE9Jory7lO9rznlKckeS6M36ybwA6i5pFKu93zQqBVh7sdHf x17/F4zA2ou5T28uZprZlEsR1KMZxvZ8mp7YxrSjHTw+Ijf1ZhIYezkWzZrE3mDsJ9Buc2vZvMU7 QD103o5AusepHVY4NU2ABKTOCPmyvGF0QJqS7GMJER4/C+vNYoK/sKbCUXQbHF3SnDAy5EoxOHox VAghM51xiyCIuqDdGhrig8U8QTQaxGO6hgNv4IvWAm00DbTQYxyE5m/8WDCOptkbszmuC6jSR8De 5tGiHsIW4XL66xKC9R59dlihzw7iD4G1c0JgzYMnlXqCjxy/D6xTkkShMBxlLTPsKWm56Np8RpUy FMDukkzaZCeWekA9S20n07Hi0jVQd0Gzvtk6wdqLGVDO1brH1kUpwNoFLa88lxN0OgHiKIfj4fUI 4o7iJz0H4m0CLephOoA0JqH+XM+I9fUekbYIyOZKo6qeQpCmC3YkCqNDUJT+WUlyrwfLHVXheRXf cFa8kRLrRUkSMMU+LG1nUq+XKWmkB96D7PZfZTFRfUyg3Z0VUanXKcgbP1zE53rL2Pc3rdxeVCU5 gHz62yznDWvLCFAbhGnOtjF/+O6br8uYaj3vsx6e92Fd6raLNZiC8R5Xdr3ClSlrDMZO9WDP3KDQ IH6AzWJCAAj3vogHGKekxQh1KTCUzwRjl7QbnzhzMuAA68XsajgT6PY/Yn1A7IK3sJ2wlDXyUiMQ R4P4+PaM8yXeE6xd8MA7lzCoVeUMejRNQDOXRZo96kL+zmrcBD16RpQrzxr0liNg7zFk1ysMmW6a ANvJHsBmA6qJbAE7i68hdjuiWSEE7JQkpAMuudSitHVxmQDbJVmomWv1ORHA9uLlahTqMBofEHsx hOWYGlkAAWIX5PYXrmLXIakRiKNBC5q4trcf4ic1YtcuyO3e8xOIpUbPSo1AvE2MRT0cc5051q/b qjVSAvUeMXZtAjp3S6+A2hke88lgs2o7Oq/TTRLUt9LagnrWSQw/2WlGsIDai4nUuOPUUuY/oPZi oIYfmW91RrERSRyHjHWDb9RNRCgId67hKAi+IWi3RuzFprEcWL38GhNnT11EjHwNsG4zX1HPHUck LGq1tNdnC6x7DNj1CgOmgdLA6qQOsHJ1cb4N1IrN3eA8uH7jOIBlVkTfu1jwFb4zJDnI5JYXCpI/ sRgA9irhibDAYiF0Y4dVuyATN4RbFzYufhqouyAHWiys5CIePwKwvRz/iyxhHNPn54ogqEfXWKQt wKMJypoC6ttcWNTDQ9csct1DhbXkCOp7XNj1Chd2PXFhSAUXxvrVkQgrxpySvFBKOOc4YKCexdf2 BHItmYoRxpyS3PGy7BftVwq+zPDA7pK8fE1sYiXJ0CqB3QXtGZWthGbAHjUyR3OEVo2LxoG/C4I/ u1zyYI2fC+xefgtVQqbTSr0pswKwD1SVtINvFh2yaCQ83G4/LnDvEWPXTowNSqZXIzFyZ3hs7mbo RZlZprOYyAISOqXST9sl4E5JzqGJvWwYqtMF3C7JMk06ny7aKjH2YjZMsGU6tYOsF1uKJDyLix0C WRe0B3TJs9XWVL1vC7LRH+702WrS9E+gAeLoGe85EKxSs44IAvE2Gxb1EOtgqe3rHk2ZkEC9x4Zd r7Bh17LKALUTPUB9JHnCDHUWY69m+u0nkkCdksS5k5eiCWqdQO2SzOdkoej8a5l9MWwXhMPiXlw5 QDrpAL8LQmRwkl1es84AwB9N44gvAfmtl6PhAn80TeYGIqXqFrKgCvzRtF0iJXVKU3GZpYB/mzGL eu7QcEvU1TpWM4XAv8ecXa8wZ3ooBPzOAUHcc7G5fwdI+o/RpyQuC+koWgcVXzQhJfHxuT9fRi+D hya4JGQoyXxK0dPmvdTu/pHmqhFeiirwuyAZydlbdQfr0h7wR3uoHntlffQK1KPcLpoAZmtSKgJ1 F7QDD7yCiqOTbwD1beosG3yCnp04sykWQdDe486uV7gzPXUFbaeDzHmbcgeCcJZyosV8VwiLYYJw SjLeQ8osmRVA2CVxyeGz9YIaFu7FuFf23FCnVKM9ArELchJFoF7lpeoGbFEaII4GuU1ygAm6tL0C axckjBSGHLRTTWWGBGsX5LoHiXKghVNQLASstzm07Jml7sFLqQjI9q0j5sc9Dm0RkH1Yd2S2DMhT kEzX7bhcks7uqxk9K0lSNMBZtW4tFT2vYvwP3gAZi19kMV4YgaW3ojIvs5hVklyH3WGKaMyrFDTf 3BiJ1l3xrV6nIIkPSU/LHN30dezZmxSE4mAq5w7rWP42y4knZUd+V3eHRfCdCW5xKTHS3ORmAe+O S2uoBOA9Au24QqAptwnATuFg1OxkTpfNFoBTkjhP4rbb0KoqgHVKcnoD/T+OGFgHa0QArm1g28jP qLsgkbxc7OreZxFBUHdBDq9JrlfLrfYM1KNpu/ZD02KtgB0tGqFjGXjzI6cpPFskNxfXqep+2jSF I7iJenToCYuG7RbKbgTtPQbtuMKg6QYKtJ0VMn+Ni5+XMQTtlORWdh8TPi/YIcmhBpxjLWbqZ4G7 V4mNW/CxWCQ27sXEG1HPZbUAbRfkVIKrxursg3E0Y8/1sC5cWoYBOxqk5/am+qUpABOPBo+kVyM2 pgnOYG9zaVHPCT21R4XbSe8lL+24x6UtAjqHi70BunNGgG4HVO0UZ+XIuiQJxOxiudWQMPGsE7qc XDRpJ1OdoB6Mli2UnIqMkwGoezFrOIxQ9/qafAWouyAnIgRqXVYz8I8GORSF8plZlyhnwrbMdRej 0IDdKyICiXszJBXPiWqGfZtryw494TzXPICavsTG9zi24wrHpiQacDtZtNj4lNcIw85iJi0igvKj +OcIDRinpF3N6B9gkwEAY5fEkOwYZsbYi5nHmZsrAku1CoxT0HL2dWuydA2MXZD4AC4QdQkH5gk9 arQ3CewiaCrqPKG7IDf+bGE4NSupCXlxZFjGB/ZD6nmfPWMZJw1RR1GVoIC+R7EdVyi240SxIRW5 GkBgOIQeUQX/lGQyGA66ytFIly0lIQv7q9pdiM0iCf5BMNkZJCNcOjU2jrW7IHtySKn+PG4URBNc 0J65tEdUEzZdsdGEaBoOzdRUNIVJPlq04zqCqi51DWsPwSUbSK/tY9dQgG2yLeq55SUwbkXUafHF SX6PdDuukG56rQmrdyIJqyfjCff26zf2HwVIyYVCFf3G6rOY/U85QABQGpyop6Qd+NaqOOXyAHaX ZKfOffnL/hmwu6Dl4WFFLv9EegnsLkiEvz3w3sxa94jg74K8/sahtA4bqHvx8Rb/1+7JpaJJg6C+ zb9lf7gixP6ygkDKqMTs9/i3o/Nvg65pyAioO38E6mR/qjtoE1ignpI8uEDWrFIPsRgUICWJUbZn HOo3ahJm75Ksj3bcKqsCqHvxsrRPGQnA2ost+xYvUHUaOzYD1tGMncxwD0OgAeJoh3yLfFodo8iX AXa0iC6gNN3JzdgiYG+zbdkhFvQDL+GsDJCAvce2HVfYNr3GC9hOGwE2Xe9cJZ30ADslryEqew5N 1kfATklOg87lkZJteBwTwHZJwD7i8jVD0WkB2F0QwgNnp2PtpW0UwAXhWnAiVyM4l4kGBXBBzkRx woojV41DE1yQPEzsxHH+EhlxJtEEF+S9AlgCTh5SUHQYTdhm4KIeTo640oLVl26KBuwxcMcVBk6T hqEBTiahARwYKRsP7FlsEeddDLcqCLCnpE3IFaw77YiB3SWN8zx0N+C0SmB3QSJBrkmPU/oxw+6C nJTf2EWDHHq9ywrs0bQ9rX0ir+mokaDt5TAzeHY0mnO3LFSgHV3DmyAfU5Obw10Q3Nysez0cn5If mB61rreejajf7HFwi4Ds33RD+xQyKDk43PDOfVbTe1aSbKGneL7nVcwTJDzJlOMFz94+IJb2aJLz NKIqNNjrZVaE9XD5UxMIvcpiNmBE13TTjwDzOgUJXkMLyQEyduNNlrN44wyQ4iEHXATfpiAJ1uxg u+IrJnu2Ed+IYovvxnvncPnYhRgJsHvc280K96bBHADr5A/mzJULsRPAzFKOEm57l16+HlxTEmYY RyVHiX+OA/oiJVm37OXMMlJBBoS9SjgWol8r5ExVDqxd0AnzLqhcagRrFwRr20zo54J1lC+HqwRl pXZKRWDtgsuFHvI6to+ouXdR4ncmuIl1NMi1btZwpqw2WAL2HvV2s0K9aYAQYDuJxJkPvpo6MaDd isll3gXt6o4HtFMSTpRX4gvt+oC0Ypdk7ibgad6WR0WWytLYjfb5y1+DrP81syvvxGg3wNOL7Vk9 /MmaTGQuAdjoBQ4BX6bPI4Knl7PzPljcXvnOY4fAc5tdi3rIlsft0lOFNNUcILjusWs3JqCzswwy uDpLhBGTE+Uk2gquWXwA9O6avA4ouKYkGa4hvLdwdUncWPbaOv1iu14M28TsrG4kuHoxeyzunBYj okEVIOyCRA5jjHWLfo52yAaZVrjPoHGbIOwVHTnlhimsI93ZYreJtKiHGGNcUFQ/p4iaOgXhPULt ZoVQU0MAYaeGQJhk7pUBbGWT1SRxP7u8AyuhLU3ScvP3a7qMCVO2t25LscUnjEYB2EFwQb2Zs19a MwoCexBcZq8EIebYqR4CezTITMUY1/wqqo1hh6C9L9QnuJY+gr8LwrhyT459fXZSbAkL3+bWoh5e /IMchInPb6ieCf573NrNCrd2M3FrSEX4GjFntzWdLPMkFp7F8tKfrr5YeEoCeuekMBwjWIDukkZa cYe/fGQRBH4XZETsKa+Lm2jgd0EmYQs1K4tZPgLQvZgoX+C5nO4F0F0Q4gW97XmE8RMAPXrG6sO2 ok4IpGlAHziOwnLp2fus50iKIBJcN7eg01sBfY9Pu1nh0zRBIEbvxBBGcA1xLIsaoGcx55J9Wknl RgE9Jc8c8euJHEh7sVFjsM5iEeDrxRZBynWli6MIvi5ou26ik2WQwdeLOT2xS/q1xkqD4BsNclfn zCV9gQNYvZx8iNw2sWw48ZMWgXWbMIt6zmR5s/uiK669wLpHmN04YTbMIDfSK2B1Coi5/JYs81IM rFkMnYZZ5sdN+2JgTUnMk2trOaVNUz0IuyQIk1KqO/xZ9BuEvfhA6mg7ZmpNSt9A2AXN0+aluZoT ilhOW3ZBLhOAXx1Nq2qCdTTNaffwopE0DeguuLy9bQHs7WtHowf0beIs6rmztB5YTVutamsvoO8R ZzcrxJn61oDubA+gcxO9tv9rC3hK8r4rRHX7zvnUu9WJ6pInt8GmOyTw9zqXIKb51DtKLcaBRPoy 8oDuf4yVMGJdh2QVwsBdkPhPoif1jitQezHRQzwUyDQ6AgfCXk4eFS6uEoCSXy7zAwhvE2JRD/wU 2zy7TNcaEmT3CLGbFULspvRkUXWQdUbGXBU2Q/JVmHMWE/Z1rnuH060tzDklSfdpXnX7yQAAZ0re 4a50M4SSKFi2S3IDh/uHyt0DrRcT08+lSPky8PRSe9CHSbYsToAHWRckNz2R5kxFbcCXIQLZ6IXd +uZAsn2YuBIgu01+RT0ELzBAXMppFbUGR4Rv98ivRUC2Vzey0D7lIZB0vojOV9/8WRVz15WYy9Yp neyelySeF+GiFyVflCTOKg5wScqQvUxJ9j2shF2iKRF8lYIkvuFQpUskFTN2fKQFExEDXEMrCv0m 64EQs6PFeghJ5o23KQghxp1BwuzzI0Sd35ngFkmSPTuxW8QfaA5I9UxQ32PGbleYMX2iFtSdmzHv C9+g1jr1lFGAlFxOMztY5UtRgJTkvMly2NSvafACBwoQzJDlPiQa4JIg+Lsgkze3o5XyAXUv5twK TpyRzp+g9ToFLaUKrkZpnHwD+EfPCEYk7kHUDNS9+IZTSCKZK9dIobV8IahvU2NRz51FbBCX3py8 mqUE9T2K7HaFItOQbVB3Joh1mqWjUrOurNNNEnPiQe1CSIYE1LPOG5ymuouzwnmHJKYFjXo5UgDU vUqCGHgduruBIGiBvwti9dzaaiY4nY+DvwtCfXIwWXcs59Ps7CP+ADfKusOTUYXRBK+RJwhI3onb k6o3a8I2qRb1cK8EP8fuV8avVFg0YY9Uu10h1TrqddFPNMEZI3PTCdu4jC/2n5JsDdn+Zv8mnUET UpKb0T333e0k0/5dEo/dXtLasn8XRBPMOSvPUkYZTUhBeKt+8RGVQRNckLBy+/Daz8u6yEwQfVzy bPVZeydNcEF7jAJ9qWlPmmZO2CbfokFe9IbGhKNOm6vth2jCHvl2u0K+6Q1+NMG5I/PdGTgZBuDP YnTT4uLbTyAA/pQkDxb00ThMzPlebNbPHq4qknqwfheEXbUONcNSvx/MXdBeCLzF/Ws9K5d4UTcw d0HL18G0V3tzEQTz6CN7bx5H3bj8HYLXZEVEg9vlhPnAE8HN1d8btESqRAF3mUoF6j2e7XaFZ7ud eDakgmdjxanEzCjaCBaopyTHuehiquIkCeopySW8A4t5/cY6UQCXRL1Ji9gdjs4K4IIcdNurcW1t 1GkEBXBBsodakvOGv2oKChBNcwzKlZ+aR6RpFMAFeXqEFery+s7074I3duGTRNBtHpmNfpt8az3j vjl0X7cBEw3YI91uV0g3fQsTY3dyCWOHye4TH80akJJ2G6RbB+eNeqvz9mSzVsEwTwFZJ4vw1r0k 5gCXhHVl2q+LXisq4IJkTSQko2bKNHwvxUpJyNQ5CCII7i7I2SlGz1Zj1F3g9nIile84RtdNFFP7 NhcXf35LzOotS16bqmqEBO09Lu7WubhBt5TbAG1nlfgojkRlssPGs5S7X/BYZbiiw9h4SpLaqp8L dN7Axl2Shd2u24t5AasXc+i9hE21JqVFLNsFeRr0mquANasIcFi2C0LFEWnePaEmTYOwC7KxW+pr NLcIArULQtQQI91nxhh1Asy3qbjsme05z2QqSru4iPkeFXe7QsXdCqpg7jwTFs5Gl+Pr+o39B/+U 5PiDWz3ZvzXHLiXxD3B2q0qBA/xd0rK5oHNiRuDvxXaYQkb1mrEFBPB3QRQFipyDkPyJooB/NMhR rT3/Ii0Ce5TDlnE6XFHn0iKwR4uWn5OdTBuN8sOXOQXYt/m5qAcvDsiviZuJXzUopr7H092u8HTK ZgG7k1DAzjaiN+Z5Yk9J6ENuHNavFHP5Usw+JSEIyKFakrVLXSSB3SXt2jbZVNseRhdiFMAFOUQh wIsLKfmr0VlqRAFcEC6MVNwF23yGHoLQMOaHNStTQTQh+sjzY7iLnfcz2gWaEH0kwZSd5DRPVUwN Tdjm87JnliCo30KX0YyacNrj8xYB4fP04OwpVp9O3jVWXVOnTtbPStJi9rozB5V8XpKEWAyRxGKP L1IS7eeYrI+dGUf5ZQraqQxnvs1MVGVepSDx43a403ZFauqvU5BIUQh6S6WUv7HpN03QLhDcdSna RQnfpiDRrhxW9GlVxhrfmeCWlx+QsPyTlJDUR9mxmq1EE/Y4vtMKx6epidEEJ6tY/okuEesG/VZq dFi3rFevYh5oktCh/bjOIcwhCfog1VmtjCzoe+PkUcW9vDy/g34QbvZUJlv7nC9UTUDfBUkFxIE2 eW9HiAA9WoQrRJHq7STpGqBHi5zkWs7hNkdN5o/gJujRIYthtwDo6pGAvUftnVaoPQ2SAGzno2zd JzCmGlswBO0shnhjS5cayD/HgcLWU5LEs9f9rC8ahK27JOdubNS3YihCEFtnSjjV/BdzfRTbDTL8 9JrCBRowjgaZUfHMiLOInwgCtguS94dDxikwD4y9HB/vzMyjQQHY8zZnl/0gLQRHff1hoEC7x9Wd Vrg6vQAPtE4wmR2TtCk/mn/Kd4NySgLxkBJZ9AGUU5LXBnsnV/UBlF0Sl84SHkqTWLIXgy3vJnTr r/hNWLILkmrJIC7HQwRBORoEZTS540QWdQHcaJFdHRHLFc4oaxEouyAJrNltEm6QIyctAvc2MZcd slQGxGy0+PYaC4F9j5g7rRBzmpIB2J0bwqJhVjZOyYA9JS2Yqe5aTKESwJ6SXKJiOC5OA8Duknbj lBOKi+szCuCCFvEMs16uukwsKIALQtbjFnfvTQtuKIALEmZKBsYuHFBwQxOiacwQalINBwWIcs54 n9yQU2Wc6sB9m5yLPyc7GLrNKU2OVk2EgvseS3daYelOE0uHVLB0KO22uafkNZxCF7mlVgruKQlE zAzjQAC2FxvzTH6vsRSEvRQTN5L14hoMwi5oh7DcS8rhmtQQhKM9S+BGrGT7SGkahEMQut6O6QVB EPZyf3fyWO9Oyg4FqAeqRNp5n/XAw0IPczSVU0XVI1Dv0XGnFTpOY5cxcaeVMHG7VNCGYW1mT0nY WHs2uH4jWkCdkoSU4zOV4Ix6StqunijZ9hNJNMAlLdUTLzEKCuDuxZBwUCbdnrJGb5m6wd0FcdE5 6+reJxI8wN0F7RieK0zd+dT4tShA9IztAZ5apRWWGlGAbYYu6jlZwl648TYYNRSiAHsM3ckZumGG 0ahBFMDJJhQAirW5mqtLe0pa4FwdE64EzrU6ub6wHQQbkpj9kRAAGTJQD8qMWYHpRWZfUPdiTAYv seeSR4xA3QVxttg+1p1BZZJB3QWXHRxaLuoD2F5OjNUNR++lFQXSomeAvU3NRT325PSBp6ia3teS JWDvUXOnFWpOs70DtlNMgA1VoUF0rOJZzFUl/k/1qrq1fB4mnpLMGl2cEH8xDj0Tu0suoXHkYKk6 R0GwdkHmeG769XP3KAjqLrg87skOr9UokwKoR9PkdCHSoMCSPoJ6NG2Jfznya56h6CPwu+ARG+X9 hy5oZewj8G9TdFHP2S5IEorX6KpqUODfo+hOKxSdJhsFfueVcOOJs+pj5ardBV80ISV5T+rUr+ti g2hCSt7Z6wHdBFI+ylInmuCSRktC9Wz5cy7IPtnecmpHFfPRS9RI2Dg7xf763AgHmhBNWxQXMYRl b6MgmuCCll7djqdWgFk+Bk1wQULW8R5ORXKJEqIJ2xRd1IMm4A93SZoLkVET7vYoukVAKDo9Cn/K h6WHRzxyb2xiG89KkojRPsZf0XhekjDrnE6mAzO5Ei9KEtsl31pJina9TElOc7gf3IV+1PAseLxK QTZa4NsdAsvE/DoF4WDN7MqVFHLlTQoy1XNDHIyzl9L02xS84bSY6Ln6bqnxnQlu0TWByZnLWHgR BUp9gqjCHkd3t8LRKfeBKjhLZA4A99ur++rCowopaSHW3Z3fFVVISaKD+5yw8/IQdeIA8FaLxn6C v1cEpXZk5a65XtQU/F0Q/xAl7e/HjhYO/i54ZZw4PoXMUsAe5ezYiDfVOE7QjoYswQSxIY1JlR6B 9jY5F/VwSsMK0D1TU9yUoL1H0t05STfsMnS7AtrOO0FLcRzNcVX7lZbFEtAkeakZGFP9VwKrS5Kp tcvNodf9Mfygz8ipgd8wQgPYwZnBcdhlhdaiWBxguyAGh6Fcnj4A2wXtwIX7a237rE2DenQM27PT 3svzfghyz9FyE3cJScePAf5tAi/qIc8A7/fwnFr7c0F9j7+7W+HvNG0tqDsPZQs/73KLzmPYWWw5 19vOk/GX+Zg5PiWh14l4b9rTccux2ockh91sFi5bLqh7lYBJitc669LpB9RdEFYc1q0SBWjToO6C hFKAI0tRG9ula4Dt5XCzhzPPh9bBwyiIrUfX2CzWLSiGRRQSsLfpu6jH4uoJE65vrBVCUN+j7+5W 6Du9NwrqTj4xs/MokPQZ0LMUhSj+Y/46QE9JeyWrS/uh44B9u6RFVY5vI40jC+guSIwzl+tqEVaF A3QXtDdJyaPcpgQVBPRo2iYFPJpaKsamQd8FD+gRkZ/luZUJLmoC+tG03aLm2labj8QoQH/YYstA v8967L4MQQf9w76C+h55d7dC3t1N5B1SmSbuBpazTFRWKDQgJe3lpC4puuKKBqTkiY1jd1NFbQ8N cEm2e0wOc/hNFLPRInNe58/JmIK718MeANZTV2HQjmZI00JKyflJrGwHBSNVccWZSzuA7BURVkV/ 2COO2gK2w3o6Y+t/TlL25TyhRrvVIxjvsXZ3K6yd8qFYtnNOyz6+G8VpZgLjlOS1KEyydWvRcYDN Ykt208WlrjhqLsk4EW1YE9dSD/bspdfQ4LhxNQyic+DqgtyIslhDWYnANVrhMiwrqKoXxuvlsHKc sNq7lPETYMA1OmQPPpAqIuXm8FgEN51yr4drErdscGsdK0URgPdYubsVVq5LQrOMJwA7z2QHbuSY rMlMcQHgJglp3C3I6uOAdUqSyJ+HUGpiqG9ZWseIXdJYuTF7+6g+wO6Cdr7MAWxNz2JmwO6CRLTh hnUEnOgHChBNcxkJ4LpkW0vXUIBokcsKgMF18YsK4IJQNQeW+O4u0PgNWPg2U5cdYvYmDJW0i+3v Bfg9hu5uhaFTQwJ4Z5iw7OWx+/y8NctOSdgyPuKiJMCnJFzOwLLLdADwLgnwTHydUyDmBfAuiL1z U6D8alVPgHdBLrNY/v5mr7rEAHw0bZZvr4O0YU7go9wIFzzPxgpJ17D86NqyOyCBSNPzsUaA3+bo oh42aDxw8/+4FnO3x9EtAsLMaMYzFMCJJRSAYe35NPlQLD8lWUu71xjXvPaUvOOAqssMoPMrCuCS KAD61CWOkcZRABdkv82V5kJDcUUBXNDusMD6Ff8rUwQK4IIHLqRBP1diUGmaKSAEiZO0yJ0NTXBB En/CYnZhw6L2aMI2RxcN4iNx/ohXUxuKcQo473Fzi4BqQE0oMfcjFaevTFv9Wio28YxLuunqYf61 rZgmi+clacRNf0NYWn+RkkZLIHdxJX+ZguSOIo6yW3nEj36Vgnbz0R4+HM3wdRZbthFGuBqsUY4Z IL7WHqI8Gy18wbDfZo14+OQfYMq7IPjOBLfW/miQGQDSAyIr66kvFPz3CLnzCiGnvu1T1ubEn6si eoYD6FlM3ifCqMbhBOksxtgISM8+T0fgIO2S5tHh20wuXRQbuc4Z1cXlBXy9Hs4/caG7PZq4FSAd DRIpiyJc3He/ScFryAPOd7qPGD8WpL1GqFcerIBozF7Kx4D0NhmXPbviIywvV+meILxHwp2dhBs2 hBoJCMLONuHdQX73aXEFTcBOSRY99t7j9wN20Fb2DBvrcH6+zsJgnYIWWj6nE4tigiG4AN6F75Sm LzYI1l6PZXliKizmRKZUsI4GQYbL8J3k+Alg7YIHorLwIOvYQNYHsHZBnsU8sm2v53hmrLeZt6jn bHd72arUKWfrmWC+R8GdVyg4fZIAzJ1LWig44pkaVIoVmKfk0RbBIphnj75JEqDAQ8RVpygK+Hud 2Dqevx4MMpd7MbciOD65PGeAvwvauxz2rm4bskU9QN2LuYcK66HFYB3NWFAkC1bbL8iaANYueMPM i2szI7xNt8Vf33Erz/yiRl3XhCQI79Ft5xW6TZMcgrDzRXhupFNVsIA1iw94nuwk20++HqtOSTau w1mGmCOwpiRnWZbvtf1kyEDYJZlRsZwuhFMaB2EXtCutkMV1HFSDl1hHjegUFHYXyTcqBaiHoL3k wOTaVF+aBnUX5J1yHriDnMuvkamA2XyYX6We91kPpAwGflfRFRdn9T3i7bxCvJ0n4g2pIN7sPePu J/1HFVKSKf1MLv/2k0FGFVISyO5qzpt8fFTBJfHcOcFQogf8vRgLP29tFsHfBY2Z5RqidB0Lj2YI iyIWX6/0AXaUM0vzFIOGG4Gxl5MJ1F7grfx+0hAYbxNvUQ9ZfJcIxeY21kIkNr5HvJ1XiDcNSMLG nQ5iFme1Ks3Cyxq1HoxTEnK1n1J1YgDjlIRchadvyqDZhsDYJbE4juT6c9WxcdB2QVhJTveXkNzw A0dB0HZBNtWwW13qUoED3KNpcCfYokJixfhQABdkPef2JelS83NEEE2Iprm/bCkXN3y3bYYu6jkT k0NKYRzG+JUtiSbsMXTnFYZOnxJHE5xfIhnXXU1pNH188TsZPHTBZU1ruP7flr21fVpKkhtleA5X hg9dcEmI9hu8oY7NGyFGF1wQd4esQ/15wCiILrig3XjkcnTVKKsOuuCClh4QDq72YeJ1oAvRR/wB 4m7qu+Vj0IVomj0ifSyXR5pmVtgm66KeEynQcHPZ18evlkPRhT3S7rxC2ikpiS445WSkHYSTDAPw ZzEb6u56/bKOYv5ZamkB+ilFPh7IXRKniJi7y0gCuQti/hzo1mUvnaSA3AVZmdlmVQoB5YWAPJpm 6rEXtGuWXT4CpKOcq8Yko9IwYwD2clvaOfovYGTaBOBtUi7qsRcU7YWwclWbMgvAe6Tc2QSEktEX zADYmSRz7ew6eE4xkwGDdUpyRM3WriRLBRP3lGQdJA4pVXXlWY5WJ1d9CF+rOkXTAN7rZJK28L6S FIMDeBfEy3vChdlqvFyk9PJckPuHuNIVBKV5qdCAaJpsRFzEKmREi1EFFyRyjpBdwoPzc2SAUIVt Vi7qIV6aMJYuRdOFeR8vC6Q/f/gVtK++vWKP+BOPBFzZIrR86p9cQFVBhvipSeXdCGI3CzU1rmcl ySRJ1EWJypA8T0kMm2T3mmPsRRbju5kD3SY19SRepiB2D6VTvpVuMV+lIAwq/kb3EdKz1ylo3hxm n1BN7uebFCRFIRe14W/za6XGtynoT/OZ7sVP4TfBDXIu6zlxLHNmn9I+ogAbZgIuru3Bv0LOdUTQ oiTA74wTMwHEop5vg3kWcxzWP4yjEIB5kGFU9IQZs81fSztgnsVEV28t7yloSYEJJBfXA6S9HmIY 4H27G9Zq6Clor9ywgdKrvADsFRn7Ch94Me4NgKNFlgr8iNpqStfemeAmwF4Pfh1XizjDayMkuO5Q cocnK5ScLnDg6uwSuFqujOZEzjN8SUI5GglWv9bDBUMgzjp5srYmRJMfJUHbJe3Wsj1KPRZj10F9 cbOWSbg6J0MK2i5ImilecCo3Shc07DoahObna1fQ9vID7C+Wpjk+ANnLIV5J90/oZhuEseuAvEnG ZT3kdYP+J7dpfZGgvEPC0YmVdVwmH1B2XgmUuTJrV8nyJwskhpySsN/X3RGCYgfKKcnm40xQYPvV TJQ2nZJcHuhvkmumCAB3SQtXx0xYCfM3Di+AuyAwXDNLSIvA7MVm1Dwbo44rRh3tMCD2/HIp89gO eLvgDYE78EIVJVx4Ld8I3pvUXNZzhodi/1+36asewX2HmiM8YgV3sS9wd2aJz+QUsi0VNqjjh4J7 SpKOoj4TTEVDwD0liVrs6TwNMcG6XdJuqXPZsD51GTLA9mKOyG3mLU5dpmjAdkE2zMv7uJcUDdij Qa5BEsuqqxSwe7lllYDHOJR+jaMB7NE1wu+Ww6ZsUr4B2DcZuazHQuB4FRqNbg0J3DtMHC9aTXBj xa22ZUSB20km4GZm6umPGe6UhKUhnCjNbDotA+6U5G1LO+hqPzE64HZJnHAuDnS3G+qjE3gXXHJR ccGt1SjTFsC7IM8oMkV2CU6lRoCPprlERVS5htMDvJdzxo5u29ul8ZOKAN4FiZ6xAz3RRODeJOfy r8/s9rgLUgfT5eUI7DvkHK+drsAunQZ2Z5TMyrkC0pv5qCBYeUraA4JSD1BnKWnJ7A3b+o31AHVK Ekc8SIpSYOQuuezMYGAvVQnWLshswNPN/enP2DZYR4129dwOesdysI5yQu3wsjUrPRBHQ7gAdnhY e8CxIsDe5N+yHoKbyea0PDXoH1dDIGDv8G+8kbECtsw4gO2UEWDDuehFTRDOYgYRRy0VnaCW8fNA OyWhIAkoK2RE60HbJaHYmTL7wIyxSsB2QYtkgR2czdmLeZOM+8JdMIYIArELQqqw6tYtQT2/Bevo 2REPkeMd0QWw9nIed4BV5Pxp7DAQb9Jq+edGq5E1oV68rhESiHdoNaJ7ViAWZIDYSSNoU2bnUzc5 y/eBdkra3a/eBxO1Ae2U5H4VR/2FdqnrMjuDtkvik9tJiBSDsRdb+AtTTU0SMrYYtAtaeIRdkGwt 1uAtDYJ2NIgrTAbh6fQ0y7m2QGpD3gRrNY1ognZ0DbjwSUv3ZTCAfZNsy3pgWCy3QxGO9YkC+w7Z xhyzAnvxNbl6O0GEZXNVojisyQUD9ibJ8zJdiKe6dcCekuQxIVyppgMZE2BPSQIh4JVKUvqJBrik ZYZnoShgRTvRABfkiif1dVegaxxTA1yQ1wohWy67/dh7NG2qwq39RqLI16AKLshBOtNH51xK06jC JtmW9ZANl49A2WvNHFXgao9kWwRGkg13YdTgp1hwkmxoOmFa7VftLkP2rCQ5j+tT+s7+equTnce1 Zip9kRVZkiHMr7Zx0uLLFOSAFHaj48RE8FUKEitDdR3sk+FHzxbYTzC8Fwz7TdZouYFhRPRawNss 5zIx+eyOdYtNVPedCW5RL61DFpTD7F/aImjvcWpXM6eGvzCh7UwP8zw3qfvMYNVuop2SAEjASxuo 2eBp2WlaAqzu+nuOomsAn5LEy/Xhwsr9gbxLcpJ2xynH+BXA7aXkbCTQuQt0lY94nYKW6dcypcmy B8pe0RW5+ozGuaQOwB0t2qXnE+xfWoloInBvM21RD3cRCQ5ilsh6CiiBfY9yM3ZdDlXQonHAMHLn kMyDI3NK6/3KPN8kycQyXPiUsXtedaIbdnGi/WbYgwGDryZCqHbdMnuDugtaMAln6TK2wO7F3Gxg VemOhkQ/gD0atNhq0nXLcAB7lNtRiz10lF2XFoE9OsTAEZWqd59Ae5tyiz/nhUUOG0+VvKNGSNDe o96uZuoN12FC2xkkc+ZQsW61lAFnSk/Ja+jB7mxKSVvQTkkiAvscvXoygpG7pI29MbE5trpKgLYL ct2HlIJbbl0Iwryx0WZ9bL/xw8Hda+QIhbW6Dka0jyhANE3khB3KiG6Du5dzhsorAbfntnkXTUMB tjm47BDmzgsyRSdfNPc9Du5q5uAYkHEcMHfnkszcmdNEP0A9i+06S68eIgnqKUkAThfVj8GPTYK6 S9plRBIqiyGBtRdbCjAePmoA6mKCjbsg8YT4KnpWA8LRDG/PL3ccxm4AbLSDy8ArAXq1BWC9nGRA OFYcAIx/D57b5Fo2b9cTQJS9ov/qe8Wg90i2qxWS7Woi2ZBqB6Fs/JtJqU0BbUoSewy0JSlfCrQp yZUSXnAqSEQJgNYlOWQidfix5q7FUQBaL16g5d7jOKIA6sWs1Vx33zReF8QkeaKmTcnTEgXG0SBs yxGHVb4MjKNFpgES4FXEkAgC9ja1FvWcOe+zbOJt2Ev3BWxhW+K0+z35nYDvxz9+/69//qf3V7ff 8h9u/vkPj380SEleZUnqOY2J29E1+l75468/3d8/PP/w8OGPf/jl/svf7p/d//zz10c/fPr7r5yp 2/LU/uujL/c/fvfNnw7fvj1+83j+71ffvr2y//64/cHXP/7h84e/3f/5w5e/ffz166Of73+kSl7N YFi+fPybndn7/3n49Jnj+28e/cenh4dPvyz/+tP9h7/efzEBhH/89Okh/w8NWJ3f3z/8/fOjzx8+ 33/5/uM/7r/7hj3Ppy8f7399+PDw8dOv333z+dOXhy8fPj4QG8B//8cnCn5+/vkj25UDdxE5QCV2 /NF/3X95+PjDXEAj9789vP/6sPzz0d+/8Hf/Y2TtAa/hd3+6ffrkdzf2P2xAn/zORvjp6RmBAU+e /O83j3775edfv377y2/fffPTw8Pnbx8//vrDT/e/fPj6+18+/vDl09dPPz78/odPvzz+9OOPH3+4 f/zLhx8e3//2w/3Pj4H/jv/78Vcb8t++/cv7f3v0509/5cvw7//l1/u/8NHLv//793R4+Vcba7rp /7t09vF/f/rynwugf/w/AQAAAP//AwBQSwMEFAAGAAgAAAAhAHWvyOk6AQAAQAIAABEACAFkb2NQ cm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIyRXU/DIBSG 7038Dw33LbRbjSEtS9TsyhkTZ/y4I3C2EQslgOv272VdV2f0wkvyvjw851DNdrpJtuC8ak2N8oyg BIxopTLrGj0v5+k1SnzgRvKmNVCjPXg0Y5cXlbBUtA4eXWvBBQU+iSTjqbA12oRgKcZebEBzn8WG ieGqdZqHeHRrbLn44GvABSFXWEPgkgeOD8DUjkQ0IKUYkfbTNT1ACgwNaDDB4zzL8Xc3gNP+zwt9 ctbUKuxtnGnQPWdLcQzH9s6rsdh1XdZNeo3on+PXxf1TP2qqzGFXAhA77KfhPiziKlcK5M2evbV8 mzwoV+HfWSVFb0eFAx5AJvE9erQ7JS+T27vlHLGC5GVKipTkSzKl5ZSS8r3Cp9Zwn41APQj8k3hN J4SWxRnxBGC9988/Z18AAAD//wMAUEsDBBQABgAIAAAAIQCdjBLDKgEAAFwEAAAQAAAAeGwvY2Fs Y0NoYWluLnhtbGTU32qDMBiH4fPB7iHkfI066P6gFozGKDtcLyBoVgWNYmRsdz83Whm/70TwqW/6 GcX49DUO7NMuvp9cwsNDwJl1zdT27pLw87t6eObMr8a1ZpicTfi39fyU3t/FjRka2ZnesW0F5xPe rev8KoRvOjsaf5hm67ZfPqZlNOt2ulyEnxdrWt9Zu46DiILgKMZtAZ7GDVsSXoePnPXbEJwNv0dx 9Wr3m2giJRFFpCCSE5FE6jC6TnX794qIJlISUUQKIjkRSaQ+wjj1E0K4PcS/fdwnxqbCpiKNxkZj o0lTYlNiU5JGYaOwUaQpsCmwKUiTY5Njk5NGYiOxkaSpX3DzETRCiaAQCoQcQSJk5E3OyLuUkekz sgzecYZ78haF/64R+3ch/QEAAP//AwBQSwMEFAAGAAgAAAAhAOnR+K2TAQAAFgMAABAACAFkb2NQ cm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnJJNb9swDIbv A/YfBN0TOV1bDIGsYmg3dECLBUjanTWZjoUqkiGyRtJfP9pGFqfbaTd+vCAfvaK+2e+C6CCjT7GU i3khBUSXKh+3pXzafJt9lgLJxsqGFKGUB0B5Yz5+0KucWsjkAQWPiFjKhqhdKoWugZ3FObcjd+qU d5Y4zVuV6to7uEvudQeR1EVRXCvYE8QKqln7Z6AcJy47+t+hVXI9Hz5vDi0DG/2lbYN3lviV5tG7 nDDVJB6t85ESNuLr3kHQairTzLkG95o9HUyh1TTVa2cD3PIKU9uAoNWpoO/B9vatrM9odEfLDhyl LNC/sYEXUvyyCD1YKTubvY3EgL1sTIY4tEjZ/Ez5BRsAQq1YMBaHcKqdxv7SLAYBB+fCfsAIwo1z xI2nAPijXtlM/yBeTIkHhpF3xPkeCYLwV/y8uA0wcymzHe9oBwN477tNDz6+4FO7SXeW4OjkeVGv G5uhYvOP/VNB37OJOfRDbhsbt1AdNX83+gt4Hs/cLC7nxaeCv3RS0+p00OY3AAAA//8DAFBLAQIt ABQABgAIAAAAIQBIZhxhaAEAABAFAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10u eG1sUEsBAi0AFAAGAAgAAAAhAFB8TsH2AAAATAIAAAsAAAAAAAAAAAAAAAAAoQMAAF9yZWxzLy5y ZWxzUEsBAi0AFAAGAAgAAAAhAJbV+XMCAQAAPwMAABoAAAAAAAAAAAAAAAAAyAYAAHhsL19yZWxz L3dvcmtib29rLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhACSn37DfAQAABAMAAA8AAAAAAAAAAAAA AAAACgkAAHhsL3dvcmtib29rLnhtbFBLAQItABQABgAIAAAAIQCxaD8GMxcAAIIwAAAUAAAAAAAA AAAAAAAAABYLAAB4bC9zaGFyZWRTdHJpbmdzLnhtbFBLAQItABQABgAIAAAAIQAwD4hrEQcAAN4d AAATAAAAAAAAAAAAAAAAAHsiAAB4bC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAMSn 4laKAwAArxEAAA0AAAAAAAAAAAAAAAAAvSkAAHhsL3N0eWxlcy54bWxQSwECLQAUAAYACAAAACEA Tst78KBtAAADoAEAGAAAAAAAAAAAAAAAAAByLQAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1sUEsB Ai0AFAAGAAgAAAAhAHWvyOk6AQAAQAIAABEAAAAAAAAAAAAAAAAASJsAAGRvY1Byb3BzL2NvcmUu eG1sUEsBAi0AFAAGAAgAAAAhAJ2MEsMqAQAAXAQAABAAAAAAAAAAAAAAAAAAuZ0AAHhsL2NhbGND aGFpbi54bWxQSwECLQAUAAYACAAAACEA6dH4rZMBAAAWAwAAEAAAAAAAAAAAAAAAAAARnwAAZG9j UHJvcHMvYXBwLnhtbFBLBQYAAAAACwALAL4CAADaoQAAAAA= --Apple-Mail=_56DF6124-70BB-42C7-81C8-3AB5C8090F6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 1, 2015, at 11:45 AM, Yoav Nir wrote: >=20 >=20 >> On Jan 31, 2015, at 12:35 AM, Yoav Nir wrote: >>=20 >>=20 >>> On Jan 30, 2015, at 3:37 PM, Yaron Sheffer = wrote: >>>=20 >>> What I would suggest is: we give the client a single puzzle, and ask = it to return 16 different solutions. Indeed each puzzle then should be = 16X easier. The nice thing is, the server should only check *one* of = them, at random. The client would still need to solve all of them = because it doesn't want to risk the exchange being rejected because some = solutions are invalid (the game theory is probably more complex than = that, but I think what I'm saying is still close to the truth). >>>=20 >>> So: the client does the same amount of work, the server does the = same amount of work, but the client run-time is still much more = deterministic. >=20 > >=20 >> Note that these are still single core results, and most laptops can = do twice or four times as much. Now, I know that what I SHOULD be doing = is to randomly generate 100 =E2=80=9Ccookies=E2=80=9D and then calculate = the times for different bit lengths for each of them, and then calculate = mean and standard deviation. But just by looking, it looks like it=E2=80=99= s much closer to what we want. 16 bits would be a fine puzzle level for = my laptop. No idea about a phone, although I could try to compile this = and run it on an ARM-based appliance, which should match phones. >=20 > OK. Now I have done it right. See attached. The data suggests that 15 = or 16 bits is the level of puzzle that for this kind of hardware is = challenging but not too onerous. Add another bit if we assume (probably = correctly) that the vast majority of laptops have dual cores at least. >=20 > I would like to run a similar test on an ARM processor, though. The = capabilities of phones and tablets are all over the place, what with = different versions of ARM processors and devices having anything from = dual to octo-core, but it would be nice to get ballpark figures. >=20 > Yoav >=20 --Apple-Mail=_56DF6124-70BB-42C7-81C8-3AB5C8090F6F-- From nobody Sun Feb 1 09:36:47 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3E31A1A50 for ; Sun, 1 Feb 2015 09:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyfSbc5jJURy for ; Sun, 1 Feb 2015 09:36:44 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A5291A1A45 for ; Sun, 1 Feb 2015 09:36:44 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id fb4so11107483wid.2 for ; Sun, 01 Feb 2015 09:36:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2d86E9YBvEjV7XWsIefqt8AqENyZLOhKKi5IDxhU2LU=; b=eGlhmsphOgJ8fsFQx/ENd9agzrMcnAVFxVLPLNGkKxpJlImjwtUa1YK/jVV1DvtxzJ tL7siqUhHf8pKyPRc+E9Y4JfHcCWjX8nwF+F+cXr2AVFaYFTDL0/SQXW1LRGdeSh/499 CMubbG8LCb7SkYm73+icp1AMnD87WKt2Il8WMz0nmlWNMmX1X04JUDOtJ0YTTZpgLw+1 Zi+6wAsJRuVRqTJ6Iex7f3v8edCiQRvooijwXHTZCqkdhRydio0SES9dZr9Jdr64ncpu BKgGq+1E3H6ckcItm7YeA7UeBYM1kW/3I3tPqlKNfLrdlTCvaL3p/NbPxz9BMo+bbigj 89+g== X-Received: by 10.180.205.243 with SMTP id lj19mr16230756wic.26.1422812203205; Sun, 01 Feb 2015 09:36:43 -0800 (PST) Received: from [10.2.0.130] (93-173-247-187.bb.netvision.net.il. [93.173.247.187]) by mx.google.com with ESMTPSA id cb14sm16082845wib.22.2015.02.01.09.36.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Feb 2015 09:36:42 -0800 (PST) Message-ID: <54CE6429.2020800@gmail.com> Date: Sun, 01 Feb 2015 19:36:41 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Yoav Nir References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> In-Reply-To: <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPsecME WG , Valery Smyslov Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 17:36:46 -0000 Hi Yoav, This is good, but I'm not sure if it's good enough. The ratio between min and max (which I trust more than the "mean +/- 3s" rule, because this is not a normal distribution) is consistently around 4. So if you have to design your timeouts on a particular machine, you would still have a lot of uncertainty. For comparison, could you try again with 64 replacing the 16 tries, and with lower bit lengths? Thanks, Yaron On 02/01/2015 11:46 AM, Yoav Nir wrote: > And now its really attached. > > > > >> On Feb 1, 2015, at 11:45 AM, Yoav Nir wrote: >> >> >>> On Jan 31, 2015, at 12:35 AM, Yoav Nir wrote: >>> >>> >>>> On Jan 30, 2015, at 3:37 PM, Yaron Sheffer wrote: >>>> >>>> What I would suggest is: we give the client a single puzzle, and ask it to return 16 different solutions. Indeed each puzzle then should be 16X easier. The nice thing is, the server should only check *one* of them, at random. The client would still need to solve all of them because it doesn't want to risk the exchange being rejected because some solutions are invalid (the game theory is probably more complex than that, but I think what I'm saying is still close to the truth). >>>> >>>> So: the client does the same amount of work, the server does the same amount of work, but the client run-time is still much more deterministic. >> >> >> >>> Note that these are still single core results, and most laptops can do twice or four times as much. Now, I know that what I SHOULD be doing is to randomly generate 100 cookies and then calculate the times for different bit lengths for each of them, and then calculate mean and standard deviation. But just by looking, it looks like its much closer to what we want. 16 bits would be a fine puzzle level for my laptop. No idea about a phone, although I could try to compile this and run it on an ARM-based appliance, which should match phones. >> >> OK. Now I have done it right. See attached. The data suggests that 15 or 16 bits is the level of puzzle that for this kind of hardware is challenging but not too onerous. Add another bit if we assume (probably correctly) that the vast majority of laptops have dual cores at least. >> >> I would like to run a similar test on an ARM processor, though. The capabilities of phones and tablets are all over the place, what with different versions of ARM processors and devices having anything from dual to octo-core, but it would be nice to get ballpark figures. >> >> Yoav >> > From nobody Sun Feb 1 10:39:06 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57861A8AEA for ; Sun, 1 Feb 2015 10:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zt1nnwmR9TAR for ; Sun, 1 Feb 2015 10:39:02 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D5311A8AE3 for ; Sun, 1 Feb 2015 10:39:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4301; q=dns/txt; s=iport; t=1422815942; x=1424025542; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=A85WS1pXYTWiCHG31rfItAhjByoZAgvI5xPMk+9L1GE=; b=g1RDQu24zwA4BkLhGUEQX3C6hfWo3bKYVea+mHujwQZz669SjJSy7AdT BTS0JkLo8H+LZcFVyF3+Rou9Bo8PzjxXtMb+ZoRKIHPbQkZiQ3MMGCsYy tMj0xEGyCLpIBgVbiH1hV9BeeMkGpaIhwqw/hqXN6fRVfFY0pBPWAWWXC Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMFAFNyzlStJV2T/2dsb2JhbABbgwZSWQTEUQqFcQKBEkMBAQEBAX2EDAEBAQQBAQE3NAsMBAIBCBEEAQEBChQJByEGCxQJCAIEAQ0FCBOHfgMRDcw9DYVQAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSNToF5MQcGgxCBEwWPCYdfgl2LSIJAgz0iggEdgVBvgUR+AQEB X-IronPort-AV: E=Sophos;i="5.09,503,1418083200"; d="scan'208";a="392582945" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP; 01 Feb 2015 18:38:45 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t11IciPg013755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 1 Feb 2015 18:38:44 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.3]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Sun, 1 Feb 2015 12:38:44 -0600 From: "Scott Fluhrer (sfluhrer)" To: Yaron Sheffer , Yoav Nir Thread-Topic: [IPsec] DDoS puzzle: PRF vs Hash Thread-Index: AQHQPApmyeO+d1j/8UOVDEGtNVHlU5zYCYeAgAAdRoCAAGCfSYAAeYGAgAAPeQCAAJYfAIACTaCAgAAARYCAAINdgP//op6g Date: Sun, 1 Feb 2015 18:38:44 +0000 Message-ID: References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> <54CE6429.2020800@gmail.com> In-Reply-To: <54CE6429.2020800@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.219] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IPsecME WG , Valery Smyslov Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 18:39:05 -0000 If you want to tighten up the time between worse case and average case time= taken by the problem solver, might I suggest this: - When the verifier is asked to generate a problem, it pick a nonce N, and = use it to compute m k-bit values S_1, S_2, ..., S_m (for example, S_1 || S_= 2 || ... || S_m =3D AES_key(N), where the AES key is secret to the verifie= r), and publish k, N, HASH(N, S_1), HASH(N, S_2), ..., HASH(N, S_m) - To solve the problem, the solver needs to produce the values S_1, S_2, ..= ., S_m, and send back N, S_1, S_2, ..., S_m - The verifier verifies that the value N was what was originally given (for= example, the nonce might include the solver's IP address and a timestamp),= and that the values S_1 || S_2 || ... || S_m =3D AES_key(N||0), (or alte= rnatively, that those values produces the hashes it sent). The solver can always solve the problem by computing 2**k hashes; with mode= rate m, we can make it unlikely that it can be done with significantly fewe= r hashes; I would suggest m=3D4. Of course, the cost of doing this is a) larger messages, and b) larger up-f= ront cost generating the problem (which, IMHO, isn't too bad -- one AES enc= ryption, and m hash computations; however, you are free to disagree). -----Original Message----- From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer Sent: Sunday, February 01, 2015 12:37 PM To: Yoav Nir Cc: IPsecME WG; Valery Smyslov Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash Hi Yoav, This is good, but I'm not sure if it's good enough. The ratio between min a= nd max (which I trust more than the "mean +/- 3s" rule, because this is not= a normal distribution) is consistently around 4. So if you have to design = your timeouts on a particular machine, you would still have a lot of uncert= ainty. For comparison, could you try again with 64 replacing the 16 tries, = and with lower bit lengths? Thanks, Yaron On 02/01/2015 11:46 AM, Yoav Nir wrote: > And now it's really attached. > > > > >> On Feb 1, 2015, at 11:45 AM, Yoav Nir wrote: >> >> >>> On Jan 31, 2015, at 12:35 AM, Yoav Nir wrote: >>> >>> >>>> On Jan 30, 2015, at 3:37 PM, Yaron Sheffer wro= te: >>>> >>>> What I would suggest is: we give the client a single puzzle, and ask i= t to return 16 different solutions. Indeed each puzzle then should be 16X e= asier. The nice thing is, the server should only check *one* of them, at ra= ndom. The client would still need to solve all of them because it doesn't w= ant to risk the exchange being rejected because some solutions are invalid = (the game theory is probably more complex than that, but I think what I'm s= aying is still close to the truth). >>>> >>>> So: the client does the same amount of work, the server does the same = amount of work, but the client run-time is still much more deterministic. >> >> >> >>> Note that these are still single core results, and most laptops can do = twice or four times as much. Now, I know that what I SHOULD be doing is to = randomly generate 100 "cookies" and then calculate the times for different = bit lengths for each of them, and then calculate mean and standard deviatio= n. But just by looking, it looks like it's much closer to what we want. 16 = bits would be a fine puzzle level for my laptop. No idea about a phone, alt= hough I could try to compile this and run it on an ARM-based appliance, whi= ch should match phones. >> >> OK. Now I have done it right. See attached. The data suggests that 15 or= 16 bits is the level of puzzle that for this kind of hardware is challengi= ng but not too onerous. Add another bit if we assume (probably correctly) t= hat the vast majority of laptops have dual cores at least. >> >> I would like to run a similar test on an ARM processor, though. The capa= bilities of phones and tablets are all over the place, what with different = versions of ARM processors and devices having anything from dual to octo-co= re, but it would be nice to get ballpark figures. >> >> Yoav >> > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Sun Feb 1 22:32:05 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1F21A9237 for ; Sun, 1 Feb 2015 22:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kX_MV48O5Pwd for ; Sun, 1 Feb 2015 22:32:02 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (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 176661A1B94 for ; Sun, 1 Feb 2015 22:32:02 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id h11so13452572wiw.0 for ; Sun, 01 Feb 2015 22:32:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=JxaT8OvBDZL+tBpIUk0az1Q0IqfX5ce+bnTuEjk0IDM=; b=YpWQRjcIVr/l5OVyuiiukpeCQ0gIYxqCd+0povdfhKw/u80ynyFY8DBzCeWysy1hx1 cNkyyc/PajFhVa88tbZ6mR3dVdti4m5x2ZKxWYj5+lUXStK8JcFNUuDcKL1iAomHdNVX 4mhOQq5XVZUHrcuCDRTBFl/4G03TznCNSKcB9vgZ5Cr/MV2kVX6D8QGgBUFya/aaVJHd dRNtOWQV3wmsBx3SxWmak0XNr12xB5eXWmN84TVEujEHMZmPqPbJzw2b/RGiJpSszVUp kw1UMDGbvFqTVlAa68BnA405+fgMpWlmp6naxNw8Ewebcg7+encXeDSDfgZD08/ZEkjX f/2A== X-Received: by 10.181.13.115 with SMTP id ex19mr21210846wid.31.1422858720944; Sun, 01 Feb 2015 22:32:00 -0800 (PST) Received: from yoavs-mbp.mshome.net ([176.12.144.165]) by mx.google.com with ESMTPSA id di11sm18355892wid.8.2015.02.01.22.31.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Feb 2015 22:32:00 -0800 (PST) Content-Type: multipart/mixed; boundary="Apple-Mail=_080914A0-1E80-45C7-8458-A9A8B6F8A13B" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <54CE6429.2020800@gmail.com> Date: Mon, 2 Feb 2015 08:31:37 +0200 Message-Id: <45BEE118-9B68-4D7F-BB9B-16A617A0C5AE@gmail.com> References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> <54CE6429.2020800@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: IPsecME WG , Valery Smyslov Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 06:32:04 -0000 --Apple-Mail=_080914A0-1E80-45C7-8458-A9A8B6F8A13B Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252 The three-sigma rule applies even with a non-normal distribution. Anyway, I tried the 64-key sample. Results are slightly better. Yoav --Apple-Mail=_080914A0-1E80-45C7-8458-A9A8B6F8A13B Content-Disposition: attachment; filename=data64.xlsx Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="data64.xlsx" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQBIZhxhaAEAABAFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACs lNFOwyAUhu9NfIeGW9OyeWGMWbeLqZe6xPkACKcrGQXCYXN7e0/ZXIxZWhd7U9LC+f+PU34ms11j si0E1M6WbFyMWAZWOqXtqmTvy+f8nmUYhVXCOAsl2wOy2fT6arLce8CMqi2WrI7RP3COsoZGYOE8 WJqpXGhEpNew4l7ItVgBvx2N7rh0NoKNeWw12HTyCJXYmJg97ejzgYTKWTY/rGutSia8N1qKSKC8 neVn6wIY7CjcWvWLLj+SFVSZxLHWHm+ODq/UmqAVZAsR4otoiIPvDP90Yf3h3Lroxjzj5qpKS1BO bhrqQIE+gFBYA8TGFGksGqHtH/zTYuRpGA8M0u4vCfdwRPrfwNPz/whJpscQ494ADrzbg2ifcy0C qLcYKBmDA/zU7uGQwsh5TUdk4CacdLv86dwugvNICQ5wOcB31Nrq3JMQhKihM2wnR4r/5Ya/0gbt /aJAnfHm6T6bfgEAAP//AwBQSwMEFAAGAAgAAAAhAFB8TsH2AAAATAIAAAsACAJfcmVscy8ucmVs cyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAACMks9KAzEQh++C7xDm3s22gog024sIvYnUBxiT2T/sbiYk07p9e4OguLDWHpPMfPPN j2x30zioE8XUsTewLkpQ5C27zjcG3g7PqwdQSdA7HNiTgTMl2FW3N9tXGlByU2q7kFSm+GSgFQmP Wifb0oip4EA+v9QcR5R8jI0OaHtsSG/K8l7H3wyoZky1dwbi3q1BHc4hT/6fzXXdWXpiexzJy8II Pa/IZIwNiYFp0B8c+3fmvsjCoJddNte7/L2nHknQoaC2HGkVYk4pSpdz/dFxbF/ydfqquCR0d73Q fPWlcGgS8o7cZSUM4dtIz/5A9QkAAP//AwBQSwMEFAAGAAgAAAAhAJbV+XMCAQAAPwMAABoACAF4 bC9fcmVscy93b3JrYm9vay54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAKyS3WqEMBCF7wt9hzD3Nbr9oZSNe9FS2NvWPkCIo5HVRDLTH9++wYK6sNgbbwJnhpzzzTD7 w0/Xii8M1HinIEtSEOiMLxtXK/goXm8eQRBrV+rWO1QwIMEhv77av2GrOX4i2/QkoosjBZa5f5KS jMVOU+J7dLFT+dBpjjLUstfmpGuUuzR9kGHpAfmZpziWCsKxvAVRDH1M/t/bV1Vj8MWbzw4dX4iQ xEMbBxCFDjWygj+dREaQl+PvNo23OmD5ziFud0mxLK/B3G8JY3Rrnq1u3LyOqbQGkW0J8e3DiSwi zxBTieTYydZgdlvCcLxanEFGKcd3YpBnZ5//AgAA//8DAFBLAwQUAAYACAAAACEAAJApYtgBAAD6 AgAADwAAAHhsL3dvcmtib29rLnhtbIxSTW/UMBC9I/EfLN+z+U7LapNq2Q+xEkIVgvbsOpONtbEd 2U6TCvHfO3FYKOLCyeMZ+817b2ZzN8mOPIOxQquSxquIElBc10KdS/r92zG4pcQ6pmrWaQUlfQFL 76r37zajNpcnrS8EAZQtaetcvw5Dy1uQzK50DworjTaSObyac2h7A6y2LYCTXZhEURFKJhRdENbm fzB00wgOe80HCcotIAY65pC+bUVvabVpRAcPiyLC+v4Lk8h76ijpmHWHWjioS5rjVY/wV8IM/cdB dFhN8jS+oWH1W+W9ITVzEH+IMnQJLWn1eFKXrVLa+eYlRefY4PROS9Rp7b3gbsBgLiDQbNWDgNH+ wZyvZHoUqtaj//7yJh59+lHUrp3pFBHCL7lPIM6tQxZ5VmDSsaevMwOUhG+wU/imlTcbW/qTKO8E 6mBFtuL2eZaBwzihYJRk1gIDc6pjj3L9ylnHUf18+IdZFEX4mmvFB2NwCDus/BIJk/tsXbXBkwxG lPTHTZ6kh3yfBkl+TINtfoiCuEiToMiOSZ7tkiTLk5/XDZDTPysgBTfa6satuJbhMn3cGh7CxMEv 0e2yRNVGTuut4e1pT44dO6PvideBXNCTK7PwurbVKwAAAP//AwBQSwMEFAAGAAgAAAAhAFBQloCt FQAAfy4AABQAAAB4bC9zaGFyZWRTdHJpbmdzLnhtbJTaza7eyHUu4HmA3IOgaeCIrH8a3Z1BgtxA Ti6giizajbglpyUbPnd/nuqMDqmBY0Bt7G9vfixWrfX+Lf7wL3/75U8f/jp//frzl88/ftz/efv4 YX4+v1w/f/7Djx//8//8++/axw9fv/XPV//Tl8/zx4//d379+C8//eM//PD167cPrv389cePf/z2 7c+///Tp6/nH+Uv/+s9f/jw/+8395ddf+jc//vqHT1///Ovs19c/zvntlz99CttWPv3Sf/788cP5 5S+fv/34MYX08cNfPv/833+Z//o/n4S9fvzph68///TDt5/+9cuX//p5/vDp208/fFqf/M+n+/67 8fO316fhu5/G736avvtp/u6n5buf1u9+2r73advb2Hs5z9Dadc6c7tzadrZYY8n9THu/U4ltez7R ty/f+p8+2M0P3+bXb79//nreV4tbiud271s+wnW3LVzHDOeoNe4xnrHuvV3P61o87zr3fPYWy9Hq HtJ2xhySpRx33HeLymc5Xtf1buVnKvU+2j5HvsI5Zx772XKcVxlh7Kml/XldDeXetpTzvR0hetCj lf3qLjz2OPYZw3befvO8LqcUQtiO+6q27JoxzRb8Zb/mNXrKm8tamq/r0rzL3c49x9FCrts8+7iO vY7Qz5FLuKazmL0973elUGaJc1796ufWriPWEs5Wgye9yxWOvaT9uJ/X3fux1XbmOe8c6p2OtMd6 tzxm6zG3rYR0bXd/lXGaeyythZTLfvaZplvO47jitu33mDnudz1nHc/7XenM17WuyLkepfj+OXvN uTvUODzZdrf9ft3vyDHVoBuPeszUSjuL7ctnU4HnfsWxteNOV3/er5+1tnz3Uuoo47jGrszucA3V F/o2epx3DfurzmYOMaetjXKUoD5aV69x1Gyt3Y9n2bqVv55vVn/XW04eYszbHc+45dMTpzby3OYV xlXu9zrbfpY0ZgqrXmaKVz2V+hGvPJRlqXbqtqDn8zm/qChqHr3fdz62TQcd9SzjjHs+xrH5hjjT 8zpb1e+xjX1ENZKixijbvA/flqofxl0UwnitUzHs2xbTVmxGOM5xjfu6Fc+erxqq09ngRH2vs8+2 H2Hr+s3t2jw82NxnS/FWoEOlHb2k+lznUYDEdh/pvNzKF9R+lunceh/nvLTW1eb+hp/eSmlxRCd4 Kw6buV3JroZTj/QwUnfTml7nV/aclK7j7+Fy61I0wdpETTisIIZj3Pf5xgkHO/Nd2hUXRqaSnduw PSGfITTodgxIGZ7P145+hHlsqbVxneHcwsK+q9WUx1Egy+wjzfN8XnemFq89nDmMAZas7bj3q3mk fpeRAOF5ttFf6+xHAZ1HbOnUehbUt5pBWpzB91xli3Vueb764WoNntRjh03DjQ58kK8ttoAVjpQ7 QFQB3zn3Mq+WwgYxr6kZrxjuOFuDnqPe23mV/cYhz+cbW1YZeYtnyvDwbDB01HbtJXSwsm+gChG9 rpv73WrWD6U4+ADPmu6+cZjSA1VXviace9U1ZN2r/ejH7hGvVGu+NNPRTzU7t77vCGuEF6/ce9j3 /ajqEoPoJxSWYu4F5F8gx6/ylfoL57cG5vd1UchHzpdNDTqxhU3nKt4TFgyg9tyX7hRKyLFue9We eh1TzoQeQttSzyAm1nS++uiO2TEMlFQ2NJs6vEnWaJNivNJ1lNH8e9Xn5nzarnmvqjgOe9nDPI+z BTQ6cEqf49Qpz3XCy1W5u4eJeOdKo2ghD5RvtbYB7a3Ndr6eb2F6B7TxTminLzppPeQ0a4h+dpit lW2U5/0KNWKlGqlPuxnOlEZuTvE3SvMQFdD57HkdBtNHA/SWet3xbGp6Dwu27xZ69vhdebYXfs64 L7rDP9e1hXCEikXAjNor9WxNd971Si8ea4panZRFg+cVW2w0BW3i6tSqB2+o6TxefVuv3FPYwxVK jP28/WjZAAdyxHBec8aYjvg6h9vyf2Oq1s84QozKDh3O/boILDhRq2Psr33x7HF2FB2x7hxIwUa0 s8LH+9gyUKz9qvurH45JGFqaw8/FheTElvcTfpITyY6t4p3l1bdkWVKLM2+nTaxU1r3D3vvaVDPl HTJG0o3P88tWFyH51XLFMNaMzbQO1EEy96HhU0/ltS95accrXsXv8MSElfSEM73UbCrnMfSGJnze b9Z4JCr1tnuQSJVsVztvZeZLTnhvnfdRX3WNRjzSSNTDLCB09IM020JL5YBMYKeexxFe/bdDzdRV FpI9+p2zOknHFnxHPHPJO1UC61/XOdNYW1w9gSFjKBVRHM7RwSo88qcdlNG7zqbGPue5L1gC8+ig ORr68BxhxnNvlXarr/uVvhdSx+pGXRgduyOgy1H1eZBDFM1RYnjh7th3GneQhBPptvsc+qODh9Am Qsw5bvTl9Tp3iy+TJbk7QLM1I2Lm7S590OWhIf5kz951BiCol/1O+SCV71K2GjY7vNlnREMLFrz0 1oOMxX5wDC6HY1e8F670UuNNxcJfyNod4Asn8pVVB5DAYeTb6GOcWaUdJ2Q7sq8dFyH5fr6x12vb Sc/mrCbmctBaoWBgFU2dXeeJlp71ibFqOxjTUhNcivQxHqUudjqelnXssad3vydicHmOevVqsYXP ieqYwAYw+uKkwgD/C88AbS9ExV3oWleko/cdVxzULBEJDRX1fbz6yAPslfFSjbkuAWvry0EC0kPX NtH7smvjtS8OaZ9LuZQU5h3uACL0YIcftMgGXQ9Fn1/8R2Lg8GO7qoYNVBOhTWCdybEo75R6d/Pt dX5dEaO/fl1zK3M/KdWq3nYgvr4unzVN0jw+z6GVgYzvoCE2ABtJA9hAuOS2hwPXQBde9XU/xcff bSBvNNWhouJZI5oH3zwMN35vqcwXfkaKo9tD8DnStpGoJSOWce/Eaum8R5kZYz3XSY8vw5JZYYB0 +MEJXscxMtF81IR35l7i6xyOi6glHDmAZaTPZRePxIAvs7jEj65So9fzfrsuCGBXz7FK1w5xUw52 aukMLiDrJUrrtU6+HS9MGu7ckubFa8jTk+r0jhLPWzGc1wuX7uVwBBTA4MRcfP9+Or2EosISkKRQ qMj8uc7twlrIGCIBC14TKqmwlg/FMBmySJog5Od14AATZY6azK1k2lDUen2kvMs8im2+bsbxeZ24 4NI6pS6hcnKyxLXlFgZQcdM255brPfLzup1yIz4sTgjhi3mOztApoOvKy6gw90PQ8bzuqlMbHcsk Tofgjw/1TdUtzicuoPVvXP28zmENzXmW3kNJrj8ahQGk73uRyigSg2Crn9eRueFqoaZ9CQgPFoPT q6xmmzTQtW+NSg6vuvbH+YwgRYMKMRiwJchOXLNoicty43G9+6GKC+yBupJENKBtD1VbXeLqN3/U 0H4pr/M7zjyAbD9kLc7DqdjcZacQ2LJ4MHQETvf5fNthC+G7OIEEwe8xo6hEzvYDB67vXDjen9eV i/5eTUaLBEQAZpPqunbPLali5AVQc7764XQ6UHrp6ASCu521++QxDmXRYyQNSbAXvuCEHnHD0IPI 4bRNpMnqdwAnQgKfXSW88CzJzCQlB8JVqGrRDUunRJDQVgjnLhO83vnSRhB03nLc2x6TvzjKlbfZ hT0XJEzU6YLw1/00GTu0xIt84CBTQQRt1iNlpojGfsNfAcVrPzdRhBOnyju96fmoszEkOKh+Ew4C xq4UnteRmWzb2JwT/lCqVHKeKge8M61EqeDizK96wX1hS2Nboh+Jod1r7/R4XjGa2I2hJiPfOmSR VLy163DV4BcqQCyAQXgp0FnoOqern+sUj97lbOIbOlMwEgf7YcHhoBBpl8mBLs/2vA456AGqioi5 77YCXdZd9x47Sc5ZLw7073ndCa3IwSx9kRDN7hjnzZM32qQKAIWNFjLe102QdU/blheJadwCnogQ 6LEsh7sxnOH1fHno6NArgQ1jyU96ZqNzLhXjIBSQRJSRea5zKWPCuBByTVhaaY6ID9hQmpdTFcjJ ft4+VR1RGRlbSW5sTZ6d32jyPUgtal454269z/stcaRFcfvyiNHdMT7FBiuEfGwBX1w19PO65dRC CzdWcjX2JV1FuvqWgOVwg/oDGq/rNFlMYglaDCBBpUW7YsG+tgl9i90oxbf/4zVnogTZ/B0VKc6u 0sMtPr8pEO0f4xzbq//qLvQoaOSUTlSu55IKr2IVq0DHbSBFadVrnTBEESLWi6iLkIRfEJXSgZRy AL5Vb6il575Q8eppUCyMg1aUXNbjPCRxbjxlW74U1r34QSkUmfW9WlDwT6a2i2Qq8kTMIsR1EgTc qx+4e7KAjxOlSJWSInchqVunI+K5PGdl2J7rpB50EWE25cO3XqTzboaXG269moOc/C2Ie163xQIJ 0eO6+pyHaccdKS0IiocDhwNTgfDzOhwrqoNeRCPZsxGeN5HANDgT5gDtW29+94NgMWzXit24BUoZ cECwVt3VDGWVEbpKr3XOvkluEDFGXoggaZBIERasOWwil80u5FrPdVq7OCfsYm6TmO10FBz85DZ8 jpqy0zj2d79PCpVgglgiKS6YglfUUui98g2WgdlOs5fn/SjAWyJL3ET/F4Atj3xvcErgSrfyO8cg oZ/XzXvPVbyNUfo8KtGswEiaRepZ9FtIhZHj6zoqvnKja2bV5RoSPsV/myPJMT3dRmOzBu86azS+ bHxtmxQDXxME8t2EYI5iInTpaUt+4SAlLqpBIEhHtwm2HLrEz34REql24k7Q9dLl2yL9PGnIIXEO YCKGaVcnrnDjcN93HfzVc19wAmR38m3id8d3tEkzJ+XVmV0ibc3W3rpcEtjl8CSjsGcv83Bk0rAs kDyV+7lsuaDjpXtOwluzgnJ1zwTkdC6sWLmrjYICvvZq38EJVbyxzsvDGjjp+8AyKJS2b2rhJrkD 7/Lq9z6Wkkdht50bTpgiUwXZwAN+nFNYoZqu+dwXG8FC4aRDxE1+mOgF4lAE7eRl38Fh0Amvc5CV j2rPTZq4FmLtUGY0qzBxhSiZzavq/NW37BpLBbyUoj49BUZRhKACjC2GuJHhLj2+cGIJ/gPusok6 SdMbEpL/GHZ5QvuLLw4E/3y+xFAiD70kRQRqBy2w9kFLyMai6tNRFvK8zsSWX29hFtKfklGcNIsQ FvUOCRlJs4lrXz783vpv+GMwhRHkIQZG5GPfTMaovU1aKO3aXudgdsJE5bhkjjPQP2pkgZrZB1kh VmEPaNjnOuX3FCMe4ZyFLuh6FbkAFaiZWRow8GX7ePFKA/HgSChoAiP3XkxGlwEVAlbYuAa4K0J4 3s+uCcbpd4S8iUEPcmLL220OBc40FFiTwb/yQXmJnB2WqQ56YqcKiHOZqAhVfsvLL8X/1te4HIKa BmAUApx7Rmqe2Gyt+y9xLzBSq891qkbqFhgu+DLGkVabxho+dfYNNokSqOf3OpekTdcF67T8Jenx SMtC0pNiStRtpFHK/aozvNUJeBRPI8m/iwhaFw8YIfYVgBX9W944KAq0PGjkpmSS0auhaugiGfrS eIV+lYO+/VErBiKZ77qlc+dZJTcS+Y0ZwImmurc5njz0dX6yzeX3cGaNweR4XissZ0a4JEqE7HaO 36mXc1cka6aPkhmr2+iWujtMzye13owcg316+9sOQAWLgfWSuwIK2BBFBCbWhIYu0caihrc+444k QuufWYLpuKzzOKaBXhBFb5J2DJ7KS5+ZcaBoHm8XlYF5Cdyp19WZKcQuQptev3DvZ73IGURLycy1 mFMYh3fiSNjPQmw8VZqXkbOXEJ7XUWH8DaJasEfIH1JeaGF6IrXRWPB1dIb1eR3mSsaJC9W8LCDp YVGUiESTjFpF6l0HOfYLl5YG49PFRbZ7mFd0c67UfrvPJqByLxFLefHRWFVVd/CUVnyMhTyvMpB5 m2Gw5tyW2n89n1kxlFUQRWxiWrv6jtvsdl/NIgqjHrLrtc6w2FxZi13tJk4jaCzdRImiNHeUr6xw 9IVL+NSn0pr1nkA4ZaECirhOUNqgVEYmUuzVcz+luo430ND0lH0UfClqtkwGt5K6JURMkF7nzpnu Te2u7MX/zDk2MRgdys15JcO80R5d7zklSLYg1KFNK36UXxGg/UaZAlRYVisBN17rNEg9yVZTdGqc RGNWL0MBpbIYzGxAIqIe3rwiz6I+jyTFhmmkr1SJ+ljjWHZOKsYBKqbnvhiy7pSGSY6/lZ9Ih1Z6 YqwXirHMvrH+uvK1L/SJMrmmkGUBEKlMTqSVUfoPaL1AqTeHXtcJcoWAeFqAOtS2OZpp05pdaWLc eRyVAr9f/b7cJqupwLxWwkOcGFbqKgOb3ohg0sG3fOulC5TwLlBf4ckaGRIdnBLLt2ZiJsX8P6uW 3+9LGW5Jr4EB9QKFNP4wOOQYzCWyeIuJYUTfOV9l5GyXTN2GO0LjH/tEUy89wtE5G3z17ne7sIa8 t75IUrqq/djxY4rcDf6NNr3kIZ559QN0UB1SGtGpCgPBWkrjcGFyJUDOFBB473o51mtt600bE3oC yxRuTcQRoT3G9mAmkScvfiC91O4lOt7XcvUCRvAZk0T5ThGmxIoWfdYZC2ekIblfjwjvvOhE9gRQ Af+Ze1sG3N46xHRfDWMT5YJv7QOR660SuXYmldYbULtp+qvO1lBidbpZHHzAdyZs3H4REvFx3pLA Ar7yhbt8lM2udt77CBev5/2saIPrdqw3rXADEU0cPZ9vBS3r/Y8xPKXv5mpsIT4xBWexf0vzvJbw us7XN+/vGaftgd2hq7C1UdsOwC3TS0ay7/5+7wKGNGMtJWpEqFPJZN2zKFsr7yJA2trWvPqIy4TQ Dor+FgebccpcshuYu+v1hf2q6I3zDJBciAaQaolFJqQNaBk/U4KkOtO6/PXLF0vyoLRXLiRfghZp Dalri0k2W2zAzCoLvF68MhPd5uUckb/3IA13VmakszCK2FW4aJ5ucvKqaxCXtWCK3IUJhUGQDfWo 5JMozZtTXoRa0dbz/DSRtyq8+2K2xnA4ZGwkCCm8n2aMOsV3HC8eY14FKaIpbwqsngfXprDYmbUG EkII4KIWnveb8h3TMO84Cr0JepuDEeCLt/M0BoXG2rPKz+v0AfoZdY04nR+IIUUIWRtEipgqEk7O 8qV7vFNg8iAnMktlkY0WqVYZjgogyU2rBUYK4NVHt9mEmev6e77LS25ehOWQTJs8oA0xq2FZygt3 jXCkGHBEAL6crRm2TlwJ4SmtJUVlD949eN2vosgdBbEqdN96h22RPOOjZKjsG9iLtdNrX/oyjogy eCnVgG2Zxg7vBZPeuGQN+nFrz/ass/Uu9O+//pmF//Gjl52/zl//Oj/+9B/frn+bf/39h8fmf/+P f5n98//iT38X/xd//E9/9x///Hevof/t711A/9uHTx9++f+/+ZMXyH/6fwIAAAD//wMAUEsDBBQA BgAIAAAAIQAwD4hrEQcAAN4dAAATAAAAeGwvdGhlbWUvdGhlbWUxLnhtbOxZT28bRRS/I/EdRntv Yyd2Gkd1qtixW2jTRrFb1ON4PfZOM7uzmhkn8Q21RyQkREFckLhxQEClVuJSPk2gCIrUr8Cbmd31 TjxunBJAQHNovbO/9+a93/szf/bqteOYoUMiJOVJM6hergSIJCEf0mTcDO72u5c2AiQVToaY8YQ0 gymRwbWtd9+5ijdVRGKCQD6Rm7gZREqlmysrMoRhLC/zlCTwbsRFjBU8ivHKUOAj0BuzldVKZX0l xjQJUIJjUHtnNKIhQX2tMtjKlXcYPCZK6oGQiZ5WTRwJgx0eVDVCTmWbCXSIWTOAeYb8qE+OVYAY lgpeNIOK+QtWtq6u4M1MiKkFsiW5rvnL5DKB4cGqmVOMB8Wk1W6tcWWn0G8ATM3jOp1Ou1Mt9BkA DkPw1NpS1lnrblRbuc4SyP6c192u1Cs1F1/SvzZnc6PVatUbmS1WqQHZn7U5/EZlvba96uANyOLr c/haa7vdXnfwBmTx63P47pXGes3FG1DEaHIwh9YB7XYz7QVkxNkNL3wD4BuVDD5DQTYU2aWnGPFE Lcq1GD/gogsADWRY0QSpaUpGOIQsbuN4ICjWE+BNgktv7FAo54b0XEiGgqaqGbyfYqiImb5Xz799 9fwpevX8ycnDZycPfzh59Ojk4fdWlyN4AyfjsuDLrz/5/csP0W9Pv3r5+DM/XpbxP3/30U8/fuoH QgXNLHrx+ZNfnj158cXHv37z2APfFnhQhvdpTCS6TY7QPo/BN0OMazkZiPNJ9CNMHQkcgW6P6o6K HODtKWY+XIu45N0T0Dx8wOuTB46tvUhMFPXMfDOKHeAu56zFhZeAm3quEsP9STL2Ty4mZdw+xoe+ uds4cULbmaTQNfOkdLhvR8Qxc4/hROExSYhC+h0/IMTj3X1KHV53aSi45COF7lPUwtRLSZ8OnESa Cd2gMcRl6vMZQu1ws3sPtTjzeb1DDl0kFARmHuP7hDk0XscThWOfyj6OWZnwW1hFPiN7UxGWcR2p INJjwjjqDImUPpk7AvwtBf0mhn7lDfsum8YuUih64NN5C3NeRu7wg3aE49SH7dEkKmPfkweQohjt ceWD73K3QvQzxAEnC8N9jxIn3Gc3grt07Jg0SxD9ZiI8sbxOuJO/vSkbYWK6DLR0p1PHNHld22YU +rad4W3bbgbbsIj5iufGqWa9CPcvbNE7eJLsEaiK+SXqbYd+26GD/3yHXlTLF9+XZ60YurTekNi9 ttl5xws33iPKWE9NGbklzd5bwgI07MKgljOHTlIcxNIIfupKhgkc3FhgI4MEVx9QFfUinMK+vRpo JWOZqR5LlHIJ50Uz7NWt8bD3V/a0WdfnENs5JFa7fGiH1/Rwftwo1BirxuZMm0+0phUsO9nalUwp +PYmk1W1UUvPVjWmmabozFa4rCk253KgvHANBgs2YWeDYD8ELK/DsV9PDecdzMhQ825jlIfFROGv CVHmtXUkwkNiQ+QMl9ismtjlKTTnn3bP5sj52CxYA9LONsKkxeL8WZLkXMGMZBA8XU0sKdcWS9BR M2jUV+sBCnHaDEZw0oWfcQpBk3oviNkYrotCJWzWnlmLpkhnHjf8WVWFy4sFBeOUcSqk2sEysjE0 r7JQsUTPZO1frdd0sl2MA55mspwVaxuQIv+YFRBqN7RkNCKhKge7NKK5s49ZJ+QTRUQvGh6hAZuI fQzhB061P0Mq4cLCFLR+gNs1zbZ55fbWrNOU77QMzo5jlkY465b6diavOAs3/aSwwTyVzAPfvLYb 587viq74i3KlnMb/M1f0cgA3CGtDHYEQLncFRrpSmgEXKuLQhdKIhl0B677pHZAtcEMLr4F8uGI2 /wtyqP+3NWd1mLKGg6Dap2MkKCwnKhKE7EFbMtl3hrJqtvRYlSxTZDKqZK5MrdkDckhYX/fAdd2D AxRBqptukrUBgzudf+5zVkGDsd6jlOvN6WTF0mlr4O/euNhiBqdO7SV0/ub8FyYWq/ts9bPyRjxf I8uO6BezXVItrwpn8Ws0sqne0IRlFuDSWms71pzHq/XcOIjivMcwWOxnUrgHQvofWP+oCJn9XqEX 1D7fh96K4POD5Q9BVl/SXQ0ySDdI+2sA+x47aJNJq7LUZjsfzVq+WF/wRrWY9xTZ2rJl4n1OsotN lDudU4sXSXbGsMO1HVtINUT2dInC0Cg/h5jAmA9d5W9RfPAAAr0Dt/4TZr9OyRSeTB2ke8Jk14AP p9lPJu2Ca7NOn2E0kiX7ZITo8Dg/fxRM2BKyX0jyLbJBazGdaIXgmu/Q4ApmeC1qV8tCePVs4ULC zAwtuxA2F2o+BfB9LGvc+mgHeNtkrde6uHKmWPJnKFvCeD9l3pPPspTZg+JrA/UGlKnj11OWMQXk zScefOEUGI5ePdN/YdGxmW5SdusPAAAA//8DAFBLAwQUAAYACAAAACEAUJmJVW8DAABGEAAADQAA AHhsL3N0eWxlcy54bWzsWFtP2zAUfp+0/2DlHZx2wKBKgzakajwMIcGkvTqJ01r4EjkOtPz6Hdtp 47bQy1pNe+AFbMfn83eOz81NrqeCo2eqa6bkMOqdxhGiMlcFk+Nh9OtxdHIZodoQWRCuJB1GM1pH 1+nnT0ltZpw+TCg1CCBkPYwmxlQDjOt8QgWpT1VFJXwplRbEwFSPcV1pSoraCgmO+3F8gQVhMvII A5HvAiKIfmqqk1yJihiWMc7MzGFFSOSD27FUmmQcqE57ZySfY7vJGrxguVa1Ks0pwGFVliyn6yyv 8BUGpDSRjRgJU6NcNdKAtRZLyH+5LWDx4ixCXukbVQCN+DSO4winCW7F06RUskO5AIqW6eBJqhc5 sp88tN2VJvUreiYcVvoWI1dcaWTAwoDcsyuSCOp33BDOMs3sYkkE4zO/7OTcpbT7BAMTOUL+hH97 TgP0NunkTHUspbYddlQLZqFmZ9bAO97W9stZgnakN0KrRjOq0R19Ca4Z23uuwTcY5wsX7oML24U0 gWAyVMsRTFA7fpxV4GUS4t7DuH1bdo81mfX654EAdgemSaZ0AXkmDB6/lCaclgbMpdl4Yv8bVcHf TBkDQZkmBSNjJQmHIZ5LtANQJ6ecP9hc9LvssGNQa1oGUQlpzapvA9QOQZN26AH9BA5YErrqhHrv CiFSVXw2AnAH7WeA382+O8W7+TfOxlLQUOBeK0Nz43KwC4AlHgH5/hYed43IqB65nNudaC+1mx2T z5f/jM+HfcC/V/34w38+4kt38b9L/sFhWvVJNsivl3+VXtG0fDvPBv5pe6e3k/NCOky4rhS+lyvP D8Xq2azfVo2dwZYzMCAE9WEj3b1V98jBbdp+FHpAX1zQRGn2Cuxt82gLrCvJ03Klxh1i+z0IuNL+ NoOgyloyG29/mznb5ntboV/xpdUrs42G9X/w+KC/WO4uFvGBbK86jEaKc/VCC/QDmibNmXyCtt75 O5TIrGHcMGm9H7SdsKKg9rFl7bE7DnjgUXC+HgkHNNmDz5pZoFIH4vDK3GiWNXGIlkPE4dF1iDjQ 3UP8zrZjfO4P4OSBrKvWq05wT3UO/eFcArw+kPC99UIEXLSYdq2vwzP2Aeya4oXTwqkFLUnDzePi 4zDqxj9pwRoBd9ruumfPyjiIYdSN/S73tsHdDwDpHwAAAP//AwBQSwMEFAAGAAgAAAAhAO8V1/nW ZAAA9psBABgAAAB4bC93b3Jrc2hlZXRzL3NoZWV0MS54bWyMnVuz28ixpd8nYv6DQk9zCVMEQICg olsnmnfSMRMnzsUzr7K0262w1OqR5Lb97+dLXKoyFwhs8eG0D/dSsVArMytrVVbhh3/5x6ePL35/ +vL1w+dff3xZrNYvXzz9+u7z+w+//uXHl//5H+c/tC9ffP329tf3bz9+/vXpx5f/fPr68l/e/Nf/ 8sPfP3/569dfnp6+vaCFX7/++PKXb99+e/3q1dd3vzx9evt19fm3p1/5y8+fv3x6+43/98tfXn39 7cvT2/fdP/r08VW5XjevPr398OvLvoXXX76njc8///zh3dPx87u/fXr69VvfyJenj2+/0f+vv3z4 7evY2qd339Pcp7df/vq33/7w7vOn32jizx8+fvj2z67Rly8+vXt9+8uvn7+8/fNHnvsfxebtu7Ht 7v+ZNP/pw7svn79+/vnbiuZe9R2dPvPu1e4VLb354f0HnsCG/cWXp59/fPlT9fqPZVG/fPXmh26E /vTh6e9f3f9+8e3tn//96ePTu29P7yHq5Qsj4M+fP//VgDe+WtPm1w5gbb599+3D70+Hp48ff3x5 B/31/3W/ci9e/7FYb9p629gvvUo/5f/3+LPnjrt//fLiz2+/Ph0+f/w/H95/+4XfxkbeP/389m8f v/3b579fnz785ZdvfFszOjZIr9//8/j09R3sWJ/4kXefP9Ii//fFpw9mYwzt23/0j9A3uKlXTbNZ NyVNvPvb12+fP42/NPzz4R/yu/2/tKfv/ylf/fLh/funvt3pP37V/3j3mMe3396++eHL57+/wNIq huS3t2a3xeuC9rpHaBnCd/bXvf256yIP8ZVvf39T/PDqdwbp3YA4TBFlRByniCoiTlPEJiLOU0Qd EZcpoomI6xSxjYjbFNEmxCsGLI3aZnHUfrI///gSFtOolYWM277HbBnTn9/89KfTv/10Of23fdG8 3mP8//2HVz/bWK9XRdNU5WZdr4ePPNPBtdL92C9vvzy9f9l70mHz+mZ//9D5xPgbB37jEH6jqqpi 0zTF+BsyKseZ3+jbxa6tn8223ZTrut31nzaPW2dHp+fbKFZVXWyqdk087D5iRufnmyhX22JXtHW5 3fTdkNG6PN9EvaoZh227HodcDPH6fBMFk0dZNbtNse1pE2vvOPnxZce858yNZ1ms2l3Ttttd0TeR hzOYIRa24Lw/2Z/VDNfJoHsH7zG9Gf77fxxPf5oYYblaF3VV76qqLDab7W7Xnv4g3BxcK/6RulB7 qF/f7O+YYfHyTf8baoSb1bqudtttvdny2E1Vbye/cZz5jb7dzgzbFYO23u0Yd8wRU5q2cnq+FXO6 dYs77DZ1W1cFjx7H7Pw9beC1bVsUJQ/T7rYbjVbf00RTrbdV3RTthofaVGux5uvzbRSrTdmui3XV 0IOSkRHeOl5mTLGwOef3N+Vqty4bBqKp17vSxiMNRjDFZtkU7c9mijYNdhNL/8U2fXHQL476xUm/ OOsXF/3iql/c3Beh+9vl7tuf1ZNkLPc9pvek/eYP1f/YQ/oYxgmNBPLteg2hdbOWEHtw/3bqP9vX N/s7/lO+fHOwlg+5ZSYW4l3Z0u6u2mRyulE+zrTbtzWE7s16V+F5GOm22TTtRszs9D1ttHgtvls1 5YbJaldLP87Pt1GstptNvSnadrduMfxGhvfyfBPVqim27bYoNru63hbbQpq4Pt9Es9pWO6bc9bZs NtV2XYvfdkTMOEzZO0xRrewhirIsdluLmDOx29YT84nXT/ZntTiZSPY9ZrS4/xksrixtSm7L3Y4H gRSZxw7u304trn19s79jcZVZHC07i4OlbcN0QLtr/itUH2ca7hsbTG632W4I8m1Zl5VFWDW559tg gqw267Ko1tW2rplrU1TqDP/8fAtYy65qic/Nelc0u7KUKH95vontii6UjHKz3hBoy5249fX5Jop6 hbFtGYitxfpqLQ/S8TBjcFVvcBXZFyuZpmLKKrcE6tyLEOJ2ywZnfw4Ruv/CRWj94qhfnPSLs35x 0S+u+sXNfRG6b6utJYfp/q4eI1a/H0C9y/yv2/+eJDtM/uUap43mdPD/buouxfr1rUPgMJuXb6xd TXDWKwyl2I65LQmuEH2c+wlznE3P9HpVQ3SFT4+fHFs6sz99VyM7IiMRKn3E+87f0QjRmo/NZ8NH nubyHW1U5LhVuW7GJtYarr+jjXZFprahlfEjIbKnZcZ/hlEtSD6LuibZHj+J/GiAph4sRGxbPU9C tswf+wE0GOBP//eBARKJSP7HvvDf1J2O44Nv4oEtFtii9QSzqbFFfmJqi4TwaiPtHufa7VsaIzfR Ki0UGXRxlNN3NELornfN2llxfMDzd7RRrZiAirbKoxTbuHxHGw32tyZoj6ajHnn9jjaKZsWyxZLs 4SN+0FMxY39dNvz7m4qEgdi/Ts6U24j2Vz5jf/b3IYLHf2iyxpLh9rIHywknV0hQ2Bc9qOn0Csz4 FbF0SG+L1Y5FUkEmig/Zyksc+eD/7QOLrbBYax2LpXns+xXxNrdNKkXOvKt366Jiso9EH+fa7lvr rBaD27CI21l6S95Rq+WfvquNXbGpt91sv2UhpCup83e0wUK6JC2sthVzDOlCKcHq8h1tEHgJDSiE u6basihspI3rd7Rh/SB6rxmNtqlZXuaEoYswPRsdGT/87PlyY1quqqbBdXBBVoc1C4jES7Q9W6Qu 2V6/iEVVSbanCoUJqtg1MS1BsocMIXEKERs8PmhFhu70ACLh7fwAIgZ5eQARX7o+gOThGyiYPlGe 6+MI25LWjfCwwP6p6Je6BIU0bBLxURu7kbXJqNMaMUw3HWs8ZBoJ8BKvN6Fs/MhwHgWOwFiX+Rm6 xzwFDGrFGrGkmAvq54CuVsgayOXJ7roWLwFTdyHePGb4yDBfAxrhrqGLLjOKbd8CutysahZZqsrc DZRG3OKYV8v/yF9tsDfbFXIAy5Zx8LK5RnJtyfqI3H4p68mdCMxFXu527ELVQv55EDhrxpZlUfoI c0eBbxEqt25KF5M/BThEE9RbIeMcMGi5rGo03F8CplmVFeE091J+9RrQBU2WNUYYKbkFUFmukJDL zYPJuLOvu6EX6O19adOs2MdJoj2qT/rNSK8tEB/R2y8cA73S7X2RF5cdvRtmuJwHT503wjHzZuP4 mtAb4Sz5WSmPxoo4np5n8GMPh94K8XXWj86h66V5gkWe8SMPegnoeoVSxYI92aXEtGtA7xCEaxbE Y9M6KreALnasr1hPMJD9RwblbugF7m3XDNdmqYeIlEcrT1aRe1voPuK+XwAH7rP5dMO9L8ZF8hC4 65qFYaTkIBg0wqaQwToKBjWm2clDnwIGatuS9Vb8rXPAVCs2rFhjRswlYJoVenRRSZ+vAUM4bnd1 NZvj3wLatkxaJER5xLuBFjjb9ZzVpLAs+5Oh5AcMnJWiQYxzbfe9ybPup+TZ9gMmTba7kh2GOEYH wWxYExR5faIL5KPAW9QfH3SEgVOAF8xexML8oJ1lnQOmXNXkurs0KtqBS0DXq3XD/FnNOds1oHdY Sc3WxOhrusy9BXS5Rpgl/55r+27oeZr56+CarCQICGMzeYQizbLSTzT3K/xAs0RCdm9DklTwY+xJ pU/+xW682YgNcHtGJ0SoMx4Fbmr9zk0z0plTgBfMlpt1Kz04B0zJzMy6OtucoC8BbZulDVN5ejqJ U9eA3qHw73brTUJLpLkFdFmtqm7/M7rI3UALRLPDaDEYfaBpizyp5MeIREPloxhc2vfiz5Jb7AdM 8mfU7EIwB8GY2Lxx06K4/1HgmDuyVBounbxOAc6mM6tLjfDngLH9cdbQmV3x/ktA4881i7vcX3m6 a0DvViQUtVPixBZvAc1UywZCtUnBXWzhbugFmtkIg+aKCRtbZTE8fHJGGWkWAST5c69phJ/KTfRT bdljEs3sXOyyUqhR6yBwMgFWKWP3CKXRmo8C3xITc4ybplkBTsEEWgbbuuMnG/kQy33XWbBv2VUT Vi6hRRjHm+ucFk4Y9y3acok5U1WMW2iyrG0L2tmcdPJu6AWi2X8yf25I5LqiinEo0zhGoq0640FO VfZVG4Fosbj9gMlEs4uZI5s630HgJXGYtWv6TIjOdSOWrTNNVgI5SYtk85SnpQZ1KjgHOKuWigVV 7u/Es/3vb1bkFSxd00dylWtomw1N5J2mlP7eAshWw1s0QLGvu4EW6GW3pKeXndJtnnaykUR6TRR5 RG8vlgRLkti6t5o6Qnqit6bgZD62HgTOegbhMI2XJkJHgbMStoqZ9BE/OgU483LLxrmM3DlgmJcJ OvNx5xLQ8FuskTlTfyfzsh8MIveWNVKel/Pod3HkFtq2BTIhzakkyRU79N3QC4yzJ2GMEzsQI9i5 HT7ZGyPjJjk9YryXorxDlyK17MsoV5GJbd30NHXoCIdB9I80glPGI5xZgd298WmokYqjcgqdIXLj 3M1C5PaNk4UTZlvx0UtoEaHLtuNmf/8a0ETubcFupJjlLYBIuflRnDo+yd1AC/wO+pbtaVCRknqU g0fkd0bfKqf6VilmuR8w2aNZIWS+pvxGOYzd2NJLFBIvjtL6cxuvAU4uxlKyFMbOAWOyB9JVGiDN JC4BTZUA07dzujyendddA7qwErZtU2WVJHJ4i2gmVzSvHABk7rgbeoHxnoBqy0O3rHVGG8weEBk3 peiRR/cKUvBo6ci+9CqTPWOBYDz+Hv+NT3kQOPWLtSoOR8EQBqlCzFYkxn8KcJbQ+LxLEsRCzwFN IZ15RA4pgr4ENGkTtVBZH9b4cw1osukN1TjZ/MU8bgHNXI0Oaort8JGe3A29QPigc9Ur4h2rrJGA /JuR8Bmdq5zqXJpK7gdMcnET83KOM3XxKIuxScfyaezeJCYfpXWyAex3HBNWU9GcTgFuEvYWDTXB ZQzPAU0Ip3ayEmu6BAyLaUqJdplD+f1rQBPCa6o6tcTtFkCEcDYs3aJMOnk39ALRgzhGqKJcIO9P 52wiEF3NiGPd93ExraFxP2AS0ewCaX58EAx1eoXzD6XrKPAG56tdtM3hqQugpwBngq7WHA3JthNt 4RzQJGf01ilvwtwloE1qpBp3nueAJpRTqbGbFdVuEd2ubExqmXnuBprnmb8Oq2mew6pTh88czyZZ PYjgVS9lhQguFr8fMInnjYnA4+9NaqIOAmct3VIbkz454nQcHgVOBpxjHD+Sn2eg3GtvBSuohi35 1LjMJufQuG1/UyE6ayCXgN6Y2MGuUmpbOn4NaFybff2JUHcLIFy7tap8MeO7gRaYHuQxsm9kfLd1 GR0ZCh8SbN+LI0sKua96TCbYCnHTc0+maIFX7DM5+UHhR4Ezphz3yK2LtZ0CvDtf0rotMgmG54Bm tmYTw0rmx0+MAJeAbhDfrP45WbK0fQ1oCC4QbrKuLuhbRLcIoajCad4T9N3QC5T3UhkLrjXl4blQ KTtD5N4UnkfO3Ss//qdUENhXPSZxv6VaZziI0w1iHMGDwBEDLSVPH3nMo8Cpp6eAZSRnMrmfAtzi ecGaNfbgHDCIo6Zf5g4L+hLQJD/IvexEpk9s+xrQlpBTaFaKt9wCyNIymswlFTICd0MvED1IZSz+ rUY0jWSejCLRJgg9IroXigLRMhL7yotJPBprE580S78PAre5rJAZ6igY1t46WKcAwYW2VGFJID0H DIxusanZufMS0JZxExKT/el0cQ3oHWcN2LeOpN8ChBBt05WLZxF9N/QCn4M2xjLcCh3zxJRaiXya pPOIz17qCXzK1LavvBzUr6s09B4EY0X7WnR/FExT2FGM/BGyTgFuMbHx06908hzQpFwbPDqzJUxc AprwbEdL8jwkPbkGNHpnyR5YLaBbBO2oE6nXzQNauuTibugFcgcZDJmEJYpleP0ne1ok1/SgR+T2 OpEnt1IZrPJakpHLtmsKDg9SrgjvapHn4UdpvSlbznbM+tApwFnC2Mm0tAzV9dw5oJmRKxLnTGIe q27ELwFNlm2Td/Z9MZBrQDMj7xB4cyYqIewW0ATqXbve5J15Qd8NvcD9IJG1tmzg2NRz3M9IZNVU InNn87oh2Q+YNCNv2E9M63V+N4WSDn4QuJ3CKmSUj4JhTUUx6QLhXnXDx6mu0ZLVc2gSeZkTuG5R IIN7CWh0MSa7vHGgJnQNaCrAOGszWR7dAqjkDBiCOJXMw0c6cDf0Arv9YG9ajvKv0U9HdvNYR8+e kcOqqRyms81+wGR2UXQlBT4I5rlDKAJH9UTiiVZyChgyK7Y4NVaeA6ZcccyK5XEaijwWg+d6XY9N SDsInPPTDnMNLdqqmIXFo/39Dn0LaLYsCHqtm4viE90NvcDooHeZpO23SXJEiYzO6F3VVO+q5CH3 AyYxih40dVIRuciDKTfLn/hsR2myNpUwL0Sn5PrWIbfccJg+NnkOTZJkEcDdZqK4yyWgKd+jcN3p MDLJXgPaaCbLyNOVtH2LaA4DcRhWSyDuBlpgtxe5KCWg6NOtV3LcC+xuZkSu7vu4NlateT9gErsc J9BqnINg7FiIm8QmIpfACdeIYpGuU8AQgllkUC44fmRIzwFNMMZzirxPmm2+99yAhtwN+mxaqGpv rwENuXb6c3a5c4toCqY5a+lMNz7l3dDzLPPXTuJq2WvdsA2Q/nEkd0bZ2kyVLdVy9wMmk8uJzPQr 3WAdBMKSFJUzO65ExaPA7Qy+W8voTHcKcDwXyYnjpONnQrPXvvBhpDVSt/GTjX+g2aOfPbcXe0LK yfGb+b2ogGbNRFF8lRNiGZS7oRdoHvQtdG8uXyAUDJ8cZSLfJM6P0uqNfS/OLGTuB8zId2mbLy6u Sr8PArdSkVac6SgYioHY4RoJnBYDBXhXc81eVDS5c8CwrmGTmEqV9InoS0A3LHCsSDyBZQSuAY03 W50PdjR8pCe3iGb1ZPV5OSWIPbkbeoHmpGm1rBiZ0obPnFvPaFqbqaalmw77ATPSTEVAxR0z+RP7 fRA4K3fKqcbuTbaUjgK3wnYnF+jUfwpwGN+QzrkAEvtyDmhOy7BfognHJWC4fYrlSJnnhjyeXRi4 BrQxzraHW1XH378FNHVgFHNzODANXUTfDb3A+CBuMcVTxFqkrHrOsWfErc1U3Kok1u0HTGacOkUx 5oNgKCTaaL37UTDM4q48a3pwNsAJ30y7bprqxv8cMFaczW57Ni7p5CWgOadKBZeXY+P4XwO6Ww9z KVQyXWn7FtE7LMHuLxj7Iui7oRe4HYQu00LqOguwc9zOCF2bqdBVSRTeD5jMLUt+MfKDYKqWuyHc KE+CdtTOtpTA7yYZmMfgt2gkfhsrMnEOHWBQdlQK5RW2jO0loBG60K28ihbbvgY0y2GudGKTfMYn bwFNQTYnYAvXeGz7bugFlgfFa7tiD7/N64X8PHFqNhnqgeK16eUpPz1sVPEaMIlljiL5UyRiFAeB 46doCqMpTwSyo8BRvLIQxL8SczoFeFcYtHN7/PnpBw/36htpGZt0vo4wjvgltE2AZRmW0+lp9u3b JnoDn5QPhBbRuVD2ueRlxj7uhl5gfNC56BgKQW5lzq9ndK7NVOdS4Xk/YBLjlFXl0kJ6H8ftIPAN B9f9PJo72JFyFPiWJGAxEY+SF0siPXJ4Di0ij5Csu1IGMYpLQLNNsa5MIhs/YnDXgLZFFmW5WsR3 CyD0kZZy2Lw3KB24G3qB537YNxsywDW+Pe1Y9OwZxWszVbz0IoH9gEk8k86qwx0EU5Usg3KE08LM o8A5ys6+QjL4nehppwCncpcLs/xdHdHQzgHNKHNHzybvWcgwXwK6XrF5wn5k6orkKdeAhmf0bm6c Gwdf2r4FtBUPoNpmIxL03dALhA+CGGoqWqpLfCLPpiQ9iuC9whQiuNjwfuNVKNuzmIhQB4GwNcBx 6vHpH2TasUUOTnEBVRrbiQwWWudkIWp/p8UN/0Jp9o13u0dch5EaF+IuoW2CI5sAbg9EhuIa0FYa ska+ib9/CxiiNtvo7hKoLojdDbNA6VDqxexMnpgSOedcgdt6RgXrvo8LZ71KaT9gkg/bw4v9HQRD 8Qw7zGlAJz4scC4Eo+gtjtEpYBhGW0Mkb9EOnAMa+dgmiNjgJUBYOpGuu4p7eaJrQNuNQ5SCklmO n9j2LaBZOlmxURZ5xaDuhp6nlr+a9FXbbnTpThflHkZqTep54LZ1LwEFtxU73A+YRG2z2TL1p0/+ xc4kDwK3mgXnkjprHwVOpA7Ct3TmFODd6TjS7jjO54CBZtLSXGejRnEJaHIj7g7irqb0iW1fA3pH qGTlmtcR0ttbQGMfOKGVlwwfGbm7oRcY71WwigeimmqdGMgWHBmH04eM2/fizKIB7esekxivkLTd ZKuJl8ApsqyWgrbAt6gHeZE5TbUDnM1lLrbZ5mfuE+yAYUuZa78WNqYCmi1lSvbdcVtZCl4DmlM1 LQcMctSaMO6HrqsVoTgtGdPEx0EvMD4IYnazD1uOo9nMhu8ZQayeCmJ6N9B+wCTGcXGXAQyO3bcz Ysj+fU2ALkyO0iTpmp+CJndNBDgpmN1dmmUlMblzQHc1+L5oS4b5EtANkyH1+rltsf5rQDM3c09V 5S7ViAHhFtEooGtnSxps7oZeIHzQw0rbtWIFPzKeTTK6+IweVk/1MHddaUfmfsCMZFL11Lo8S/t9 EDi7CiimY/emeZnAkVcb7nDInziGpwBnFqdOdmkW7x+v7zpiB1vArmI/j1X3oJfQNkkUocxlQoK+ BnRLpdmOWJL6LXZ1C2gOP5c1tYs5RYxPeTf0Ave9XsaBG/K8h1upkXsTnx5N6L0o5eOKXp6xr71w RR6+47RvTlp0hj4IvIJL75nimkeBbzkt5h5nsvQKcDt7w8NLUD0HDJo3u335jLn29xLQ7HdQUeCO WE283Q8G2hk3D4lR3EKDCGbcQE5SM1qFGMXd0As0D4KZXXFZsVOabCSya6LOI3Z7scezW6tOVntB CHa5H29hP/IgcC7tYUmUetX50FEwVLNSnjM+P/+N8FOAI3pzp6+kOucA4SQyipSrAZMGLwENo2RR 3DEyfqTta0DDKHsffjnbPdItgkjkdlylIxLR3UALVKZDkdQEsUxPoxCpnBHA6qkApvdr7wdMCtKW HItvHATD+bLCu5sM5VHgnCfkTOEClaJ6oeP7UJEeuRvUc2gcYZmre5bSMN82VweZipKDp3BxDW3D KtUOJCmxA7cAYsnMDOoOf4mh3A29QG8/7Bu2Qagaczum6TcjzzMCWD0VwFQ43A+YxDMzVCNx6iAY SizY258l7ihwLsgkyU497+g6BQyhlyFVyeQcMIggHOzxe5mxxUtAk1lTlMRqYPzI+F8DGkq5yYIL 9WOTtwCiio9kjJqJCLobaIHJXtmqLavkfs30byN/pvY8Crm9ChRCrgzkvvZKESGX2ppGHO8gGGL/ 4rkIgbMnuGVhmj/pIQYqfQ/IoCgZZJ0yfmTgz6FxXIk7WCmSHz+CvgQ0O45sW7lLE2SyvAY0Rddr Ss10N/YWQN0qiQdMEV06cDf0Arvpsi9u5nd6SiYg8NzMiFzd93FdrAfu9gMm+SkbZ66CX+fBg8DJ sDmsPI7ydAtK4HaHq9+DyvNLT3mAY9o4pk4g54CxaZZqyRxi8wh1LV4C2q5AZt8225z43DWgWSYh QxGRol3eAoiATJUWgSiC7gaa55e/dndLcGCKuSenHbk/kd8ZpauZKl36Goj9gEn8tpx1WkiMBc7d mtx8nl1UhvcocPb0qE3PcAn4pwC36GxbEsl6xEfOAW17EuxXPxqrgel+MPoHRYjk2JXeVHINLbIT QdkZUlek7hZAXNbH9R8YYgTdDbTAb7rci2vMeNFBGpHUSuSXSPwoTjf2fffis/RTtQzpfsAkfi2R zRs3k0WvwOket8ukXnUjeRQM72nY+bvApAenAO/ELL8anZDaP1PfX0jl9FTeztPuXkLbTL7kPm6N Lm1fAxppknpc7q6OT3cLICZfpA0qIUYjlCbvhk6DP7kjl792ijXzPNaZ1+B5RCPPM2pWM1WztE59 P2ASz7akWfJjEbbYXFy4dOUorSNuIFYlq9VtjFOA206PVYPFcT4HjOW2zJk5NORIN3iv7y+nVljf 5Qs6dBa6hrbRLxFnXQovy4lbQBe8CoV33XAl+fCRntwNvcB4L2chaXAK1B3+mGN8Rs5qpnKWJoD7 AZMYZwDzLTV0Po73QeAMX35Ge9QIPwqcLJXl6jAk/Efms1OAW9EXkqCDx8bPAW1yFptCEjYuAcMe cmUXLY9u6FaenX1cA7rlDqE1N6gmtNjeLaDJxWqurXISc9fk3UALRA/aFRf3sYrLglk2l+jaJrk8 SLWbXorxUURf0rYfMIloijb05NFBMHaepBU7PwqGIj5qi9MY6fOfAtwONXJ4U2g/BwzR2lRmmQov AUPRR1fEkH42O8ZAZNCmsCQyaQ37t9BkSUE9WwWuNCJa293QC0QO6hTnYNEaityfyN+MOtVM1alG 1akBk/jjAM9STY/A2Rtc+6IvoeAocOqs7e7g9Mn22I3vKcCZjZE2Xbm8RIFzQCMUsq+jp5kvAYP+ wN6gO5WRx3Pg10t1aFAUh84nbbfQdtFScccdrfOheVG7oq3u5ATXO3FhsItgkWhTaB45aq/ceEdt JBnYN17dYU1MZYYeOToIhqsOSZ+TN6gTHgXuT23ZPxJfOwU4zsP7NfTc4zlgkArtXt+0DlVXuwS0 nUWl0FJC9TVgrLKje3ne+FAySreApmLLpv0sbQr6bugF5+2ditcNc+kiNyRNfzOSOyNYNVPBSt/a tx8wyYs5UaAGcBAML5Xwd+NNtgsFTjEpWlPyXJ2STwGO69o9vbMr23NAI0xy76WbEWWYLwFNkLZ6 gJw+ShC5BrStkzgxoS9BuAUQ66SyRIpKc7JMyXdDL/CcTi6iq3O/WxqkFOojzyYNPXLiXjIKTiwB at94WQkn5rV+bsuiC2IHwZC/UDOT+qTEHQVOuZo/OOgi0RCifQ8sl7IX3KQH7TDn0CQqhwlOWXWU wb0ENMdS7eXCeY6QGeUa0LBL3sUNslPX6npyC2jkDioZx9cF80/Ezu6GXqA56Vq8yNBKbYdPbiXQ vJ3Rtbrvo66lb1fZD5jkzpbCZYNXCg8Cp2413zJIJ2XAjwKn2oJ681kDOQU48ZOD4O5EkU7KAc2k zGVPeYGqXbkEtB2M4YK92Z5cA9ruU7WglOHRCm8BjYuzj0itTwTdDTRPOX/tpC4u8rQ7+FI+mt0y Uj4jdW2nUpcWF+4HTKLcdjQlsh0Eg3hIvjGa4aRQ5yhwXiQVXvMgXnsKcEupUTsFcw4YbgchQ3KC q/T3EtAkX3aJeDZj9eyAtnUxV6dm8Ul6cgto1sXdwZi5OHA39ALNQyWXSawsJFOomvNsQvSjAL61 78Wzpdv7AZNoRp/Tl1YfBGN1PT5+iwkfBd5QIOmOEuv+5CnAO5m60XeyngOGJMgKOjIVE5r75+6f iZo6eqAlgNfQIoUZXBDhVjN9sA4YqjeoKeheKNd7uPzq3dALlPbiVmUiNYpJMowcC6PnmoLzYE7e 9sqO/ykt+d0PmETpoxebCgbdn5VFjlzybEeBN4SeXPQyvYQrwKEUr0QaHT/ZivvZOaBJsZku8tF/ nRMvAU3uZVeGZGuUjl8DmutSKZrCusaPOMMtoC3Zpp7a3SSqoXpR26KtLlRb7Vn3vo7xR1MrkfAZ bWs71bYaecj9gEmEW8Y0Djb/lfE+CJwtE3chN71MHezoOQqce1/CeXTRTU4BzuyMlqkdPgeMMW4Z 8Tg+qo9eAtp2iKiLSWCdEa4BTdTmEIEbDBmLW0AzJ6O3uLsCBX039IKLp5u7eCERd5mkPqYBjYzP iFzbqcilWcJ+wCTG7UXSabHwgHEvE1EQXnBhf/YZHfCjtI5eRM1Ieho1kFOAk9Z09XMZnp5+8Hbf F3OOLYdIk7XmcNihL6Ft9vZ5N4J7mZ2grwFtZ2N4T42+sfMWQS3bICWTbOpv7O7d0AuUD3IYm5uo 4O5yiMj0jBy2ncphW5XDBkxmmlfc5+Ga+rYXjOy2HNbdaZ3/IPOOcF5TwxGSNBRTpj2c2noSWO3B OXQY3+Zk7Hx/LwHd3epkN4+lTyTjGtDGL3Xu+m7JWwDZkSdEsHy6WKLb3dAL/A4VXBRYNxSGPreS 3s7IYd33MRHT4un9gElEw/PiEiuqZ1y5iSyfxk1XyUdpnUvA7eBU+kyCuG8dlybvmd9AOofGoZyY 605NyWx1CWjuvrTLXPPACvoa0EiaVOe6S8LyuqcLF7eAJmNjf56DTWN0mYTzRbWMtgYF1DZK3fyU jDI6+Yxatp2qZVo/uh8wiXtq7rRS4yAYqqZcwH+w1up/dmySWhGq+MaBmMwQp9A6GRv1Qe79XjJw 54Dutms3zsPExS4BzZLGgnjuilB4DWhqvuwgPtXe4ycN/kC4f0xbU3OgVdcvd2tywccHtYyrXdlq fz4zN73pUWbe61A+M9d6uv3Wa1VWBsZF7o5FGeaDwO2QjRZKHQXDe8bCVSLiTqcARxUlb8gHhaax 3PeX1TXjsxTLPRppy8pd8meyuvZoeGYjhs2V0UJlKG6h3/DMdX7uxTySB9wNvUD4oJtVvGqWbf/U ydzD4NjtjG7WfS9BXXYY9gNm9EKT3fOvdBZ8EAh3ToSKIoEfBd7YGZv0BIx29I9TgKOhcNlqpkTR 54DGry2pTNFTreMS0A3lXaTxGS1DcQ3ozq+5pjPBle+ApqKeDK1xZcjxKe+Gnuebv3YrMSrqOcjg AmukeUYra6damR4/2A+YRDMXtLtccOC5b2fEkOaUdhvU+BFHPUqT3WWxeQk9EVECHL8mqZ2/POQc 0GxEE17n1+eXgKaahFeOuXNdwtw1oNne4vQN57rm/DqiuRrVjELG4m6gBXrT5V/EGw7/jT+Vg0Lk 2cShB/G7te/FnUUf2A+YkcMixkN1kIPA7e5kdw5JteejwJnJEA6ipZ8Ew+t2/cpZF8PnALeJuuXG idHk1P0vAW3F2ZSvJg/Vp7sGNMk4xy4rBd0CyC6c4G7o2Sbvhl4gejjtyBFcgjYHB4ZPtsBI9IyE 1k4ltK1E2f2ASUSjtbt0SJ/yIHA7q+9XMdL6UeD2Rh63AJ0cgApwcjN7hYOLHNFCzgHNgON6eai0 55eAtmuEuMcxyc2KvgY0lNu5B93fvgUQU7W98CDfFiYGfTf0AuWDiMZ7Xaluzydcc9IYKZ8R0dqp iKYnQ/YDJlGO6KE1QQfBWDLErdrpkyNOF/KPAq9ZjPjpV4biFODwDG1+jaY898/U95fcjIzI3bIm bV9C2/aGV+5ans/BA9p4ttf3JrPI/tbn4AFtJdyFbV6nKBP7fTf0AuGDhmZvM+BXczoTeTYN6VEM 77UlH0W2uYmut/vW60/k4KxzJrexCoZLRigHSDRPA3dskpMYpGQZrovr0Do52drugk/DJf09B7QV jZEFJCrUQy8BzVqLOOFqOcUqrgFd2G7TFnV17PmEZ/+YJa91Zq+tkIe7W5ML9PZ6WU0RWtgVyp4T eTa96RHPvQ7leW5VOGu9VmU840955tGBOwi8W3XKABwF01CK7rNpCfOnADclnMt3Juz6Xnb3snHO cM4WLqFFMjFuYXf7zfL714C2gj024fO8IcTdAhpbQE8i41bnpbsL7A41YxzArDnx+CAERHZn1LK2 F58Cu0LFfsCkaE1+rJeaHQTDVTLeANQCjgI3vSv72bR4LMCtCoGLWvLet/T3HNCckis5ZpZbz+bf xahLQNuFrMjvE98NEh0lS1bhlPdFInG30CIxGmfgiG4E3Q20wG4/2Bx3JMlmbT+Gidz5yK4pM498 t1dsAru5iSFGe1XHfJe8dX4D4tBGuMkI7pyoprlHgZMUk7eOTzNR0k4BbusZ7v4SvzgHDEGa6hh9 190lYOziIHYic/IwWS77Z7LsmgyRuWr8ROZuoW00b7shwMX9iL4beoHndM0Xl4Cz95P+caTX5JtH 9PayTqA3Z2sDvV76obOcK3WarjrmoY1wFlEsVseB4L+pg13rR4EjQ3Fz1iz8FODQiyI2eWFUwEAv 0ryrqhM3ugQ03ru2muFkXzIY14C29TJRSm3nFkBcDEUBBofv4oPfDbRA66B6scbmDGROyPPwBX53 M6pX931cJusrivcDJgdne4V1GoAJvwLnSBIXSGXCZHiPAudZwmIrP09nDqcAt1nYCnhz63EMzwHN 2VTO4uQLuDQGXwLaruuiQinPAcp0QHPwFS3AqhWHj8wYt4AmYnOOgZcTjR2XQbkbep57/topYHb8 giVFfvz09JH7GSlsN5XCdIm0HzCJe27WyNc20/v0ix07B4FTLh30DIEfBU7+Rbo6jgk3scTWTwGO a1Ee5mpFpPFzQLMzjYBWJHo06b8ENOHcllQZPeHeq3+Ec/Q59uxTz2O/b6FtltCc0/MBJ6Lvhl7g fpDHeCACrRut1Erknsj9KK7v7Hvxe5XHBkzi3m7CyjPc1O/7Jke4vSvA1depqRyl9a0dlZ4Q7pvE 2clB9QTGObRjIjfFo+JOl4Ah3HKayik0MvtfAxppe8dJdT3KcAugykrM7SUfM95/N/QCp8NJSa4C srdjpNiaY0jkdEYJ202VMM1s9gNmJMmKMP3aNv/i4M99kyMcwYM34SVL6ydoaZKCIl/TMeXUN2mF /NyL4Ha6Y+Pn0HhFeRjxJK1op07s27ZCfnZocnSc8OzRTNWcL/EyX+zJLfTEtqzY7nu0JuoG5W7o BcIHHQzlhreB5AfKiXMkfEYH2011MM119gNmZJD3rMJ5ClTqlQeB2/Ezf65SHOso8Nbu3c3rIA0R pwCHe2NSos45YJiyTTjKHEoHLgFtb67h3rGsiEvb14CGcXYdua9GiQ5KHMId7+Jx+UtE363JBaKz /kW6z8Gr4ZNNMRJtksyDLHzXSzU+iLTS7f2ASURz450TEKdEe/WHyiIKb9yddwo/SutUsxDfx2g3 KUQ6BbhNeChRKaypWZwDmnzcdqTyRJOdonOtS0Db/hWXsGYlSNDXgN6t7AU5mQZ9zFtAm5NTMFqm 55ToeDf0AvdDMZnd6dxdtTNwn40ycm/S0SPue0nJc79TcWznZSdWYF25x2hr/Dfa7EHg9vamBa89 Crwh7Lkzc9MA7ztDlsauc1b6p9x7NIoZr0lQj7yEDiAlsx7Pb4vRSeAa0ORmlAOyAIlDcAsgI9r0 9hS5JkTTyQWih6oyWkF6yCcQ8m9Gomd0st1UJ9tJR/YDJjs5XpvTzinRXlSykWC9kJ1WuThK66YL uRc+6W7kKcCJk2tO1ee5Wbp+Dmi70xb1NLvC4Nq+v9ypbS8iS3vN2t1raNGIZgLPu5Hy+7eItvfE sYyX6eRuoAWi+3HfEC6tXCU9a14dRKJN83nk0b0WFDxawtZ+5/UiPJpaIS0xPAiGco2s4sGyNHkU OPU5/rYhhZ8C3HJvHDMHZRndc0DbTXBQIRrYJWB4PWdJtpDGUH//GtDM1RvEcX0p4C2CKBDkqIGr bY5Ofzf0ArvpmCUKInfwj/Fzzo1NxnrEbi9vBXazgXR2vt9FCYyFHHXT2TFlcA8Cp3zTn4pSrz8K nMtF/Dal2vwpwNm/QrDR+yjOAUOUtvuDZufzS0CTlJFZuDIF8blrQOPGZHy6y3cLGOqH7Nx2LreR Fu+GXuB5UM7s9nYqItKw51EPXgzgMdH9H+IaWs8l7UdQithceKTHMQ8K4k0CE036qCBGKZyqlFh6 inhLtsnOJSacI4hsmwjur2eIDnSJcFPIyB1SUqvh/BrhJpPgVW6xF1u/RTiTMvfy4M+jH0oWc+/g 8zTbnzuVrOLEGNvpKYXP1iI8z8hkbOhiAMKzLILh2StCBOwdppUXIuqjUB7xvJ4HH0m2qHMd7Ee8 bX/yhOmTjbeLMLDv8bBvL4aZ9VjswMM5VkuJPTdIjp88ZP08HeHcP4DkIqYF+b5J7sm2rH42T4d8 D7c9D6vYkMeCc1BLnA8nLe0EIP8+5Q55KhLOCdOPgjhHDKaci4fBeQ9Kvm2zj5MvxWDhPOKpKmxz ffJ0wlY8lTe8EWPkZCqPRjyrLtI3TXxh2nfCioARX2ZnYTzewykGQbd2BaoyJJDu4RbM22pSjwHX HgXXzBAU343GPCUd+BLpw1lMzgMSXfKyNFukkG66z4OZmxqaKel59u+n7hGUSOc46iQzUxC7Ozxh Zk78Ce/2UhTjQWaWXWW6hxnxeDcV+NJRiPZtomIS/R1zYpwQ7eFopNxXkc1C4xFEe7jtc3EZpWt+ Eto9nMJBppltfsIp48CXGB/0M1b/O5auad02y/iMgFaspwqa5ke4uReEWGZgvrylKX2k87h5xPN+ T4rA44DAeATBuJ93tRPEc48nG+adIP7a59g85Hs45FcIGWmYlE3I93CEU9uRzZFMzBXyPRyFnKUf JZzjiMiA4O4eTvbG1TALi+0OvkT+oKmxgmCGyuWNOckWd58R1dCNpu4ubgH5UScjmLG7PT7p5OAN 5Ec8hUe8SXvJ8yOeKx+5dDKyCfkeZORz2aeEXij3IDZCKEN19YbCIZR7uB2W2e64OG78ZE/qwh6U e3jL5aCYa3YCaR3KPdzelMARMjo0fMRCmNaBL1HeS2mctmd7x110nHsplJuo9DDC92pTnE9UTWOH vzOMFOKtbEKGG6IjiNeWcSXS+IATw8DhI54VHwuYjM8ZypjAeTyclyTwMsxw7kG4+Y5Y6OaZaEdw 7uHGOX6Y1rkac+Dcwxl7Clx0gQPTHsQtZWxgcTHxaPHSY5gGvsR0uqeMY+x2w/DwmWXaFKOHTPdS UmRa7A7v9oITOScag7tx+EHWHvF2dYZeGg3TEdTwkhB/2nLq3R7PZM4Le+cNCc49HLXcNmXT4kZJ hHMPb1gLIW7k0Ry924OYze3SBj2sANUexfoMpYWlajQyGAa1xHDvVrxnkis6uC/+WYZnVDSuoJiE b2bm2BsYFiGNOjktlMOXI4jpnZcXxZagNYK4eIgTIGPvJw5P0PZ4HNiidnpanYKh1cNxZeqG3Nmm jifI9CDbPeQ0du5DngFHWj3ckrTGXu88+qbMdfDr4XZfBnVJ2RTFeSAa+BLRg54G0VQ4uwNUEqtn dDRmzQf8yiPCr0hpvOVb7xCF3wiqbEcvU6FGA9URz14Xa8k0bJO6lIhnmHkNhtoPBPtGrcKfktGc AovhQrWHU5BC0ZXbFBMyiNUezsILlYl4HW0YhgOKq2LRzN1rBiIchoEvMTwoaV1O7KpxM0mR6mJO Sev+EBUWssDYmz15VJyW2er1LMqQHBTP6oeAFRs9KshecOzvdJfodop4U0uZxCVUnCOIxY69bymr KdKHS4STfXNL2TprR9L6NcK58MKkoJxJTDgPw2bvrLTS4jxhxAG5d60vcE5r3TF6K5ukoDr97izn Jus8mqCLXu+JE7TMjXDuVSGboItwqeSU84gnK6NEbDZIQ3/EkwBTH5E9XdIX6Pd49rzs/V85a5bu YAgejrzKvqVrfWoIHs6JvU6ZSb0RW8QQPNx83l6HIeZyiyhWX7yO+OHbbbo5A/5pdIn/of4MhYBN nvxj4unQ+ph1+4N6em6l6wOs96iUgLOI0pPyuHcEdQVdKV+caCZQHfHsPzopmkGOjgDVHs/8zZkB rX2CYA/CJzhZlfcFdWLB0z2cIUQxqXOuJxEPgj2c+dverZIPPYi1wbSH26Y2pe15sSqBAaaBLzE9 nM/ktDbVcrmUL5uhcG4Sz0NP77Wf+Gu5lZFzrxDh6bx7wuUMHQjOI6gk/8nqzyPOI97eOePuC1PN DM493lRz5NEcPmTAYd/DkUGQwNx9xgKHfQ9Hu+K2G7e9IQYI+x7ObdH2fvvZxR3sezhF5byTiOKy MXpIJIN94Evsp6OatPAwVxL2TeN5yH4v/kT2pTd4vJeIYL/lAM78dgiGEPE2Ebl3X2h2jfNHfMPe Wc6Dpzf6RzzOzyFdmZtg37fJPTm8qcppmuJusO/h7J3ZNbR5lpcRgX0PZ9rGDJmbRzrFWGDfw0sE GmLL/KnNDr7Efq+x1cwWvE+tSiEqP5Swb3LPQ/Z7HSiyL52Hfa8WGfvsGDubE0eC/YhHZHPvF5ks xWA/4lkD81Kx2ayAMODxVtnCVk2cHmDfY6hn4QtX5pQHqotcsO/h5HhUP7jVo8Bh38OZ2kmHcYd5 9j3cNlSolsjXTcv44fvAl9hP16Bx2wOlEONI5TEQ9k0Cesh+rw0F9vU9MbDvFSQeleNhrjpbJ2bY j/hqy0rUxQoZS9iPeDbRrIAifST7gH2Pt4W73dwwjoGGFgzBw1k0s2et1gL9HsTCHenA7brlge2s Bfo93DI7vD/HQ+ET5w9wXtuDOstNQMNH4NAPfIn+QYNDy+sOzEzbEfpNFnpIf68XRfqlN9DvVSVz foZPYi2cR5DdYOa3y6ecRzxbp7zAY3yQyVYrnHs8Hm+7kWIYMO1BMM0qLdebPUj2PJzLGGz7O68C pXU493A2VaiOmlzRDNUeRZzH012xrAwuVANforpPsWvkCN7Cm0c0G6RQbQrRQ6p76ShSLaxAtReY oJpy+5yh4JAxxsJ6xNvrOtg6Sh9pH0+PeLvWPNd9PNgwD3hY57Zk9zJvGUz4983bkNF9sVQ83YM4 58XmgTt4PE3xPRw6GROnQAsc+j2cQG9FJq5QIw4g9ANfor+X6NhXoc6fot4xJubkXOg3+egh/b2u FOnPRjSm+F59QjSyuyGzQzygP+IRI/GgsY+sjePTQn/Es2Rp/S3IQhVO7/EEesqTnFgwpd/DcX+8 f37tjyF4OAIeZ6znb0bF/T2821PlVtc5mQZD8HDe1IYQTPVJHBH4B7XEfy/g1biivbc1rZ5zO5H/ ck7A6/4gy3qt/9zz9JjPjy/Tsh6J0t1qpTPrQfH28hUXQKf8S/vo7agZcUhOsVGrMUNQyjODwM8R bq9OLf3FZWKClwgnyWeSd5mstH6NcK7g4BFdsBCDvUV4VyNF/XfawJPO3Dv4AvsMV1cgx4UwbKqm cRLKTWN65PJlLz5Fl5ceQ7mXqGxy5zSNzHzwHEF2YkBfh3xUEHspdDoHgxyyumADz75RYjtZT64H U1uDZw9HqaOQiHsqx092iCGdD3CUOnaDXBiWJ4Rn37oJOSTWemUR9HoU+g0voqFsb+yDGA/0Al+i d1DqOJnMOjPLRjksC9NQ+Zhp+4M6tzwiTPeo5NzM1JV0GaYjCDWLpdv4gA/0G8GbYOLuPJluxAS8 qfO8bsFt3CQb71iEdN8dW8PxEsHcG+k9zu3hdqEax5tlHKDag4jjmPJ0JzWAcOQNdzPqC5UgmKaW CE4CXc2GVr6id9aVTSB66Mq9chR+rRCHgmCvLw1lUEn+nyy64TriK8RIXxGbe9mRgYNHvF2F47fN pT84uMdbyo7aJWzAsAfh1og0m6RmaBSAYQ+ncp3gnZIi3tAS7QeuPdxW6UxnLgxEOP7t4eyvQrna D6QDWiI96XLsnqP3j+aaI5R4telCD0nvBaNIupAC6V5Wsvht5yvjc8F0BFVWv+4W5OJHMB3xLPg8 XLMYmPZ428Xm/ubxuSeGB+f/n7Bz67XjRq7wXxH0PiOd6z7biAeI7lJmkAEGSJ4VzfFYiOUjSGcS Y4L893zF7matWs1m9oNley9xd3NVkcXFYlHheDWVDOVsvi0y4Fzht9gRFShyk2bPucLxbyrvsIda uwSqFYUY+zxKZkyGcuAz0teUNwo+6F2yxnRoQEOmF3GoMm3dANMqIcE0YtY5u2EfnBueQGRXmx+m a6OUMyYV8pA6mFZ8LMj4C+KAtZdhWuHUHGZj07do4FdBcUUjk8JhwIdPKzym6ufkYfRxzmwZohUe qjt1eiSYamMbTg1qxu8quIWdxAHV/p7GcMg8Q4YX/acwfLlLa7tUlQiG2br2Wi/4cgWxHg5c/5ih w3DFk4nMOqLDfciEYcXTuwixHibAq4IYJ1mc+L0P8Kog9tIiWko93aYLeFU4YzV78lT46j3diIJO RbFZSmIrp1AqCjpBzehcD4SS6RoHavrfNjZDyRmyuUg8lU0zPPxVhSDYjFLhEuqYf0NsxVNL48QW W//kU27TccVH0VG52dTv6oRYxeO6LNauM9RsjUKsgtgu5ZIm3YTtPdXgUKzwKMpCmzmxWOtQrHBc l1w+tmNro1CsKCrxcKaEw2RbR1g/wDXwGddLwHsdxRnZtcrBqv+ssR4CzpD1RdmprOdI0HoE1lX/ ifmY5eiU9YpnkU8VnByArX3cueLZKCHJJvHW5bCueDZM2452x5vRwr/COcZ35nRI73qfY+Bf4XEe +IJSnL11exj4V3jcDkXG7J5+BUUQFik/qUJ12lqHQz/wGf09yY3zXkyB28Plsxn9IdsM6V/0nEp/ trLRr6pPTNKsEYxDPL2CUJHZCK7vBdEVRFUscke2px8I5AUP0Sg3snDbE63NRwzGwf5s3h4ZohXO zjh7OlLayHwSohUe2yPc95b1b+1h8HiFs67mYDvrre1l7WGgHPiM8jXrDYWe/VgZXyrTV0daWfvC ltNeIe4Fe4MYimhlca9Szm7uKi8dz5ZtvdXP+bf2KV5Gzu/WJQz1Ff+6th+bYhTwN9CbCor1NIlG 2ah19NsKv446fORbbAOxv+K7Cof1VqDzODIrbxhiGdc95nrJjORDa33COq2tYtkpzjP3t8qXMvpD yxk5+tUi8lRHt56EfpWCwtFZO1dKoLxi4uCIawivHESJNaT+5NlGGHjWRllrsbiRinkWVcC4wpuf I3PXB4VnBcFz1PHqI6UvwuFZ4TGNkymR2/VG3PsKJwInvpdDgAaHZ1qf8byqZrdkPvDpY1a2YzxD 5Jjn+MLd3CJJeF5QXTW7YWkr4bP1N5xXfNytqBcH5VO2CQP6K54qvpnIhadZ/Av9iod+gv9rewhI V1CE50zjEoTs6Fc49LNDrsJOhUO/wklvPZGQezgqQL/C41ACidU5itjUAf3AZ/T3s6RReCQF5mzH 6A9JZ+jmi9ZTfu3Suhv6VRFqbr6/UcZBrF61IpaPk3BeG2VZTq3ZHFbNBuFc8XC+qwIO4wphVYTo IVaandOsDodXODIaMm9uLg0cXuHsgvDJ08AuB8G4whnYWcccJ+nBOPAZ46ugdoGIz20afcctuTLG Q9kZMr5IPpVx6xoYV2EIFZXUFQmAnUwcvuI5bgT71WVgvIIo7UIGeX5sdoFxxTOZs+nkx5jgXEEE O5Q2SgXLSYRzhbfDPZII6yTi5QqPyTxKhOUgUt8QzhXeonam8uOoPeAzzlc9DfUuyuD0QDaHT+M8 RJ4h54v6Uzk3euBcNSK8/IojYQaC6ApC+kJ7qd0A0RXUks76FLWTQiFa8bh27Ljnci5ft/ktlCuc cwvIuBLlGxzKFQ7lvJfYspk+lCuc65dxckmAtKgByhUe2cxcYHOV4VZ7ZLwb1IzpXoSNBQupFZtT 5LsY06H/DJlehKHC9NVOYrtS+SiYRkyWLtmTXvGAZ7dEwn/FR81R3aAwe4F/xcM/qSXWg5CuGA6e kZUqxYgMDukKpxw2a145hWNwSFc4wRz77eTIV7uGa0Uhu0EUFxzuydpIBz4jfdXfOCF+Zre+jypp kUZ6KEJD0hepqJKeptOeBvdWQQnSWUrV98O5K+SKm6Zkj2GfyWB4hAXJUdhfXlDbj9V5nFerDwHR +hBcWhA5gmKcFQ7RCkd8o+RDFsVyYReiFc6+CNvTLEEPKIRxhaPCRYyXQnMytTEOfMb4qsLdsX1D 2ZOkyIgO7WdI9CIKVaLNliFapSOIxpAlV2swd1d8nFwXpWnAesVHOrmsk9xr8G7FM41Tt0vT6Sqh 8K/wOCzOgNp9w58e/hVO2E4ui+TMZ3jUGIJ/hePoJByQFVGfAdoLiv0sEjP7Et6DCkZ34DPaV/WN XyNozTtL8+GM/xCChvwvClHl39bG8K86UuSvIWvVF8TTK4alCKVOMvjOJ2vdxohe8WyEMqlvXjPy dMWHxE3ys+TE1ceBc4XjlHFmqzul9zecKzyuFaFo7eHaC84VfhcrB024s4UG5CucwJ1by2cn0QI+ I3/R4a5O6HCooL0Tsosr+ddHglz7wlbqVzZFveCoOrYjghxFU5WoHHIasS8dH8UOdbCwEe6V44lU WBmkIZgnva54nJ9oW7Pm3RDK4xPNM/14gvPb2ibrNqqYZVqJiwXvKpwYnvxZIpj6y+8NFXFf3FXW XaLCPzT4hHXeY0taY2tSTsgb2aEhjTz9ehGXqqfbfA3ZKkHFSM+xzeTC/QayKx4xPW6T6p892RV/ hxqtP2DGBNmKjyAqqpv15nczfYGjynF4RFbIZkrQrq2TSko6htR9TX9aR/oCjwwn8mYnVQUKnDge y6aYydab9qrwz8PM+O/6HE5PfufWTr6UGQJMjw0hvnCvtyELQ1hQXZ+LSoJmLbBfQUR3JBsmO3v2 K55EnlkcAfuKx9WjVHE2v2df4czz5Ckf56DCvsJj4R7pEb35PfsKh31y8pmAqhfj9Ipivc6Jc0Sg rVXrEUgHPiN9zXSLipNczNEXBoekh0I09P5FOiq/dmWvCOkqMOH9VL3RmgD2svBf8WgphL7buw7y 1A1PLaVSodWMEP61fWIdVhheduVNBSFssI7zHD641pYiWeWKK8D7k1pHMMArnCtu+F1ODXf8jnSF s4ojYKQuWEXBNagZ16sedxcngcQQs9fNwUMZGnK9SEaVa7M8uFZhCa5DejxOLoPrimfK1Sz9fUxv eOq6SnWkXUohXGv7xHeUeNGZpHYmrCs8Kk2c2LHuBNnbwr/C2VDnPDE3QvRPbR3+FU51ZY7fyG0Q Zi44vcJZ05GRcnvu05Q9DIYAfGYIq0hHUhSBxW2ffw+dPvSioSEsQlI1hDSnNqthCCo3YQgsvfbZ UQbiuTjAvU1Bu11zgrraKLOH3sy9X9EVPPM8CcmXFlDBuTbaCkBxt0SlDqYVBNPU3PMkAPhVEAkT iAzHbwO/Cr84RbxHHLm9/n4mBz7jtxd14462rRH+POQ3NKIhv4t4VPi93klz1yoxxaDOrefWtXh3 BZHL9zx3BHCT2svwW/Ekp5BKlO9iXYJ3Kz5GcnLe+2zmYSVMK5wxnYOrXrsLphV0S0kfxP9s04Zf OFc48zd5HNxRV18MqhXFUo17iTiKUFF4MKgZw6sOR6W5qHCeIVFvx4by0ISGDC9iUWXYOhcPVkkJ hpebBTsbhofsikeMJrGvw50NyK54pJYefcbfsvYhW/HLUO4WBMUKIoWV0fv4GSBb4Ygyt4yiffje i3IFzu0nd9QhStswc4Z1bZ2qjcz2KIlbl9gLQj/wGf1L1MzpwqiGLYGAsR6S0JD1RSuqrJsNwroq SrDOfOnSJ1RXEG7KbZ3be+2og+qKZ23NHlni7SGgWvGhyrBDakMyVCuIVVncpZcPYW1CtcKJfJkK kHq2j8Hxa4XHqoxkF9aJ68e4g2qFh/6KGiyBRvfQNjtCNfAZ1asQF3MCGwK5OuntGOehBA05XySi yrkN03CuQhKcszWktTTtZaG/4lmy4DNb1+iM094W+iueXS2UyMRb+9Cv+Dh2dM3yvOMNjiEoHJ9/ zvonN+gtTsIQFB5TOcuLHHn2A7zCMQSenXOg/dMZae+KISiclVo7K3EU42MIwGeGsCbHRcG656iH WyekuVZDuDkS5doXtjz3zKIX7NxiRyLKUdlvUrX6pePJG6AMx/aMA0Ow9sm1Pck05vuzr2v7xG/c /u21IN5UEEvja8qLyCBeCXpb4azZ4kLbnErNWt5VOEM490TkvorPP+8rnHGAUyrHm0IfGnxCP/3V 1DnaQQLJmSZdwOgP5Wk0DtwsklQdByxKgX4VrhgH4sLJNF1/Weiv+CgigYiUn9r1rxx/iiV1jm2+ 2IN+bT82ZAibBF+bxxAUjqNSzkp22Gx2xhAUHhcRc04pHdumGwxB4YwDVAMjUas+A/wrCv4vOMGR W5NmXfAPfMb/qs7dsSHD1kR/92zH+IfgMf/xhbu/vSL8L6iuzrF49xgI0iuI3ECyz9Ln0zTXwd/w lGgjESNtxB4C0rX9mPsJmZIWYxHSFQ4rdPaxf0K6wmNDm/u+0q92g3+BI8nHFqwkGO3Y19YjR5aV mGepQTqoGemrOsdagsPrufw5HPNDJho6/aIflV/zCywgXVUmHplh5twNDZ7qO8J/xVNHm5zGCsLT KwgRlBVzBcG0gmAaSTMz/j3+h2mFc9jhOdONWQ/8Kug2Ks6RhNat054Tp1Z4KHLUbblI71rn9IJi To+N27yy2ywefml0xm9X5NhxuRsVFTOnDhloyO+iD1V+7eHhV1Uk+CUj0u+BgdQKInuAwp2920RD 2Jy64hlnqdKUeBsWoVrxHFPjdIRM0WZjUK3wOFNCMn2af3sGqFYQARLlJCUdwCwDqhUerswO/K39 MuO3ovBg6r9LrGrPANXAZ1SvmhtHKpjAc/8x2zGqQxEaUr1IRZVqe3ioVkEpXPmOHIlkxQwV1ise R7nR+j7WPl5d8bHo04wHw8O64onjCfZ8LQnXCmKdRfhugQlUK4a1G3OqLIrsd6Fa4VDN+RSGlj7n 1HEIzhUe++hRfqKH2tZrcA58xnmv9obEo3Wu+88a5yENDTlfNKPC+c1Oh7tRZSlmnJNe5umjKJxX PCkJV6c0x829K4iUZ84J9v7znWuIVnyM5BwCs36DaAXFel0p9OAPzhUet95xPiXjjP1IrnA4p8b4 pdkRTCuIvVNWrhc5ZtjQCdPAZ0yvehxrDrYVRpVhjemQg4ZMLzpRZdr6D+9WNQmmsWmvhAG9FUTt AOKzZM5eEZeueFRctJkcMqwHYVrxME1h/+My6nCucDjnFOutxQEwraBY6sQqoj+DzSV4t8LPSKm3 nAfvr2itw7nC24KcNM8eVVkvwznwGedrZhy5P3GSMzd7jrw7dKEh54tgVDk3R4RzlZWWyVsrn9vI B/0Vz3K8VHizt4X+iucyRc6h9a7fn0oueAR3rqbXgaF3QhtHoF+bj6U5bmIEQb+CENxD6+vHBnxc gH6Fx+BO5UK/LQ/WFRVZEojyk8r8AZ+x3o+lct+k3vdhDh7az5DsRRSqZJthQ7ZKR5BNWodu2O7J rnhCpNjg6p+9r1f8LeXcvIA/Dq6gGCEZdM1s4FVBuPUNznC4RoNhhUcNP9Y1GV3uh3KFs9ImU9af E4IVFEutO7ShozketwY+I7gfQiVMYw2wuUA6ZGX69khna1/YQtvPgrxAx8NQRGeLa5jE7ay/Xzoe HRoj7ET7Gu2V45njd0cZX1cQMTmJ3bOMt/LM7YZvrTZnj/y2tg7nPIIvrN5VEEM56RMpluzFlfII OHWkQ2Rmldn7h9b6hHNaC3HtiqxZiiPlMJbtGOch7Yy8+3bRfKp328wJ56oMhXdHZZNDDuG84hGz MvOev5ZPucZshj8xKKp2a14G/dp+C845m5rP40N5gbMEZv8mE4d8hIB+bT2it1iub17l8wqGoPC2 Dj+xF7fhzbjeVzgq2wldJjMjbKDEEGh9ZgirysaGHms96YTeB2YIMD02hPjCnd8WohjCguoqG8fn /fY52K+gS2IW0kf7Z89+xcdBI6mc5dYC+4rHk6K4g5nsmwpCW8M8vJQwTGtL1AOiAo1cgmZvD9MK Z/pmRYio23u6GTMEKwqCWe8xz1cUvIKa8drT3C6pLND37kTNMF5DDBo6+KISlV/zOAZeVUvCwUlN 8bgEXiuIZHZuqtzsfLBzanhkmWIH1r3wqu0T9qAws8mwfcyRYFjh3DNPaqvszBkcrhVOCWZSAmT/ xh4GrhUeW2dxs5rFf3CtKEb1OJufsmfOwM00IB34jPRVXUPb5YRlrhjTeIz0EHyGpC9KUCXd/A7S VS+KKIRKl91L+ZdqsvBf8WyYsElRQUzfFcQWooY2A2dWPDEbhMvesz0DpCuc/dK4TtdAUK0g1DXq fMm5NLMMqFY4VFOI0scTmFZQFPei5oUv0iEY1IzgVVOLqxFxsW7caShGcKg7Q4IX2acSbP0AwSoO QTDrVykjPCC44kNTEwf0iRKuK/5EiV0tHGM+hYMr/iJujWJTLC2umhJcK5whnElbhF2jEdYVHhmH XFbSe9jz62Bd4RxFwHPzTKjP8vCv8LYUj5KfB4MThgB8Zgir0IZmGJNd74R0JzOEEH+GhrCoQsUQ bndC261qR4iEhAoiOwwMoeJJCJldkoEhVDyXkEV6Y//kW7VxEENQPPEbpaVytHM7wxAUzpqKecEJ gn4FRQ04lmmpxKSHtUeAfoUTRsfklHCLOKFf4Qz0UE99q2P6gc/oX9U3FACSvDI/5HCgDx1oSP8i EFX6zTMYB1RGinEgCl1Xb2N0r6BLEpLSLnezAZxXPApFqRpk7cO54oNz7nQ1EEwrKHZESTrL0Nte DM4VTtk1Vg1ysMrGHzhXOOcSEYx03VB7BM4VTg47NSGId485Bz7jfFXfoj47oUoKm/1nzeVDBRpy vshDlXPrSThXEQnOqRQiKWPuY9Bf8Qgy5Dx3D/YhAvornkwkigge4qFf8eRDkJpn0RTsK4ZTydxI nEOsPzLsKxz2OUzkixE4V9By6Jz/1x+0d/4WvCs8ij4iVfv2HaM7qBnVq+QG1Ryyz93CHAeN6tCD hlQvQlGlOgeJ9sxQrXISVFN9UHLInDqorvhLyoh4Pi/8VhCVbSWHY3BYoeBZlDH9er9BsDbKQvyO MpK5MszuaS8GwQqPLBfuK7S3h2AFcTlWVBGUY7A7ghV+eWKvpV3wsnq1uRFMA58xvWhvXJqCThUn A9dPmnZl+nSkvbUvbPktabIr0ysql99xeVB9w5coG1hTCnSxYSD6gpvDK8eTVsKhvG2U2xVif13x sfxG68iZ08boNxUex47Ja+iD6N6py9NTghltRDZUrPV3tXVid8yOHPbaJe8riiU5aqG8ojX6ocEn pPOILbPtxDKNKsMZdhvXoQuNvPq0CEbVq03AeHGxojauiTeoAVBfDK5Ve4qNQ+aVdKgB1xVPaQ1O 4iXXFvbAteKD6/1QAcMKwqs5555jnj/D2wpnIcWuhIqJ9RVhWFvn6kMqlXnqDAQriJvnr8/UzDka 5SEY+IzgRVQjW52Cz1jr5tU5QBnTUDlmOr5wrzYSYXpBbUwT8lDmLEkx84T0ime3uFx5Z2MYDl7x nPoniTnb35Ou+DhOHtWetj5wPqFf4WyoMEpzxGP7ZJ+tg3qBo45FKJSJHvay0K+tx94444EkUlZr wRAUzjKNfSJKAlQU/IOa8b+KbyRqMVqJJtLbMf5DBRp6+iIPlV/zPWT4VxEp5m8Ewyn/Fc8MxhHz rb/5sz9l63H4r/gTgZ3Q7ytjnF7xSDJRqqTvKvmIDf8K59zhmcWfjWY4vYIYgCMpKt/R5jBYVzgZ pJfEYX1y3W+uFPgF9RrJHcgSINYh0E/rM/oXGe6KxyTjLM/gpG0a/SENDelfNKNKvzkE9KuyBP1x MW12t/c37l/xUUpGDo75whj6K54lj5q0a5rQr3gkTdQCVsf9U60L+hWOw51JvE9mzfUwBIVzggG8 V7yFfgURtFN9Eb2i/jK+rih8/Ro/yJxs62dYBz5jvZ8xZRtVbqE4ZD0EoSHri1JUWbeHh3XVk2J9 hgjS+3jnxLBe8eSP3kw3zA2PfqN3Hg2cXtunx0l0lgu5shPamALrCo8sR6LGZN3gsK5wBn3Ojgw3 NVrr8K9w+IcQzc7fGYLCI/Exps8+a1vXYwjAZ4YgdeKuSEHZWEmDMvcPaWhoCItmVAzhtNPmTqos YQgRcYi72dNjCBXPNgY322/PONhbNTxHcSKLPT+1M3F/bZ/Rn1qMctusPQ6GoHCWQbg/GyX9U1vH EBQeKl1cDtDR1jqGoHAM4XQZWTu1UQYCRUU+BQJXZk6bMcI/8Bn/qzgXNz7E4Nd/zWgPdWhI+yIb VdrtIfB/FZfC/0uBA5/Eob3iuR1O6zH6LMGoX/ERBeV+w2hVp/jQNykybpEqZCuIqR6dwZPyoVhB XG9MAQxJbrE2oVjhBHgnDh/mPp71G1wrPHZXL0nM7fGjweEa+IzrVZSLW5jZ0Onr0kPSQx4akr7o RpV0m/wgXdUlSI89aQuVYLqCSH/BvzNct0ZhuuJRVftrxN8yPA6ueOZ3VAs//Q7TCoqUCUbNXFjm ULgF9Qpnc5VBQ8rO2iPAucKDc/T8/cVJFXUmZYY4Jx+i+2V7Bqim0RnVvUAcxT9xgK1H02TMv0Mo GlK9KEiV6jSY9jRQrToTVLOSuLNug+oKipqseurLhkOorngiYvJNaz/Ar4JYvnEn8KX9MvwqiC1P Al2NP2qb+LTCWbNfcHdI7q3Zy8OvwuH3fIeqZG+DKytqceVzJtrYe8Ev8Bm//bgpW/VSOC/bqfze HUlx7QtbtJ9sznnB9gXmkSob1qdS5n78NnzoT07dK2+UOxBOpJr3j/Xz64qH6th2y/dtlvimgnBl BtiMkv1B31Y45RrO3GWTE7pJa+8qnLoh5CAdH4R6X+HUDQEvFczNTD80+IRzOrWlwXFZMkeD/v+6 MHchE418un3hnNvIDOeqMuHTKMeTLbKXjqdaN4+YwY71JfTX9rnZLsbR/rHngX7FQ3/cod3DVWcW Q1A4Qg1SrFRbyXFwHdMLnFCN/R1J4zKqMARtPYQaIo7Yg18/dUTBEAo80tdYoOUSv8IxBOAzQ1jT 4JhK6LO8Vy6dwZyf0XtsCPGFG4LFLBjCguqKHXU0p4eVDM/NSzjh1jO7qxcwhNp++KusrvZTesET Jbc8j9qF0K+Nch8ZITLZM9vH+GQcUDiSCgO+ZHvZUAT9CmcbJopKyoZgfRjoV3go8tw4k5fOJG3r 3B7wGf2LYHdDNIMVZTiY7Rj9IS8Nx4FFdyq/djI/hX5VpxgH6Jtc++4S4RgHKp7QGpG0j+r72N3w mAo5lInPt2q9wzig7ceS7cxRkI3YwTig8LYLl7PuLl7EEBROOizLO3l6GzYwBIUzDlBJh1SnHf8F dbfcCtUjCmsU9wc+439NnONkJBFipvMnc8Z/KEdD/hdJqfJvDw//KjzFPMB6+phP+K/4EGzziqpd j+P+FY/7Y2HJ534eUHycUEVeOVxUMxAoPPKqKGVR+YF0xXBqEco5XbV9jB9IV3ik0JFwl2fTDY73 KxzljjMYclrc7Bv2gc/Y78odOQvnLGKXL2Xsh1w0ZH/RkSr7FrbCvqpNsI8mYU8M4xUT1Un1OEw+ WfNgGK94VuvoHFtvD1brBR/6GGeTrJfhWRvFzzkb71vKEK0gciVJoJGhw0wfohUeye4359lqvcAv YxYhKMj2q9VBNK3PiF6UuRtmeU7M5C5QdqcRHbrQkOhFMCpE3+2UuTuVlYJoMpJnJ10Mj4pHvFRf EaZro2zGaH1QL1nB2K74CPGppLlnWkGkQnMWxXUFmFYQgT3CTGTbrh9rE6YVzjhOqRlKhh/AcekC 564m/o8v6SEY1IzgnhdH1gIbfduv5erLCA4xaEjwohJVgu0V8WTVkiCYUcsne1y5ghi8S92fPcEV z6of/83BO211m7wVzxY76/A8PeKxAU6t8JAomRu3btqFHpCu8Ci+x1DUu9UDSUhXONvfrM5kK9qC PkhXOEXiIjIYFYXYojjgM/aXeJptdwRDuWAgu8zYDxVpyP4iL1X2bYyGfRWhYJ+5IyvHQ1j1XAyh 4pdyUYfE4ukVT64F3CbeFhV4uuKJ4iifxqSxfcx4MQSFR+1l5oAMEmzgxhAU3rKk9IJFexgMQeGU jqLwhsjHyUhjFkNQeKTNndlB65vM9uwMA8BnhtClOjahZNGR7ZghhJA0NIRFYaqGYFaMIagOFYZA Wo9ZC+xXUJxh1DuQ89G2Gb3iOYNA7bWNzF3MB/uKZ5xndZaj7WAYUHgcWZjtBsC+wsmkOxO05KBk xgL7CmeW52oGzuJ3262eAfsKZzGHEsb9vNvLWtfAPvAZ+6uQxxxCIULZ7K+kn4/0u/aFLeG9ys8L TjhhM6LfccWjjFx77zc8vXGZ9W53fL7y9k/U+5Fh3Ql9XfEs4Vmcyz0/1odvKhyC4g7ew8HibYWz 646WL4cdrPV3Fc7cz4YaKf1Oe+kSkq5I/FJ9q8I/tEYntNNay6ojJ57QV2qx9XaM/xCQRk5/XpSl 6vS2ZoJ/1Z+a08uBq91E+tLxrPiQUTcTH/Ff24/ceF3zZUSzhgHleSJ/FiV3soYr8DgSIbszu01g +NenIQwgQ0fS44xZ+Fd4bLtGDpCNEu8riuCey3AR+rc+MaOCfxqd8d/rxbEMuOU03/rJ4dr4h+Ax //GF+7+9IvwvqJTwmP/NSCC9gq44BpKr2p2R4PQVj9fIpLkzEpxe8RH7US3KLANXVxCpFlgGJ5i3 j7EC1QpHWOPsKRJ7/3RvanYH1QrH1W+Z1fZnWgsqdthZ3U/WcQGfUb3IdZxex8LjCpj1k2GFUR1i 0dDVFxWp/JpfhwDVqjXx7OQ36+LaDBXWK55hFVGx9htUVxBH1jl+XUHwqyAmdZIJtfZBhcO0wkml uqaMhv0w/CqIfWvS7bqv7C6Jgl+F48oEFiRdbM5l745PKxyiqZN1m8ZmMTE+DXxG9KrLsSQlOSuj 6zRaIzp0oSHRi2BUic5Wmi1DtMpKEE1Bhtzn3bkrRFc8N1CRZL11zc5d4bziSbUmLWkzXiaEyif0 K56uJ7NPzuBY30O/wkMUYzTow6mv1TAEhXP8hVuopL5O+tLm6ApvOVWRJF0fGf4VRSAf1zNT7GH9 WI/DP/AZ/6syFxEny/luSNmO8R/q0pD/RXaq/Js1wr+KU/CPcOpn/iG9guIAcSzRt48F/pBe8Th6 3I3QP8YipCs+smevKNN1BId0hUP6OepNbv3tcy6kK7yV6KXgW4fvSVd4eD8pTS5xQLqiIB1Duk5T SrKaJUE68Bnpa/4cqjEdlXvH2Y6RHsrRkPRFUiqkn3cq3VmFpyD9GhWn98ggkK94+Pcri+C8YuKK a1lb71NmC55eJgV2uGxtHQjn2jycUyJS1OHspwaHc4UTvLPFcRwAMOIrnBmdeYm0gJ2jKypyJsmK YZdh/ZgXwDnwGeercMehbmrTXw7WfsZ5CEdDzhdFqXJuPoajq+4E51ya1oOIoL6+LD5f8Ugr3F60 vetuYoD/iie3gx2KtKn9PK/42ITkUIMNrbCuIGZ3zuldZ3C7ca0guGZNJQt1+2G4Vjj+zTuRGVhf H/9WFIeXOa6FGtHfp8LhGviM6zVnLg7EcpS1xxL5LsZ1aENDrhfRqHJtlgfXKi3BNUGRuvee64qn kAYHF5Nrax+uK55E5riWuH/yrRpDjO+KjyNRcfNP70t7HFhXOL7OKoOCXttn7+sKXwrDIoFtH/Ni +Fd4iPSsm1x1h39FxfjOdvUoWaa9IfwDn/HfC8oxSVzmMjLfxfgPdWjI/yIbVf6tv+FfxSX4p5Lm nP+KjzxgSUhy4QX+K56Al/vpOv0edsG/4sPXUbty89d8D/4Vjtfjn15+hxFeQVxyhdOfMiYxk4V1 hYfXU4liVPqp8Qn9CmeoZ7ohtX+zKbNY6Ac+o7+Xm8OIKA28dVUSV+hneBjTv3xh6/SzjZovNlRf p8fOsoFeOoghkNB8e7D9+O54iljFUqF/8lUWn6/4iOnYs6uj5puKIbuKQ1a6k1rhbyscyZT/4eUQ 3lVQTOWkRsvhgNrme4NHhfjI+T4iusGPiY6vW3LdieM3jIo5aPWfNaJDNBr4OWe3+MKJtsUSRKvm FHEcick23kF0BV2x+TU7/OB4VFIOx/cO2QVyFQ/RrNd1z6a/ebMLONfHiT0Yko/MMGBaQdR747Tr tQ0TMK2gKEcSWZpHBgnTCieBAi+8zcoXORIvI3qDz5hepTdmMwb/i3QvI5iRekxwfOEEW6wCwQuq e/Kp7O34wAzXFR83L2g2pPXzK8fjgOh1ybUZ3OuKj4mc3csMiqx5uNbHQdBgIspiIP70sK7wOF7A KZ1cBtoIA/8KJ4Hm6oS20PFmLvCv8Eifi4sjrMc/NNSM9vWYK+fYuaElw4w0H+M/tKGhgy+iEc+U v+a+Bf8qLUUgR61cezFIryDei62n7gc+G0N6xZNyQJpGdVOYVhDZMhwgvzVzgF8FcZgQVY2V+/bJ PmkuBb8KJyO+VkHwKbvCSZNGa5KUMWsdfrV1NtapVsczHzwMRAPPrrcl8r/E12ua9Jlzhpnzm09p RIcINCR6UYcq0fbwEK0aUkRscdZve3b+rPTAecWHpCbHPNyQ4Lzib6lJIAeMXDOBfsWHo1PgLcdW M0EMQeEhw1ER3p4Z+hWEvEVOZ6ad+miAeyuciI08DKau2hGwXlBcZs9iIUd1ewZYBz5jfRHfUNmp g0YksDGQ7mGshwo0ZH2Rhyrr9jSwriISrBOme1ohVFcQFS3iIov+MVOC6oonA0vLq+9OsVY8Qgwj zKQ2SYWH4H5G6Dh6GkjXp4kSkowQ2ZttYIBqBbUMOcbWPdWKYgKPYxO+fwDDoGYMr0rbHbcWcM94 X4Uc+nVoPkOGFzFIGSb8q+YJwyoZwTDCku5mmEVAdsXj1lE8u3/M8SC74jmckEYLKTZi49eKj2Gd U0kZxVvz+LXC6XESEfOggLssZCs8VDd6xNqEbAWRsMADSN0BC19xcIVTp4CLIdgzrf0M66BmrC9a 2xU3BF0zlHV1IJ3H/DrUnyHriyxUWbdXhHUVj8Kv2ZvtYwm01KeH9YpnBuchKwiqK4i1hdbN90ah WvEseE9MzTk52zNAtcLjUHJUM5v4tcLJcD+zsD00JEhXeGyZsg3iKcBwXVCUAkN1yfMw1iOQDnxG +hI2R0kaDsNf57v3njXSQ/IZkr5oQZX0HDDaIAbpqhhBOkc/zP0gumKoscqY373bfQXOK54DMyqS e2gH54pnLRbeOovPFX4Vd/FwfXvvnS1qUxD3NXAyYVJdyh4hDrUwJZuHwLQ2SjB+TTZWBmtmnDAN fMb0Iq9xloXCSAyxm9mmxRjToe4MmV5kn8q0TUQwreIQTBN6zUqDOp5baMSqd8MBrNf2udZJA98B 64qPPVOEMDM9/FtBrMVCFTk0DYZyhZOETn0VCQCtS/BvhUdNMcZ0X9bDuqKiIDDRwLGo2uAz1ldV jVTLuGy+D+o5hVTWL45UtfZFXYsTKFY/eHG5ovpaHGd02filg7gtkX2wiYNbo81fZb43Z3xd28fB m+H19s3N3lQ4AhuH7nT3vb7i2wpvlxrvzlG8q6AIoyLTbfM4jzjeV3hkR1wjU5l1fmioCdV007oa 4+IRkm36gxvDIfGM/Ppi0X6qX9tDwLAqRPh1FDfoVrXzU8iueEYe8mD7o7Xh85WDqHl4rWK84WFY G4XhECPTIvYMKxyGqeLhoQO8KuiGmJ0lhOzN1UeGYYWz8kLKRBatKIhVFOE4dfE4ULPZoj0oDAOf MbzqaYh9cU1sH8JzKjCq4XJMdXzhzmwrDqheUN2Zkb9nOySOp/4SuVzbu+6CXFiv7d9GwTn5ATM9 WFd8xOXsn2f0lZ3QjAq/VjijLUfBbu0dYV1Bcc/WWROed0N4gcd6m0nnZhA0tUeAfm095FRKcHml UVgHNWO9V42j8rSEm+kVxnpoPEMHX8Qf/TXCw2qysK4SETt/ZBa5AohXVxB1GbkIvo9vLpVAdcXT CWiciTfuoFrxODhrF1HrzG+gWuFkLXPMQ5JdrHVIV3ikupXTJWYjuLrCIT0UcV+fw7WiLqkqQiHq 1AjskSEd+Iz0RVqjACwXNpCyv/VV0mWkh8QzJH3RfirpGfM1Q4V0VYgiLueQhbii9SD8V3ycO5Xd 5wH/FU8+nGR/DZbgpf1IL+IvGC+wro2y8GadoBk61bBhXeHUHaD0cCYRuRoI6wqHdXI1yTqqjcK6 oiJGp9q/+xRkg5qR3dPZGKRkdy9/zcgOkWdI9qL+VLKNPMhWjQiyr9iHO/YuyK549v6uJczdFQZ0 PGM6E1vOAzao4uzafsyk/MJm7/xZuxzaFc4iPCbpdItm0JCtIObLeMGM5A0O2Qpn6c3kj7pdfxmy C4oiI1yJepzv0uAz1heVjaV3XBSX7eTDLaw/+/7z/f3jq4+PH//wT18//u3+Tx+//e3zr9+f/HL/ E61HYaunT759/tvP/T8eH77++JRI4j8eHh8fvrR//fn+41/vvwUa8E8PD4/bfzxb2vzL/ePfvz75 +vHr/be/fP7H/Y9PWYQ8fPt8/+vjx8fPD7/++PTrw7fHbx8/Pz598jP//x8PfPHLq6+ff3zKkoJ8 T3ahMLr/uv/2+PnT/gt+5P63xz9+f2x/Pvn7N/7e/xBmx9B28bt/vn3x/Hc38Y/IePkd5UAuXpxe Muk8f/6/T5/89uWXX7//8OW3H5/+/Pj49Ydnz75/+vn+y8fvv//y+dO3h+8PPz3+/tPDl2cPP/30 +dP9sy8fPz27/+3T/S/PUNXu+M/PvxIUf/nthz//8d+e/Onhr7wZC5x//fX+z3Rk+/d//wsP3P6V p+Tv8ozxz/awz/774dt/tt7/w/8JAAAA//8DAFBLAwQUAAYACAAAACEA9iZlDkEBAABhAgAAEQAI AWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJJd S8MwFIbvBf9DyX2btMOhoe1AZVdOBCd+3IXkbAs2HyRx3f69abfVyrwQcpPzvufJew4pZzvVJFtw XhpdoTwjKAHNjZB6XaGX5Ty9RokPTAvWGA0V2oNHs/ryouSWcuPgyRkLLkjwSSRpT7mt0CYESzH2 fAOK+Sw6dBRXxikW4tWtsWX8k60BF4RMsYLABAsMd8DUDkR0RAo+IO2Xa3qA4BgaUKCDx3mW4x9v AKf8nw29MnIqGfY2znSMO2YLfhAH987Lwdi2bdZO+hgxf47fFg/P/aip1N2uOKC6FJxyBywYV78b tk0epSvxqNgtsGE+LOKuVxLE7X7kO9cir49/gIJIYiB6iH9SXid398s5qguSX6WkiGdJpjSf0oJ8 dE//6u8CHgrqGODfxOKGkmJEPAHqEp99ivobAAD//wMAUEsDBBQABgAIAAAAIQCahneeJgEAAGgE AAAQAAAAeGwvY2FsY0NoYWluLnhtbGTUy2qFMBAG4H2h7xCy74n2TlEPmJvu2wcImh4FjQcjpX37 poXa9p+NkN98YZwMFsf3eWJvfo3jEkqeHzLOfOiWfgynkr88m6tHzuLmQu+mJfiSf/jIj9XlRdG5 qZODGwNLJ4RY8mHbzk9CxG7ws4uH5exDevO6rLPb0nI9iXhevevj4P02T+I6y+7FnA7gVdGxteRt nnM2piI4m76eYs9TUd/5b3IDSbPbnz1NjqrJUVmiLFGWKEOUIcoQpYnSRGmiFFGKKEWUJEoSJYlq b6Gp7R0GaRj+XUSDpEHSILFILBKLxCAxSAwSjUQj0UgUEoVEIZFIJBKJpH3AFmJgMTAYaAwUBhKD GuuoyQ4yDzWZoppMUY0fXP9pidj/EdUnAAAA//8DAFBLAwQUAAYACAAAACEA/lTD+ZsBAAAqAwAA EAAIAWRvY1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACc kk1v2zAMhu8D+h8M3Rs5bVAMgaxiSFf0sGIBknZnTqZjIbJkiKyR7NdPtpHGaXfajR8vXj0iqe4P jcs6jGSDL8R8losMvQml9btCvGwfr7+KjBh8CS54LMQRSdzrqy9qHUOLkS1Sliw8FaJmbpdSkqmx AZqltk+dKsQGOKVxJ0NVWYMPwbw16Fne5PmdxAOjL7G8bt8Nxei47Ph/Tctgej563R7bBKzVt7Z1 1gCnX+pna2KgUHH2DMZ6DlRn3w8GnZJTmUqcGzRv0fJR50pOU7Ux4HCVntAVOEIlzwX1hNCPbw02 klYdLzs0HGJG9k8a4I3IfgNhD1aIDqIFzwmwl43JELuWOOpfIe6pRmRSMgnG4hBOtdPYLvR8EKTg UtgbjCCpcYm4teyQflZriPwP4vmUeGAYeUecEhjuFjND3SfG4dvptQ/+q9C04I96VaPZZ+uQVqDk qah+WL+nl3YbHoDxNN3LotrUELFMCzn1zwX1lAYbXW+yqsHvsDxpPjf6q3gdT1/PF7P8Nk9rntSU PB+5/gsAAP//AwBQSwECLQAUAAYACAAAACEASGYcYWgBAAAQBQAAEwAAAAAAAAAAAAAAAAAAAAAA W0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBQfE7B9gAAAEwCAAALAAAAAAAAAAAA AAAAAKEDAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCW1flzAgEAAD8DAAAaAAAAAAAAAAAA AAAAAMgGAAB4bC9fcmVscy93b3JrYm9vay54bWwucmVsc1BLAQItABQABgAIAAAAIQAAkCli2AEA APoCAAAPAAAAAAAAAAAAAAAAAAoJAAB4bC93b3JrYm9vay54bWxQSwECLQAUAAYACAAAACEAUFCW gK0VAAB/LgAAFAAAAAAAAAAAAAAAAAAPCwAAeGwvc2hhcmVkU3RyaW5ncy54bWxQSwECLQAUAAYA CAAAACEAMA+IaxEHAADeHQAAEwAAAAAAAAAAAAAAAADuIAAAeGwvdGhlbWUvdGhlbWUxLnhtbFBL AQItABQABgAIAAAAIQBQmYlVbwMAAEYQAAANAAAAAAAAAAAAAAAAADAoAAB4bC9zdHlsZXMueG1s UEsBAi0AFAAGAAgAAAAhAO8V1/nWZAAA9psBABgAAAAAAAAAAAAAAAAAyisAAHhsL3dvcmtzaGVl dHMvc2hlZXQxLnhtbFBLAQItABQABgAIAAAAIQD2JmUOQQEAAGECAAARAAAAAAAAAAAAAAAAANaQ AABkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQCahneeJgEAAGgEAAAQAAAAAAAAAAAA AAAAAE6TAAB4bC9jYWxjQ2hhaW4ueG1sUEsBAi0AFAAGAAgAAAAhAP5Uw/mbAQAAKgMAABAAAAAA AAAAAAAAAAAAopQAAGRvY1Byb3BzL2FwcC54bWxQSwUGAAAAAAsACwC+AgAAc5cAAAAA --Apple-Mail=_080914A0-1E80-45C7-8458-A9A8B6F8A13B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Feb 1, 2015, at 7:36 PM, Yaron Sheffer = wrote: >=20 > Hi Yoav, >=20 > This is good, but I'm not sure if it's good enough. The ratio between = min and max (which I trust more than the "mean +/- 3s" rule, because = this is not a normal distribution) is consistently around 4. So if you = have to design your timeouts on a particular machine, you would still = have a lot of uncertainty. For comparison, could you try again with 64 = replacing the 16 tries, and with lower bit lengths? >=20 > Thanks, > Yaron >=20 > On 02/01/2015 11:46 AM, Yoav Nir wrote: >> And now it=92s really attached. >>=20 >>=20 >>=20 >>=20 >>> On Feb 1, 2015, at 11:45 AM, Yoav Nir wrote: >>>=20 >>>=20 >>>> On Jan 31, 2015, at 12:35 AM, Yoav Nir wrote: >>>>=20 >>>>=20 >>>>> On Jan 30, 2015, at 3:37 PM, Yaron Sheffer = wrote: >>>>>=20 >>>>> What I would suggest is: we give the client a single puzzle, and = ask it to return 16 different solutions. Indeed each puzzle then should = be 16X easier. The nice thing is, the server should only check *one* of = them, at random. The client would still need to solve all of them = because it doesn't want to risk the exchange being rejected because some = solutions are invalid (the game theory is probably more complex than = that, but I think what I'm saying is still close to the truth). >>>>>=20 >>>>> So: the client does the same amount of work, the server does the = same amount of work, but the client run-time is still much more = deterministic. >>>=20 >>> >>>=20 >>>> Note that these are still single core results, and most laptops can = do twice or four times as much. Now, I know that what I SHOULD be doing = is to randomly generate 100 =93cookies=94 and then calculate the times = for different bit lengths for each of them, and then calculate mean and = standard deviation. But just by looking, it looks like it=92s much = closer to what we want. 16 bits would be a fine puzzle level for my = laptop. No idea about a phone, although I could try to compile this and = run it on an ARM-based appliance, which should match phones. >>>=20 >>> OK. Now I have done it right. See attached. The data suggests that = 15 or 16 bits is the level of puzzle that for this kind of hardware is = challenging but not too onerous. Add another bit if we assume (probably = correctly) that the vast majority of laptops have dual cores at least. >>>=20 >>> I would like to run a similar test on an ARM processor, though. The = capabilities of phones and tablets are all over the place, what with = different versions of ARM processors and devices having anything from = dual to octo-core, but it would be nice to get ballpark figures. >>>=20 >>> Yoav >>>=20 >>=20 --Apple-Mail=_080914A0-1E80-45C7-8458-A9A8B6F8A13B-- From nobody Mon Feb 2 00:53:56 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D861D1A0070 for ; Mon, 2 Feb 2015 00:53:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLTx5KXUG_Xd for ; Mon, 2 Feb 2015 00:53:53 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ABB11A006D for ; Mon, 2 Feb 2015 00:53:53 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id u56so37662620wes.0 for ; Mon, 02 Feb 2015 00:53:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5OLTruEMy1d5WZ5bi4P2h+SSiRLmxGWOwrId/r2Jrfw=; b=cWYdbIZV9qS4NBAt7KEgMeRr17Qzb543PD+ys7w/6ZZrKif87WWCTw1CfqYr1hvGSA 9h1riDf+rZvLPammbQb0Lh1Niama3R/GZsLeFe1LJmeJ4AUlocuLn1aKwfwupk+DR8Ff 0tZXr+0BBBBDffVMX8z5zB0pLKlLvCf3uGhFaZ6Ejx05D9A3+89ufcrhl2WLimWnbWs4 ep3cvXQYTCINrOgZr0/JWeImaWYvpqh5msvUVJ53JKrX7Gd+DrvO0DNuQua8a9tlYj/1 nqmrH4nVBKlR8Cd2QZJCHvXdGrNpz6lOY5sbOPjRMPHeW/PjHzFrFn8X040PkLcLdPfH jteg== X-Received: by 10.194.190.10 with SMTP id gm10mr39543933wjc.91.1422867231730; Mon, 02 Feb 2015 00:53:51 -0800 (PST) Received: from [10.2.0.130] (93-173-247-187.bb.netvision.net.il. [93.173.247.187]) by mx.google.com with ESMTPSA id r8sm14790669wib.16.2015.02.02.00.53.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Feb 2015 00:53:50 -0800 (PST) Message-ID: <54CF3B1D.6010607@gmail.com> Date: Mon, 02 Feb 2015 10:53:49 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Yoav Nir References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> <54CE6429.2020800@gmail.com> <45BEE118-9B68-4D7F-BB9B-16A617A0C5AE@gmail.com> In-Reply-To: <45BEE118-9B68-4D7F-BB9B-16A617A0C5AE@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPsecME WG , Valery Smyslov Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 08:53:55 -0000 Results are actually way better, with the 4X changed into 2X. However it seems to me that Scott's proposal is better - slightly more complex but certainly more deterministic. Thanks, Yaron On 02/02/2015 08:31 AM, Yoav Nir wrote: > The three-sigma rule applies even with a non-normal distribution. > > Anyway, I tried the 64-key sample. Results are slightly better. > > Yoav > > > > >> On Feb 1, 2015, at 7:36 PM, Yaron Sheffer wrote: >> >> Hi Yoav, >> >> This is good, but I'm not sure if it's good enough. The ratio between min and max (which I trust more than the "mean +/- 3s" rule, because this is not a normal distribution) is consistently around 4. So if you have to design your timeouts on a particular machine, you would still have a lot of uncertainty. For comparison, could you try again with 64 replacing the 16 tries, and with lower bit lengths? >> >> Thanks, >> Yaron >> >> On 02/01/2015 11:46 AM, Yoav Nir wrote: >>> And now its really attached. >>> >>> >>> >>> >>>> On Feb 1, 2015, at 11:45 AM, Yoav Nir wrote: >>>> >>>> >>>>> On Jan 31, 2015, at 12:35 AM, Yoav Nir wrote: >>>>> >>>>> >>>>>> On Jan 30, 2015, at 3:37 PM, Yaron Sheffer wrote: >>>>>> >>>>>> What I would suggest is: we give the client a single puzzle, and ask it to return 16 different solutions. Indeed each puzzle then should be 16X easier. The nice thing is, the server should only check *one* of them, at random. The client would still need to solve all of them because it doesn't want to risk the exchange being rejected because some solutions are invalid (the game theory is probably more complex than that, but I think what I'm saying is still close to the truth). >>>>>> >>>>>> So: the client does the same amount of work, the server does the same amount of work, but the client run-time is still much more deterministic. >>>> >>>> >>>> >>>>> Note that these are still single core results, and most laptops can do twice or four times as much. Now, I know that what I SHOULD be doing is to randomly generate 100 cookies and then calculate the times for different bit lengths for each of them, and then calculate mean and standard deviation. But just by looking, it looks like its much closer to what we want. 16 bits would be a fine puzzle level for my laptop. No idea about a phone, although I could try to compile this and run it on an ARM-based appliance, which should match phones. >>>> >>>> OK. Now I have done it right. See attached. The data suggests that 15 or 16 bits is the level of puzzle that for this kind of hardware is challenging but not too onerous. Add another bit if we assume (probably correctly) that the vast majority of laptops have dual cores at least. >>>> >>>> I would like to run a similar test on an ARM processor, though. The capabilities of phones and tablets are all over the place, what with different versions of ARM processors and devices having anything from dual to octo-core, but it would be nice to get ballpark figures. >>>> >>>> Yoav >>>> >>> > From nobody Mon Feb 2 04:06:59 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697061A0267 for ; Mon, 2 Feb 2015 04:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.669 X-Spam-Level: X-Spam-Status: No, score=0.669 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbewwPbzjl8Q for ; Mon, 2 Feb 2015 04:06:55 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E8991A0262 for ; Mon, 2 Feb 2015 04:06:46 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id s18so40116721lam.5 for ; Mon, 02 Feb 2015 04:06:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=uzJW/ntM3QXH5Zd98avLH2e7+n7/plNqVGUdaZJJ/OE=; b=HtSb3uemdKp/TrJ7ZxPTFlUdn1+tekLikCW20xikXQLVmKKGLwzZ9Noi8vcCb6IOWx DrW9/6fK7wLjPQPp1A5ICUCTonchkcH2XQDI+Swz1y5gAwho1ipqke2JCsJcrMP2kpMg tL9NCR00COi1h7/bOXJOyF1sDx9cVKh9VP4oDsxBVWG1zfYLXS8NJsiVpUpoEypcBUNc n9Uf/kou1f3RYEK2fdmeRThoa5Xf790GODOBDOubk+A1TA7ayZw4nh47XSChlcTYIJ/b TaQzaQZLiBoaxNlTgiqOQqvG5RxZyePZD7lS+uEL39TJvwtvox4bCMkdcoPHIg8N97oP PhzQ== X-Received: by 10.152.44.228 with SMTP id h4mr13446617lam.31.1422878804531; Mon, 02 Feb 2015 04:06:44 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id d8sm4347965lah.15.2015.02.02.04.06.43 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 02 Feb 2015 04:06:43 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Yaron Sheffer" , "Yoav Nir" References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> <54CE6429.2020800@gmail.com> <45BEE118-9B68-4D7F-BB9B-16A617A0C5AE@gmail.com> <54CF3B1D.6010607@gmail.com> Date: Mon, 2 Feb 2015 15:06:41 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 12:06:57 -0000 Are we going into the right direction? Is it worth to solve the task of making puzzle difficulties less erratic if the computing power of clients may differ by the order of magnitude (or even magnitudes)? Can we make the process more flexible? For example - the server may indicate two difficulty levels in puzzle request - the desired one and the acceptable one. For example, the desired level is 20 bits and the acceptable level is 16 bits. It means, that if client is able to find the solution with 20 bits of zeroes it will reserve the right to be served. But if it cannot (for any reason - insufficient power or the puzzle is by chance too hard), then any solution with the number of zero bits higher than 16 will be accepted. But it doesn't mean that the server will immediately serve this request if the solution contains less that 20 zero bits - depending on the number of zero bits the client managed to get, the amount of time it takes it to solve, the number of puzzles this client has already solved and the current server's load the server may issue new puzzle to such client. The process continues until the server decides that the client spent enough resources and it can be served now taking into consideration current server's load. The advantage of such approach is that it makes the whole process more adjustable to varying factors, including the wide variety of clients and their computational power. The disadvantage is the higher server load (it needs to prepare and verify more puzzles) and the higher network bandwidth consumption. But unlike the previously suggested approaches it doesn't increase the size of a single message, that is very good as it decreases the chance for IP fragmentation. Valery. > Results are actually way better, with the 4X changed into 2X. However it > seems to me that Scott's proposal is better - slightly more complex but > certainly more deterministic. > > Thanks, > Yaron > > On 02/02/2015 08:31 AM, Yoav Nir wrote: >> The three-sigma rule applies even with a non-normal distribution. >> >> Anyway, I tried the 64-key sample. Results are slightly better. >> >> Yoav >> >> >> >> >>> On Feb 1, 2015, at 7:36 PM, Yaron Sheffer wrote: >>> >>> Hi Yoav, >>> >>> This is good, but I'm not sure if it's good enough. The ratio between >>> min and max (which I trust more than the "mean +/- 3s" rule, because >>> this is not a normal distribution) is consistently around 4. So if you >>> have to design your timeouts on a particular machine, you would still >>> have a lot of uncertainty. For comparison, could you try again with 64 >>> replacing the 16 tries, and with lower bit lengths? >>> >>> Thanks, >>> Yaron >>> >>> On 02/01/2015 11:46 AM, Yoav Nir wrote: >>>> And now its really attached. >>>> >>>> >>>> >>>> >>>>> On Feb 1, 2015, at 11:45 AM, Yoav Nir wrote: >>>>> >>>>> >>>>>> On Jan 31, 2015, at 12:35 AM, Yoav Nir wrote: >>>>>> >>>>>> >>>>>>> On Jan 30, 2015, at 3:37 PM, Yaron Sheffer >>>>>>> wrote: >>>>>>> >>>>>>> What I would suggest is: we give the client a single puzzle, and ask >>>>>>> it to return 16 different solutions. Indeed each puzzle then should >>>>>>> be 16X easier. The nice thing is, the server should only check *one* >>>>>>> of them, at random. The client would still need to solve all of them >>>>>>> because it doesn't want to risk the exchange being rejected because >>>>>>> some solutions are invalid (the game theory is probably more complex >>>>>>> than that, but I think what I'm saying is still close to the truth). >>>>>>> >>>>>>> So: the client does the same amount of work, the server does the >>>>>>> same amount of work, but the client run-time is still much more >>>>>>> deterministic. >>>>> >>>>> >>>>> >>>>>> Note that these are still single core results, and most laptops can >>>>>> do twice or four times as much. Now, I know that what I SHOULD be >>>>>> doing is to randomly generate 100 cookies and then calculate the >>>>>> times for different bit lengths for each of them, and then calculate >>>>>> mean and standard deviation. But just by looking, it looks like its >>>>>> much closer to what we want. 16 bits would be a fine puzzle level for >>>>>> my laptop. No idea about a phone, although I could try to compile >>>>>> this and run it on an ARM-based appliance, which should match phones. >>>>> >>>>> OK. Now I have done it right. See attached. The data suggests that 15 >>>>> or 16 bits is the level of puzzle that for this kind of hardware is >>>>> challenging but not too onerous. Add another bit if we assume >>>>> (probably correctly) that the vast majority of laptops have dual cores >>>>> at least. >>>>> >>>>> I would like to run a similar test on an ARM processor, though. The >>>>> capabilities of phones and tablets are all over the place, what with >>>>> different versions of ARM processors and devices having anything from >>>>> dual to octo-core, but it would be nice to get ballpark figures. >>>>> >>>>> Yoav >>>>> >>>> >> From nobody Mon Feb 2 07:53:44 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E021A7026 for ; Mon, 2 Feb 2015 07:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9wZd_a2phmM for ; Mon, 2 Feb 2015 07:53:23 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC8011A70FD for ; Mon, 2 Feb 2015 07:53:23 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2404720098 for ; Mon, 2 Feb 2015 11:00:17 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 8640C637F6; Mon, 2 Feb 2015 10:53:22 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 69390637EC for ; Mon, 2 Feb 2015 10:53:22 -0500 (EST) From: Michael Richardson To: IPsecME WG In-Reply-To: References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> <54CE6429.2020800@gmail.com> <45BEE118-9B68-4D7F-BB9B-16A617A0C5AE@gmail.com> <54CF3B1D.6010607@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 15:53:30 -0000 --=-=-= Content-Type: text/plain Valery Smyslov wrote: > Can we make the process more flexible? > For example - the server may indicate two difficulty levels in puzzle > request - the desired one and the acceptable one. > For example, the desired level is 20 bits and the acceptable level is 16 > bits. You are describing a situation where the server simply has multiple queues, I think. One for 20 bits, and probably one for each of 19,18,17,16, and then one for all solutions <16, including not supporting puzzles at all. If one further creates various queues based upon initiator IP, it seems like one can rather effectively adjust to situations of attack or not. One concern: is the gateway, in selecting the complexity of the puzzle giving out information about it's current state of health? (Do we care?) > The advantage of such approach is that it makes the whole process > more adjustable to varying factors, including the wide variety of > clients and their computational power. The disadvantage is the higher > server load (it needs to prepare and verify more puzzles) and > the higher network bandwidth consumption. But unlike the previously > suggested approaches it doesn't increase the size of a single message, > that is very good as it decreases the chance for IP fragmentation. Over time Internet protocols seem to evolve towards the pseudo-technology of William Gibson's Neuromancer series... which he wrote on a typewriter in the 1980s :-) {In this case: bad guys need bigger computers to pull off bigger scams :-)} -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVM+db4CLcPvd0N1lAQLsiwf/YNGCSMkmtlSKl8KUS9nmWSpHrYZSdOob uHsunnDvhy0FMvfx8TeA8FVVpdmRoZ3GniGzu+OfM4mK9bM7jkNi+OkaaHHCDEEI wksIIVNLwGZvAm5vFIzUyKrGgtL7xOHSkGI3bjWtu8zKcasHlbvDinXlaBo+0WBh yyMt2Hhaos9Gw5kjBPkD/lYiU6PCQk0MNlTWfsTS/dDyw+ZwFkVK8xeo4XxfIDOk B5EdnEVCqxOLtNUahnMZMTGhz10Oa/8CvZHfXKeNt2gP4VsH9h5fjhadHeNJBbNJ mfV8lpH6Igo1x/EJdkFCP+jcfOZTLqTVwaN7JLn8TaxlT3mJUuYn0Q== =gH+4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 2 08:11:15 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD5C1A0154 for ; Mon, 2 Feb 2015 08:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.353 X-Spam-Level: * X-Spam-Status: No, score=1.353 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CE59zNwyPcBB for ; Mon, 2 Feb 2015 08:11:10 -0800 (PST) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3A211A86FE for ; Mon, 2 Feb 2015 08:10:07 -0800 (PST) Received: from [10.20.30.90] (142-254-17-182.dsl.dynamic.fusionbroadband.com [142.254.17.182]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t12GA6DF010296 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 2 Feb 2015 09:10:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-182.dsl.dynamic.fusionbroadband.com [142.254.17.182] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: Date: Mon, 2 Feb 2015 08:10:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <587EB741-0C86-4E70-BAC9-E31D6BF4B060@vpnc.org> References: To: IPsecME WG X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [IPsec] NUDGE: Re: Second WG Last call, or continuation of WG Last Call, on "The NULL Authentication Method in IKEv2 Protocol" draft-ietf-ipsecme-ikev2-null-auth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 16:11:11 -0000 [[ We really want to hear from everyone who reviewed the draft earlier, = and would love to hear from at least a few new reviewers as well. These = reviews are really a helpful way to participate in the WG! ]] > On Jan 28, 2015, at 2:22 PM, Paul Hoffman = wrote: >=20 > Greetings again. Please review = draft-ietf-ipsecme-ikev2-null-auth-03.txt: it is now our WG Last Call = item. >=20 > If you commented earlier, please look at = = and see if your comments were reflected either by adoption, or by an = adequate comment on the issue you brought up. >=20 > If you did not comment during the first part of the WG Last Call, but = you were intrigued by some of the comments in the last call, *please* = read the document and comment, even if just to say "I have reviewed this = document and it is fine" or "I have now reviewed the document and here = are a few things that still deserve comment". >=20 > If it looks like there is general agreement, we'll close out this = second/continued WG Last Call in two weeks, on February 11. >=20 > --Paul Hoffman From nobody Mon Feb 2 22:54:03 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74881A6F29 for ; Mon, 2 Feb 2015 22:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.791 X-Spam-Level: X-Spam-Status: No, score=-0.791 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, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNS6AMGhGDGR for ; Mon, 2 Feb 2015 22:54:00 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A7F01A6F14 for ; Mon, 2 Feb 2015 22:54:00 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id gq15so48574662lab.12 for ; Mon, 02 Feb 2015 22:53:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=m7H+B064GnMJ3dHRV5i3vagqgVypuL7a+FBnhVxJkZc=; b=a+G7glITIZkdvFZKPoUXpW95gAW+uaKFcTuUV2mLzljWeX0k6YzmLkq4AbW/KII8ay CDnBg6oZk0xxGNGw0FX1XAHLiBACPxp0loF7b3aC6AAnALKh+6IjzIHNqrSGHXUmrO0D sHmsh7BkN02U6oJrRueAITuxWHf3koS4eeCwKEFXNyNRjSj5Qom0lBPOB/bNixHT5RZ0 kemGjlBt5sBhIWV4q5gfHcu9SHP0t5GtphU13KSGmQwuohUCr06zTZ7soXFryckHGKGX b0fuPzkNizbz9TC80DwVs5PRf/HfJZ7sTEO40LRghMDDSoGgRMrnGeRKrlVMvzdO9F5k lP5Q== X-Received: by 10.112.163.229 with SMTP id yl5mr23066290lbb.60.1422946438703; Mon, 02 Feb 2015 22:53:58 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id j8sm2407496lbd.15.2015.02.02.22.53.57 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 02 Feb 2015 22:53:58 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Michael Richardson" , "IPsecME WG" References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> <54CE6429.2020800@gmail.com> <45BEE118-9B68-4D7F-BB9B-16A617A0C5AE@gmail.com> <54CF3B1D.6010607@gmail.com> <8624.1422892402@sandelman.ca> Date: Tue, 3 Feb 2015 09:53:48 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 06:54:01 -0000 Hi Michael, > > Can we make the process more flexible? > > For example - the server may indicate two difficulty levels in > puzzle > > request - the desired one and the acceptable one. > > For example, the desired level is 20 bits and the acceptable level > is 16 > > bits. > > You are describing a situation where the server simply has multiple > queues, I > think. One for 20 bits, and probably one for each of 19,18,17,16, and > then > one for all solutions <16, including not supporting puzzles at all. Yes, but the queues are virtual, the server is still stateless. The server just takes a desicion on each request based on the number of zero bits the client was able to get, the amount of time it took the client, the number of puzzles the client has already solved and the current server load. > If one further creates various queues based upon initiator IP, it seems > like > one can rather effectively adjust to situations of attack or not. Yes, but again, the queues are virtual. All this information must be encoded in cookie, so that the server remains stateless. > One concern: is the gateway, in selecting the complexity of the puzzle > giving > out information about it's current state of health? (Do we care?) Yes, it reveals some information. But do we care and can we avoid this? Even the sole fact that the server asks for puzzles reveals the information that it feels itself under attack. Regards, Valery. > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Tue Feb 3 05:48:50 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B07141A0071 for ; Tue, 3 Feb 2015 05:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWxWm5gtltNI for ; Tue, 3 Feb 2015 05:48:47 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CD371A005F for ; Tue, 3 Feb 2015 05:48:45 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t13Dmgsq004070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Feb 2015 15:48:42 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t13Dmflv007753; Tue, 3 Feb 2015 15:48:41 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21712.53689.477475.787000@fireball.kivinen.iki.fi> Date: Tue, 3 Feb 2015 15:48:41 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> <54CE6429.2020800@gmail.com> <45BEE118-9B68-4D7F-BB9B-16A617A0C5AE@gmail.com> <54CF3B1D.6010607@gmail.com> <8624.1422892402@sandelman.ca> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 8 min Archived-At: Cc: IPsecME WG , Michael Richardson Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 13:48:48 -0000 Valery Smyslov writes: > > You are describing a situation where the server simply has > > multiple queues, I think. One for 20 bits, and probably one for > > each of 19,18,17,16, and then one for all solutions <16, including > > not supporting puzzles at all. > > Yes, but the queues are virtual, the server is still stateless. > The server just takes a desicion on each request based on the > number of zero bits the client was able to get, the amount of time > it took the client, the number of puzzles the client has already > solved and the current server load. No, server does NOT need to be stateless when it is collecting which clients to serve. This is already after the checking the cookie, so client has already proven the point that he is reachable, and is willing to do work. So after verifying that cookie is valid, and suitable work is done, server can put the client to associated queue. Each queue could be limited to exactly n clients, for example 100 clients for different queues, i.e. for 6 queues (20-, 19, 18, 17, 16, -15) that would mean 600 entries in queues. If associated queue is full, the request is dropped. After collecting entries to queue for some time (for example 0.5 seconds), the server will sort each queue create one combined queue out from all the queues using suitable algorithms (weighting in the work done by the client, whether that ip-address as tried before or not, whether that ip-address is know, whether that ip-address has been server in last n seconds in such way it didn't result in successfull authentication etc), and truncate that queue to something manageable. I.e. if server thinks he can do about 100 request per second, he might take 100 first from the combined queue, and process them for 0.5 seconds, and then throw rest away. During that 0.5 seconds he will be collecting new queues as before, and after 0.5 seconds he will again take those queues and sort them and create next combined queue. We need to be stateless as long as clients do not commit real resources for the attack. After that it is better to have some limited state so we can do smart decisions. -- kivinen@iki.fi From nobody Tue Feb 3 06:06:29 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E535C1A883A for ; Tue, 3 Feb 2015 06:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91f9Z6r8DOZf for ; Tue, 3 Feb 2015 06:06:16 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C4E1A86F1 for ; Tue, 3 Feb 2015 06:06:15 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id pv20so51815723lab.7 for ; Tue, 03 Feb 2015 06:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=iNFq8ksLFJQwT8tOoUg+QBaLY/zOhkU8YYSFUgxfjsU=; b=gHcbLEFYfE1CTkxzypQw1SzmUnJ8YZGX9oW5e427P0YVZNXAFhsAd/p6CRoB/xxwui u47rBXNv8VHZIM4VrTG8GgSnWrtSVOX+lfOygBICtOuKvQSF51nE8gSukH2hP4bcgMr8 0Hxcck/bdAlDvJ90lEuy+tDNNmWcRiZE3Dny50pqX7z15jSXiVgmt7qTIZ/3OLdIKIaz +/GADQ/gvoQipZ8MD2RXRK1Wlkah6sZX6Mwv27D6HS046ARzzJ7as71dTluBoeWPfsrN HjOCjZ2Hurlkq9Ds5p2bpVONzZH44R5iO9P6WLtlaEo+5Ca6K1fzopp4XDSkWTLJAuuK yG9g== X-Received: by 10.152.10.65 with SMTP id g1mr12275356lab.84.1422972374421; Tue, 03 Feb 2015 06:06:14 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id 5sm3800839lau.42.2015.02.03.06.06.13 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Feb 2015 06:06:13 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Tero Kivinen" References: <54CAACAF.60806@gmail.com><44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com><1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc><54CB8932.8010406@gmail.com><54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com><22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com><54CE6429.2020800@gmail.com><45BEE118-9B68-4D7F-BB9B-16A617A0C5AE@gmail.com><54CF3B1D.6010607@gmail.com><8624.1422892402@sandelman.ca> <21712.53689.477475.787000@fireball.kivinen.iki.fi> Date: Tue, 3 Feb 2015 17:06:04 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG , Michael Richardson Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 14:06:25 -0000 >> > You are describing a situation where the server simply has >> > multiple queues, I think. One for 20 bits, and probably one for >> > each of 19,18,17,16, and then one for all solutions <16, including >> > not supporting puzzles at all. >> >> Yes, but the queues are virtual, the server is still stateless. >> The server just takes a desicion on each request based on the >> number of zero bits the client was able to get, the amount of time >> it took the client, the number of puzzles the client has already >> solved and the current server load. > > No, server does NOT need to be stateless when it is collecting which > clients to serve. This is already after the checking the cookie, so > client has already proven the point that he is reachable, and is > willing to do work. > > We need to be stateless as long as clients do not commit real > resources for the attack. After that it is better to have some limited > state so we can do smart decisions. I think this is implementation dependant. You may have these queues and be statefull, or you may store all the needed information in the cookies and have some kind of distributed queue. Both approaches are possible, and RFC should not mandate any of them. But I agree that some guidance for implementers should be given. Valery. > -- > kivinen@iki.fi From nobody Wed Feb 4 09:07:01 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692BD1A8F49 for ; Wed, 4 Feb 2015 09:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vR7WNAwl-fLg for ; Wed, 4 Feb 2015 09:06:51 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 7D4C31A8BBD for ; Wed, 4 Feb 2015 09:06:43 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id l15so33247773wiw.4 for ; Wed, 04 Feb 2015 09:06:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=KBPOGRKMvB2wEe91vtSDUf0qzAnfusfPOsE6uuXvlGY=; b=v9LO1Ov7cCukWAPyd7MB3DWjeiQMFYwYpZyr8uwxlxB+rp0D1KoXBsngmscO+lNosB qElzg1JMhIFsooye72bxM/n/g5LjfNQl4ofPYnrwhzEf0LBlOZ8rho4Yso9M1Y4mHtl9 X2ProgmdNqjXRpKz3MReI3MHch+J5ylJsKMzgmJvfgZC9vawCAnxwAzv8Zf0UbfLrcyO Bla6PBnaXX1i6IR0Cts0yDSBgJkk3IN8cdCzKvEAkEe/t+tS3fvuEBHb7aAvCMwS4gJv r9o9GUWYMmU5z7xQT0z3tOQwiox48CpWybiIfhXy06gWVJ2XXSiDFYk0zO39wa8nvfRR iwXg== X-Received: by 10.194.122.233 with SMTP id lv9mr69190650wjb.95.1423069602253; Wed, 04 Feb 2015 09:06:42 -0800 (PST) Received: from yoavs-mbp.mshome.net ([109.253.136.19]) by mx.google.com with ESMTPSA id uo6sm3522689wjc.49.2015.02.04.09.06.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Feb 2015 09:06:41 -0800 (PST) Content-Type: multipart/mixed; boundary="Apple-Mail=_2594CE88-2AA5-4665-A2E3-51A8ABEDB344" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <45BEE118-9B68-4D7F-BB9B-16A617A0C5AE@gmail.com> Date: Wed, 4 Feb 2015 19:06:34 +0200 Message-Id: <6B33D43D-71C8-4C0E-A280-1763573A8BEB@gmail.com> References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> <54CE6429.2020800@gmail.com> <45BEE118-9B68-4D7F-BB9B-16A617A0C5AE@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: IPsecME WG , Valery Smyslov Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 17:06:56 -0000 --Apple-Mail=_2594CE88-2AA5-4665-A2E3-51A8ABEDB344 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 OK, now I=92ve got a chance to test on an ARM appliance (similar in = power to a 2-3 year old phone, I think. Again these are single-core results, but there=92s an extra bit of = badness here in that this is a C implementation of SHA256. We could = probably gain around 2 extra bits with an assembly-language = implementation. As it is, it=92s about 4 bits behind the Intel i5. Yoav --Apple-Mail=_2594CE88-2AA5-4665-A2E3-51A8ABEDB344 Content-Disposition: attachment; filename=data64.xlsx Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="data64.xlsx" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQC1FZPfbgEAAJgFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADE lMFOAjEQhu8mvsOmV7Nb4GCMYeGAelQS8QFqO8s2dNumUxDe3tmCxBiySNzEyzbbdv7/m0lnxtNt Y7INBNTOlmxYDFgGVjql7bJkb4un/I5lGIVVwjgLJdsBsunk+mq82HnAjKItlqyO0d9zjrKGRmDh PFg6qVxoRKTfsOReyJVYAh8NBrdcOhvBxjy2GmwyfoBKrE3MHre0vSehcJbN9vdaq5IJ742WIhIo b0/5ybgABjsCN1b9oMsPZAVFJnGstcebg8MLlSZoBdlchPgsGuLgW8M/XFi9O7cqujFPuLmq0hKU k+uGKlCgDyAU1gCxMUVai0Zo+wv/dBl5WoY9g7T5JeELOUb/xBHp3QFP37+XIsmcSRzjzgD2nO1e 9JxzLQKo1xioQ3sH+K59hkMKI2c1PdWei3DU7fKn/pkH55EmSYDLAb5avo3OPQlBiBo6m/7oSGPo csMfXQ/tnFOgTnjzNFcnnwAAAP//AwBQSwMEFAAGAAgAAAAhAFB8TsH2AAAATAIAAAsACAJfcmVs cy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACMks9KAzEQh++C7xDm3s22gog024sIvYnUBxiT2T/sbiYk07p9e4OguLDW HpPMfPPNj2x30zioE8XUsTewLkpQ5C27zjcG3g7PqwdQSdA7HNiTgTMl2FW3N9tXGlByU2q7kFSm +GSgFQmPWifb0oip4EA+v9QcR5R8jI0OaHtsSG/K8l7H3wyoZky1dwbi3q1BHc4hT/6fzXXdWXpi exzJy8IIPa/IZIwNiYFp0B8c+3fmvsjCoJddNte7/L2nHknQoaC2HGkVYk4pSpdz/dFxbF/ydfqq uCR0d73QfPWlcGgS8o7cZSUM4dtIz/5A9QkAAP//AwBQSwMEFAAGAAgAAAAhAABBmPgJAQAAzAMA ABoACAF4bC9fcmVscy93b3JrYm9vay54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAALyTzWrDMBCE74W+g9h7LdttQymRc2gp5NqmDyDktWViS0a7/fHbVyTUcSC4F9Pj zqKZj5G03nx3rfjEQI13CrIkBYHO+LJxtYL33cvNAwhi7UrdeocKBiTYFNdX61dsNcdDZJueRHRx pMAy949SkrHYaUp8jy5uKh86zXEMtey12esaZZ6mKxmmHlCceYptqSBsy1sQu6GPyX97+6pqDD57 89Gh4wsRkiMXRkMdamQFh/EoZkkEBXmZ4W5JBuKhjSWOEMd5Lv5+0XirA5ZvHOINTymm8hzMakkY o1vzZHXjTnWM0hxEtiTElw97soh8ghglkofN7OvI/xkm/21Gnv3B4gcAAP//AwBQSwMEFAAGAAgA AAAhAIobflfoAQAAMAMAAA8AAAB4bC93b3JrYm9vay54bWyMUslu2zAQvRfoPxC8y5KpJalhKXC9 oAaKIiiynGlqbBEWSYGkIgVF/z0jqU5c9NITZ8Ob9x5nedermryAddLonM5nESWghSmlPuX08WEX 3FLiPNclr42GnL6Co3fF50/LztjzwZgzQQDtclp53yzC0IkKFHcz04DGztFYxT2m9hS6xgIvXQXg VR2yKMpCxaWmE8LC/g+GOR6lgI0RrQLtJxALNfdI31WycbRYHmUNT5MiwpvmB1fIu68pqbnz21J6 KHOaYmo6+Ktg2+ZrK2vssjSe39CweFd5b0nJPcy/RAm6hJZUptvr80pr48flOUXneOvN2ijU6dy9 FL7FYGgg0GDVk4TOfWAOKemfpS5Nl9MgQYDXS4ZxNzaeZemrgVAWvde+gTxVHnmkSYZFzw8/Bw4o apjhwssXeOCHgShuDq9Wj+YjhfElenRmrz2gOWNpj9pRnV1IDOy+HAGuh7lVV6PsapSNuy4LBK8F ejY8I2YSRRECC6NFay1+3Ro7f6yB3n93vljiS1orc/rrJmXxNt3EAUt3cbBKt1Ewz2IWZMmOpcma sSRlvy93o/p/DkdJYY0zRz8TRoXTzeCtiRB6AePp3U6nVyxVv1hZUe03ZFfzE/7WpAO5oHMXZuHl 2Is3AAAA//8DAFBLAwQUAAYACAAAACEAtUFmlLsDAADjFgAADQAAAHhsL3N0eWxlcy54bWzsWFtv mzAUfp+0/2Dx3hCyNlsjQrVVQuvDqkrtpL0aMMSqL8iYNtmv37EhwbmnSzrtIS+tbXw+f+eaY4c3 U87QC1EVlWLsBb2+h4hIZUZFMfZ+PsUXXzxUaSwyzKQgY29GKu8m+vghrPSMkccJIRoBhKjG3kTr cuT7VTohHFc9WRIBX3KpONYwVYVflYrgrDJCnPmDfn/oc0yF1yCMeHoICMfquS4vUslLrGlCGdUz i+Uhno7uCiEVThhQnQaXOJ1j28kaPKepkpXMdQ/gfJnnNCXrLK/9ax+QolDUPOa6QqmshQZrLZZQ 8+Uug8XhpYcapW9lBjT6vX6/7/lR6LfiUZhL0aGAgS250bOQryI2nxposysKq9/oBTNYGRiMVDKp kAYLA3JgVgTmpNlxixlNFDWLOeaUzZplK2ed0u7jFExkCTUn/NtzaqC3SydrqlMpte+wk1owcTW7 NAY+0Fv7nbMEbUnvhJa1okShe/K65uYlJIekKpKxF8cQqm20bnTBfqYL1/4lS99EYwURTBlbJNoA Es0sRCGkvCZKxDBB7fhpVkIuCKhOjbJ2357dhcKzYHDlCPj2wChMpMqgGrop3ixFISO5BqcqWkzM fy1L+JtIraF0RGFGcSEFZjD05xLtANRJCWOPpmL+yjvsIag1zZ3aAcXXqG/KiBmCJu2wAWwmcMCS 0HUnFGwVQrgs2SwGcAvdzAC/m32zinfzr4wWghNX4EFJTVJtfylsmi7xcMgP9vC4r3lCVGx/GboT jVO72Sn5fPrP+JztA/G9Gsfn+Dnnl+ry/1x/3q8enuvPuf4ckl++27Y0TYzbv5j7z7YWYHv/gqb5 5kbG+QEwV6jN3c9C2u1obK+5jcnVsViBaavatuxgsOUWBxCcBmwn3Ter3iA77jRuwfPuDU2kor+B vblDmg7W9rzTfLvn3pOA7Z03M3Da2L2xs8+c7R18Xye9EkurLtvRoAyPjSkn1j8fi+XG58Fgq8qu xafNfch25+6yfHNZ1AZkropweZSMyVeSoe9wIVOMimd42LCpDu13UlOmqTCJD46e0Cwj5rnJhMLh OJB8J8EBI50EBzQ5CY5x4GmATmXp4G2mXvM4NBiOQvDCtdPja+JQgo4Rh+w8RhzoHiMeQG4fJX+k 8YK3We/e3MLZPFWXudtL2mp+PhCVwrPAXGI5dpsnlYUIVI9s2r14WDxtXmftW8iinsCpGclxzfTT 4uPY68Y/SEZrDunW7nqgL1JbiLHXjZtd9k3L716noz8AAAD//wMAUEsDBBQABgAIAAAAIQBiylQI 2CcAAKGrAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDIueG1sjF1tj9w4cv4eIP9hMJ/ygu1pSf1q 2D5Yaslr4C453F728nV23F4P1uN2Znp3fRfkv+cRq0okH5amPQEuXhVV5MMqkg+LVPXLP3x9+HT1 2/Hx6f70+dV1tVheXx0/353e33/++dX1f/11+G53ffV0vv38/vbT6fPx1fXfj0/Xf3j9z//08vfT 4y9PH4/H8xU0fH56df3xfP7y4ubm6e7j8eH2aXH6cvwMyYfT48PtGf/5+PPN05fH4+378NLDp5t6 udzcPNzef74WDS8ev0XH6cOH+7vj4XT368Px81mUPB4/3Z7R/qeP91+eTNvD3beoe7h9/OXXL9/d nR6+QMVP95/uz38PSq+vHu5evPv58+nx9qdPwP21Wt3eme7wH4X6h/u7x9PT6cN5AXU30tAS8/5m fwNNr1++vweCsduvHo8fXl2/aV68q/ab65vXL0MP/Xh//P0p+ffV+fanH46fjnfn43sY6vpqNMBP p9MvY8F3eLSEzqdQYNR5e3e+/+3YHT99enX9fY3iT/8Tqhn/jSpupjrSf1t9QzDanx+vfrp9Onan T3+7f3/+iErhHO+PH25//XT+y+n374/3P3884+ka3TL2zov3fz8cn+5glrExqOTu9Aka8b9XD/ej c6FPb79K20XharPYbFbLTQ0Vd78+nU8PVlNoo7wfWnq4Pd++fvl4+v0KXtIAzZfb0eeqF/vrq9CI HdDfjcJ2lIZK0IwnPP3tdV1tX978BqB3WqYry1R5iUNZos5L9GWJJi8xlCVWeYm3VmLsrLHx3/OD d8mDG8Cf+mD1XB+8GaWvrtGrSR8QwlbKbNFDH16/+bH/y5u3/b+01eZFCy/815c3H8aeqxb1utlV dbVebfabqqk2OYAuURLq+nj7eHx/LR7drV4Mo/w++KZV0aGKLqmiXqw2zbLZbbarZdNUqz310WGm ClGLjvvt9XqBqaReNct9s6/rzboiFf1lFfvFfls39XK1qva73X61IxUByKvr0Fsp0KQV9XKx3C13 9W5b7+tdtSWfe2uNmGzND94lDzJbw47z/v5mlLKtl7mZWikjtv7hr4f+x8LSy0W13i7rfbVr0IHL Zr/f5zq6REfaA2FW6dYvhlEOU1fXr6UGNvRyATOv0c3Vdr+ElbarXV7DYaYG0RosvcR8sam2u2bV 1HDJ1YoH5WUV1QKNWC/Xm121rLeb9YZUBBwzlg5TJ+aTxQY4GkDZ7jf1Fk6TA3lrrZhMzQ/eJQ8y U2+eNfUoHU1telt5sJ0edPzgwA96fjDwg7f84Ht+8C55kLV++2zrRyk7KnV+K2XEUdvVd82/tWud ipaL7a7e1qvNstliqFfVhgZYl7xbOuj2xTDK4aD19etu1NyZ5mqxXtf1Ct6/hFcVA/cwo1d0Bbds MAFttxj9m1W13m2rHXl2f1nFerHbNzvMgPvdfgnv2qN16ZIVWj/jlvVof0zW9aJaVpvlfr1aN3sM Y+qgt9YKc5/v+cG75EFm2JEEzq64b0YpG5bWwlbKmGH/PTFstYBVd/v9FmNytR8NkCPvkldLu+5e DKMcdm1Gu0LxZNdm0WybHSadertdVVjESPFhRrEoC126hWFX2y1WwGaz26x3K7JKf1lFtVos18sd nHa3Xm6rPS+hofkzhm3EsPVusdyMDdmPKzDWJxo1b60Vk2H5wbvkQWZY0KdnDDtKs/lGHiTzDT84 8IOeHwz84C0/+J4fvEseZK0fCekzzQ9idkyaq1stJJ75p3f/4ayMO2Y96TulS1bLF0MoAadcXb8e dfJaCJ8nnYc5naM3rsQP4NDU+v4b3tosmIpI62Z8TuvCZMJM7O1U2eRnxZN36ZPcVuMeZH4OqUYx 24pGW6uF1FZv/ruwVbXYEc3t0nccW1Ww1Vg1enkNW0En26pZrIkKHeZ0ihadOWiQ9t/wEuaK0lbS MQFz2v6krnoDDp1Pmm+n2qKtTJE9eZeWyW1VP2+rUazzQv7euFt5xsaymQH3SbYl1PC2kkKbsC+B xW8wQpUCjOvbCuy0AunaLzdYJHPQXfpu2lfCUasGth61w9ZQD8+46RLd4LxbMDr7P/Kjw5xu0RZs jvatwSt3m7rerlerfUU6+m/Tsas2uwYL4qgL/5djFAQBwMsPKcasHaCku7qu16C3uy1309upGeYJ 3xdP3qVPchuP1PUZGwuzxVZmsjFvRsaAAdwH7jgVKdbmTgth3ZoKUW8enCLFmJOqUi1ETAZHC02y b6cGx/4yCPbkXVom76+RLMf+0o3+m0o4NFa2CV9dEW3EbjzEL7BlyZ0AU5QENhbU1IMKVov9bpn+ Ubley+1HbpL+EUUarKJqsYkqcnwjZzR8Y7NCIONNJVQyx0fjtUUhiTJUCAYmf2TpTss1i4oMfFAJ 8NJa0atkv9iSZFBJjWBnVJdjGumSg0lYVIapLrx7jESNkZMqAYR/FpikHMIfsWND1x0qkawWFZm9 VwmCFdSTg0qq/WIVX8oxjSTKwTQ+fnWdY6K2IiKkmHiZQSAnSOrFjnr5oJLVotijm7Ya8ZLcrwdT h7ciwgxGnVK+6G7hMcOI1pXIIAqJaZY0qXYqqRd17D0xhkqwPcub2qtgv+BZfrBq9ov1FmGU6S9q yBGN63JpGMRpS8NQ61oUEkQcS+lUAkSxIxWRvNMg4sWQVNsY9ctFg6nDLjzqy2GknCExjHCF3L/I 49sae3KJNlKTOpWAjOYNOqhgs2jIyr0pQ7wp9niAPpi2etFED8hRpAwmQSGkJEdBfdTW2IEGFIny UG+nknqxpsYeVLJCCGLyk/EfsXlBQ6/ltsVsMVitOwQQpj7KMY1xRcfBJNyYY6J62xobGJnNCsuI BA6Wz90FQinXLHjX2pvu5aIm5YOJdotNdPkc1LgCO6BkYc5Bkfa2BtMPoHj+6SYJT7AHlWwWS3Le 3t7B0IhtVX+TihAZ3sQpNYeRsoPE3xx2UJM3t/VYflxpqNpOBYhKRY8IDTqoZL0gK/UqAB+gWgar ZZvOFzkGnwHUDgPgyahFIfWv3P+p4Z2Ww2q5zZZVwnHQcjgRoE7prablYkeiwZTDR+OYziH6hKB2 CEHDhACFBCK1tVMBosnU5weVwEwk6U2ZN0UroYAoAsxRYFh4Y2Z8TGtnE/01eE5bGwWoyf87lWDz Q5PHQSUwBo3A3rRVixVVNJg6ULoZGI1PAcJjhkF93qKQGoNhqKQu+OJBJZij6Z1eJZh6N9nsTbUO Vus6VZGZpvFJQHjMmGK3iGlQSOcBknQqASY2jUqyBgVtvUr2C3plsGrWs9ys8SlAeMwgqCtbFFLD kEN0KsEwmZY3mcxUsC55sinDlFyYQuvZ4TQqs9mkPLeLzwcahw80ce5QuwgfWGIvNikPkg6vj2BH cpb9UbmDlmtw9JFr6FWyTbdlQfegkmqkCulUGbs1B+iTg8YhB0xrWhQSm+HUNvvLG9tN5RLuqCY0 cpCM9SDp9Z19EdAbTNsuZd45Jp8bNA43aGhmalFIBxN5TqcSLEEkOagEg6kwk2oDf439r3ZSboCd RdSXw/C5QeNwA2a6LQopDF5JVTJy0cxm1PSDllstcBye/lGH9Vpu3OzkZh+sDdiuRuU5Qp85NA5z aAhHi0LqfFF56NlOJTAU9flBJatiU9SrBActea/QNDWYbkypUXmOyacKjUMVVkwVUEgwUbWdCrDN LiZBeQWTcvQiHUGqDKEbWhcGU7ecn8p9qtA4VIF7uUUh9b3CMhYtSBhKaOxB38kYmMKQdzDaaX4d rB7sAaNzZLZY+UwhPKYFibuvRSFBUZwoqMSJ3KgEhIfa2ps2hIVINJg6rGNxBOUwfHKwciIESfQn dF+LQgKDqXenkvEyQz5wDyrZFPuy3rTh/Cq6f6hoMHUI0k3qchQ+O1g5AQIOibUopChiF4VqO5WA fdKYOagEoSQaM71pw52Xxl8iFZLUWuNUZg6TTw9WDj3go+MWhRQTtbxTCegBoT2oxKGipg1bTXpp MHWAm6/TM3byGcHKYQTcsy0KCSYeAJ1KypjfQSWrYhvUq2SbbmjUMloPXpoB4VOAlUMBVtRfLQrN DRldsxMXD+056Ctr3or3pgtmmRqqEFQXVpI4PecDxl//V876z+G/FoUEQxOVh3o7lWD2ohYdVILZ K13vy1iUlsMOgeb3wWqFKB1XSew7B+gv/ytn+U/CwQFGi0IKsBg9IkGMLw5atZJIMJyzYV9EdFT3 brEl3YNKagzNiD3H5C//K2f5X/Pyj0KKKfeVTgVY/smaB5VgksvIfgkpkgHiCYMpzzosx+STgZVD BtbU5y0KCablfsYl1C2NGuBuV/pHrT2oPtDS3EvJmXstB0+kFg3WIkTuo/IM79qnDeEx0QYO6LYo JHh5SHYqwVaAjagS7ARI0ps2XC3NeWnuIIOVw652kuSQfAqxdijEOqqQoYZCAomXo04lzlyikjGu PTUoaOtVgv1C7P0gGawezPdxSs5R+BRi7VAIjtW0KKQoyFU6lZQBBhU4dM6UIcDA7mXaQJFiR+Yo fNKwdkgD916LQupeUbkMIJVgjoidFyQHlTjRRJUgyl5lU35hGY1XINQ8w7TXPmkIj3nIUP+3KKSY qC87lcAyBSZ5B0FCeqfXd3YLHoCD1YOtROy83DI+a1g7rIF3uy0KCYpqvDud/OX+32k5TANxBVE7 iYZ1sa72pvviNKCcYpWufTlCn1OsHU7BwYwWhQJCBiSPMQnkMzw50UFfh8nS+R3XGnN9vZZD1CBn q9FmOl1ovbjzFUU5WJ9frB1+wVe8WhQSc7KhO5VgoJHrHVQChM8vxloOVxNiwxWTchcciUVRjsnn F2uHX2yYX6CQYKIR2KkAJnz+dEXLOVFjU41DVxqqg4kQyoumzjH5/GLt8AtezVsUEkzJzBT6slMJ Al1xztKBJu8gZkId0Zs29AStW4OpQ8wk2j2DsfFpQ3hMcyB/dNCikMAotukqAYzYewJDJdldiSDp VYLLILGpQTJYPdipRFGOwmcKG4cpcFypRSFBwWGITiUOg1XJOj1eVBSibZ8e1isKkeAGT9IpOQqf KWwcppBcbAraWxRSFDSFdSoBUybvOKgEkUWa1XuVwPtJ22D1YPmNL+UofKawcZgCB3FaFBIUF9Yj LYcdTYFJNGCPna9oNMB7qwnxBRINJhrvmSVLYnK6nuP1WcTGCT1saOi2KCR4k0tdwZ6dShAiii4f JAeVIOpIa5Apw3RG7wymDdQ2zis5Cp9FbBwWwbymRSFBwfV2KvHmAeMNZMDelOGiW2EYrQer7MxC s/GZQniMy5uY6+LFxcR/dQhN4Qdy+g7vjwABg/r8oJINB1d6FVRgP9llxcIyqhqTTKw1t4xPCDYO IdhE4yokIwTF5TG8LpCS/aT6l0jKy2P6CiAV64xpQ9g+9lCOwqcAG4cCbJkCoJD6F42fTiWjf2Uj NTZCMYmGi0EUq8lhBCbapbc2c4g+I9g4jIA3YC0KCcToBKHlnQowe0eXV0xGCAoyasouhYpNN3ZI scMySFufHYTHxA740LpFIYVEHKBTCXZIhPagEmeHZNpwFkFOPphom96CyGH49GDr0ANmty0KjTCc A3GVOJ/FqAQk5/kLzVoOlCefygdTDWeLE0YOyecKW4crcECwRaGZ8aQSjKc8chPdQ3xPy2F3ztO3 6YbvMSY9mMDYihbMMfnMYeswB74f3aKQYqK+7FRycaun5cAcsgm7GF1aDtwoNy710WAtQtAodlKO 12cOW4c58F2YFoUEL7evU8kYGX12TtRy2HY/f1au5QCjsKi2YTwrT6uKPZHD9SnG1qEY/EFRi0IC l0d/pxLnJpdKsGPKPbFXAZqd7xxpdRmsUozCKMoh+Xxj60Qm+DZMi0ICKQkcypyvErDb52+pajlY kAGqakxahc1UBP4+h8nnG1uHb/DVmBaFFFN0ecVkfONCqFw1jDc4GJRoGJ0tlwxW6xYumoZp4uqS G82nIluHiuyYiqCQAORNaqeS7I6FTpZGPi5EWFQDov/ksIPVmt3bzzH53GPrcA+OALUopGOLOrZT Cc4/LywHouHitRvVh41VvjkrnFT04QpyQrgzvDufmITHREwSXh3s0aKQOin1c6cSDDxq0UEl2CrT O71KcHMtuluoZ7B65u9I7HxeEh4zChrjLQqp1TKfT44tZeBpOcyP1L6DSvDJDkl6lcRlWgFplThj nEZgbhWflOwcUpKE1dQqRkr4aLvD6yNS50KoSnC/nXqnVwn2KmTJwST7RZ2d98Y+yCH5nGTncJLk HrZCMk5S7O7xukDiYN5BJYinU8N7lVxctbRclX1CnWPyecfO4R18datFIXW76APqaCIB74gLS5Ac 9B1MD/ROrxKcAJIBB6sHl9u+5Xuknc8twmMeSdSIFoUEUrEQq6Q8ZFMBDtmo3b0pw9Q1jZHQC4NJ YJc5X/PZxM5hE7w6tiikIGiC6lTiBC9UguBF4WuqDaSZRIOpQ4aI2JG5e/kEYucQiOTrHx0yRiCq C7Oa0Ynl8xt/VDp2C0h97PNQU68S0PiUMiAlCptNa0ovw+RwfTqxc+jEnukEConV+IOwTiVYimgW PqhkDOVlfzTqei0H8vo8y7Wa5uPSO59chMc0uJhvtigkCC9EdLUcHC7v/4MKAJcs06sEh6YXAGoT cO88M3X07Myee59ahMeMlpyqRSG1J8HoVFJ+E6gCrGFk6N6UIRJKosFE8yx+71OL8JhR0BzWopCg YN/rVFJOCweVICJAfdKbtuwMSqZEU9ekwzM3hs8o9g6j4MwfLQoJDD5U71TicHWVgLKRAXuVIFZD LHmwemCMzBFjR+SQfEaxdxgFfx/eotCcZYxRXNj1qwasXAVA0VCg0ypx8DsHyKcTe4dOJPtome9R SG2UD/tOBVh6yTsPKgGbKBCoMsQIaa4YTF2WqyQ3i88g9k50gr9BblFIzUK916nE2VGoBPMavdOr BDc+ChRaD2aRiD1H4VMIpOgsvpbjbXSLQooiKg9W6lQS7R8eH/QxBgvNT71KsPbkZh2sjt3sIeje Zw/hMU9cpL1FoTkExheYVh/0HZwtk6P1pg3zL4kGFY0b1Gij3BA+K9iXrABXB/NOalFIYPC1hE4l 2JDnFwnJhQ5aDp/LEwvtVTIm58prHaxWeGSEm2PyecC+DDIg1V2uvUUhNU1Urs6lm33eqR30lYsB Si2H6A+BHazSbNLOIIFlup+XyvPc3xrexrVjKbUUozKRc3BjIofSmGjct9IgRP4rrQxfbubWn7qa oPkUAOn2iskA+eYmJTIxj6VmnNBE2SwkM4KJMJrIJZH0SxViOLHrmQzjKYnWEBqfCSAfpoOG+g6G Mi5AOJFLyaILVb4R4MnOCl68WWAFEeUiHTChNmM+7wGymM44ZMkPGv5gAThltS4DvwA6MYQ4ZZnV RARSQMMWVtPl3/kC3WS4WJ6EMchqPjdASizHauQWQGPsgKNuQGPRBiL/1OXIUCcFR7PlLg5sqh6z OL0GS6l+YIvORNh8xlAthTJktw0a3lcC3EQaaBkDOBMld07MVCLC0WJpKhEhmJJ7Mo1EYJOCsFsS wCdsPo+oliWRaDj7AqAZk0hWktB+QBMRqi69UETYQlCHwFKqEFeXyUmARjXOXz+slj6nkOc8yVPl QGOsgi9QAc1EK8i54HciAuGkFgONiLBfoLoARuvCadvkrWQZn1hUS4dZjIni0nyswCLUAvMDdT+w GOvgkypgEZGbylFE2ITnVQGKSOBlc/fdqqVPKOQ52YVjVMBilIJTkAGLcQo+nwYWEY1z3bPhEyuI YDfZFtBUfRyCuY1CPskyzwtiWuWsx8F3ZA80UsG0Gsn/RIRdEXkOsjuK6OLxtRVEHLmY9Ew9Yl1z 7hfSL3rQHFKR3FgPox/QjFQ40EQEapunpaDZC0CloHMUY6Jt8cUx0mVqzVh5o+eT1WYYRuUwDGZn gGYMg2cvWM0oBl/7ARgRYQtFOJF5U0Tjx0CZo5ZW05rHUGZWchqRhHOGYWj2RIzJ6ZJcwx/+AqcS guKSIXCKCB/TxoGhy5aKcKmsxClv4cYs+TSMpnVhtwL2G/9iFxCyGbZROWyDE78AmdKBdE+nq5aK MO5KZPIWrgKTCBZUhc6dpUkG2HNmmqEXmrQxN1P0aRtpRiGq/OiW+hhGUzJQ3IGHc4oIXIPUA5qI so1VqBlGU4VI6TNrpxl2gcSNHKZoeGDATkoGij0GwCgXKHZPACOibHcbWgwwIgJxot4BGK1rJFVz dpohF8jYWIKhCgBGF/wiSzLAiKg8fTIJRhOtusCi+nDeGx3LLKMKswvtNIJm2AVSNRZgyiySltCx OD8HGGUDuDsaxzH+FV0kNBJ2koLgTXEJMjuJCJHI7EgwiYUZUClYIf70LReTKmRwvHJyTMlz4iF8 NQAmNB7CNwCAWkSYEQkMcE48JDqW4RQRmAdRR/ijiLBRTuK3uQmRydEFE54zGOr+FjlNddvPYcnO RM6RlIlAqvJDKWp/bwVBPshzBxMhB1DSxQRtJqLhpJ1skm+RQrcCmpGPcjdpmSLTqsNbB3sLobQS jCjc4dPPbN0toU3k45tOCCqkfPRN6DARBgOcygf4631YUCQY/zQPAaaInHMBE22LD0hgM60qe41s NsM2kAKynFFolADLxDZolACMso1pWjaDyXM0iV6B96k28FuSAYrI8HlO8jUMQZmhF0j8WEIhbwEU oxe8ygCKiLAppmbBLiLCjWgaqkAjIudipolqJOGKliYwM/QCmSFLMLT+A4ws8rg5TiYDGF3/F2vq AoAREQhFtgYkU5nOgKYee/qM+BHFgtW0suw7GQI6QzaQI7IESv0PoEoA0vk2NBJARYT5MEdDhgJs Kegc9ZgIY4tqBrSJeiScmaDNUA/khiyhRUcI7Qc0oQNerNCSSxYkAmDkrfLSqUm2xWIHLMpKcK1p Gq4EZYZ4IHdkAaXIVllZhsmCxMJKE/HIDmdL4qEFQTzIgBhpyicQlY/tD70IaKofCZ3iUCBsM/QC WSNLbOTiMJMs+eWhJrApGygi6jCTiLBLjq2ywSUiXCYtwajCKj04ysEgLaS7NoXnRC/4Vgt+J8Ho BfUxfgXBQhvMafEjBiKi1uKHCVRZebUJPzig6sbToxmXQ25IH4kTyuDDQSCZ2MSkXucFlYC3E0gg kZfwLXL+ErCIBNtBcgBA0ZpA96NCMsoMYUBOydLDiJ4AihGGS3tFLYgZj/YWQGb8ITZR3U0lzr1t ewmUL3FFQjZDH5AxskRGvQpkuuBjSsoYGs2F8D5d/YtTAiAT0cXLzVYwyzmsk4Spn89dVyFDpO+N DrngG5YAauTiQsYaKwiqUZpQdMAYtNzDO1U9XivdU2T577mQEWe4hpPcsuEzb2CbuEY+aGC1iWpQ i2E1oxrJB6/mkCLCFYR8K0o6MPC04vkL3BXSRfpWc8hFMhGFlgCZkYtk6QgiQDNykXzqGkSAJiIn oYGJcHzM2zegmfhEsrMmO83wCSSQLAcbjSGg0UU+vRhqaESEKZE6GWhEhBPjcn4XEYJM+cU9qhnQ tOYsVk/QZviFk+KyKVJcVlOOSz4ghaG+lV9oQfCLPFkUTccYbKIRYC5sK61Vm/T8kmDPUA8nJ2bD J4qwqNABGvLArDTh0meCVhCY4yIcXAIojYVcSENtBRHMmftiqUI2SncUhufESThI045vy02HS3Pn VLAckyoC28jvIxc+rQXH/BDZikTL5jC1CrBj/+fGRfZKH7ZDYDi5BWAbgUHkJf2LtengtSSZTlBV RdjQ0WrST+pxrZhsD2xSNY4GE7ZD2GYYDdJgFlNRckIfmgxsxmgS/YZGROCM+WEJNfJgOnAcXYxQ VQ8jkgjQVD0YdDQpQZuhNEh5WUIrKI3lzGQK2VWWMjN1mAAaWITD4NMDsi7spBQJc3Mxr5pGXP6I 7xGYGdqCNJglGBoNsJPRFu5IoFFaUYRqgEZEuDIdWxWAAo0qpINv2EUFCB7HlwjKDEtx8m82fCIC KEoW+FcqgEQkcPZi8VMRYlXl+JG3EN2ht4BFqxq/o5soEWGZ4SVIdlmahVwfWIyX8JIAMMZLmLLA LCLCHBg938yiCvHtd2xxkAGNysDHIlJCM8NLnKSbmH+nLgkVAI2yg2K0Ao2IcMknX5MJALBJwXET kKuHy6l6BAeoamBT/WCQcSATthliggyXhaWK5JuV5sHMfj4jwAa2iZhcwiYFwSfjyDC7iQhn0AQb 0EQ0LsuxtwjaDPlAMssSGtUNsyn5KIYNoBn/4FAqDCUifNRIkw0MJSIc5V1aerVm9Mic1ZC70l16 w3NiHHy5rK0s82U5V6gEkzGNE/xwoNAU7zRWRbj3kDsnfidQuQ2+dowKcyshg6UPxWERfJ8LUL6V RUwF+eQHyEQHBkn0JHVAewsbmmJwqWxkEdHWhG2GRSDfZemBtJYDm7EIvmeJH3qcWAR1OdCICBcC SNSbCNsz5sOwlGrMPtQlNDPEARkxSzTRc3Ua1LyZmCpib+lUoSLvrrKKMPHlrgUwQhywOyOrAYty CoQYczo86SBgMyQCyS9LYNR6mEmX9pRMGjARIWCVx38IDIwmBXHMQm4GnKoesZu4PgX9AKr6xyxP GZ2fAzpDMZxknU2yGpoFjWLwtAd/NI7BHyEDmojWTlzbUnQil1icHQyaasSlvygjs82QDCcxZ8Ob AJhN133PH0UEs+UHReRowCYFwQTJojCbqofZJmMYNBXhi4FoUYI2wziQBbP0SHIZQFNKwO5PBWE2 5QcXN9JacIxmZ34W2x+wAbZoxNYkWs1ga6twmyp2CcGeISNIh1nALjJ1VpY0M734E+oGUCMj7Aew oYhwUkHdAzBGP7b5FpWmAIxDVT96zGRtgjZDRpAis4RWkBHLsZmeJhg0IyNJWC2IAE1E+E0Kmo0B TTnGODVNLTZDqQxTa7RvjgYpMd1FOzwn/pHws1ABfqHXIh7M1PEbvSLCUkDWwK/0GgFp8nAcORp+ plcKgo7QqMQv82rNCDJ/08oQMng6103Dc8ZJDQFOIyccIQBODUGk7FWtpiIc11IXAJm8dTH3kxWs srAmmXCGmyDDZumQ0avNhMZNLkVvNGEn/Iy6BwY1psLfFwOoiEDuC+9U0XhPJ5qXoM0QFWTWLKFR BbCasgeH+KsIXx4VS4GKkO0ptir0FcCowuwL9yCDQ4oM1z4SXkpoZtgJkmqWaGhqAhqlD8X0Bh9U 9lB8ywHTiAiUmBQCjYjG/CU8cVhduPeWTZixswjZDB1xsn42HLkHMqUjeSsAy7jIhaxBVhB7tdJk oiPLYWIW02qzrxEI1wwx0TygmPHjDWfe2QKX0oPCLIAmouyDp9AsWExEuOFA4wwWU4XlVxfwP9WI 6EEahE0iWwRthpg46UCxzc1NA2hGTJKhG9oPaEZFOOYDaCJClCq/iU7+B6CqHp/40agGUNWPKz1T qwjaDPlA5s1inBU5QivLz+mNMyMfZcxK38KsEVfa0CEAI29hLOXLHXUqkBn5mMM1wzyQfrPEVTAP S+ZZdClMZszj0qeLWtDZxJl2JG6NZrGBpuqRq34GGTJvuiwkPKfVmW/VtJXl7UyySakvqsT7kEBF CM0U3mf6cNpExhysLlyIm8UyEwZBKs7SSjTEgcWYxqWLBloQy3F+uBebFfrgYBrB+Kmy3kROKn4T VZBFP82HGTJ0+kZzeEeROrSy/J5F7L0zkRfn1rfggPlYKqEJ7/Aui6gOrNSzUW+k3PShObyD2Tps aLwjmXzNIZUlFF4HO4kI179KMKoQvKN0SNWIcE80PRlqhncgIWfpkTQagMZ4Bw5Qs79pLBs2YyHl 7BhThF4ym+jA1ZfodUE9Rp62I0szR0BnaAjyb5ZAqScBVPlA6hYGzZgIzaqwmvELXqgwulQfgnR5 VwGL6kNsL86WhGWGejgpQRsOAgKLMgVEQjObUa9irClt4FNAIBOJF3407d5JhSnMvvMmaDPUw8kM 2iSzT7AFoCk3wMdhM0THjKZEIT2oCyJgE9HlKxRacDxlL2yo6seklpOMgM4QEaThLPyxyBBaWbLO gp/DakZEkpsMBk1E2ZFDEMEhRVRhGiE/hkeqxuy3LQnNDP1wcoM2yTFvqBxmExIA6hqnqSACGqMf vEeEoUTk3cFX0RgDLziiybC3mTENcmq6M3x4TowjuS2pYCwjZxEu7MCgwiUQL6eFijCiihneFIKp xBaHyoZJI6hVNFtuGuTZ9NE4nIMjtG2lWToR0KeOBBqLbiQ+Hpp1MBGiG1MXB0lvEliG6wIYVYiD qek1wjJDK5Bvsxw0RTjDsnIWUQpgEUqAPVfsRsMiIifNjb0FHpTthMvUI1bzt349i/Savs0cjsHB eNhMKUFxxxI4TZSsLYZTRJ7N9CWMz9IBRQbOmxxMk9FmKAayb5ZGi5YPzQIYoxjJh55BBDBGKi4k kreCGFy0xsEfVX15uA1/VP1Z1JiwzbAK5OEssdFSD2yy1GMsEGxgU4KQ3pE3Q4kICxS9BTT6Fi4e kR8DjcjwVV/y5TShmeEVSMdZoqGpGmi+lVdYds9iHGLiEB0jtoyblEilIAZUXrB0UCkIRp9EKgj2 DOdwkoniZGSamsxBjXOU18A0/Sfme3oLQOWtjOQFhTCiKsShEsGGEVWGn6GIBiY0M8QCKTgLIxa5 QitN1Ilvrqgn4ZJGLHgTAjQiwtaLJl2gUWKBz+GoE4BGZc9cP0T+TX8mdOIa/HE8XFIoAgZ3bjWA MV5BgxJYRAIs5Uqs6vCZDMmARRVm60RuGSTUdLGE58QreKZtK0vH6WxBVISL89TFB3sLn3WQL/Um qrCXpu4ZJln2K7GEZoZXIN9m6WfUXUBjsQyqujMJqDPNMAAjLyErcMErVIR8htQFwKK0Yj4oiOSa vmEcWpFE8HUCsNSc6bdZQQQsRisuBWK0oBdxMvVwYhpcgKb6YfnYj2SmGSrhpAJtOJEfzGR8Ibmk ZNh05U8z7wQR7CQi3CLKj9ap/XBBKehleLCan0mKgHybvtkcYsEfVgOaEQvyJVhNJE1xNgdkIsKx VD6hAIqqg5loSoGZRDZ+UJ/tS6MSstkMq0DSznJoUW0AZtShXJBUhMBgXD3MZvIWDoNo2AGaKkyz U4e3gExF43cEU48QmBlSgSydJRiqG2CMVJSXd1U0Rjmnqg2M0QhKVlPOgUYjOAgJaFozwoTxNYF2 8/TxeDwfbs+3r19+uf35+Kfbx5/vPz9dfTp+wJnPuOm8vnq8//nj9B/n0xf8Mtz11U+n8/n0EP75 8Xj7/vg4lkbhD6fT2f7jRnT+cDz/+uXqy+2X4+MP9/84huXh9Hh//Hy+Pd+fPr+6/nJ6PD/e3p+v rz7i+T9OEHw6fLl/db2q8fuwm22NyeHqt+Pj+f6uFKCS49fzH5/O4f9f/fqI9/53g9Fab5vquzeb dvndevyfGrkEvttu66rddsvxjOL/rq++Pnz6/PTi4eur64/n85cXNzdPdx+PD7dPi4f7u8fT0+nD eXF3erg5ffhwf3e8ebi9uzl+vTt+usEeaYf/vP+MTfDD1xd//uOPV386vQcyLIv/+fn4Z3Rk+Pff fkCDwz/RSryLNo7/Gxp78/vp8ZfQ+6//XwAAAAD//wMAUEsDBBQABgAIAAAAIQAwD4hrEQcAAN4d AAATAAAAeGwvdGhlbWUvdGhlbWUxLnhtbOxZT28bRRS/I/EdRntvYyd2Gkd1qtixW2jTRrFb1ON4 PfZOM7uzmhkn8Q21RyQkREFckLhxQEClVuJSPk2gCIrUr8Cbmd31TjxunBJAQHNovbO/9+a93/sz f/bqteOYoUMiJOVJM6hergSIJCEf0mTcDO72u5c2AiQVToaY8YQ0gymRwbWtd9+5ijdVRGKCQD6R m7gZREqlmysrMoRhLC/zlCTwbsRFjBU8ivHKUOAj0BuzldVKZX0lxjQJUIJjUHtnNKIhQX2tMtjK lXcYPCZK6oGQiZ5WTRwJgx0eVDVCTmWbCXSIWTOAeYb8qE+OVYAYlgpeNIOK+QtWtq6u4M1MiKkF siW5rvnL5DKB4cGqmVOMB8Wk1W6tcWWn0G8ATM3jOp1Ou1Mt9BkADkPw1NpS1lnrblRbuc4SyP6c 192u1Cs1F1/SvzZnc6PVatUbmS1WqQHZn7U5/EZlvba96uANyOLrc/haa7vdXnfwBmTx63P47pXG es3FG1DEaHIwh9YB7XYz7QVkxNkNL3wD4BuVDD5DQTYU2aWnGPFELcq1GD/gogsADWRY0QSpaUpG OIQsbuN4ICjWE+BNgktv7FAo54b0XEiGgqaqGbyfYqiImb5Xz7999fwpevX8ycnDZycPfzh59Ojk 4fdWlyN4AyfjsuDLrz/5/csP0W9Pv3r5+DM/XpbxP3/30U8/fuoHQgXNLHrx+ZNfnj158cXHv37z 2APfFnhQhvdpTCS6TY7QPo/BN0OMazkZiPNJ9CNMHQkcgW6P6o6KHODtKWY+XIu45N0T0Dx8wOuT B46tvUhMFPXMfDOKHeAu56zFhZeAm3quEsP9STL2Ty4mZdw+xoe+uds4cULbmaTQNfOkdLhvR8Qx c4/hROExSYhC+h0/IMTj3X1KHV53aSi45COF7lPUwtRLSZ8OnESaCd2gMcRl6vMZQu1ws3sPtTjz eb1DDl0kFARmHuP7hDk0XscThWOfyj6OWZnwW1hFPiN7UxGWcR2pINJjwjjqDImUPpk7AvwtBf0m hn7lDfsum8YuUih64NN5C3NeRu7wg3aE49SH7dEkKmPfkweQohjtceWD73K3QvQzxAEnC8N9jxIn 3Gc3grt07Jg0SxD9ZiI8sbxOuJO/vSkbYWK6DLR0p1PHNHld22YU+rad4W3bbgbbsIj5iufGqWa9 CPcvbNE7eJLsEaiK+SXqbYd+26GD/3yHXlTLF9+XZ60YurTekNi9ttl5xws33iPKWE9NGbklzd5b wgI07MKgljOHTlIcxNIIfupKhgkc3FhgI4MEVx9QFfUinMK+vRpoJWOZqR5LlHIJ50Uz7NWt8bD3 V/a0WdfnENs5JFa7fGiH1/Rwftwo1BirxuZMm0+0phUsO9nalUwp+PYmk1W1UUvPVjWmmabozFa4 rCk253KgvHANBgs2YWeDYD8ELK/DsV9PDecdzMhQ825jlIfFROGvCVHmtXUkwkNiQ+QMl9ismtjl KTTnn3bP5sj52CxYA9LONsKkxeL8WZLkXMGMZBA8XU0sKdcWS9BRM2jUV+sBCnHaDEZw0oWfcQpB k3oviNkYrotCJWzWnlmLpkhnHjf8WVWFy4sFBeOUcSqk2sEysjE0r7JQsUTPZO1frdd0sl2MA55m spwVaxuQIv+YFRBqN7RkNCKhKge7NKK5s49ZJ+QTRUQvGh6hAZuIfQzhB061P0Mq4cLCFLR+gNs1 zbZ55fbWrNOU77QMzo5jlkY465b6diavOAs3/aSwwTyVzAPfvLYb587viq74i3KlnMb/M1f0cgA3 CGtDHYEQLncFRrpSmgEXKuLQhdKIhl0B677pHZAtcEMLr4F8uGI2/wtyqP+3NWd1mLKGg6Dap2Mk KCwnKhKE7EFbMtl3hrJqtvRYlSxTZDKqZK5MrdkDckhYX/fAdd2DAxRBqptukrUBgzudf+5zVkGD sd6jlOvN6WTF0mlr4O/euNhiBqdO7SV0/ub8FyYWq/ts9bPyRjxfI8uO6BezXVItrwpn8Ws0sqne 0IRlFuDSWms71pzHq/XcOIjivMcwWOxnUrgHQvofWP+oCJn9XqEX1D7fh96K4POD5Q9BVl/SXQ0y SDdI+2sA+x47aJNJq7LUZjsfzVq+WF/wRrWY9xTZ2rJl4n1OsotNlDudU4sXSXbGsMO1HVtINUT2 dInC0Cg/h5jAmA9d5W9RfPAAAr0Dt/4TZr9OyRSeTB2ke8Jk14APp9lPJu2Ca7NOn2E0kiX7ZITo 8Dg/fxRM2BKyX0jyLbJBazGdaIXgmu/Q4ApmeC1qV8tCePVs4ULCzAwtuxA2F2o+BfB9LGvc+mgH eNtkrde6uHKmWPJnKFvCeD9l3pPPspTZg+JrA/UGlKnj11OWMQXkzScefOEUGI5ePdN/YdGxmW5S dusPAAAA//8DAFBLAwQUAAYACAAAACEAPWg1WM9kAADfmwEAGAAAAHhsL3dvcmtzaGVldHMvc2hl ZXQxLnhtbIydW/MbR5Ld3x3h76Dgk+2NAdHd6EaDIWlDuAMbdjjW67FfORQ1YgwpyiTn9u39y75U ZZ6+kHhYzeJ/WKiuk5mVdSqr+vt//ceH99/97e2nz+8+/vbDi2KzffHd29/efPz53W9//uHF//6P 6x/aF999/vL6t59fv//429sfXvzz7ecX//rjf/5P3//946e/fP717dsv39HCb59/ePHrly+/v3r5 8vObX99+eP158/H3t7/xl18+fvrw+gv/76c/v/z8+6e3r3/u/tGH9y/L7bZ5+eH1u99e9C28+vQt bXz85Zd3b96eP77564e3v33pG/n09v3rL/T/86/vfv88tvbhzbc09+H1p7/89fc/vPn44Xea+NO7 9+++/LNr9MV3H968evz5t4+fXv/pPc/9j2L3+s3Ydvf/TJr/8O7Np4+fP/7yZUNzL/uOTp/58PLw kpZ+/P7ndzyBDft3n97+8sOLn6pX/1YW9YuXP37fjdAf3739+2f3v7+zAf/Tx49/sT88fv7hxZY2 Pr99//aNPfp3r/nP396e3r5/T1NlCWn/r2+W/02TL1Ob/n+P7V87kv7np+/+9Prz29PH9//n3c9f fsUaMIaf3/7y+q/vv/z7x7/f3777869f+LZmGGw0Xv38z/Pbz2+gwTrDj7z5+J4W+b/ffXhnxsQY vv5H99+/9w3u6k3T7LZNSRNv/vr5y8cP4y8N/3z4h/xu/y9pYvinfPXru59/ftu3O/3HL/sf7x7z /PrL6x+///Tx799hUhVD8ftrM9DiVUF73SO0jN0b++vR/tx1kYf4zLd/+7H4/uXfGKQ3A+I0RZQR cZ4iqoi4TBG7iLhOEXVE3KaIJiLuU8Q+Ih5TRJsQLxmwNGq71VH7yf78wwtYTKNWFjJuxx6zZ0x/ +fGnP17+/afb5b8ci+bVESv/r9+//MXGerspmqYqd9t6O3zkmU6ule7Hfn396e3PL3qXOe1ePezv 7zpnGH/jxG+cwm9UVVXsmqYYf0NG5bzwG3272LX1s9m3u3Jbt4f+0+Zx6+zo8vU2ik1VF7uq3RL4 uo+Y0fXrTZSbfXEo2rrc7/puyGjdvt5EvakZh327HYdcDPH+9SYKZomyag67Yt/TJtbecfLDi455 z5kbz7LYtIembfeHom8iD2cwQyxsxXl/sj+rGW6TQfcO3mN6M/xf/3G+/HFihOVmW9RVfaiqstjt 9odDe/mDcHNyrfhH6kLsqX71sL9jhsWLH/vfUCPcbbZ1ddjv692ex26qej/5jfPCb/TtdmbYbhi0 7eHAuGOOmNK0lcvXWzGn27a4w2FXt3VV8OhxzK7f0gZe27ZFUfIw7WG/02j1LU001XZf1U3R7nio XbUVa75/vY1isyvbbbGtGnpQMjLCW8fLgikWNuf87cdyc9iWDQPR1NtDaeORBiOYYrNuivZnM0Wb BruJpf9in7446Rdn/eKiX1z1i5t+cdcvHu6L0P39evftz+pJMpbHHtN70nH3h+q/HSF9DOOERgL5 fruF0LrZSog9uX879Z/9q4f9Hf8pX/x4spZPuWUmFuJd2dLuodplcrpRPi+027c1hO7d9lDheRjp vtk17U7M7PItbbR4Lb5bNeWOyepQSz+uX2+j2Ox3u3pXtO1h22L4jQzv7etNVJum2Lf7otgd6npf 7Atp4v71JprNvjow5W73ZbOr9tta/LYjYsFhukSS/Kja2EMUZVkc9hYxF2K3LRyWE6+f7M9qcTKR HHvMaHH/EiyuLG1KbsvDgQeBFJnHTu7fTi2uffWwv2NxlVkcLTuLg6V9w3RAu1v+K1SfFxruGxtM 7rDb7wjybVmXlUVYNbmvt8EEWe22ZVFtq31dM9emqNQZ/vXrLWAth6olPjfbQ9EcylKi/O3rTew3 dKFklJvtjkBbHsSt719voqg3GNuegdhbrK+28iAdDwsGV/URuiL72tKHiimr3BOocy9CiDusG5z9 OUTo/gsXofWLs35x0S+u+sVNv7jrFw/3Rei+rbbWHKb7u3qMWP1xAPUu898f/2OS7DD5l1ucNprT yf+7qbsU21ePDoHD7F78aO1qgrPdYCjFfsxtSXCF6PPST5jj7Hqmt5saoit8evzk2NKZ/eWbGjkQ GYlQ6SPed/2GRojWfGw+Gz7yNLdvaKMix63KbTM2sdVw/Q1ttBsytR2tjB8JkT0tC/4zjGpB8lnU Ncn2+EnkRwNkdbxqgPZ3NUCZP462xAY0GOBP/3fGAIlEJP9jX/hv6k7H8ck3MWOLBbZoP4LZ1Ngi PzG1RUJ4tZN2z0vt9i2NkZtolRaKDLo4yuUbGiF014dm66w4PuD1G9qoNkxARVvlUYpt3L6hjQb7 2xK0R9NRj7x/QxtFs2HZYkn28BE/6KlYsL8uG/7bjxUJA7F/m5wptxHtz1SrlYyhsL8PETz+Q5M1 1v5hL3uwnHByhQSFY9GDmk6vwIxfEkuH9LbYHFgkFWSi+JCtvMSRT/7fzlhshcVa61gszWPfL4m3 uW1SKXLmQ33YFhWTfST6vNR231pntRjcjkXcwdJb8o5aLf/yTW0cil2972b7PQshXUldv6ENFtIl aWG1r5hjSBdKCVa3b2iDwEtoQCE8NNWeRWEjbdy/oQ3rB9F7y2i0Tc3yMicMXYTp2ejI+P4Xz5cb 03JTNQ2ugwuyOqxZQCReou3ZInXN9vpFLKpKsj1VKExQxa6JaQmSPWQIiVOI2OB5phUZussMRMLb dQYiBnmbgYgv3WcgefgGCqZPlOf6OMK2pHUjPCywfyr6pS5BIQ2bRHzUxm5kbTLqtEYM003HGg+Z RgK8xOtNKBs/MpxngSMw1mV+hu4xLwGDWrFFLCmWgvo1oKsNsgZyebK7rsVbwNRdiDePGT4yzPeA Rrhr6KLLjGLbj4Aud5uaRZaqMk8DpRG3OObV8n/jrzbYu/0GOYBlyzh42VwjubZknSO3X8p6cicC c5GXux27ULWSf54EzpqxZVmUPsLcWeB7hMq9m9LF5C8BDtEE9VbIuAYMWi6rGg33t4BpNmVFOM29 lF+9B3RBk2WNEUZKHgFUlhsk5HI3Mxl39vU09Aq9vS/tmg37OEm0R/VJvxnptQXiHL39wjHQK90+ Fnlx2dG7Y4bLefDUeSMcM292jq8JvRHOkp+V8misiOPpeQY/9nDorRBfF/3oGrpemidY5Bk/8qC3 gK43KFUs2JNdSky7B/QBQbhmQTw2raPyCOjiwPqK9QQD2X9kUJ6GXuHeds1wbZZ6iEh5tPJkFbm3 he4c9/0COHCfzacb7mMxLpKHwF3XLAwjJSfBoBE2hQzWWTCoMc1BHvoSMFDblqy34m9dA6basGHF GjNibgHTbNCji0r6fA8YwnF7qKvFHP8R0LZl0iIhyiM+DbTC2aHnrCaFZdmfDCU/YOCsFA1inGu7 702edT8lz3YcMGmyPZTsMMQxOglmx5qgyOsTXSCfBd6i/vigIwxcArxg9iIW5gftLOsaMOWmJtc9 pFHRDtwCut5sG+bPasnZ7gF9wEpqtiZGX9Nl7iOgyy3CLPn3UttPQy/TzF8H12QlQUAYm8kjFGm2 9fOMa5b94j3QLJGQ3Vv+bb/g68IyP8aeVPrkX+zGm43YALdndEKEOuNZ4KbWH9w0I525BHjBbLnb ttKDa8CUzMysq7PNCfoW0LZZ2jCVp6eTOHUP6AMK/+Gw3SW0RJpHQJfVpur2P6OLPA20QjQ7jBaD 0QeatsiTSn6MSDRUzhJt34s/S25x7IpIPNFtWQjmJBgTm3duWhT3Pwscc0eWSsOlk9clwNl0ZnWp Ef4aMLY/zho6syvefwto/LlmcZf7K093D+jDhoSidkqc2OIjoJlq2UCodim4iy08Db1CMxth0Fwx YWOrLIaHT84oI80igKSw3Wsa4adyE/1UW/aYFLbZuThkpVCj1kngZAKsUsbuEUqjNZ8Fvicm5hg3 TbMCnIIJtAy2dcdPNvIhlvuus2Dfs6smrNxCizCON9c5LZww7lu05RJzpqoYj9BkWdsWtLM56eTT 0CtEs/9k/tyQyHVFFeNQpnGMRFt1xlzg7qs2AtFicccyV3b0+TS7mDmyqfOdBF4Sh1m7ps+E6Ng6 02QlkIu0SDa/QyhNH+nvNcBZtVQsqHJ/J57tf3+3Ia9g6Zo+kqvcQ9tsaCLvNKX09xFAthreowGK fT0NtEIvuyU9veyU7vO0k40k0muiyBy9vVgSLEli69Fq6sK8TMHJcmw9CZz1DMJhGi9NhM4CZyVs FTPpI350CXDm5ZaNcxm5a8AwLxN0luPOLaDht9gic6b+TuZlPxhE7j1rpDwv59Hv4sgjtG0LZEKa U0mSK3bop6FXGGdPwhgndiBGsHM7fLJ1R8ZNcppjvJeivEOXIrUcyyhXFTyjm56mDh3hMIj+kUZw yniEMyuwuzc+DTVScVQuoTNEbpy7WYncvnGycMJsKz56Cy0idNl23OLv3wOayL0v2I0Us3wEECk3 P4pTxyd5GmiF30Hfsj0NKlJSj3LwiPwu6FvlVN8qxSyPAybNzDUrhMzXlN8oh7EbW3qJQuLFWVr/ 2sZrgJOLsZQshbFrwJjsgXSVBkgziVtAUyXA9O2cLo9n53X3gC6shG3fVFkliRw+IprJFc0rBwCZ O56GXmG8J6Da89Ata53RBrMHRMZNKZrz6F5BCh4tHTmWXmWyZywQjMff47/xKU8Cp36xVsXhLBjC IFWI2YrE+C8BzhIan3dJgljoNaAppDOPyCFF0LeAJm2iFirrwxp/7gFNNr2jGiebv5jHI6CZq9FB TbEdPtKTp6FXCB90rnpDvGOVNRKQfzMSvqBzlVOdS1PJ44BJLm5iXs5xpi4eZTE26Vg+jd2bxOSz tE42gP2OY8JqKprTJcBNwt6joSa4jOE1oAnh1E5WYk23gGExTSnRIXMov38PaEJ4TVWnlrg9AogQ zoalW5RJJ5+GXiF6EMcIVZQL5P3pnE0EoqsFcaz7Pi6mNTQeB0wiml0gzY9PgqFOr3D+oXSdBd7g fLWLtjk8dQH0EuBM0NW2dhsLElquAU1yRm+d8ibM3QLapEaqcZd5DmhCOZUah0VR7RHR7cbGpJaZ 52mgZZ7567Ca5jmsOnX4LPFsktVMBK96KStEcLH444BJPO9MBB5/b1ITdRI4a+mW2pj0yRGn4/As cDLgHOP4kfw8A+VeeytYQTVsyafGJ5R7tG1/UyHqVvYxWNxCV3YmdrCrlNqWjt8DGtdmX38i1D0C CNdurSpfzPhpoBWmB3mM7BsZ321dRkeGwlmC7XtxZEkhj1WPyQRbIW567skULfCKfSYnPyj8LHDG lOMeuXWxtkuAd+dLWrdFJsHwGtDM1mxiWMn8+FGC/YM2iG9W/5wsWdq+h7YhuEC4ybq6oB8R3SKE ogqneU/QT0OvUN5LZSy4tpSH50Kl7AyRe1N45py7V378T6kgcKx6TOJ+T7XOcBCnG8Q4gieBIwZa Sp4+8phngVNPTwHLSM5kcr8EuMXzgjVr7ME1YBBHTb/MHRb0LaBJfpB72YlMn9j2PaAtIafQrBRv eQSQpWU0mUsqZASehl4hepDKWPxbjWgayTwZRaJNEJojuheKAtEyEsfKi0k8GmsTnzRLv08Ct7ms kBnqLBjW3jpYlwDBhfZUYUkgvQYMjO6xqcW58xbQlnETEpP96XRxD+gDZw3Yt46kPwKEEG3TlYtn Ef009AqfgzbGMtwKHfPElFqJfJqkM8dnL/UEPmVqO1ZeDurXVRp6T4Kxon0tuj8LpinsKEb+CFmX ALeY2PjpVzp5DWhSrh0endkSJm4BTXi2oyV5HpKe3AMavbNkD6wW0COCDtSJ1NtmhpYuuXgaeoXc QQZDJmGJYhle/8meFsk1PWiO3F4n8uRWKoNVXksyctl2TcFhJuWK8K4WeRl+ltabsuVsx6IPXQKc JYydTEvLUF3PXQOaGbkicc4k5rHqRvwW0GTZNnln3xcDuQc0M/IBgTdnohLCHgFNoD60213emRf0 09Ar3A8SWWvLBo5NfY37BYmsmkpk7mxeNyTHAZNm5B37iWm9zu+mUNLBTwK3U1iFjPJZMKypKCZd Idyrbvg41TVasnoNTSIvcwLXLQpkcG8BjS7GZJc3DtSE7gFNBRhnbSbLo0cAlZwBQxCnknn4SAee hl5htx/sXctR/i366chuHuvo2QtyWDWVw3S2OQ6YzC6KrqTAJ8F87RCKwFE9kXiilVwChsyKLU6N ldeAKTccs2J5nIYij8XguV7XYxPSDgLn/LTD3EOLtipmYTG3v9+hHwHNlgVBr3VzUXyip6FXGB30 LpO0/TZJjiiR0QW9q5rqXZU85HHAJEbRg6ZOKiIXeTDlZvkTn+0sTdamEuaF6JRc3zrkljsO08cm r6FJkiwCuNtMFHe5BTTlexSuOx1GJtl7QBvNZBl5upK2HxHNYSAOw2oJxNNAK+z2IhelBBR9uvVK jnuB3d2CyNV9H9fGqjUfB0xil+MEWo1zEowdC3GT2ETkEjjhGlEs0nUJGEIwiwzKBcePDOk1oAnG eE6R90mzzfeeG9CQu0OfTQtV7e09oCHXTn8uLnceEU3BNGctnenGp3waepll/tpJXC17rTu2AdI/ juSaxDOTZu166SekWRJojwMmk8uJzPQr3WCdBMKSFJUzO65ExbPA7Qy+W8voTHcJcDwXyYnjpONn QnNUs6xMhdRt/GTjH2j26K+e24s9IeXk+M3yXlRAs2aiKL7KCbEMytPQKzQP+ha6N5cvEAqGT44y kW8YneXbvhdnFjKPux4z8l3a5ouLq9Lvk8CtVKQVZzoLhmIgdrhGAqfFQAHe1VyzFxVN7howrGvY JKZSJX0i+hbQDQscKxJPYBmBe0DjzVbngx0NH+nJI6JZPVl9Xk4JYk+ehl6hOWlaLStGprThs+TW C5rWbqpp6abDccCMNFMRUHHHTP7Efp8Ezsqdcqqxe5MtpbPArbDdyQU69V8CHMZ3pHMugMS+XAOa 0zLsl2jCcQsYbp9iOVLmuSGPZxcG7gFtjLPt4VbV8fcfAU0dGMXcHA5MQxfRT0OvMD6IW0zxFLEW KatecuwFcWs3FbcqiXXHAZMZp05RjPkkGAqJdlrvfhYMs7grz5oenA1wwjfTrpumuvG/BowVZ7Pb no1LOnkLaM6pUsHl5dg4/veA7tbDXAqVTFfafkT0AUuw+wvGvgj6aegVbgehy7SQus4C7BK3C0LX bip0VRKFjwMmc8uSX4z8JJiq5W4IN8qToB21sz0l8IdJBuYx+C0aid/GikxcQwcYlAOVQnmFLWN7 C2iELnQrr6LFtu8BzXKYK53YJF/wyUdAU5DNCdjCNR7bfhp6heVB8dpv2MNv83ohP0+cmk2GmkvF ennKTw87Vbx2UcIifbUC1PyJ/T4JHD9FUxhNeSKQnQWO4pWFIP6VmNMlwLvCoIPb489PP3i47zpL KzbpfB1h7PkttE2AZRmW0+lp9u3bJnoDn5QPhBbRuVD2ueQlDV38/aehVxgfdC46hkKQW1ny6wWd azfVuVR4Pg6Y7Nd7bgBKvdZ59CTwHQfX/TyaO9iRchb4niRgNRGPkhdLIj1yeA0tIo+QrLtSBjGK W0CzTbGtTCIbP2Jw94C2RRZluVrE9wgg9JG23lJ9MjYpHXgaeoXnfth3OzLALb49tpI7Fj17QfHa TRUvvUjgOGASz6Sz6nAnwVQlyyBnCzLdnwXOUXb2FbLpyDLvEuBU7nJhlr+rIzrINaAZZe7o2eU9 CxnmW0DXGzZP2I9MXZGO3wMantG7uXFuHHxp+xHQVjyAapuNSNBPQ68QPghiqKloqS7xiTybkjQX wXuFKUTwbCqdxx13XoWyPYuJCHUSCFsDHKcen34m044tcnCKC6jS2E5ksNA6JwtR+zstbvgXSrNv vNs94jqM1LgQdwttExzZBHB7IDIU94C20pAt8k38/UfAELXZRneXQHVD+jTMCqVDqRezM3liSuSc cwVu6wUVrPs+Lpz1KqXjgEk+bA8v9ncSDMUz7DCnAdXi6rPAuRCMorc4RpeAYRhtDZG8RTtwDWjk Y5sgYoO3AGHpRLruKu7lie4BbTcOUQpKZjl+YtuPgGbpZMVGWeQVg3oaepla/mrSV2270aU7XZR7 GKk1qWfGbeteAgpuK3Z4HDCJ2ma3Z+pPn/yLnUmeBG41C84lddY+C5xIHYRv6cwlwLvTcaTdcZyv AQPNpKW5zkaN4hbQ5EbcHcRdTekT274H9IFQyco1ryOkt4+Axj5wQisvGT4yck9DrzDeq2AVD0Q1 1TYxkC04Mg6ns4zb9+LMogEd6x6TGK+QtN1kK+uvk8ApsqzWgrbA96gHeZE5TbUDnM1lLrbZ52fu bO4aMGwpc+3XysZUQLOlTMm+O24rS8F7QHOqpuWAQY5aE8b90HW1IhSnJWOa+DjoFcYHQcxu9mHL cTSbxfC9IIjVU0FM7wY6DpjEOC7uMoDBsft2RgzZv68J0IXJWZokXfNT0OSuiQAnBbO7S7OsJCZ3 DeiuBt8Xbckw3wK6YTKkXj+3LdZ/D2jmZu6pqtylGjEgPCIaBXTrbEmDzdPQK4QPelhpu1as4EfG s0lGF1/Qw+qpHuauK+3IPA6YkUyqnlqXZ2m/TwJnVwHFdOzeNC8TOPJqwx0O+RPH8BLgzOLUya7N 4v3j9V1H7GAL2FXs57HqHvQW2iaJIpS5TEjQ94BuqTQ7EEtSv8WuHgHN4eeypnYxp4jxKZ+GXuG+ 18s4cEOeN7uVGrk38WluQu9FKR9X9PKMY+2FK/LwA6d9c9KiM/RJ4BVces8U1zwLfM9pMfc4BwmY lwC3szc8vGCuAYPmzW5fPmOu/b0FNPsdVBS4I1YTb/eDgXbGzUNiFI/QIIIZN5CT1IxWIUbxNPQK zYNgZldcVuyUJhuJ7JqoM8duL/Z4dmvVyWovCMEu9+Ot7EeeBM6lPSyJUq86HzoLhmpWynPG5+e/ EX4JcERv7vSVVOcaIJxERpFyNWDS4C2gYZQsijtGxo+0fQ9oGGXvwy9nu0d6RBCJ3IGrdEQiehpo hcp0KJKaIJbpaRQilQsCWD0VwPR+7eOASUHakmPxjZNgOF9WeHeToTwLnPOEnClcoVJUL3R8HyrS I3eDeg2NIyxzdc9aGubb5uogU1Fy8BQu7qFtWKXagSQlduARQCyZmUHd4S8xlKehV+jth33HNghV Y27HNP1m5HlBAKunApgKh8cBk3hmhmokTp0EQ4kFe/uLxJ0FzgWZJNmp5x1dl4Ah9DKkKplcAwYR hIM9fi8ztngLaDJripJYDYwfGf97QEMpN1lwoX5s8hFAVPGRjFEzEUFPA60w2StbtWWV3K+Z/m3k z9SeuZDbq0Ah5MpAHmuvFBFyqa1pxPFOgiH2r56LEDh7gnsWpvmTHmKg0veADIqSQdYp40cG/hoa x5W4g5Ui+fEj6FtAs+PItpW7NEEmy3tAU3S9pdRMd2MfAdStknjAFNGlA09Dr7CbLvviZn6np2QC As/NgsjVfR/XxXrg7jhgkp+yceYq+HUePAmcDJvDyuMoT7egBG53uPo9qDy/9JQHOKaNY+oEcg0Y m2aplswhNo9Q1+ItoO0KZPZts82Jz90DmmUSMhQRKdrlI4AIyFRpEYgi6GmgZX75a3e3BAemmHty 2pH7E/ldULqaqdKlr4E4DpjEb8tZp5XEWODcrcnN59lFZXjPAmdPj9r0DJeAfwlwi862JZGsR3zk GtC2J8F+9dxYDUz3g9E/KEIkx670ppJ7aJGdCMrOkLoidY8A4rI+rv/AECPoaaAVftPlXlxjxosO 0oikViK/ROK5ON3Y992Lz9JP1TKkxwGT+LVENm/cTBa9Aqd73C6TetWN5FkwvKfh4O8Ckx5cArwT s/xqdEJq/0x9fyGV01N5O0+7ewttM/mS+7g1urR9D2ikSepxubs6Pt0jgJh8kTaohBiNUJp8GjoN /uSOXP7aKdbM81hnXoPnEY08L6hZzVTN0jr144BJPNuSZs2PRdhic3Hl0pWztI64gViVrFa3MS4B bjs9Vg0Wx/kaMJbbMmfm0JAj3eC9vr+cWmF9ly/o0FnoHtpGv0ScdSm8LCceAV3wKhTedcOV5MNH evI09ArjvZyFpMEpUHf4Y4nxBTmrmcpZmgAeB0xinAHMt9TQ+TjeJ4EzfPkZ7VEj/CxwslSWq8OQ 8B+Zzy4BbkVfSIIOHhu/BrTJWWwKSdi4BQx7yJVdtDy6oVt5dvZxD+iWO4S23KCa0GJ7j4AmF6u5 tspJzF2TTwOtED1oV1zcxyouC2bZXKJrm+Qyk2o3vRTjo4i+pO04YBLRFG3oyaOTYOw8SSt2fhYM RXzUFqcx0ue/BLgdauTwptB+DRiitanMMhXeAoaij66IIf1sdoyByKBNYUlk0hr2H6HJkoJ6tgpc aUS0tqehV4gc1CnOwaI1FLk/kb8FdaqZqlONqlMDJvHHAZ61mh6Bsze49UVfQsFZ4NRZ293B6ZPt sRvfS4AzGyNtunJ5iQLXgEYoZF9HTzPfAgb9gb1Bdyojj+fAr5fq0KAoDl1O2h6h7aKl4o47WpdD 86p2RVvdyQmud+LCYBfBItGm0Mw5aq/ceEdtJBk4Nl7dYU1MZYYeOToJhqsOSZ+TN6gTngXuT23Z PxJfuwQ4zsP7NfTc4zVgkArtXt+0DlVXuwW0nUWl0FJC9T1grLKje3ne+FAySo+ApmLLpv0sbQr6 aegV5+2ditcNc+kiNyRNfzOSuyBYNVPBSt/adxwwyYs5UaAGcBIML5Xwd+NNtgsFTjEpWlPyXJ2S LwGO6yJ3cE1u+sSodw1ohEnuvXQzogzzLaAJ0lYPkNNHCSL3gLZ1Eicm9CUIjwBinVSWSFFpTpYp +WnoFZ7TyUV0de53mz505NmkoTkn7iWj4MQSoI6Nl5VwYl7r57YsuiB2Egz5CzUzqU9K3FnglKv5 g4MuEg0h2vfAcil7wY2y6zGoHCY4ZdVRBvcWOsCxVHu5cJ4jZEa5BzTskndxg+zUtbrePgIauYNK xvF1wfwTsbOnoVdoTroWLzK0Utvhk1sJNO8XdK3u+6hr6dtVjgMmubOlcNnglcKTwKlbzbcM0kkZ 8LPAqbag3nzRQC4BTvzkILg7UaSTckAzKXPZU16galduAW0HY7hgb7En94C2+1QtKGV4tMJHQOPi 7CNS6xNBTwMtU85fO6mLizztDr6Uj2a3jJQvSF37qdSlxYXHAZMotx1NiWwnwSAekm+MZjgp1DkL nBdJhdc8iNdeAtxSatROwVwDhttByJCc4Cr9vQU0yZddIp7NWD07oG1dzNWpWXySnjwCmnVxdzBm KQ48Db1C81DJZRIrC8kUqpY8mxA9F8D39r14tnT7OGASzehz+tLqk2CsrsfHbzHhs8AbCiTdUWLd n7wEeCdTN/pO1mvAkARZQUemYkJz/9z9M1FTRw+0BPAeWqQwgwsi3GqmD9YBQ/UGNQXdC+V6D5df fRp6hdJe3KpMpEYxSYaRY2H0XFNwZubkfa/s+J/Skt/jgEmUzr3YVDDo/qwscuSSZzsLvCH05KKX 6SVcAQ6leCXS6PjJVtwN8zWgSbGZLvLRf50TbwFN7mVXhmRrlI7fA5rrUimawrrGjzjDI6At2aae 2t0kqqF6VduirS5UW+1Z976O8UdTK5HwBW1rP9W2GnnI44BJhFvGNA42/5XxPgmcLRN3ITe9TB3s 6DkLnHtfwnl00U0uAc7sjJapHb4GjDFuGfE4PqqP3gLadoioi0lgnRHuAU3U5hCBGwwZi0dAMyej t7i7AgX9NPSKi6ebu3ghEXeZpD6mAY2ML4hc+6nIpVnCccAkxu1F0mmxMMO4l4koCC+4sD/7jA74 WVpHL6JmJD2NGsglwElruvq5DE9PP3i774s5x55DpMlaczjs0LfQNnv7vBvBvcxO0PeAtrMxvKdG 39j5iKCWbZCSSTb1N3b3aegVygc5jM1NVHB30W9kekEO20/lsL3KYQMmM80r7vNwTX3bC0Z2Ww7r 7rTOn8m8I5zX1HCEJA3FlGkPp7aeBFZ7cA0dxrc5Gbvc31tAd7c62c1j6RPJuAe08Uudu75b8hFA duQJESyfLpbo9jT0Cr9DBRcF1g2FoV9bSe8X5LDu+5iIafH0ccAkouF5dYkV1TOu3ESWT+Omq+Sz tM4l4HZwKn0mQdy3jkuT9yxvIF1D41BOzHWnpmS2ugU0d1/aZa55YAV9D2gkTapz3SVhed3ThYtH QJOxsT/PwaYxukzC+apaRluDAmobpW5+SkYZnXxBLdtP1TKtHz0OmMQ9NXdaqXESDFVTLuDPrLX6 nx2bpFaEKr5xICYzxCW0TsZGfZB7v5cM3DWgu+3anfMwcbFbQLOksSCeuyIU3gOami87iE+19/hJ gz8Q7h/T1tQcaNX1y9OaXPHxQS3jale22r+emZuWNJeZ9xqTz8y1nu649zqUlYFxkbtjUYb5JHA7 ZKOFUmfB8J6xcJWIuNMlwFFFyRvyQaFpLPf9ZXXN+KzFco9G2rJyl/yZrK49Gp7ZiGFzZbRQGYpH 6Dc8c52fezGP5AFPQ68QPuhmFa+aZds/dTL3MDh2u6Cbdd9LUJcdhuOAGb3QZPf8K50FnwTCnROh okjgZ4E3dsYmPQGjHf3jEuBoKFy2milR9DWg8WtLKlP0VOu4BXRDeRdpfEbLUNwDuvNrrulMcOU7 oKmoJ0NrXBlyfMqnoZf55q/dSoyKeg4yuMAaaV7QytqpVqbHD44DJtHMBe0uFxx47tsZMaQ5pd0G NX7EUc/SZHdZbF5CT0SUAMevSWqXLw+5BjQb0YTX5fX5LaCpJuGVY+5clzB3D2i2tzh9w7muJb+O aK5GNaOQsXgaaIXedPkX8YbDf+NP5aAQeTZxaCZ+t/a9uLPoA8cBM3JYxHioDnISuN2d7M4hqfZ8 FjgzGcJBtPSLYHjdrl8562L4GuA2UbfcODGanLr/LaCtOJvy1eSh+nT3gCYZ59hlpaBHANmFE9wN vdjk09ArRA+nHTmCS9Dm4MDwyRYYiV6Q0NqphLaXKHscMIlotHaXDulTngRuZ/X9KkZaPwvc3sjj FqCTA1ABTm5mr3BwkSNayDWgGXBcLw+V9vwW0HaNEPc4JrlZ0feAhnI796D7248AYqq2Fx7k28LE oJ+GXqF8ENF4ryvV7fmEa04aI+ULIlo7FdH0ZMhxwCTKET20JugkGEuGuFU7fXLE6UL+WeC8qIzy gex9MhSXAIdnaPNrNOW5f6a+v+RmZETuljVp+xbatje8ctfycg4e0Mazvb43mUX2tz4HD2gr4S5s 8zo9Z+z309ArhA8amr3NgF/N6Uzk2TSkuRjea0s+iuxzE11vj63Xn8jBWedMbmMVDJeMUA6QaJ4G 7tgkJzFIyTJcF9ehdXKyrd0Fn4ZL+nsNaCsaIwtIVKiH3gKatRZxwtVyilXcA7qw3aY96urY8wnP /jFLXuvMXlshD/e0Jlfo7fWymiK0sCuUPSfybHrTHM+9DuV5blU4a71WZTzjT3nm0YE7CbxbdcoA nAXTUIru3Fk1l0uAmxLO5TsTdn0vu3vZOGe4ZAu30CKZGLewu/1mmWbuAW0Fe2zC53lDiHsENLaA nkTGrc5Ld1fYHWrGOIBZc+JxJgREdhfUsrYXnwK7QsVxwKRoTX6sl5qdBMNVMt4A1ALOAje9K/vZ tHgswK0KgYta8t639Pca0JySKzlmllvP5t/FqFtA24WsyO8T3w0SHSVLVuGU90UicY/QIjEaZ+CI bgQ9DbTCbj/YHHckyWZtP4aJ3PnIrikzc77bKzaB3dzEEKO9qmO+S966vAFxaiPcZAR3TlTT3LPA SYrJW8enmShplwC39Qx3f4lfXAOGIE11jL7r7hYwdnEQO5E5eZgsl/0zWXZNhshcNX4ic4/QNpq3 3RDg4n5EPw29wnO65otLwNn7Sf840mvyzRy9vawT6M3Z2kCvl37oLOdKnaarjnlqI5xFFIvVcSD4 b+pg1/pZ4MhQ3Jy1CL8EOPSiiE1eGBUw0Is076rqxI1uAY33bq1mONmXDMY9oG29TJRS23kEEBdD UYDB4bv44E8DrdA6qF6ssTkDmRPyPHyB38OC6tV9H5fJ+ori44DJwdleYZ0GYMKvwDmSxAVSmTAZ 3rPAeZaw2MrP05nDJcBtFrYC3tx6HMNrQHM2lbM4+QIujcG3gLbruqhQynOAMh3QHHxFC7BqxeEj M8YjoInYnGPg5URjx2VQnoZe5p6/dgqYHb9gSZEfPz195H5BCjtMpTBdIh0HTOKemzXytc30Pv1i x85J4JRLBz1D4GeBk3+Rro5jwk0ssfVLgONalIe5WhFp/BrQ7EwjoBWJHk36bwFNOLclVUZPuPfq H+EcfY49+9Tz2O9HaJslNOf0fMCJ6KehV7gf5DEeiEDrRiu1Erkncs/F9YN9L36v8tiASdzbTVh5 hpv6fd/kCLd3Bbj6OjWVs7S+t6PSE8J9kzg7OaiewLiGdkzkpnhU3OkWMIRbTlM5hUZm/3tAI20f OKmuRxkeAVRZibm95GPB+5+GXuF0OCnJVUD2dowUW3MMiZwuKGGHqRKmmc1xwIwkWRGmX9vmXxz8 uW9yhCN48Ca8ZGn9BC1NUlDkazqmnPomrZCfexHcTnds/BoarygPI56kFe3UiX3bVsjPDk2OjhOe PZqpmvMlXuaLPXmEntiWFdt9c2uiblCehl4hfNDBUG54G0h+oJw4R8IXdLDDVAfTXOc4YEYGec8q nKdApV55ErgdP/PnKsWxzgJv7d7dvA7SEHEJcLg3JiXqXAOGKduEo8yhdOAW0PbmGu4dy4q4tH0P aBhn15H7apTooMQh3PEuHpe/RPTTmlwhOutfpPscvBo+2RQj0SbJzGThh16q8UGklW4fB0wimhvv nIA4JdqrP1QWUXjj7rxT+Flap5qF+D5Gu0kh0iXAbcJDiUphTc3iGtDk47YjlSea7BSda90C2vav uIQ1K0GCvgf0YWMvyMk06GM+AtqcnILRMj2nRMenoVe4H4rJ7E7n7qqdgftslJF7k47muO8lJc/9 QcWxg5edWIF15R6jrfHfaLMngdvbm1a89izwhrDnzsxNA7zvDFkau85Z6Z9y79EoZrwmQT3yFjqA lMx6PL8tRieBe0CTm1EOyAIkDsEjgIxo09tT5JoQTSdXiB6qymgF6SGfQMi/GYle0MkOU53sIB05 Dpjs5HhtTjunRHtRyUaC9UJ2WuXiLK2bLuRe+KS7kZcAJ05uOVWf52bp+jWg7U5b1NPsCoNr+/5y p7a9iCztNWt376FFI5oJPO9Gyu8/ItreE8cyXqaTp4FWiO7HfUe4tHKV9Kx5dRCJNs1nzqN7LSh4 tISt48HrRXg0tUJaYngSDOUaWcWDZWnyLHDqc/xtQwq/BLjl3jhmDsoyuteAtpvgoEI0sFvA8HrO kmwhjaH+/j2gmat3iOP6UsBHBFEgyFEDV9scnf5p6BV20zFLFETu4B/j55Ibm4w1x24vbwV2s4F0 dn48RAmMhRx109kxZXBPAqd805+KUq8/C5zLRfw2pdr8JcDZv0Kw0fsorgFDlLb7gxbn81tAk5SR WbgyBfG5e0DjxmR8usv3CBjqh+zcdi63kRafhl7heVDO7PZ2KiLSsOdRD14MYJ7o/g9xDa3nko4j KEVsLjzS45gnBfEmgYkmfVYQoxROVUosvUS8Jdtk5xITrhFEtk0E99czRAe6RbgpZOQOKanVcH6P cJNJ8Cq32IutPyKcSZl7efDn0Q8li3l28GWa7c+dSlZxYozt9JTCZ2sRnhdkMjZ0MQDhWRbB8OwV IQL2AdPKCxH1USiPeF7Pg48kW9S5DvYj3rY/ecL0ycbbRRjY93jYtxfDLHosduDhHKulxJ4bJMdP HrJ+no5w7h9AchHTgnzfJPdkW1a/mKdDvofbnodVbMhjwTmoNc6Hk5Z2ApB/n3KHPBUJ54TpuSDO EYMp5+JhcN6Dkm/b7OPkSzFYOI94qgrbXJ88nbAVT+UNb8QYOZnKoxHPqov0TRNfmPadsCJgxJfF WRiP93CKQdCtXYGqDAmke7gF87aa1GPAtUfBNTMExXejMU9JB75G+nAWk/OARJe8LM0WKaSb7jMz c1NDMyU9z/791D2CEukcR51kZgpid4cnzMyJP+HdXopiPMjMsqtM9zAjHu+mAl86CtG+TVRMor9j TowToj0cjZT7KrJZaDyCaA+3fS4uo3TNT0K7h1M4yDSzz084ZRz4GuODfsbq/8DSNa3bFhlfENCK 7VRB0/wIN/eCEMsMzJe3NKWPdB43j3je70kReBwQGI8gGPfzrnaCeO7xZMO8E8Rf+xybh3wPh/wK ISMNk7IJ+R6OcGo7sjmSiblCvoejkLP0o4RzHBEZENzdw8neuBpmZbHdwdfIHzQ1VhDMULm8MSfZ 4u4Lohq60dTdxS0gP+pkBDN2t8cnnRy8gfyIp/CIN2mveX7Ec+Ujl05GNiHfg4x8LvuU0AvlHsRG CGWort5QOIRyD7fDMvsDF8eNn+xJXdiDcg9vuRwUc81OIK1DuYfbmxI4QkaHho9YCNM68DXKeymN 0/Zs77iLjnMvhXITlWYjfK82xflE1TR2+DvDSCHeyiZkuCE6gnhtGVcijQ84MQwcPuJZ8bGAyfic oYwJnMfDeUkCL8MM5x6Emx+IhW6eiXYE5x5unOOHaZ2rMQfOPZyxp8BFFzgw7UHcUsYGFhcTjxYv PYZp4GtMp3vKOMZuNwwPn0WmTTGaZbqXkiLTYnd4txecyDnRGNyNwzNZe8Tb1Rl6aTRMR1DDS0L8 acupd3s8kzkv7F02JDj3cNRy25RNixslEc49vGEthLiRR3P0bg9iNrdLG/SwAlR7FOszlBaWqtHI YBjUGsO9W/GeSa7o4L74rzK8oKJxBcUkfDMzx97AsAhp1MlpoRy+HEFM77y8KLYErRHExUOcABl7 P3F4grbH48AWtdPT6hQMrR6OK1M35M42dTxBpgfZ7iGnsXMf8gw40urhlqQ19nrn0TdlroNfD7f7 MqhLyqYozgPRwNeIHvQ0iKbC2R2gkli9oKMxa87wK48IvyKl8ZZvvUMUfiOosh29TIUaDVRHPHtd rCXTsE3qUiKeYeY1GGo/EOwbtQp/SkZzCiyGC9UeTkEKRVduU0zIIFZ7OAsvVCbidbRhGA4oropF M3evGYhwGAa+xvCgpHU5savGzSRFqoslJa37Q1RYyAJjb47kUXFaZqvXsyhDclI8qx8CVmz0rCB7 wbG/012i2yXiTS1lEpdQcY0gFjv2vqWspkgfbhFO9s0tZdusHUnr9wjnwguTgnImMeE8DJu9s9JK i/OEEQfk2bW+wjmtdcforWySgur0u4ucm6wzN0EXvd4TJ2iZG+Hcq0I2QRfhUskp5xFPVkaJ2GKQ hv6IJwGmPiJ7uqQv0O/x7HnZ+79y1izdwRA8HHmVfUvX+tQQPJwTe50yk3ojtogheLj5vL0OQ8zl EVGsvngd8ezbbbo5A/5pdI3/of4MhYBNnvxj4unQOs+6/UE9PbfS9QHWe1RKwFlE6Ul53DuCuoKu lC9ONBOojnj2H50UzSBHR4Bqj2f+5syA1j5BsAfhE5ysyvuCOrHg6R7OEKKY1DnXk4gHwR7O/G3v VsmHHsTaYNrDbVOb0va8WJXAANPA15gezmdyWptquVzKl81QODeJZ9bTe+0n/lpuZeTcK0R4Ou+e cDlDB4LzCCrJf7L6M8d5xNs7Z9x9YaqZwbnHm2qOPJrDhww47Hs4MggSmLvPWOCw7+FoV9x247Y3 xABh38O5Ldreb7+4uIN9D6eonHcSUVw2Rg+JZLAPfI39dFSTFmZzJWHfNJ5Z9nvxJ7IvvcHjvUQE +y0HcJa3QzCEiLeJyL37QrNrnD/iG/bOch48vdE/4nF+DunK3AT7vk3uyeFNVU7TFHeDfQ9n78yu oc2zvIwI7Hs40zZmyNw80inGAvseXiLQEFuWT2128DX2e42tZrbgfWpVClH5oYR9k3tm2e91oMi+ dB72vVpk7LNj7GxOHAn2Ix6Rzb1fZLIUg/2IZw3MS8UWswLCgMdbZQtbNXF6gH2PoZ6FL1yZUx6o LnLBvoeT41H94FaPAod9D2dqJx3GHZbZ93DbUKFaIl83LeOH7wNfYz9dg8ZtD5RCjCOVx0DYNwlo lv1eGwrs63tiYN8rSDwqx8NcdbZOzLAf8dWelaiLFTKWsB/xbKJZAUX6SPYB+x5vC3e7uWEcAw0t GIKHs2hmz1qtBfo9iIU70oHbdcsD21kL9Hu4ZXZ4f46HwifOH+C8tgd1lpuAho/AoR/4Gv2DBoeW 1x2YmbYj9JssNEt/rxdF+qU30O9VJXN+hk9iLZxHkN1g5rfLp5xHPFunvMBjfJDJViucezweb7uR Yhgw7UEwzSot15vNJHsezmUMtv2dV4HSOpx7OJsqVEdNrmiGao8izuPprlhWBheqga9R3afYNXIE b+HNI5oNUqg2hWiW6l46ilQLK1DtBSaoptw+Zyg4ZIyxsB7x9roOto7SR9rH0yPerjXPdR8zG+YB D+vcluxe5i2DCf++eRsyui+Wiqd7EOe82DxwB4+nKb6HQydj4hRogUO/hxPorcjEFWrEAYR+4Gv0 9xId+yrU+VPUO8bEnJwL/SYfzdLf60qR/mxEY4rv1SdEI7sbMjvEDP0RjxiJB419ZG0cnxb6I54l S+tvQRaqcHqPJ9BTnuTEgin9Ho774/3La38MwcMR8DhjvXwzKu7v4d2eKre6Lsk0GIKH86Y2hGCq T+KIwD+oNf57Aa/GFe29rWn1nNuJ/JdLAl73B1nWa/3nkafHfH54kZb1SJTuViudWU+Kt5evuAA6 5V/aR29HzYhDcomNWo0ZglKeGQR+jXB7dWrpLy4TE7xFOEk+k7zLZKX1e4RzBQeP6IKFGOwjwrsa Keq/0waedObZwVfYZ7i6AjkuhGFTNY2TUG4a05zLl734FF1eegzlXqKyyZ3TNDLzwXME2YkBfR3y WUHspdDpHAxyyOqCDTz7RontZD25HkxtDZ49HKWOQiLuqRw/2SGGdD7AUerYDXJhWJ4Qnn3rJuSQ WOuVRdDrUeg3vIiGsr2xD2I80At8jd5BqeNkMuvMLBvlsCxMQ+U80/YHdW55RJjuUcm5makr6TJM RxBqFku38QFn9BvBm2Di7jyZbsQEvKnzvG7BbdwkG+9YhHTfHVvD8RLB3BvpPc7t4XahGsebZRyg 2oOI45jydCc1gHDkHXcz6guVIJim1ghOAl3Nhla+onfRlU0gmnXlXjkKv1aIQ0Gw15eGMqgk/08W 3XAd8RVipK+Izb3syMDBI96uwvHb5tIfHNzjLWVH7RI2YNiDcGtEml1SMzQKwLCHU7lO8E5JEW9o ifYD1x5uq3SmMxcGIhz/9nD2V6Fc7QfSAa2RnnQ5ds/R+0dzzRFKvNp0oVnSe8Eoki6kQLqXlSx+ 2/nK+FwwHUGV1a+7Bbn4EUxHPAs+D9csBqY93naxub95fO6J4cG5h+PV3GTozubLIgPOPbzBjv4/ YefWa8eNXOG/Iuh9RjrXfbYRDxDdpcwgAwyQPCua47EQy0eQziTGBPnv+YrdzVq1ms3sB8v2XuLu 5qoii4vFIhUocpNmz7nC8W8q77CHWrsEqhWFGPs8SmZMhnLgM9LXlDcKPuhdssZ0aEBDphdxqDJt 3QDTKiHBNGLWObthH5wbnkBkV5sfpmujlDMmFfKQOphWfCzI+AvigLWXYVrh1BxmY9O3aOBXQXFF I5PCYcCHTys8purn5GH0cc5sGaIVHqo7dXokmGpjG04NasbvKriFncQB1f6exnDIPEOGF/2nMHy5 S2u7VJUIhtm69lov+HIFsR4OXP+YocNwxZOJzDqiw33IhGHF07sIsR4mwKuCGCdZnPi9D/CqIPbS IlpKPd2mC3hVOGM1e/JU+Oo93YiCTkWxWUpiK6dQKgo6Qc3oXA+EkukaB2r63zY2Q8kZsrlIPJVN Mzz8VYUg2IxS4RLqmH9DbMVTS+PEFlv/5FNu03HFR9FRudnU7+qEWMXjuizWrjPUbI1CrILYLuWS Jt2E7T3V4FCs8CjKQps5sVjrUKxwXJdcPrZja6NQrCgq8XCmhMNkW0dYP8A18BnXS8B7HcUZ2bXK war/rLEeAs6Q9UXZqaznSNB6BNZV/4n5mOXolPWKZ5FPFZwcgK193Lni2SghySbx1uWwrng2TNuO dseb0cK/wjnGd+Z0SO96n2PgX+FxHviCUpy9dXsY+Fd43A5FxuyefgVFEBYpP6lCddpah0M/8Bn9 PcmN815MgdvD5bMZ/SHbDOlf9JxKf7ay0a+qT0zSrBGMQzy9glCR2Qiu7wXRFURVLHJHtqcfCOQF D9EoN7Jw2xOtzUcMxsH+bN4eGaIVzs44ezpS2sh8EqIVHtsj3PeW9W/tYfB4hbOu5mA7663tZe1h oBz4jPI16w2Fnv1YGV8q01dHWln7wpbTXiHuBXuDGIpoZXGvUs5u7iovHc+Wbb3Vz/m39ileRs7v 1iUM9RX/urYfm2IU8DfQmwqK9TSJRtmodfTbCr+OOnzkW2wDsb/iuwqH9Vag8zgyK28YYhnXPeZ6 yYzkQ2t9wjqtrWLZKc4z97fKlzL6Q8sZOfrVIvJUR7eehH6VgsLRWTtXSqC8YuLgiGsIrxxEiTWk /uTZRhh41kZZa7G4kYp5FlXAuMKbnyNz1weFZwXBc9Tx6iOlL8LhWeExjZMpkdv1Rtz7CicCJ76X Q4AGh2dan/G8qma3ZD7w6WNWtmM8Q+SY5/jC3dwiSXheUF01u2FpK+Gz9TecV3zcragXB+VTtgkD +iueKr6ZyIWnWfwL/YqHfoL/a3sISFdQhOdM4xKE7OhXOPSzQ67CToVDv8JJbz2RkHs4KkC/wuNQ AonVOYrY1AH9wGf097OkUXgkBeZsx+gPSWfo5ovWU37t0rob+lURam6+v1HGQaxetSKWj5NwXhtl WU6t2RxWzQbhXPFwvqsCDuMKYVWE6CFWmp3TrA6HVzgyGjJvbi4NHF7h7ILwydPALgfBuMIZ2FnH HCfpwTjwGeOroHaBiM9tGn3HLbkyxkPZGTK+SD6VcesaGFdhCBWV1BUJgJ1MHL7iOW4E+9VlYLyC KO1CBnl+bHaBccUzmbPp5MeY4FxBBDuUNkoFy0mEc4W3wz2SCOsk4uUKj8k8SoTlIFLfEM4V3qJ2 pvLjqD3gM85XPQ31Lsrg9EA2h0/jPESeIeeL+lM5N3rgXDUivPyKI2EGgugKQvpCe6ndANEV1JLO +hS1k0IhWvG4duy453IuX7f5LZQrnHMLyLgS5RscyhUO5byX2LKZPpQrnOuXcXJJgLSoAcoVHtnM XGBzleFWe2S8G9SM6V6EjQULqRWbU+S7GNOh/wyZXoShwvTVTmK7UvkomEZMli7Zk17xgGe3RMJ/ xUfNUd2gMHuBf8XDP6kl1oOQrhgOnpGVKsWIDA7pCqccNmteOYVjcEhXOMEc++3kyFe7hmtFIbtB FBcc7snaSAc+I33V3zghfma3vo8qaZFGeihCQ9IXqaiSnqbTngb3VkEJ0llK1ffDuSvkipumZI9h n8lgeIQFyVHYX15Q24/VeZxXqw8B0foQXFoQOYJinBUO0QpHfKPkQxbFcmEXohXOvgjb0yxBDyiE cYWjwkWMl0JzMrUxDnzG+KrC3bF9Q9mTpMiIDu1nSPQiClWizZYhWqUjiMaQJVdrMHdXfJxcF6Vp wHrFRzq5rJPca/BuxTONU7dL0+kqofCv8DgszoDafcOfHv4VTthOLovkzGd41BiCf4Xj6CQckBVR nwHaC4r9LBIz+xLegwpGd+Az2lf1jV8jaM07S/PhjP8Qgob8LwpR5d/WxvCvOlLkryFr1RfE0yuG pQilTjL4zidr3caIXvFshDKpb14z8nTFh8RN8rPkxNXHgXOF45RxZqs7pfc3nCs8rhWhaO3h2gvO FX4XKwdNuLOFBuQrnMCdW8tnJ9ECPiN/0eGuTuhwqKC9E7KLK/nXR4Jc+8JW6lc2Rb3gqDq2I4Ic RVOVqBxyGrEvHR/FDnWwsBHuleOJVFgZpCGYJ72ueJyfaFuz5t0QyuMTzTP9eILz29om6zaqmGVa iYsF7yqcGJ78WSKY+svvDRVxX9xV1l2iwj80+IR13mNLWmNrUk7IG9mhIY08/XoRl6qn23wN2SpB xUjPsc3kwv0GsiseMT1uk+qfPdkVf4carT9gxgTZio8gKqqb9eZ3M32Bo8pxeERWyGZK0K6tk0pK OobUfU1/Wkf6Ao8MJ/JmJ1UFCpw4HsummMnWm/aq8M/DzPjv+hxOT37n1k6+lBkCTI8NIb5wr7ch C0NYUF2fi0qCZi2wX0FEdyQbJjt79iueRJ5ZHAH7isfVo1RxNr9nX+HM8+QpH+egwr7CY+Ee6RG9 +T37Cod9cvKZgKoX4/SKYr3OiXNEoK1V6xFIBz4jfc10i4qTXMzRFwaHpIdCNPT+RToqv3Zlrwjp KjDh/VS90ZoA9rLwX/FoKYS+27sO8tQNTy2lUqHVjBD+tX1iHVYYXnblTQUhbLCO8xw+uNaWIlnl iivA+5NaRzDAK5wrbvhdTg13/I50hbOKI2CkLlhFwTWoGderHncXJ4HEELPXzcFDGRpyvUhGlWuz PLhWYQmuQ3o8Ti6D64pnytUs/X1Mb3jqukp1pF1KIVxr+8R3lHjRmaR2JqwrPCpNnNix7gTZ28K/ wtlQ5zwxN0L0T20d/hVOdWWO38htEGYuOL3CWdORkXJ77tOUPQyGAHxmCKtIR1IUgcVtn38PnT70 oqEhLEJSNYQ0pzarYQgqN2EILL322VEG4rk4wL1NQbtdc4K62iizh97MvV/RFTzzPAnJlxZQwbk2 2gpAcbdEpQ6mFQTT1NzzJAD4VRAJE4gMx28Dvwq/OEW8Rxy5vf5+Jgc+47cXdeOOtq0R/jzkNzSi Ib+LeFT4vd5Jc9cqMcWgzq3n1rV4dwWRy/c8dwRwk9rL8FvxJKeQSpTvYl2Cdys+RnJy3vts5mEl TCucMZ2Dq167C6YVdEtJH8T/bNOGXzhXOPM3eRzcUVdfDKoVxVKNe4k4ilBReDCoGcOrDkeluahw niFRb8eG8tCEhgwvYlFl2DoXD1ZJCYaXmwU7G4aH7IpHjCaxr8OdDciueKSWHn3G37L2IVvxy1Du FgTFCiKFldH7+BkgW+GIMreMon343otyBc7tJ3fUIUrbMHOGdW2dqo3M9iiJW5fYC0I/8Bn9S9TM 6cKohi2BgLEektCQ9UUrqqybDcK6Kkqwznzp0idUVxBuym2d23vtqIPqimdtzR5Z4u0hoFrxocqw Q2pDMlQriFVZ3KWXD2FtQrXCiXyZCpB6to/B8WuFx6qMZBfWievHuINqhYf+ihosgUb30DY7QjXw GdWrEBdzAhsCuTrp7RjnoQQNOV8kosq5DdNwrkISnLM1pLU07WWhv+JZsuAzW9fojNPeFvornl0t lMjEW/vQr/g4dnTN8rzjDY4hKByff876JzfoLU7CEBQeUznLixx59gO8wjEEnp1zoP3TGWnviiEo nJVaOytxFONjCMBnhrAmx0XBuueoh1snpLlWQ7g5EuXaF7Y898yiF+zcYkciylHZb1K1+qXjyRug DMf2jANDsPbJtT3JNOb7s69r+8Rv3P7ttSDeVBBL42vKi8ggXgl6W+Gs2eJC25xKzVreVThDOPdE 5L6Kzz/vK5xxgFMqx5tCHxp8Qj/91dQ52kECyZkmXcDoD+VpNA7cLJJUHQcsSoF+Fa4YB+LCyTRd f1nor/goIoGIlJ/a9a8cf4oldY5tvtiDfm0/NmQImwRfm8cQFI6jUs5KdthsdsYQFB4XEXNOKR3b phsMQeGMA1QDI1GrPgP8Kwr+LzjBkVuTZl3wD3zG/6rO3bEhw9ZEf/dsx/iH4DH/8YW7v70i/C+o rs6xePcYCNIriNxAss/S59M018Hf8JRoIxEjbcQeAtK1/Zj7CZmSFmMR0hUOK3T2sX9CusJjQ5v7 vtKvdoN/gSPJxxasJBjt2NfWI0eWlZhnqUE6qBnpqzrHWoLD67n8ORzzQyYaOv2iH5Vf8wssIF1V Jh6ZYebcDQ2e6jvCf8VTR5ucxgrC0ysIEZQVcwXBtIJgGkkzM/49/odphXPY4TnTjVkP/CroNirO kYTWrdOeE6dWeChy1G25SO9a5/SCYk6Pjdu8stssHn5pdMZvV+TYcbkbFRUzpw4ZaMjvog9Vfu3h 4VdVJPglI9LvgYHUCiJ7gMKdvdtEQ9icuuIZZ6nSlHgbFqFa8RxT43SETNFmY1Ct8DhTQjJ9mn97 BqhWEAES5SQlHcAsA6oVHq7MDvyt/TLjt6LwYOq/S6xqzwDVwGdUr5obRyqYwHP/MdsxqkMRGlK9 SEWVant4qFZBKVz5jhyJZMUMFdYrHke50fo+1j5eXfGx6NOMB8PDuuKJ4wn2fC0J1wpinUX4boEJ VCuGtRtzqiyK7HehWuFQzfkUhpY+59RxCM4VHvvoUX6ih9rWa3AOfMZ5r/aGxKN1rvvPGuchDQ05 XzSjwvnNToe7UWUpZpyTXubpoyicVzwpCVenNMfNvSuIlGfOCfb+851riFZ8jOQcArN+g2gFxXpd KfTgD84VHrfecT4l44z9SK5wOKfG+KXZEUwriL1TVq4XOWbY0AnTwGdMr3ocaw62FUaVYY3pkIOG TC86UWXa+g/vVjUJprFpr4QBvRVE7QDis2TOXhGXrnhUXLSZHDKsB2Fa8TBNYf/jMupwrnA45xTr rcUBMK2gWOrEKqI/g80leLfCz0ipt5wH769orcO5wtuCnDTPHlVZL8M58Bnna2YcuT9xkjM3e468 O3ShIeeLYFQ5N0eEc5WVlslbK5/byAf9Fc9yvFR4s7eF/ornMkXOofWu359KLngEd66m14Ghd0Ib R6Bfm4+lOW5iBEG/ghDcQ+vrxwZ8XIB+hcfgTuVCvy0P1hUVWRKI8pPK/AGfsd6PpXLfpN73YQ4e 2s+Q7EUUqmSbYUO2SkeQTVqHbtjuya54QqTY4Oqfva9X/C3l3LyAPw6uoBghGXTNbOBVQbj1Dc5w uEaDYYVHDT/WNRld7odyhbPSJlPWnxOCFRRLrTu0oaM5HrcGPiO4H0IlTGMNsLlAOmRl+vZIZ2tf 2ELbz4K8QMfDUERni2uYxO2sv186Hh0aI+xE+xrtleOZ43dHGV9XEDE5id2zjLfyzO2Gb602Z4/8 trYO5zyCL6zeVRBDOekTKZbsxZXyCDh1pENkZpXZ+4fW+oRzWgtx7YqsWYoj5TCW7RjnIe2MvPt2 0Xyqd9vMCeeqDIV3R2WTQw7hvOIRszLznr+WT7nGbIY/MSiqdmteBv3afgvOOZuaz+NDeYGzBGb/ JhOHfISAfm09ordYrm9e5fMKhqDwtg4/sRe34c243lc4KtsJXSYzI2ygxBBofWYIq8rGhh5rPemE 3gdmCDA9NoT4wp3fFqIYwoLqKhvH5/32OdivoEtiFtJH+2fPfsXHQSOpnOXWAvuKx5OiuIOZ7JsK QlvDPLyUMExrS9QDogKNXIJmbw/TCmf6ZkWIqNt7uhkzBCsKglnvMc9XFLyCmvHa09wuqSzQ9+5E zTBeQwwaOviiEpVf8zgGXlVLwsFJTfG4BF4riGR2bqrc7Hywc2p4ZJliB9a98KrtE/agMLPJsH3M kWBY4dwzT2qr7MwZHK4VTglmUgJk/8YeBq4VHltncbOaxX9wrShG9Tibn7JnzsDNNCAd+Iz0VV1D 2+WEZa4Y03iM9BB8hqQvSlAl3fwO0lUviiiESpfdS/mXarLwX/FsmLBJUUFM3xXEFqKGNgNnVjwx G4TL3rM9A6QrnP3SuE7XQFCtINQ16nzJuTSzDKhWOFRTiNLHE5hWUBT3ouaFL9IhGNSM4FVTi6sR cbFu3GkoRnCoO0OCF9mnEmz9AMEqDkEw61cpIzwguOJDUxMH9IkSriv+RIldLRxjPoWDK/4ibo1i UywtrpoSXCucIZxJW4RdoxHWFR4Zh1xW0nvY8+tgXeEcRcBz80yoz/Lwr/C2FI+SnweDE4YAfGYI q9CGZhiTXe+EdCczhBB/hoawqELFEG53QtutakeIhIQKIjsMDKHiSQiZXZKBIVQ8l5BFemP/5Fu1 cRBDUDzxG6WlcrRzO8MQFM6ainnBCYJ+BUUNOJZpqcSkh7VHgH6FE0bH5JRwizihX+EM9FBPfatj +oHP6F/VNxQAkrwyP+RwoA8daEj/IhBV+s0zGAdURopxIApdV29jdK+gSxKS0i53swGcVzwKRaka ZO3DueKDc+50NRBMKyh2REk6y9DbXgzOFU7ZNVYNcrDKxh84VzjnEhGMdN1QewTOFU4OOzUhiHeP OQc+43xV36I+O6FKCpv9Z83lQwUacr7IQ5Vz60k4VxEJzqkUIilj7mPQX/EIMuQ8dw/2IQL6K55M JIoIHuKhX/HkQ5CaZ9EU7CuGU8ncSJxDrD8y7Csc9jlM5IsROFfQcuic/9cftHf+FrwrPIo+IlX7 9h2jO6gZ1avkBtUcss/dwhwHjerQg4ZUL0JRpToHifbMUK1yElRTfVByyJw6qK74S8qIeD4v/FYQ lW0lh2NwWKHgWZQx/Xq/QbA2ykL8jjKSuTLM7mkvBsEKjywX7iu0t4dgBXE5VlQRlGOwO4IVfnli r6Vd8LJ6tbkRTAOfMb1ob1yagk4VJwPXT5p2Zfp0pL21L2z5LWmyK9MrKpffcXlQfcOXKBtYUwp0 sWEg+oKbwyvHk1bCobxtlNsVYn9d8bH8RuvImdPG6DcVHseOyWvog+jeqcvTU4IZbUQ2VKz1d7V1 YnfMjhz22iXvK4olOWqhvKI1+qHBJ6TziC2z7cQyjSrDGXYb16ELjbz6tAhG1atNwHhxsaI2rok3 qAFQXwyuVXuKjUPmlXSoAdcVT2kNTuIl1xb2wLXig+v9UAHDCsKrOeeeY54/w9sKZyHFroSKifUV YVhb5+pDKpV56gwEK4ib56/P1Mw5GuUhGPiM4EVUI1udgs9Y6+bVOUAZ01A5Zjq+cK82EmF6QW1M E/JQ5ixJMfOE9Ipnt7hceWdjGA5e8Zz6J4k529+Trvg4Th7VnrY+cD6hX+FsqDBKc8Rj+2SfrYN6 gaOORSiUiR72stCvrcfeOOOBJFJWa8EQFM4yjX0iSgJUFPyDmvG/im8kajFaiSbS2zH+QwUaevoi D5Vf8z1k+FcRKeZvBMMp/xXPDMYR862/+bM/Zetx+K/4E4Gd0O8rY5xe8UgyUaqk7yr5iA3/Cufc 4ZnFn41mOL2CGIAjKSrf0eYwWFc4GaSXxGF9ct1vrhT4BfUayR3IEiDWIdBP6zP6Fxnuisck4yzP 4KRtGv0hDQ3pXzSjSr85BPSrsgT9cTFtdrf3N+5f8VFKRg6O+cIY+iueJY+atGua0K94JE3UAlbH /VOtC/oVjsOdSbxPZs31MASFc4IBvFe8hX4FEbRTfRG9ov4yvq4ofP0aP8icbOtnWAc+Y72fMWUb VW6hOGQ9BKEh64tSVFm3h4d11ZNifYYI0vt458SwXvHkj95MN8wNj36jdx4NnF7bp8dJdJYLubIT 2pgC6wqPLEeixmTd4LCucAZ9zo4MNzVa6/CvcPiHEM3O3xmCwiPxMabPPmtb12MIwGeGIHXirkhB 2VhJgzL3D2loaAiLZlQM4bTT5k6qLGEIEXGIu9nTYwgVzzYGN9tvzzjYWzU8R3Eiiz0/tTNxf22f 0Z9ajHLbrD0OhqBwlkG4Pxsl/VNbxxAUHipdXA7Q0dY6hqBwDOF0GVk7tVEGAkVFPgUCV2ZOmzHC P/AZ/6s4Fzc+xODXf81oD3VoSPsiG1Xa7SHwfxWXwv9LgQOfxKG94rkdTusx+izBqF/xEQXlfsNo Vaf40DcpMm6RKmQriKkencGT8qFYQVxvTAEMSW6xNqFY4QR4Jw4f5j6e9RtcKzx2Vy9JzO3xo8Hh GviM61WUi1uY2dDp69JD0kMeGpK+6EaVdJv8IF3VJUiPPWkLlWC6gkh/wb8zXLdGYbriUVX7a8Tf MjwOrnjmd1QLP/0O0wqKlAlGzVxY5lC4BfUKZ3OVQUPKztojwLnCg3P0/P3FSRV1JmWGOCcfovtl ewaoptEZ1b1AHMU/cYCtR9NkzL9DKBpSvShIleo0mPY0UK06E1SzkrizboPqCoqarHrqy4ZDqK54 ImLyTWs/wK+CWL5xJ/Cl/TL8KogtTwJdjT9qm/i0wlmzX3B3SO6t2cvDr8Lh93yHqmRvgysranHl cyba2HvBL/AZv/24KVv1Ujgv26n83h1Jce0LW7SfbM55wfYF5pEqG9anUuZ+/DZ86E9O3StvlDsQ TqSa94/18+uKh+rYdsv3bZb4poJwZQbYjJL9Qd9WOOUaztxlkxO6SWvvKpy6IeQgHR+Eel/h1A0B LxXMzUw/NPiEczq1pcFxWTJHg/7/ujB3IRONfLp94ZzbyAznqjLh0yjHky2yl46nWjePmMGO9SX0 1/a52S7G0f6x54F+xUN/3KHdw1VnFkNQOEINUqxUW8lxcB3TC5xQjf0dSeMyqjAEbT2EGiKO2INf P3VEwRAKPNLXWKDlEr/CMQTgM0NY0+CYSuizvFcuncGcn9F7bAjxhRuCxSwYwoLqih11NKeHlQzP zUs44dYzu6sXMITafvirrK72U3rBEyW3PI/ahdCvjXIfGSEy2TPbx/hkHFA4kgoDvmR72VAE/Qpn GyaKSsqGYH0Y6Fd4KPLcOJOXziRt69we8Bn9i2B3QzSDFWU4mO0Y/SEvDceBRXcqv3YyP4V+VacY B+ibXPvuEuEYByqe0BqRtI/q+9jd8JgKOZSJz7dqvcM4oO3Hku3MUZCN2ME4oPC2C5ez7i5exBAU Tjosyzt5ehs2MASFMw5QSYdUpx3/BXW33ArVIwprFPcHPuN/TZzjZCQRYqbzJ3PGfyhHQ/4XSany bw8P/yo8xTzAevqYT/iv+BBs84qqXY/j/hWP+2Nhyed+HlB8nFBFXjlcVDMQKDzyqihlUfmBdMVw ahHKOV21fYwfSFd4pNCRcJdn0w2O9ysc5Y4zGHJa3Owb9oHP2O/KHTkL5yxily9l7IdcNGR/0ZEq +xa2wr6qTbCPJmFPDOMVE9VJ9ThMPlnzYBiveFbr6Bxbbw9W6wUf+hhnk6yX4Vkbxc85G+9byhCt IHIlSaCRocNMH6IVHsnuN+fZar3AL2MWISjI9qvVQTStz4helLkbZnlOzOQuUHanER260JDoRTAq RN/tlLk7lZWCaDKSZyddDI+KR7xUXxGma6Nsxmh9UC9Zwdiu+AjxqaS5Z1pBpEJzFsV1BZhWEIE9 wkxk264faxOmFc44TqkZSoYfwHHpAueuJv6PL+khGNSM4J4XR9YCG33br+XqywgOMWhI8KISVYLt FfFk1ZIgmFHLJ3tcuYIYvEvdnz3BFc+qH//NwTttdZu8Fc8WO+vwPD3isQFOrfCQKJkbt27ahR6Q rvAovsdQ1LvVA0lIVzjb36zOZCvagj5IVzhF4iIyGBWF2KI44DP2l3iabXcEQ7lgILvM2A8Vacj+ Ii9V9m2Mhn0VoWCfuSMrx0NY9VwMoeKXclGHxOLpFU+uBdwm3hYVeLriieIon8aksX3MeDEEhUft ZeaADBJs4MYQFN6ypPSCRXsYDEHhlI6i8IbIx8lIYxZDUHikzZ3ZQeubzPbsDAPAZ4bQpTo2oWTR ke2YIYSQNDSERWGqhmBWjCGoDhWGQFqPWQvsV1CcYdQ7kPPRthm94jmDQO21jcxdzAf7imecZ3WW o+1gGFB4HFmY7QbAvsLJpDsTtOSgZMYC+wpnludqBs7id9utngH7CmcxhxLG/bzby1rXwD7wGfur kMccQiFC2eyvpJ+P9Lv2hS3hvcrPC044YTOi33HFo4xce+83PL1xmfVud3y+8vZP1PuRYd0JfV3x LOFZnMs9P9aHbyocguIO3sPB4m2Fs+uOli+HHaz1dxXO3M+GGin9TnvpEpKuSPxSfavCP7RGJ7TT WsuqIyee0FdqsfV2jP8QkEZOf16Uper0tmaCf9WfmtPLgavdRPrS8az4kFE3Ex/xX9uP3Hhd82VE s4YB5XkifxYld7KGK/A4EiG7M7tNYPjXpyEMIENH0uOMWfhXeGy7Rg6QjRLvK4rgnstwEfq3PjGj gn8anfHf68WxDLjlNN/6yeHa+IfgMf/xhfu/vSL8L6iU8Jj/zUggvYKuOAaSq9qdkeD0FY/XyKS5 MxKcXvER+1EtyiwDV1cQqRZYBieYt4+xAtUKR1jj7CkSe/90b2p2B9UKx9VvmdX2Z1oLKnbYWd1P 1nEBn1G9yHWcXsfC4wqY9ZNhhVEdYtHQ1RcVqfyaX4cA1ao18ezkN+vi2gwV1iueYRVRsfYbVFcQ R9Y5fl1B8KsgJnWSCbX2QYXDtMJJpbqmjIb9MPwqiH1r0u26r+wuiYJfhePKBBYkXWzOZe+OTysc oqmTdZvGZjExPg18RvSqy7EkJTkro+s0WiM6dKEh0YtgVInOVpotQ7TKShBNQYbc5925K0RXPDdQ kWS9dc3OXeG84km1Ji1pM14mhMon9CueriezT87gWN9Dv8JDFGM06MOpr9UwBIVz/IVbqKS+TvrS 5ugKbzlVkSRdHxn+FUUgH9czU+xh/ViPwz/wGf+rMhcRJ8v5bkjZjvEf6tKQ/0V2qvybNcK/ilPw j3DqZ/4hvYLiAHEs0bePBf6QXvE4etyN0D/GIqQrPrJnryjTdQSHdIVD+jnqTW797XMupCu8leil 4FuH70lXeHg/KU0ucUC6oiAdQ7pOU0qymiVBOvAZ6Wv+HKoxHZV7x9mOkR7K0ZD0RVIqpJ93Kt1Z hacg/RoVp/fIIJCvePj3K4vgvGLiimtZW+9TZgueXiYFdrhsbR0I59o8nFMiUtTh7KcGh3OFE7yz xXEcADDiK5wZnXmJtICdoysqcibJimGXYf2YF8A58Bnnq3DHoW5q018O1n7GeQhHQ84XRalybj6G o6vuBOdcmtaDiKC+viw+X/FIK9xetL3rbmKA/4ont4MdirSp/Tyv+NiE5FCDDa2wriBmd87pXWdw u3GtILhmTSULdfthuFY4/s07kRlYXx//VhSHlzmuhRrR36fC4Rr4jOs1Zy4OxHKUtccS+S7GdWhD Q64X0ahybZYH1yotwTVBkbr3nuuKp5AGBxeTa2sfriueROa4lrh/8q0aQ4zvio8jUXHzT+9LexxY Vzi+ziqDgl7bZ+/rCl8KwyKBbR/zYvhXeIj0rJtcdYd/RcX4znb1KFmmvSH8A5/x3wvKMUlc5jIy 38X4D3VoyP8iG1X+rb/hX8Ul+KeS5pz/io88YElIcuEF/iuegJf76Tr9HnbBv+LD11G7cvPXfA/+ FY7X459efocRXkFccoXTnzImMZOFdYWH11OJYlT6qfEJ/QpnqGe6IbV/symzWOgHPqO/l5vDiCgN vHVVElfoZ3gY0798Yev0s42aLzZUX6fHzrKBXjqIIZDQfHuw/fjueIpYxVKhf/JVFp+v+Ijp2LOr o+abiiG7ikNWupNa4W8rHMmU/+HlEN5VUEzlpEbL4YDa5nuDR4X4yPk+IrrBj4mOr1ty3YnjN4yK OWj1nzWiQzQa+Dlnt/jCibbFEkSr5hRxHInJNt5BdAVdsfk1O/zgeFRSDsf3DtkFchUP0azXdc+m v3mzCzjXx4k9GJKPzDBgWkHUe+O067UNEzCtoChHElmaRwYJ0wongQIvvM3KFzkSLyN6g8+YXqU3 ZjMG/4t0LyOYkXpMcHzhBFusAsELqnvyqezt+MAM1xUfNy9oNqT18yvH44Dodcm1Gdzrio+JnN3L DIqsebjWx0HQYCLKYiD+9LCu8DhewCmdXAbaCAP/CieB5uqEttDxZi7wr/BIn4uLI6zHPzTUjPb1 mCvn2LmhJcOMNB/jP7ShoYMvohHPlL/mvgX/Ki1FIEetXHsxSK8g3outp+4HPhtDesWTckCaRnVT mFYQ2TIcIL81c4BfBXGYEFWNlfv2yT5pLgW/CicjvlZB8Cm7wkmTRmuSlDFrHX61dTbWqVbHMx88 DEQDz663JfK/xNdrmvSZc4aZ85tPaUSHCDQkelGHKtH28BCtGlJEbHHWb3t2/qz0wHnFh6Qmxzzc kOC84m+pSSAHjFwzgX7Fh6NT4C3HVjNBDEHhIcNREd6eGfoVhLxFTmemnfpogHsrnIiNPAymrtoR sF5QXGbPYiFHdXsGWAc+Y30R31DZqYNGJLAxkO5hrIcKNGR9kYcq6/Y0sK4iEqwTpntaIVRXEBUt 4iKL/jFTguqKJwNLy6vvTrFWPEIMI8ykNkmFh+B+Rug4ehpI16eJEpKMENmbbWCAagW1DDnG1j3V imICj2MTvn8Aw6BmDK9K2x23FnDPeF+FHPp1aD5DhhcxSBkm/KvmCcMqGcEwwpLuZphFQHbF49ZR PLt/zPEgu+I5nJBGCyk2YuPXio9hnVNJGcVb8/i1wulxEhHzoIC7LGQrPFQ3esTahGwFkbDAA0jd AQtfcXCFU6eAiyHYM639DOugZqwvWtsVNwRdM5R1dSCdx/w61J8h64ssVFm3V4R1FY/Cr9mb7WMJ tNSnh/WKZwbnISsIqiuItYXWzfdGoVrxLHhPTM05OdszQLXC41ByVDOb+LXCyXA/s7A9NCRIV3hs mbIN4inAcF1QlAJDdcnzMNYjkA58RvoSNkdJGg7DX+e795410kPyGZK+aEGV9Bww2iAG6aoYQTpH P8z9ILpiqLHKmN+9230FziueAzMqkntoB+eKZy0W3jqLzxV+FXfxcH17750talMQ9zVwMmFSXcoe IQ61MCWbh8C0Nkowfk02VgZrZpwwDXzG9CKvcZaFwkgMsZvZpsUY06HuDJleZJ/KtE1EMK3iEEwT es1KgzqeW2jEqnfDAazX9rnWSQPfAeuKjz1ThDAzPfxbQazFQhU5NA2GcoWThE59FQkArUvwb4VH TTHGdF/Ww7qioiAw0cCxqNrgM9ZXVY1Uy7hsvg/qOYVU1i+OVLX2RV2LEyhWP3hxuaL6WhxndNn4 pYO4LZF9sImDW6PNX2W+N2d8XdvHwZvh9fbNzd5UOAIbh+50972+4tsKb5ca785RvKugCKMi023z OI843ld4ZEdcI1OZdX5oqAnVdNO6GuPiEZJt+oMbwyHxjPz6YtF+ql/bQ8CwKkT4dRQ36Fa181PI rnhGHvJg+6O14fOVg6h5eK1ivOFhWBuF4RAj0yL2DCschqni4aEDvCrohpidJYTszdVHhmGFs/JC ykQWrSiIVRThOHXxOFCz2aI9KAwDnzG86mmIfXFNbB/CcyowquFyTHV84c5sKw6oXlDdmZG/Zzsk jqf+Erlc27vuglxYr+3fRsE5+QEzPVhXfMTl7J9n9JWd0IwKv1Y4oy1HwW7tHWFdQXHP1lkTnndD eIHHeptJ52YQNLVHgH5tPeRUSnB5pVFYBzVjvVeNo/K0hJvpFcZ6aDxDB1/EH/01wsNqsrCuEhE7 f2QWuQKIV1cQdRm5CL6Pby6VQHXF0wlonIk37qBa8Tg4axdR68xvoFrhZC1zzEOSXax1SFd4pLqV 0yVmI7i6wiE9FHFfn8O1oi6pKkIh6tQI7JEhHfiM9EVaowAsFzaQsr/1VdJlpIfEMyR90X4q6Rnz NUOFdFWIIi7nkIW4ovUg/Fd8nDuV3ecB/xVPPpxkfw2W4KX9SC/iLxgvsK6NsvBmnaAZOtWwYV3h 1B2g9HAmEbkaCOsKh3VyNck6qo3CuqIiRqfav/sUZIOakd3T2RikZHcvf83IDpFnSPai/lSyjTzI Vo0Isq/Yhzv2LsiuePb+riXM3RUGdDxjOhNbzgM2qOLs2n7MpPzCZu/8Wbsc2hXOIjwm6XSLZtCQ rSDmy3jBjOQNDtkKZ+nN5I+6XX8ZsguKIiNciXqc79LgM9YXlY2ld1wUl+3kwy2sP/v+8/3946uP jx//8E9fP/7t/k8fv/3t86/fn/xy/xOtR2Grp0++ff7bz/0/Hh++/viUSOI/Hh4fH760f/35/uNf 778FGvBPDw+P2388W9r8y/3j378++frx6/23v3z+x/2PT1mEPHz7fP/r48fHzw+//vj068O3x28f Pz8+ffIz//8fD3zxy6uvn398ypKCfE92oTC6/7r/9vj50/4LfuT+t8c/fn9sfz75+zf+3v8QZsfQ dvG7f7598fx3N/GPyHj5HeVALl6cXjLpPH/+v0+f/Pbll1+///Dltx+f/vz4+PWHZ8++f/r5/svH 77//8vnTt4fvDz89/v7Tw5dnDz/99PnT/bMvHz89u//t0/0vz1DV7vjPz78SFH/57Yc///Hfnvzp 4a+8GQucf/31/s90ZPv3f/8LD9z+lafk7/KM8c/2sM/+++Hbf7be/8P/CQAAAP//AwBQSwMEFAAG AAgAAAAhAHjIirl5KAAALVYAABQAAAB4bC9zaGFyZWRTdHJpbmdzLnhtbJTcwa7myJEd4L0Bv0Oh toamySQzyRS6exZj+AVsP0AymRw1Rl0td5UE+e39xdXGYNZCI6BaqFuXP8nMiBPnnIj8f/zXv//6 509/G79//eW3Lz99Xv9l+fxpfOm/3b98+fefPv/v//U//nB+/vT1W/tytz//9mX89Pn/jq+f//Xn //pffvz69dsn1375+tPnP3379pc//vDD1/6n8Wv7+i+//WV88S/Pb7//2r756+///sPXv/w+2v31 T2N8+/XPP6RlKT/82n758vlT/+2vX7799Lmk7fOnv3755f/8dfzbP36y1fr55x+//vLzj99+/rff fvuPX8aPP3z7+ccf4if/+Om6/uH65dv00/Tdn27f/en+3Z/m7/60fPenx3d/en7vp+d6Xmsrvafz vPvI+5PPc+nndmwlt76v7dnLdi7vN/r227f2509W89O38fXbH9//PJ773JZ968uzLrmm+zmXdNeR +nUc27ptfTvWdt7v686tP8dYc2/nVup5rGlf+pbT7lHqs62rh8q91Om61jx538vx1HMdV75THyNf az/zNu5ypWvdz319X3ek8izLnvOz1LR50XqW9W4urOt2rWNLS3/8y/u6vO8ppaU+92HJ7rHt40x+ s93jvtqeF5ed+5iu28dTnrOvebvOlI9l9HbddT2u1PqVS7qHvRjtfN/v3lMZZRvjbnfry3nX7Sip n0fypk+5U13Lvtbnfd2z1uU4ex7jyel49rqv2/Gc+Rpn2/K5lLTfy9OmMN7HupXzTHsua29jH245 ar23ZVmfa+RtfY4+jut9v3vv+b7jipyPWorPH6MdOTebul3ebHnO9ZnuV/O2H0k21qOO/SxnL5Yv 91ME9vXeruWsz3639/1aP44zP62U4ypXva9VmD3pvkRfasvVtvEcaZ3ibOS05X05r1JLEh9nE6/b dWTP2vy1l6V58un9xuH32pl3L3GNxx37tuTujffzymMZd7ru8szPea697NfYU8TL2Lf76EK9bne+ hGU5rNTjgd7vZ/82QXHkq7XnyXVZZFA9ern6tuZ61cUnbGN/X2ep2nMt13ptYmTfJEZZxlN92n74 y/UUgXBNzykY1mXZ9qVYjFT7dV/P/QieNd9HOuzOAieO+TnbONealibf3O4c1YuNdZz79gjQS6TV Vvbj/Zy1AInlqXu/3coHHK2XYd9au/q4pdZ9jnWGn3aWcm7XZgcfwWExl3u3qqnLkZauvbnpsU/7 V9a8C13b39Lt1qVIglhESXh5gi3V63n6jBM2duSnnPcWGLmXbN8uy5NyT+mEbvWClOn9fmdtNY26 7Od53T31JQX23eex56sWyDLatY/e39f1/dzuNfWcrgssebb6rPfpldpTrh0Q9n5ebXrOVgvorNu5 d6nngdpyZJC2jeRz7rJsx1jymPLhPk94ctQVNl1uVNWDfC/bmVSFuucGEEXAd/a9jPvc0wIx7yEZ 7y092zhP6Hkdz9Lvsj5qyPv9riWLjLxsfc/wsJ8w9DrOey2pgZV1AVUK0XTdWJ/zyPKhFBuf4Nkp ux81TOiBqjvfA85NcQ1Z18N6tLp6xXs/jnxLptq6mB1LW1cF60pTXXnWtK5rPcSlCiKflLB9y62A /Bvk+Kd8723C+eUE82tclHLN+baoSSaeaZG5grfDgguovdel2YWS8nYs6yE95bpKOXblIZ3L3jKI 2Y69T3n0bNk2XEpSWZTZvcGb3TNapG2797uW6/Rnis/F/pyr5L0PwVGtZUuj134mZfRSU9q4ukx5 Pye8jMhdvcym7tz7VaSQF8qPWFuA9nKOs0/vF5jeAO327MpOi3JytpT3caTN323meZblKu/7FWzE k0qkNqxm6vt+5dMufpQ0L3EAOj97X6eCyaML9JbjfrZ+iuk1BWw/Z2rZ6zfheU74ObY1yp36c99L SjUdqgiYEXvl6OcpO5/j3qc6dgpqcVKiDPZ7O7cTp8BNXL2fhxc/laZep7w97tz2tKY7lW1r/fFX jw1wIMeW+j3Gtu11m/bh8fgflepsfbvStgk75XCs941gwYnjsI1tWhfvvo2mRG+q7rgUBQtx9gM+ PnXJQPFo97FO+VAHYujRbH4uLkQnlrx2+IlO7FYsgneUKW/Rsl0sjrx0i3hgWc8Ke597Ec2Yd8oq kmx871/2dBskv898qDCeWTWTOlBHkXmqhN/bXqZ1ycEd7+0u/k2dGLASn7Cnt5jdS6+X3JCE7/uN Y6s7lvpYPUgkSpb77I8w8yEd3nvOpx5TXCsjXunasYdRQOjVKmq2pHMvFTKBnaPXmqb8W6Hm3kSW Ilvbk7M42euSfMbWc8krVgLrp+vs6XacW+SECrmlcigU1T7aWIGH/pwVM5rjbEjsPvoasATmlYPT 1uCH/Upj6+t54G7HdL/S1oLqeLrrCIzemi3Ay5XqXtEhjKaWLU24e60rjnuhhEPRPZ9+yY8GHtI5 FMSctwW/vKd99/BlkCRPA2iW5tpU5uUp7cLL06nw79ZsjjMAgb2sz54rqvyUshxpscKLdVZocMGi Ls18kLBYK8Xgcjh2b0/gSivH9mCx8BeyNhs44US+s+gAEmoY+na16+pZpNUO2Wr2sdeNSM7vd63H vayo52mvhsplo6VCUYFFNHZ2964sveNTxTrOuicUbodLG36sjmIXKx6Py9r2re1zvu/IYGiO426H hy10ziaOEWwAIy86Fgb4JzwDtK0gFU/Ba12x19ZWtaJis0gkNBTUT53yyAusB+ElGvMRBNbSl4oC 4kP3MpT3kGvXtC42aR3BXMqexpOeBCLkYIMfuMgCXaugz1P9QzHU8Lrch4RNWBOijWD13bYI731v zc2Xaf+aIFb+2n2PpYy1Y6qHeFuBeHxc7sc+UPPtvQ9nuRTjJ0mIBcBuqAFsQFzyuaaq1kAXWnW6 n+Cj7xaQd52iQ0Rt/diUefBNw1Djz7KXMeHnhnE0awg+r31ZUNSSFZbrWZHV0miPMrKK9X5OfDwE SyaFAVL1Fzt413plpLkeu7oz1rJN+1BvpBZxpABCSPeQi3UnwEMsBvmRVWL0ft9vlQUJ7Mo5Uule Ie6ek5UKnkEFZLmEaU3PSberCwOH68suedU1xdObyvSmJPZHMPR7wqUnFA6DAhh0lYvuX7vd25Wo FAQSFUqHYv5+zuVWtRRjiAQsaE2oJMLOXAXDIMg21ERBfl8HDlSiTFGjuQeadglquX7teeV5FMt8 P4Tj+zp2wS11yhFEpVOyyLXHLQSg4MZt+pKP58rv61bMDfnwcEwIH0xzNIJOAN13DqFC3F+Mjvd1 9zGkUQ2ROGyCX67iG6uLmo9cQOuPWv2+zmZdkrOX1lLZXV9PDANIP08UlatwDJKlfl+H5qb7TMe+ BoHwYluyewepeQ4c6F6XE0tOU1z75dw3kCJBmRgEWBCyrtZEWaKy3Pi653w42AXWQFxxIk6gbQ1F 2xHk6kMfncp+KdP+1Z4vINsqr8V+2BWLG3JKAQuJB0OvROm+32+plhC+sxNQEPV9y0rUjs62qgbG ZwaOt/d15ca/I8lwkaQQgNlddN2r9+ZUEfIMqDGmfOh2B0oHj95BcLOyVh89VkNJ9G1DDVGwCV/U hLapDZccVBy6ZUJNIt8BHAsJfDaRMOHZzjPjlFQFV6CKRTcsDRNRhJaCODee4D37SwtC0GjL61nW bfcbtdx5GY3Zc0PCHTsNCJ/uJ8nIoSAv/IGKpoII3KxtmJkgutYH/jIopvVcWBF2HCtv+Kb3w86u i4Oj1C/MQcDYhML7OjSTbLsW+6R+CFUsOQ+RA96JVqSUcdHzFC9qX1r2awnSr4gpu/fa8PEcNhrb jaBGI2ceEkVqe6Tr5aqLXjgAYgEMzEuGTqDrGK5+Pyd79Cn9ZN/gmYyR7SI/PHCqGCLuMijQ0Gzv 6xQHOYBVITHPc4ahS7rL3rqi5JR11EB/3td1aIUOZu4Lh2g02zgemvzETQ4GILPRg1zzdQNkPcOy 5ShiEreAJyQEeoTkcDeCM03vly8ZndqBYMNY9BOfWfCcW8TYCAHEESVk3s8ZzBgxLojcySw9cI5N PSBDcV5KlSHH+5l1qjjCMrJqxbmxNHk0euPk70FqVnP4jKvnfd8vyJEUVdtDI27uruJjbLCCyUcW 0MWHhH5fF0otnelRlVyt+qKuLF15i8BSuEn8AY3pOkm27WwJXAwgQaUou2zBFsukfLPdMMVZ/9Ga Y8cEyfxVKRKcTaSnh33+YCDSf9vGtUz5d6xMj6KMdO7EQfXcXOEIVrYKdFwuRZFbNT0nDBGECuuN 1G2QhF5gleKBmHICvofcEEvvdcHixdOFsRAOUpFzedReOXFuPHhbPhTWTfVBKBSe9RMpyPhHU88b ZSr8RJWFiWsnELgpH6h7tICOY6VwlXZB7kJU9xi2iObyngfB9n5O7EEWIWaDP/zIRTzvIXip4bMd +iCdvgVx7+uWrUBC5TGu7qPqdjwbpgVB1eFE4cBUIPy+To1l1UEvpBHtWRDPB0kgGuwJcaDse948 5wNjMS132G7UAqYMOCDYebirHkqEkXK1T8852sK5UYhV5EAETgNHCrEgzWETuqx3wdd6P6dnZ+ek lc2tE7N0W0HBD2rDz5WmbDfqOuf7wFARJojFkqKCMXhBzYVeD7rBY6hsXe/lfT8M8OHIIjeb/0vA lkZ+FjjFcMVb6Z16odDv68az5oO9raK0UQ+kWYChNFHUM+u3oApX3qbrsPiDGo2eVeNrcPgE/6OP xMf0dguOTRrMcXbi+LzxWDYuhnqNEPB3dwWmFh2hW0575AkHMXFWjQKi6Mg2xpZN5/hZL0RiPxpy x+iaePkSRT8PHPLiOCcwsaVhVYda4cbpeZ7joq/e66ImQHY7fw713fbVc+DMu/BqxC6SFr21mZdz AhsfHmVk9qxlVFvGDcsMyS7ce8hyRsfEezriLVlBubgnAvLeAyvCd7VQUMDH3ud3cEIUL6RzaFgN J3mfSAaBcq6LWHhQ7kS7TPnermDySthj5S47jJGJgqzhAT/6YFaIpnu818VCkFBqUmVxox86egk5 ZEHbed53shl4wrQPvPLrsOY6TVQLslaFGc7KTAwTJZN5hzif8pZcI6mAl1CUp51htLEQRIC2xcVu JLhL2yacCMJf4S6ZKJMkvSYh+q/Chia0vupFVeDf77cTlIqHXOIiArWKC8Q6SAne2Cb6ZJQHeV+n Y0uvn2kU1B+TEZw4CxNW6b04ZCjNwq6ddPiztA/80ZhSEfghGkboY1t0xrC9hVvI7VqmfdA7IaLy FjTHHsgfMRKgpveBVrBVyAMc9v2c/HuMUR2hnJkuynUEOQMVqOlZajDQZes11ZUTxIMjpqAODN87 KhleBlQQWGZjNHDDQnjfz6oxxvF3BXlhg1Z0YsnLow8FziQUWOPBT/4gv4TPDstEBz6xYgXIOU+U hcq/peWD8c/8Wi2HoLoBKgoCTj0rat5Yb635L3LPMBKr7+cUjdgtMAz40sbhVuvGaj418g02sRKw 5/k5g9Lu9w3rpPzN6fFKISHxSTal0q2lUcozxZm61RB4JR5H4n8XFrQsvmAE25cBVuRvmXGQFejx oJGboklar5qqqbFk8EvtFfyVDzrro7NoiGS66+HO9X5wbjjyCzGgJurqPvp4/NBp/3iboffUzGNL OsfjDrOcGKGSMBG02z5+J176Kkiip68kE1aP1i12V3XPB7Z+ajkm6zTr2wZAGYuJ9OK7AgrYsLEI dKwRDVkijVkNMz+jjjhC8UcvQXec11nr0NBLrOiF066C72XiZ3ocSjSNt7LKwDwHrst1caYLsbLQ hvEL937HC5+BtbTruRZ9Cu3whhwx+0mIhabax63lbAjhfR0WRt8oVAF7iHzl8kIL3ROujcSCr1cj WN/XqVy7dmKgmmEBTg+JIkQ4mmhUBKlZBz72hEvBweh0dpHlvvQrmj7Xfn7cZ2FQuReLpUz16Iqo OlbwtId9rAp5X2HA89bDIM2pLbE/vZ9eMZQVEIVtolsbeUdtNqsvZhUKrR60a3rOFNVcWLNdraaa htB4dB0ljFLfkb8S5uiES+qpn3JrYk4gdV4og2KLHeQ2CJUrIynW6r2eXF3bm3BofMo6Mr4ENVnG gwunLoiIDtK075Tpeord8F78T59jYYPhodSckQz9Rmt0z31KkOyBlA5peqiP/CsEtD1KJgMVlh0H AndNz6mR2tFWXXRsHEUjVm9NAaESFUxvgCMiHua6ws/CPuvOxYZpqC9XCfuIdiw5xxWjAAXTe100 WVdMQyfH7/JPuEPhnmjrpaItsy6kv6yc1gU/ESb3YLIEAKHK6MQeHqX/gNYblJocmq5j5DIB1WkG 6iW29dF0m6J3JYnVzloPDPyZ8j3UJqkpwIyV0BBdheW68sCGiQgiHXzztyZeIIRXhnqYJ9EyRDoo JZIvemI6xfQ/qZbneSnNLe41MMBeoJDEvzQOKQZ9iczeImII0dnnOwg5y8VTt+C2UPvHOuHUwUco OnujXs35bhWiyfvIi51Ld0g/crwOlrvGv9amIQ/2zJQP0EF0cGlYpyIMBEspiUOF8ZUAOVGA4M3x UmOsLSZtdOgRLF246IgrhNZYtQczO3oy1QfUS+zerOM1HlcuqAh+RiRhvoOFybHCRd9xRsJpaXDu 4xXhnUEntCeBCvhP3Fsy4DbzEN19MayaCBf11joguaZK+NoZVYoJqFU3fYqzaEpEpuvFwQf1ToeN 2i9MIjrOlIQq4CMn3KWjLPZh5c0j3LSe+azNAh9LjUkrtQGJRo7e7xdGS8x/XJe39NlUjSVUT3TB SewPN89YwnSdjz/N72mnrYncwatUa622FYB7TENGvO82z13AkFNbS4hqEcpUNFn2RMmWyisLELe2 NFMeUZkQ2kbh3+xgPU6eS3YDfXe5HtgvimacJ4D4QjgAV4stMiBtUpbVZ0wQVSdaQ19PupiTB6WN XHC+GC3cGlTXEqNslliDmVRmeE11Zex4m+Eclr85SM2d8IxklorCdmUu6qfrnExxDeKyFNw36kKH QiPIgnpV9ImVZnLKIFRYW+/9k0SmKsy+6K0RHDZZNWKEFNpPMm4yxWfUqY4Rr4wU1pRJgch5cK0L qzqT1kCCCQFcxML7foO/oxtmxpHpjdBbHBUBvpjOkxgYGmlPKr+vkwfKz3VEi9P+gRhUBJG1QKiI riLiZC8n3mOmQOeBT6SXSiJrLWKtPBwRgJLrVjOMBMCUR4/ehJ5r/D7dZcjNICyFpNvkBS2IXg3J Uibc1cLhYsARBngoWz1smRgOYefWoqK8B7MH0/0OJXJVgkgVvC9m2KLIEz5CBst+gD1be5/WpYVw VCiToVQNthCNDd4zJk1ckgatPtLzfMdZzEL/8etfSPifPht2/jp+/9v4/PP//Hb/9/G3P356Lf73 f/nX0b78J371D9t/4pf/2z/9y7/808/Q/v7PPkD7+6cfPv36nU/+eV2+Nyod1KxFu0NNiDZ81y9k ilw6msHu0XQe0fpMGMGRwXiKKMYHl6h2wcXULQw9poZ16vig3/GSTarB9TAgOVAYFaGg9U21K7+I Dx2CZM8zxlSMAoIPLVrZt9FpDEg9MBbHIJaGRbiJ7Kn2aVVRhiyQYfKFPxEKAN6UGDY100DJyyy+ 6itsflbOw1iiog5D2jIiG8ErhBzn1UBRjJNQMrOWRhcxBjPnG2mlKnGh9BtOkohxZDZaV4nib9N6 Mv/I9JNqlq08EwKTSSx7rSus5dkrYwbw3s+pVW+mxBilQdMYdUHD9WRvDDG6owqoEkgkTZxVAeo6 FTppen3u0SRpTGgYymU5maIyJqIl9c69n8m8JZoV8SKM/a5mgTUUOXBaoYjpGbV9wmrWC72tiaVT ROFYHJKcfomOpeYCBx1xNZb5fj9LbkUtYtA+s+kInhYN85gcF6ZYTbR2Z82IkRlgpXPQyEMjx9Xk B1SjcsWbWQYYX+fajlubdHEjURjzjNl6SgUwJbijUFwneztN+0CuG9/6cHUEh/4YysIL4UtYE8u6 rkJe9Z3ezwCYRrhuB0kSRn3TUNC7knYcV84y7+78zkwCD9B0FTfBYGzZ0M2bUsTkvBpX0ODwujI9 9mk9EflofxlQionoAqKRAN6PomJoUTvYDC7Hcdr3gzJV5ZrZF1zyEtjdfdQfZM4wJqpQeVwzZzWY bbyQfZn0DrN2pG5xZAUZ6W7agCxsOnSqRdRk9ArY1iQCzrizyr3eQYhZLcSAoZUY8O/1tAyMQK4g 91Pv4iZU9Hnvuyj2bFSFEPdkVL6vWyRpuGbR/VbleS+hhOgQ/U7dqs4P5kLfE3d59JXQDE53GDzh EYkq1rk2KEEt0no8ap3ipdGf6m100M2jxEy6rmhwK0dUHru6iSYkcspbSrTx/wAaB58pbKAFAsNe 6p0yG4ueS5gP7/fjixmaZpOq/IKSfW3ozGwzjbNx7QkJfEa6vK8z0cUOJuzNEEojCoz7nbjPBCEm E6NnEHWehdbIURcYx/oZXkrgsM70v1m9JnqQLt0j2zQ9J6NcVl76S9VqYljiyrx9CJWY99YZ5xRK tvdzUl2aUxSssSF8l+p7IE22LrwlXTFYjUPNvQAUUMvC/JLEkwYYnl9qrBtKN/wM6B29izlv9biw l5NmYa5jfcPbLiBNAWXxhtVg/LdNz0nRpkJ6GQPoNoNqMezh93SboYPDD56fpTjlQ5fm+krscBN2 K8doxcyQe5qF+RZtC7B6XdNzahNT/YshC+Q8c/edVTEuF2cYmHHqikhz0ykftDh0eGSNRUXtjJ6B Q/4cHa2tQwEythXQ6TkVO+Eeh11UTCXGu2kbekaHZ1RRmGFe55rPBtAVOorUM/oIW7yqnoF5QdWJ xUAfBPkmft/7jmh6F+4HZ9RvsRximox4AfaQValS5Vma7+v4bcSploGmHZcGm2g6GOCe87CqAKov n3CZ1qUZslLwlNeYRYhJzmjGIaskVbhj0p3ynT2watANk3ckyxCPndOa4y4bQFO4o9lifSDG7DGQ RRxKSAGWEXIbbaIETHg0kkXhV40egPF+P+BgnIQD6r4UMffLPRcAKmzDBsGjKJlZcxiyBuTmfvl7 2BbI0P3TlI6E13MwgYp08f/e9zPnJS+9OMMqzFXBHdAormGjKEDZCLs+7cOCl+m1a1Y8MJTJBL/s RQzQHEJXrTDeqQ6+7+cm9HB8pn4cd0KWGsDcwIw2oq7JorOqkzuti86JeFDS8Q0de1zOHsBp1Fc7 gZkYNYfh9L5f5JmVYww0hZ2tv5lyislG+xabR38vHMnnfZ2ygfewM4zokm4ywKQwbDeKQtxwGcKC A87v6xw0UspjmD+amqabTSiyAFBPRl2QNBI27JT3dTFOYkqaqy4NkqRTJ70jm5e9LDa194TbzOeN mThToJCLQv5/1jmWhRru3Aw5aCmZw9qK7/uRy/xSdQzf1ygcjjiZegS21sNw46MKkpR1ek5P8Zhz 0AwbaqUxF+ZJzIT0YP+MUDadxsR3etqoikFyRAwPIf/Nz3rWo8VsmHiQ7Y53MO/ezwnImFeYvL1w HMNYq2B2ZzOkipEWYJjLjJ33dTEKxywIB5QEjjHlMFhBFGNPhYZJirBona6TOxa+xGGOOKtGYSFk Opt6TiwYC0OLfGfmHhM0nCZGsgjDsK2shlGOEb8Yu2exaJUJn/f9kD2GoLyVNViVBol0gBLuzPKO yQKj10yI93VGFdRpzC6OHBpnPEk+nrfmnACVVkbTxOg8kwD7HxpFA97QAzFRnLc1w2mehKo3e5aq 5vt3ZgQAj+68ArmQR3wG3mCcHnEbRJfl4/So8ZJ1ygcyDG/BA+WF+kjPGVGznyAnTh4pj+qu3sX7 /WKmR0sXGDLJiM7mtWJd+Z4mOLTFTUAx4dr7upgoRXfNcBYdJh43msSMjKNg6J3ZD34rV3vSOZw8 nC9ou0QjrvXl7JhDeNFthp1WS6WZPWiTVaCHOEbHmTdA3tsZbjB1rw2hVFEEkGC6X3j+DMHgVWq0 SWWdKb2rrCxo4ZFL8gwXnuLTSB1ccnjFc0WTReNcydQbqSb82VUqG8E5z85LMHod9ePqx/MFmKry WlBam+ymBQ9ju044gSLqqbkdTwgd2emwoGloi6ZcdFt0D8X5hJ86rBob+uZO3elK0uEHg0IS3vJJ j9yZBKE446AJOtIeNkBdNeljQCsKpSPajz034YPh1XlGB3YKZ7auLhG1CGnxAIYwuIDX2LLioPRM eUTVeEBnHzX9zeN8DEheHkB6ocjoHnRyxnbaB3PyZoyM0+lP81oAlPOhq8sJKtgbR0HByHxGOBQ6 na2soJkCUzTrenXl3bpCN2BlOfuEE00nJIYcPErFcEUby8chXKUWdTODJGg9/1TfLZz4cswSZOKv eum4tlGg4NmolEscFcCn3nmE6wcNNFKlesBRXvumq8fNNUovHfYrJmbmHhBfA5FHHB0CJPGhLMXg AO1utBicysIg58ekVwxYmMd30MkxCbrI8VyHFKWwaH58JnxTVE1/vJ8zbB2ztOwWM7dRxIzfa/xQ jyjCYzTP8BULYaoPtnjXPoD1JsIYuabj4JAhdf2GgQbjeKbS5+fcUJQDN2NZuc8e3re2lpA162ga QVdAp5+z/37OmDrwHKEfGHZgyNlWKl7bvRCQ3XCyZqV25/s6qj9Gh2A8ZFtFmv9Cl7MZ/DTHy77Z eTkzL0cYw+BjJ+iwODufdcwhpuiTex//GMOrcy81ujiG4EN/VY2ZR8mF+Jgkn4NnznQXn4Di/ZwI GC6fEUb7ZrAfjuneIPaGEaV/EETHE54JJ/AWiNSiKoltGO8MEGtQhy74I0ZpoC2+kuB9P0T/dnZD ux3Ihg/ibb0OQx4r/GivdBR17uV4RDGPBDop0RX3jUBi76sIJqPx7TBmnE2Y6gqXjP+n1SvJ4TqO /LB+wrnDlrXMYgTG9OrEP5EOlANYAC2ElTsfngHa48XJrVBqRb9jWhdjSTIuzs9V+lbh0wV0mFEf 1MSFAVez7WZk516A4xCaPDS7k9yh+l2gKafYOySK9obLyS6Z86HHUWIb4Rw6JyWaORwwk2oaYwN9 ARIErPOP731wsAXjhAXaL7wQDpX804+2k+YWVdBoCpg2el/3OEmpi8WydgzyQ5pSWbgIusec8Hpr HCWZfTDtDFnJc4tgFnP4lrGZOIOgj2MQ+7F98GbaB6SbPaQqaePdGsB2kIjGrjUQhYAeS+aMnVP+ aYA58uxqma3ZwbNlQ4lZ844sTn30jz7UPLsULW0BZbKSf8W1+/giALKVhaISeVSy2hHLKc6MJCAo iiuurwZR3JTpGsYRHLA1fIg4HDDVBzNgXpsMAKEfVUhVJkHRBEcS7EaIZkRy4mfQ2Lig6UYCBbUg NZpzTzvxEXPHDANhQQJO66m3G0oRJrjIaJfSYNdsi/yI2TNh7jxsm+pmlDtD7pqaLN1/ONAAicjV OHcaQW7GVP58FtbBS0+JNsTxWatoD2NMTbmQ84xYD68GzrPJBlTYqn7TSLuGowTyF7w/zkMYkjU/ E/Od83cJhL7paBmuqBTRfGSrjGzCNY6wRRTENOaE80BLyloAlEAvIk6V0NCeWb+WpNSw5w5ytd/5 4DQAFYAV44T6xcHDqUtEVB0mmAhJjTZf9vC+DrgbDmVLYNJCAyzKxuhMOldK5apEJIzjO+/rOJzG DbNpGw69gZug/0uMx6oVzg0v6DrrYvZpgZcJD9+DUWzCBhQwyhh+4tqpw7wY3RZLNvHdeCnUTzia m1WpFT8PR8VBVCjAgCOynbN8PychTc6g0kYIlDs9g2gCw8Vw3/AuBSMU9XQ/bpLTJjKG6WXpcVbj rZ6ZmIwTN3oREM3Dvu9nvp8ZpFY75mfqxkJqROGqzqwm+x3NK1ixTThhXobRoPLshs6enpyS4r4Y 3ByM9PguCr0EQT/lkW6d/hAN7ney/8Q4uRIaEa3AOQfrg8XtlEdR8tBcLQfJicQ+Wr1mzT4OXcQp LWct4hjMhNemgs1yGU++GS1ILBRUoryxIUWNMzxY5B1jwgmDTQ44wUFN5QGYeTbCAxvRAzADHdY3 r2LGa60Cwz8ohCPQW3AYto99BxlxgsgXIQQjBf3vfRh+UTDSfIiVtQhH8zR7Tb7h3TrOGl0DAL2v i3lzclLvrXGtAYxvMEDOfHeLo3EgOw5ya2xP13EGjDAYw8EdT9MJzH9pxA9GAh0bbQUMm66Y1tMH iwt8OqY30WUjJGqSzFBLuBssDbxHJXs/J85pHtaOGVpwTAKFI/odUrPZjACcHSnkcE/PGYZ/yFgV WeZp3Xzo8N1kI9CMYSIJbURp2r8gYbpTzHlwa/oBLVC+MBmxF32qoRZC84nXyQBnB0YyxRATnHG0 ojtFgVlbI1xKW9GD9+k5YZLJZV5t4IUpJ3MLGjryN/w3X2GilWOidz4LW1cDrIHr9IJA1X5TGayO 5/WY7D7Or87U9JysZpMSNatj8TUsNplIGaDNSJMzmFBZAwPavPcBxANOVYDPAgApEKGGS1h7UBiT Gl7jO3rzdlANkP8DLBQsp7MNoiPqqJdj/oo+8JS97/t5KQWH0IvzSTwK4WLan+xgU0Bfxd/m2OP3 dWw+XQBnfD9IsrlSNE9vJ2xsNRj3ilOgaT4jrGaSwoKYORNHgk2mw1NYpZqZzcNook7PcR2nNA3B gQeGjX6DkSKWqXGkJ5QAiulybYwprvWgea0BZ4zyON+JBJrgQxMpCruCJsrDe6pjrBXfasLvgu2+ lwiN05TWtXx0VmEwmwpxkirvdbG1BrWljGMnWtn67qJawzrOv2jPDBNYoa+nfceJProijHyQLZ7J MkP65qcBB64vGUXLXKeNSfM62VB6sISuzk98SY5lqlccio0pXqepZ9+UTow+ACQxohsOL0oW9dej 23CegGBgl0x56+iissVgxSRlqJn3cCK9r6a671vwB90Q2u91YTBQ0tGDdjQAsfcVG6SY/Y5BPhrW oB/AmmfIvBBR6kuLdDEVEe5WyF1H81nL8mQxPYEonBOfMCco3XhQsCdYfxxs4qBHy4qKREolr8mu qW4668Xic/CcyxJKyEB14UgpYR+9dfKe0+El3+/nCGJgi2YDU4jmW4VKRemYoKDG5Aszwaj+hEtO ZHDeEHo1mqOJnTswEefXPAL7x0RD1OoZPz+mbOOUfMeYnWXzjUJOYVoLp/tjaES3mdtUpv2TLB+H Hp2tQuITMHMIwexYuJofJxd54L7KYLqOVJFgMYWnyUv9wc4PHcF4ZfK53JcG6bBN+SBvVRDeAKjX COdMyF/zf2RyM+lv/GfY27lfrHWC+mjb34vpk1KUPx5mFyfxVUZa5KY/UdFpH3iy9hf3lnnBGlHc OFl6GCOrGgLQUE3yjRnv/VNU2GS+Ycm2fWgvw224mWqKXzHVHCTzsDN+Ul6msu2+SIlCiJk7Ph+g 5kch3Mlj8DHlg6BUh8yiG+tAVqk2A0wcNQ3LJ5tQMMwmKOZ+jrE2T4mqcKBxOWe9CXpGMGnjxib2 Ba6p0Qnnw6xDiQyek6YICWRyylV6FGVIu4oJyq2a/TMtBJNUccYsvreA2WeBfEkHRm1lja+aiMHM n4m3frSx8C9QwC5nXiJb+jGGlGNqSoDhs+J92j9jnXwk1CbCy2QKZm/8ReWDGYYAPYUVR6Xe+0cj EDlmZ+UdjYRox7QGW2QL1e7RuYsybbofTfRgtOpYzLC4V1SIw/FPwwjI4IewD7R73w/d0wQwQcRq YOearGWgGtmVdADCftg8zfupbuqFbbHOrCcsVJ/j47dstFPtaARshN77jGdkL/2QlR0mg1Fdx/JU ad4uUq7F4knCUPn/vwvph69fv/38/wQAAAD//wMAUEsDBBQABgAIAAAAIQDZvL18mwEAAD0DAAAQ AAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJyT 0WvbMBDG3wf7H4zeG7lZGSPIKiPd6GBlgaTt800+xyKyJHRXk+yvnxyTxukeBn27++7j088nWd3u O1f0mMgGX4nrWSkK9CbU1m8r8bj5fvVFFMTga3DBYyUOSOJWf/ygVilETGyRihzhqRItc1xISabF DmiWxz5PmpA64NymrQxNYw3eBfPSoWc5L8vPEveMvsb6Kr4GijFx0fN7Q+tgBj562hxiBtbqa4zO GuD8lfrBmhQoNFw8gLGeA7XFt71Bp+TUpjLnGs1LsnzQpZLTVq0NOFzmI3QDjlDJs6DuEYb1rcAm 0qrnRY+GQyrI/skLnIviNxAOYJXoIVnwnAEH29gcaxeJk34OaUctIpOS2TCKx3Lqndb2Rs+Phlxc GoeAESQPLhE3lh3Sr2YFif9HfGQYeUecH56HzZ3xXitI3VS/AHhz5DJ0EfxBL1s0u2IV8q0oeRLV T+t39Bg34Q4YTwu/FNW6hYR1vqPT/Cyo+7zr5IaQZQt+i/XJ8+9geChP49+gr29m5acy3/xEU/L8 7vVfAAAA//8DAFBLAwQUAAYACAAAACEAxcYn1aUBAADKBgAAEAAAAHhsL2NhbGNDaGFpbi54bWxk lctugzAQRfeV+g/I+4aQPlWFRMI89+0HIOIGJDARRlX790XBzrh3ljm5xx5sbrI//gx98K0m0406 FtFmKwKlm/HU6XMsPj/yhzcRmLnWp7oftYrFrzLieLi/2zd138i27nSwrKBNLNp5vryHoWlaNdRm M16UXr75GqehnpeP0zk0l0nVJ9MqNQ99uNtuX8JhWUAc9k0wxSKPIhF0sdiJoF9GEeGNL0NdOZFH INnNdZksQiuL0EqZlTIrZZZklmSWZFb+BCPnzwiWo/73mBkqGSoZKikqKSopKhIViYpEJX/FSRGk CCSChJ1iwk4xwUkSnDVh55zgsAnuXNmd6Q2r7M4+Wd8VIiWzSmaVdhqyCmYVzCqY5ZpA6+TMypnl OkCW64BP8LlcByjjOuATtFwHKOM64BO0qvX6KFKtF+yB9fYIlKiUqJSoFKgUqBSo2HLStracHkDF lpMStpweQMWWkxK2nB5AxZaTEracHkClWt93SpQICgS2z6RkmLB9poTtMwHbOw/gGq6rXoS1w/0G eBm8PPsbcE2Et3+hwx8AAAD//wMAUEsDBBQABgAIAAAAIQDVxbywRQEAAGECAAARAAgBZG9jUHJv cHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMkstOwzAQRfdI /EPkfeIkLQVZSSoB6ooiJIp47Cx72lrED9mmaf8eJ2lDUFkgeeO5d47vjFzM97KOdmCd0KpEWZKi CBTTXKhNiV5Wi/gGRc5TxWmtFZToAA7Nq8uLghnCtIUnqw1YL8BFgaQcYaZEW+8NwdixLUjqkuBQ QVxrK6kPV7vBhrJPugGcp+kMS/CUU09xC4zNQERHJGcD0nzZugNwhqEGCco7nCUZ/vF6sNL92dAp I6cU/mDCTMe4YzZnvTi4904MxqZpkmbSxQj5M/y2fHjuRo2FanfFAFUFZ4RZoF7b6l3TXfQobIFH xXaBNXV+GXa9FsBvDyPfuRZ4XfweCjwKgUgf/6S8Tu7uVwtU5Wl2Fad5OKt0RrIZydOP9ulf/W3A viCPAf5DnK6yaxKg+XREPAGqAp99iuobAAD//wMAUEsBAi0AFAAGAAgAAAAhALUVk99uAQAAmAUA ABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAUHxO wfYAAABMAgAACwAAAAAAAAAAAAAAAACnAwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAAEGY +AkBAADMAwAAGgAAAAAAAAAAAAAAAADOBgAAeGwvX3JlbHMvd29ya2Jvb2sueG1sLnJlbHNQSwEC LQAUAAYACAAAACEAiht+V+gBAAAwAwAADwAAAAAAAAAAAAAAAAAXCQAAeGwvd29ya2Jvb2sueG1s UEsBAi0AFAAGAAgAAAAhALVBZpS7AwAA4xYAAA0AAAAAAAAAAAAAAAAALAsAAHhsL3N0eWxlcy54 bWxQSwECLQAUAAYACAAAACEAYspUCNgnAAChqwAAGAAAAAAAAAAAAAAAAAASDwAAeGwvd29ya3No ZWV0cy9zaGVldDIueG1sUEsBAi0AFAAGAAgAAAAhADAPiGsRBwAA3h0AABMAAAAAAAAAAAAAAAAA IDcAAHhsL3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEAPWg1WM9kAADfmwEAGAAAAAAA AAAAAAAAAABiPgAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1sUEsBAi0AFAAGAAgAAAAhAHjIirl5 KAAALVYAABQAAAAAAAAAAAAAAAAAZ6MAAHhsL3NoYXJlZFN0cmluZ3MueG1sUEsBAi0AFAAGAAgA AAAhANm8vXybAQAAPQMAABAAAAAAAAAAAAAAAAAAEswAAGRvY1Byb3BzL2FwcC54bWxQSwECLQAU AAYACAAAACEAxcYn1aUBAADKBgAAEAAAAAAAAAAAAAAAAADjzgAAeGwvY2FsY0NoYWluLnhtbFBL AQItABQABgAIAAAAIQDVxbywRQEAAGECAAARAAAAAAAAAAAAAAAAALbQAABkb2NQcm9wcy9jb3Jl LnhtbFBLBQYAAAAADAAMAAQDAAAy0wAAAAA= --Apple-Mail=_2594CE88-2AA5-4665-A2E3-51A8ABEDB344 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Feb 2, 2015, at 8:31 AM, Yoav Nir wrote: >=20 > The three-sigma rule applies even with a non-normal distribution. >=20 > Anyway, I tried the 64-key sample. Results are slightly better. >=20 > Yoav > >> On Feb 1, 2015, at 7:36 PM, Yaron Sheffer = wrote: >>=20 >> Hi Yoav, >>=20 >> This is good, but I'm not sure if it's good enough. The ratio between = min and max (which I trust more than the "mean +/- 3s" rule, because = this is not a normal distribution) is consistently around 4. So if you = have to design your timeouts on a particular machine, you would still = have a lot of uncertainty. For comparison, could you try again with 64 = replacing the 16 tries, and with lower bit lengths? >>=20 >> Thanks, >> Yaron >>=20 >> On 02/01/2015 11:46 AM, Yoav Nir wrote: >>> And now it=92s really attached. >>>=20 >>>=20 >>>=20 >>>=20 >>>> On Feb 1, 2015, at 11:45 AM, Yoav Nir wrote: >>>>=20 >>>>=20 >>>>> On Jan 31, 2015, at 12:35 AM, Yoav Nir = wrote: >>>>>=20 >>>>>=20 >>>>>> On Jan 30, 2015, at 3:37 PM, Yaron Sheffer = wrote: >>>>>>=20 >>>>>> What I would suggest is: we give the client a single puzzle, and = ask it to return 16 different solutions. Indeed each puzzle then should = be 16X easier. The nice thing is, the server should only check *one* of = them, at random. The client would still need to solve all of them = because it doesn't want to risk the exchange being rejected because some = solutions are invalid (the game theory is probably more complex than = that, but I think what I'm saying is still close to the truth). >>>>>>=20 >>>>>> So: the client does the same amount of work, the server does the = same amount of work, but the client run-time is still much more = deterministic. >>>>=20 >>>> >>>>=20 >>>>> Note that these are still single core results, and most laptops = can do twice or four times as much. Now, I know that what I SHOULD be = doing is to randomly generate 100 =93cookies=94 and then calculate the = times for different bit lengths for each of them, and then calculate = mean and standard deviation. But just by looking, it looks like it=92s = much closer to what we want. 16 bits would be a fine puzzle level for my = laptop. No idea about a phone, although I could try to compile this and = run it on an ARM-based appliance, which should match phones. >>>>=20 >>>> OK. Now I have done it right. See attached. The data suggests that = 15 or 16 bits is the level of puzzle that for this kind of hardware is = challenging but not too onerous. Add another bit if we assume (probably = correctly) that the vast majority of laptops have dual cores at least. >>>>=20 >>>> I would like to run a similar test on an ARM processor, though. The = capabilities of phones and tablets are all over the place, what with = different versions of ARM processors and devices having anything from = dual to octo-core, but it would be nice to get ballpark figures. >>>>=20 >>>> Yoav >>>>=20 >>>=20 >=20 --Apple-Mail=_2594CE88-2AA5-4665-A2E3-51A8ABEDB344-- From nobody Wed Feb 4 22:53:07 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1AD11A026A for ; Wed, 4 Feb 2015 22:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.424 X-Spam-Level: X-Spam-Status: No, score=0.424 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, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, TVD_FINGER_02=1.215] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEVJN-bmFhjh for ; Wed, 4 Feb 2015 22:53:03 -0800 (PST) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (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 1FE791A0264 for ; Wed, 4 Feb 2015 22:53:03 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id hv19so4351722lab.10 for ; Wed, 04 Feb 2015 22:53:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=1ZYBHeOq/NYjr17a6Fu7+gdFGO2fbBo7K0l6h7DaF9s=; b=xEOiavWzt2FhldTvFIpTuwN+syTqnWkVQnDN1E+gMbDSf65x3+P8vt6k5c6FxOH5aa v2pn/8D3uSp7BAyM38hRw8jgqTduKahEBznoHpDp5PTjMJK8yohBOexbI6kdlgFfQRN6 561/4idyXXyMoM//tNN69BZnxysbaw+bKh8YGBTfhrL0llPFLPsOIRdRQDSTYJTsDvHr lJBnvEecfyVmqX8HSlyzpmWaQx6O89r6WsdkLg/0SEgtve12IZYd9F303himm64re/yJ LUDWW/GrETav5GWpcDA//F+kNhD/LqNAP43cnhO8bkiehAkoIhyGk+kOvuM686qmPuh/ FcAQ== X-Received: by 10.112.136.233 with SMTP id qd9mr1762237lbb.61.1423119181618; Wed, 04 Feb 2015 22:53:01 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id dx2sm779984lbc.10.2015.02.04.22.53.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Feb 2015 22:53:01 -0800 (PST) Message-ID: <93EDF2091CD742D3AAD4A10423A4CBC9@buildpc> From: "Valery Smyslov" To: "Yoav Nir" , "Yaron Sheffer" References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> <54CE6429.2020800@gmail.com> <45BEE118-9B68-4D7F-BB9B-16A617A0C5AE@gmail.com> <6B33D43D-71C8-4C0E-A280-1763573A8BEB@gmail.com> Date: Thu, 5 Feb 2015 09:52:59 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 06:53:05 -0000 I think this data proves the idea that the difference between computation power of different clients is significant and no single puzzle difficulty level would be reasonable for all. I think we should proceed with the proposal that client is allowed to return less zero bits than requested. And in this case we may go further. The server may even not indicate to the client how many zero bits it wants to get. The server could just give the puzzle to the client and the client would return the best solution that it can get for a reasonable (from client's point of view) time. Some clients would be able to get more zero bits, some less. Then the server would sort all the requests, as described in Tero's e-mail and serve them accordingly. Valery. ----- Original Message ----- From: "Yoav Nir" To: "Yaron Sheffer" Cc: "Valery Smyslov" ; "IPsecME WG" Sent: Wednesday, February 04, 2015 8:06 PM Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash OK, now Ive got a chance to test on an ARM appliance (similar in power to a 2-3 year old phone, I think. Again these are single-core results, but theres an extra bit of badness here in that this is a C implementation of SHA256. We could probably gain around 2 extra bits with an assembly-language implementation. As it is, its about 4 bits behind the Intel i5. Yoav -------------------------------------------------------------------------------- > On Feb 2, 2015, at 8:31 AM, Yoav Nir wrote: > > The three-sigma rule applies even with a non-normal distribution. > > Anyway, I tried the 64-key sample. Results are slightly better. > > Yoav > >> On Feb 1, 2015, at 7:36 PM, Yaron Sheffer wrote: >> >> Hi Yoav, >> >> This is good, but I'm not sure if it's good enough. The ratio between min >> and max (which I trust more than the "mean +/- 3s" rule, because this is >> not a normal distribution) is consistently around 4. So if you have to >> design your timeouts on a particular machine, you would still have a lot >> of uncertainty. For comparison, could you try again with 64 replacing the >> 16 tries, and with lower bit lengths? >> >> Thanks, >> Yaron >> >> On 02/01/2015 11:46 AM, Yoav Nir wrote: >>> And now its really attached. >>> >>> >>> >>> >>>> On Feb 1, 2015, at 11:45 AM, Yoav Nir wrote: >>>> >>>> >>>>> On Jan 31, 2015, at 12:35 AM, Yoav Nir wrote: >>>>> >>>>> >>>>>> On Jan 30, 2015, at 3:37 PM, Yaron Sheffer >>>>>> wrote: >>>>>> >>>>>> What I would suggest is: we give the client a single puzzle, and ask >>>>>> it to return 16 different solutions. Indeed each puzzle then should >>>>>> be 16X easier. The nice thing is, the server should only check *one* >>>>>> of them, at random. The client would still need to solve all of them >>>>>> because it doesn't want to risk the exchange being rejected because >>>>>> some solutions are invalid (the game theory is probably more complex >>>>>> than that, but I think what I'm saying is still close to the truth). >>>>>> >>>>>> So: the client does the same amount of work, the server does the same >>>>>> amount of work, but the client run-time is still much more >>>>>> deterministic. >>>> >>>> >>>> >>>>> Note that these are still single core results, and most laptops can do >>>>> twice or four times as much. Now, I know that what I SHOULD be doing >>>>> is to randomly generate 100 cookies and then calculate the times for >>>>> different bit lengths for each of them, and then calculate mean and >>>>> standard deviation. But just by looking, it looks like its much >>>>> closer to what we want. 16 bits would be a fine puzzle level for my >>>>> laptop. No idea about a phone, although I could try to compile this >>>>> and run it on an ARM-based appliance, which should match phones. >>>> >>>> OK. Now I have done it right. See attached. The data suggests that 15 >>>> or 16 bits is the level of puzzle that for this kind of hardware is >>>> challenging but not too onerous. Add another bit if we assume (probably >>>> correctly) that the vast majority of laptops have dual cores at least. >>>> >>>> I would like to run a similar test on an ARM processor, though. The >>>> capabilities of phones and tablets are all over the place, what with >>>> different versions of ARM processors and devices having anything from >>>> dual to octo-core, but it would be nice to get ballpark figures. >>>> >>>> Yoav >>>> >>> > From nobody Thu Feb 5 02:12:02 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274C91A0162 for ; Thu, 5 Feb 2015 02:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiMnn2zkm8uN for ; Thu, 5 Feb 2015 02:11:59 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (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 5E65B1A0127 for ; Thu, 5 Feb 2015 02:11:59 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id h11so9405022wiw.1 for ; Thu, 05 Feb 2015 02:11:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7EwNgt9tl110tQvYhcBzxvloPSudvAhSuom90YiG6hQ=; b=dRW+bUPiLQlLK5tHr2afFV+wcMnpGnsZkSq3ngfcY6xrSTtjGWex9Ej9gcCdBMcHom qvF+KutmGziQ7ZsUEp1c7ZiCaMo1gq4VWFNg0QBE0gpxuudV8hSDc/bQ/ndeWxDkss67 2KjFi9PTA8cY16U+8Txfp0+VchEsKJoSWoDz3qiAK+4W5s1z1bKHobtcdZCzr6uAFvy8 QgZP0ujo0twNkeAwTsE4RPA/QSwWxLOw8WScZZiLwpuKn8V+7P1hb7Y1KSjH4kFADeh2 niFXfijqumnF2hNKDbE+9rAhhyH5hYz/NAepvzf+sPIPK6sK2M12hxkwKqPcmNIWZSr3 pPFQ== X-Received: by 10.180.189.67 with SMTP id gg3mr13613997wic.4.1423131118094; Thu, 05 Feb 2015 02:11:58 -0800 (PST) Received: from [172.24.251.208] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id pl1sm7119918wic.23.2015.02.05.02.11.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Feb 2015 02:11:57 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=windows-1252 From: Yoav Nir X-Priority: 3 In-Reply-To: <93EDF2091CD742D3AAD4A10423A4CBC9@buildpc> Date: Thu, 5 Feb 2015 12:11:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> <54CE6429.2020800@gmail.com> <45BEE118-9B68-4D7F-BB9B-16A617A0C5AE@gmail.com> <6B33D43D-71C8-4C0E-A280-1763573A8BEB@gmail.com> <93EDF2091CD742D3AAD4A10423A4CBC9@buildpc> To: Valery Smyslov X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 10:12:01 -0000 Before I respond, here=92s one more data point: I=92ve compiled OpenSSL = 1.0.2 for ARM and got ~60,500 SHA-256 hashes (it=92s close enough to not = matter to the result for HMAC-SHA-256) per second. That says that assuming 1 second as the =93reasonable=94 time to solve a = puzzle, we can expect to do about 16-17 bits for one solution, 12 for 16 = solutions or 10 for 64. That=92s pretty much in line with what I got = with =93my=94 code. According to messages on openssl=92s dev list, the = assembly-language version of SHA-256 is about twice as fast, so = respectively that=92s 18, 13 or 11 bit puzzles, Still 3 bits behind = Intel. This does not take into considerations 2- or 4-core laptops or = octo-core Samsung Galaxies. > On Feb 5, 2015, at 8:52 AM, Valery Smyslov wrote: >=20 > I think this data proves the idea that the difference between > computation power of different clients is significant and > no single puzzle difficulty level would be reasonable for all. > I think we should proceed with the proposal that > client is allowed to return less zero bits than requested. It=92s simpler and safer code to get a request from the initiator, mark = it as solved/not-solved, and process if solved or discard if not. Then = you don=92t have to do any queueing beyond what the UDP stack is doing = anyway. > And in this case we may go further. > The server may even not indicate to the client > how many zero bits it wants to get. The server > could just give the puzzle to the client and > the client would return the best solution that it can > get for a reasonable (from client's point of view) time. > Some clients would be able to get more zero bits, some less. > Then the server would sort all the requests, as described > in Tero's e-mail and serve them accordingly. This would allow a sufficiently powerful botnet to flood the queues and = deny service to phones. Suppose it turns out that phones like to work = for 0.5 seconds and usually come up with 15-, 16-, or 17- bit solutions, = it should be easy for a botnet to work far less time on each puzzle and = solve hundreds of puzzles at these bit lengths. That would effectively = block the phones that take a whole half second to calculate just one = such solution. Yoav From nobody Thu Feb 5 02:30:55 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B3D1A0211 for ; Thu, 5 Feb 2015 02:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.569 X-Spam-Level: * X-Spam-Status: No, score=1.569 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWFOdCfL--D0 for ; Thu, 5 Feb 2015 02:30:49 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 738411A0174 for ; Thu, 5 Feb 2015 02:30:48 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t15AUhp3007219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 5 Feb 2015 12:30:43 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t15AUhUO016856; Thu, 5 Feb 2015 12:30:43 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21715.18003.165707.402734@fireball.kivinen.iki.fi> Date: Thu, 5 Feb 2015 12:30:43 +0200 From: Tero Kivinen To: IPsecME WG X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 83 min X-Total-Time: 2657 min Archived-At: Subject: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 10:30:51 -0000 In section 2.3 I think the first MUST for INITIAL_CONTACT should be rephrased so that it says that it MUST NOT do normal INITIAL_CONTACT processing for unaithenticated INITIAL_CONTACT. I think using that INITIAL_CONTACT as a hint to start dead peer detection is ok, but current text says it MUST be ignored so you cannot even use it as hint. I.e. replace: For that reason the INITIAL_CONTACT notifications MUST be ignored for IKE SAs using NULL Authentication. with For that reason the INITIAL_CONTACT notifications MUST NOT be used to delete any other IKE SAs without verification. And, yes, the term verification is big vague here, and it is on purpose. I.e. verification can mean different things in different cases, but in minimal case it would mean the dead peer check. The rest of the section is ok. On the other hand if someone creates second IKE SA and because it is not only SA does not send INITIAL_CONTACT notification, it would be quite useless to start dead peer detection for the IKE SA sharing same IP-address, because the new IKE SA created did already tell that this is not the only IKE SA... -- The section 2.4 is good addition to the draft, and it does clarify things. One problem I have is that in the description there is only one entry for the NULL authentication, and all NULL authentications use the same entry. This is fine for cases where we want to do firewall type rules and restrictions for connections. This is not good when we use PAD to select the service where you want to connect. I.e. it would be possible to provide remote ID of server1.example.com when you want to connect to the server1.example.com and remote ID of server2.example.com when you want to connect server2.example.com. Depending which ID you provide different SPD entries are selected. If both of those are allowed for NULL authentication we still need a way to select which of the SPD entries are allowed. Also now the processing rules of RFC4301 is overwritten when NULL authentication is used. I think this is wrong. I think better would be to consider NULL authentication as one type of authentication in PAD. Another issue is that I think we should also add ID_NULL as one identity type which PAD can match against. I.e. add ID_NULL to the list in 4.4.3.1 in the RFC4301. So ID_NULL can only be used if PAD entry specifies it to be allowed, and it cannot be used in any other entry if they do not allow it. PAD already specifies which authentication methods are allowed for which connection, and what IDs can be used for it. I.e. if none of the PAD entries allows NULL authentication as authentication method and none of the PAD netries allows ID_NULL as identity type, then NULL authentication method and ID_NULL cannot be used. If you add new PAD entry (in suitable place in ordered PAD) which allows NULL authentication, then NULL authentication is allowed. If you limit that entry to only allow ID_NULL then only ID_NULL can be used with NULL authentication. If you say that any ID can be used with NULL authentication then clients ID is used to select one of the multiple PAD entries allowing NULL authentication and the SPD will be selected based on that. The draft has text: When using NULL Authentication, the peer identity is not authenticated and cannot be used. If ID_NULL is used with NULL Authentication, there is no ID at all. The processing of PAD described in Section 4.4.3.4 of [RFC4301] must be updated. The first sentence is incorrect. You can use it, you just cannot trust it. It can be used to select one of the untrusted PAD/SPD entries to for example select which service the client wants to connect. All of the identities will have same trust level, i.e. none, but they can still be used to select things. I would change the first sentence to say: When using NULL Authentication, the peer identity is not authenticated and cannot be trusted. The following text explaining the special search to be done with NULL authentication is dangeours, specially when you say that it is only SHOULD to check regular PAD first before going to that special rule. I would rewrite that to say that NULL authentication is just one authentication method, and ID_NULL is just one more identity type that can be used in PAD to match the rules. In normal case the NULL authentication would be configured so that it is one of the last PAD entries which is checked only after all other PAD entries are checked, and it would then allow unauthenticated connections too. But in some situations the PAD might also be configured differently, and there might be multiple PAD entries for NULL authentication, and different SPD entries depending on the ID payloads etc. One thing we need to make sure is that IDs from unauthenticated connections cannot be mixed with IDs from authenticated connections when matching SPD. I.e when using SPD Name parameter, those two IDs needs to be separated. This can be done in multiple ways depending on the implementation. In some implementations the pointers from PAD to SPD do not actually use that kind of names, but PAD has direct pointer to specific SPD entry to be used with that PAD entry. This works fine with NULL authentication (and ID NULL). In other cases the PAD entry has some kind of star-entry, and in that case the SPD is looked for matched entry based on the ID. In this case we need to separate those two SPD entries, one with authenticated IDs and another with unauthenticated IDs. In your text with PAD you ignore this second check completely. So for PAD checking we do not need to any special rules (execpt than adding NULL authentication and ID NULL to allowed list of authentication types and ID types), but for SPD checking we do need to do special rules. So this section needs to be expanded to cover the SPD matching, and I think the last two paragraphs needs to be replaced with just: The PAD described in the Section 4.4.3 of the IPsec Architecture document [RFC4301] is ordered database consisting information like: allowed authentication methods, and constraints for the IDs that can be asserted. To add support for the NULL authentication, the NULL authentication just needs to be supported as one authentication method, and to add support for ID_NULL, it needs to be added to the list of ID types supported by PAD. When using ID_NULL the matching rule for it is just whether ID_NULL type was used, i.e. no actual ID mathing is done. to cover PAD case, and then add text for SPD separtely. For the SPD we need to make sure that authenticated and NULL authentication SPD entries are not mixed. I.e. if I have PAD rule saying that ID kivinen@iki.fi can use share-secret authentication and then SPD rule of kivinen@iki.fi is used, and that SPD rule says that ID kivinen@iki.fi can create SA between ip-assigned by server <-> 192.168.0.0/16 tunnel mode. And then I have (lower priority) PAD rule saying any ID can use NULL authentication, then when we are searching for the suitable SPD rule for that PAD entry and the remote peer sent ID kivinen@iki.fi, we must not select the SPD rule meant for authenticated user of kivinen@iki.fi. Instead we can have lower priority SPD rule saying any ID (even unauthenticated ones) can create transport mode SA (or tunnel mode SA covering only those endpoint addresses) between the IP-address given by the server to using PFP (populate from packet) rule matching exactly one IP address. This matching is done by in the section 4.4.1.1 Selectors of the RFC4301 when using 1st format of "Name" selector. Instead of matching named SPD entry directly, we also check that the SPD MUST have flag enabled allowing unauthenticated uses too before "Name" selector can be matched for that SPD entry. In our example above the first kivinen@iki.fi entry would be skipped in unauthenticated case, as it that SPD entry is not allowed for the unauthenticated cases, and later wildcard entry would be used instead. This also allows us to have multiple SPD entries for the unauthenticated traffic, i.e. we could have one saying ID *@iki.fi (unauthenticated) can create tunnel mode SA between the IP-address given to them and 192.168.5.0/8 network, and another one saying that ID *@acr.fi (unauthenticated) can create tunnel mode SA between the IP-address given to them and 192.168.8.0/8 network. I.e. this would allow the client to select whether it wants to talk to the iki.fi-network or acr.fi-network in the remote end, still doing that in unauthenticated and anonymous ways. This matching is described also section 4.4.3.3 Child SA Authorization Data of the RFC4301, so we need to add text covering this: In section 4.4.3.3 of the IPsec Architecture document [RFC4301] describes how the IKE ID is matched against the SPD entries. When using the NULL authentication method those matching rules MUST include matching of a flag in the SPD specifying whether unauthenticated users are allowed to use that SPD entry. I.e. each SPD entry needs to be augmented to have flag specifying whether it can be used with NULL authentication or not, and only those rules explictly having that flag turned on can be used with unauthenticated connections. -- kivinen@iki.fi From nobody Thu Feb 5 03:28:12 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B241A1BEA for ; Thu, 5 Feb 2015 03:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 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, J_CHICKENPOX_31=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_41=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YB0bcauuKzeA for ; Thu, 5 Feb 2015 03:28:09 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (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 763B31A1BC0 for ; Thu, 5 Feb 2015 03:28:03 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id z12so7030885wgg.3 for ; Thu, 05 Feb 2015 03:28:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iUNiGc+u//oqOVA3VSszBOfTV2jGta3RlRRyV6J5A5I=; b=ho3eZ2Idv66sunj+GzApytZOa0p3BdxANQ+Ac7EImz9gPAIpI5qyDXaMMQuNTZ4T35 ZTFCBhjH9uI8mXu82HVgoUt2HYn4laLntDccbodI5jJ/ZB1RGeSI/gOyAkYCiHxzy2HK jibiysFGQuFEodDIG8I8APo4y7+kxuFZMAawkAF5JcKBqglo0mtSRymqO+t5snKds0i5 BjY/zp6GoCz8Sp4jn8Jo+v1Jw3DpXcbNINuMSso55EoA15kWTtTnDMIftd/meJEHQYoE F9D75PG2mECQbUQxTL21BU80EH4JmSW6NT/cLIauCQqJ2PjXn8GxIf233GHunRr+UVYz NGrA== X-Received: by 10.180.9.171 with SMTP id a11mr56049788wib.60.1423135682298; Thu, 05 Feb 2015 03:28:02 -0800 (PST) Received: from [172.24.251.208] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id w16sm33454725wia.15.2015.02.05.03.28.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Feb 2015 03:28:01 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Thu, 5 Feb 2015 13:27:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> <54CE6429.2020800@gmail.com> To: "Scott Fluhrer (sfluhrer)" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: IPsecME WG , Valery Smyslov Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 11:28:10 -0000 > On Feb 1, 2015, at 8:38 PM, Scott Fluhrer (sfluhrer) = wrote: >=20 > If you want to tighten up the time between worse case and average case = time taken by the problem solver, might I suggest this: >=20 > - When the verifier is asked to generate a problem, it pick a nonce N, = and use it to compute m k-bit values S_1, S_2, ..., S_m (for example, = S_1 || S_2 || ... || S_m =3D AES_key(N), where the AES key is secret to = the verifier), and publish k, N, HASH(N, S_1), HASH(N, S_2), ..., = HASH(N, S_m) >=20 > - To solve the problem, the solver needs to produce the values S_1, = S_2, ..., S_m, and send back N, S_1, S_2, ..., S_m >=20 > - The verifier verifies that the value N was what was originally given = (for example, the nonce might include the solver's IP address and a = timestamp), and that the values S_1 || S_2 || ... || S_m =3D = AES_key(N||0), (or alternatively, that those values produces the hashes = it sent). >=20 > The solver can always solve the problem by computing 2**k hashes; with = moderate m, we can make it unlikely that it can be done with = significantly fewer hashes; I would suggest m=3D4. >=20 > Of course, the cost of doing this is a) larger messages, and b) larger = up-front cost generating the problem (which, IMHO, isn't too bad -- one = AES encryption, and m hash computations; however, you are free to = disagree). >=20 Hi, Scott. Thanks for the suggestion. Let me see if I understand it correctly: Responder has a fixed AES key (let=E2=80=99s call it K). Let=E2=80=99s assume that N is a COOKIE calculated as in RFC 5996.=20 The responder Calculates S1||S2||=E2=80=A6||Sm =3D AES(K, COOKIE). = COOKIE can be any length, but for simplicity let=E2=80=99s assume = 128-bit so that we don=E2=80=99t have to deal with IVs, ICs or any other = artifacts of modes of operation. Also, let=E2=80=99s set m=3D8 and all = Si as 16-bit. So the responder now calculates 8 hashes: for each i Hi =3D = SHA256(COOKIE || Si) or better yet, Hi =3D PRF(Si, COOKIE). The responder sends to the initiator: - The COOKIE - Hi for all i. - The number k, although that can be deduced from the number of His - An identifier for the PRF algorithm chosen. The initiator needs to find Si values such that Hi =3D PRF(Si, COOKIE). = The silly way to do this is to solve run through all 2^16 possible Si = values once for each Hi (8 times), but a better way would be to run once = through the possible Si-s and find all of them. There is a small chance = of making an error if two 16-bit values produce the same result when = using the PRF on the cookie. The initiator repeats the request along = with the nonce and Si for all i. The responder now needs to do the following: - Verify the COOKIE - Encrypt the COOKIE, resulting (hopefully) in the concatenation of the = Si values. With the numbers I used in the example, k=3D16 resulting in 2^16 PRF = calculations on the client. The puzzle can be made harder by increasing = k and breaking the encrypted COOKIE into larger chunks. Did I get this correctly? Thanks Yoav From nobody Thu Feb 5 04:12:17 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B956D1A8733 for ; Thu, 5 Feb 2015 04:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.323 X-Spam-Level: ** X-Spam-Status: No, score=2.323 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, TVD_FINGER_02=1.215] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WGH76mEK_0N for ; Thu, 5 Feb 2015 04:12:12 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (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 9B4B31A8722 for ; Thu, 5 Feb 2015 04:12:11 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id pv20so6831301lab.7 for ; Thu, 05 Feb 2015 04:12:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=PQEVpwt6mobHXxDgTbjmO2jN4Mr/WObvALmOgLghpyA=; b=EDRFazd1FpwRBBUF2B3CnAOgIPgglLMX177v1axPNZzWRZFi1Q9+QtiyfDpJ/0NtW2 pPqak+RUtFt0qgcheAhZaVe1xE5vsQgaN+lpT+xC8YFZ9gnUh7L9ls5S2vBrNdAsFi7f ztwo8As2k0HZkKwKCE4ZwJ9Oxzsy8/TBAgHkBcAYDBIL8Fs9hsWvO1cHIa/J/aLH3/MG kxzAW//Q7s9AplfKcl8K3vvzZGUy/AN23hGvxz8sl5Ujyv4ueGEsPKWUR6xhjEiAUq2I xtROAYGroP5kSgriDPrqrHe/JYPE7MQgaGPcL3i0VAWTl2o0Fuumef9Y1nTjStwK+VQS W1KA== X-Received: by 10.152.88.44 with SMTP id bd12mr3113703lab.86.1423138330116; Thu, 05 Feb 2015 04:12:10 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id f9sm926955laa.20.2015.02.05.04.12.09 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 05 Feb 2015 04:12:09 -0800 (PST) Message-ID: <27360BC1A79A4F06944915A6D399A18B@buildpc> From: "Valery Smyslov" To: "Yoav Nir" References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> <54CE6429.2020800@gmail.com> <45BEE118-9B68-4D7F-BB9B-16A617A0C5AE@gmail.com> <6B33D43D-71C8-4C0E-A280-1763573A8BEB@gmail.com> <93EDF2091CD742D3AAD4A10423A4CBC9@buildpc> Date: Thu, 5 Feb 2015 15:12:08 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 12:12:15 -0000 > > I think this data proves the idea that the difference between > > computation power of different clients is significant and > > no single puzzle difficulty level would be reasonable for all. > > I think we should proceed with the proposal that > > client is allowed to return less zero bits than requested. > > Its simpler and safer code to get a request from the initiator, mark it > as solved/not-solved, > and process if solved or discard if not. Then you dont have to do any > queueing beyond > what the UDP stack is doing anyway. The real queueing is not necessary. You may act exactly the same way, as you described - get a request, analyze it and either process, or issue a new request, or discard. The only difference is what does the word "analyze" mean. In suggested approach it means: - Check whether puzzle was ever tried to be solved. If not - mark the request with the lowest priority. - Check how many zero bits are returned, how much time did it take the client (the latter can be learned if the cookie was timestamped) and how many puzzles it has already been asked (also can be encoded in cookie). Mark the request with the priority, that is calculated as (zero bits) * (spent time) * (number of solved puzzles) - Take a decision whether to process request or not. The decision should take into account the server's load and the priority of the request, and it should be probabilistic, so that even low-priority requests have a chance to be served. - If low-priority request is not served than give new puzzle for that client. The more puzzles client solve the higher would be its request priority. > > And in this case we may go further. > > The server may even not indicate to the client > > how many zero bits it wants to get. The server > > could just give the puzzle to the client and > > the client would return the best solution that it can > > get for a reasonable (from client's point of view) time. > > Some clients would be able to get more zero bits, some less. > > Then the server would sort all the requests, as described > > in Tero's e-mail and serve them accordingly. > > > This would allow a sufficiently powerful botnet to flood the queues and > deny service to phones. It is always possible. If you require all the clients to solve puzzle with a single difficulty, then sufficiently powerful botnet would quickly rase the bar so high, that phone's just won't be able to solve the puzzle for reasonable time (and reasonable battery consumption). And the proposed solution tries to avoid this, giving them a chance. > Suppose it turns out that phones like to work for 0.5 seconds and usually > come up with > 15-, 16-, or 17- bit solutions, it should be easy for a botnet to work far > less time on each > puzzle and solve hundreds of puzzles at these bit lengths. That would > effectively block the phones > that take a whole half second to calculate just one such solution. Not really. As the decision on whether to serve request should be probabilistic, than any such request (including phone's) should have a chance to be processed. BTW - the formula for priority includes spent time, so if you get only 16 bits, but spent 0.5 secs for this, then you will get better chances than somebody, who solved these 16 bits for 5 ms. Valery. > Yoav From nobody Thu Feb 5 06:22:35 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927631A8A71 for ; Thu, 5 Feb 2015 06:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.791 X-Spam-Level: X-Spam-Status: No, score=-0.791 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, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POprH-MTL_eX for ; Thu, 5 Feb 2015 06:22:20 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (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 E7FE31A8838 for ; Thu, 5 Feb 2015 06:21:41 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id f15so7644888lbj.5 for ; Thu, 05 Feb 2015 06:21:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=kY65Mm4QkoFLivNkCxIjVxiCNuoMygRjfiWJsFI9Tj8=; b=JoU+YssB76XgvQh1Fc+hLG+tlGLqKenoEWniGkKKibaCmhr5whmvwbCFziWSbkNlA1 p/2SJqAPAdBddHng1qRAsK7+t5SnmbRoYoUBhsg7GJBjFgKYXJcPI3Lvv+w9j24gni/I 2Xt9peDb3BtjD2go9nba3E1Y/1u43BrDZRSSXHzkzX+OGQf/2VKCykPL1OchtOFSJgJV TNy+v1TpbgPD4EnGszMJAXXAwNDMrJowRSuRWuoQwzM+AHRHo2DagOXT8Bgs615CitOo h2/Ct1n8O+3/DTVNxgcsa7rW6OIHYiZpVwp7g+pT9WyyyDSRLpthh26lxgjWAmuFRZap jvMA== X-Received: by 10.112.118.144 with SMTP id km16mr3735764lbb.75.1423146100322; Thu, 05 Feb 2015 06:21:40 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id s6sm990490lae.13.2015.02.05.06.21.39 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 05 Feb 2015 06:21:39 -0800 (PST) Message-ID: <00A15492FD3948939F4A474664E606E9@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" , "IPsecME WG" References: <21715.18003.165707.402734@fireball.kivinen.iki.fi> Date: Thu, 5 Feb 2015 17:21:39 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 14:22:25 -0000 Hi Tero, thanks for your detailed review. > In section 2.3 I think the first MUST for INITIAL_CONTACT should be > rephrased so that it says that it MUST NOT do normal INITIAL_CONTACT > processing for unaithenticated INITIAL_CONTACT. I think using that > INITIAL_CONTACT as a hint to start dead peer detection is ok, but > current text says it MUST be ignored so you cannot even use it as > hint. > > I.e. replace: > > For that reason the INITIAL_CONTACT > notifications MUST be ignored for IKE SAs using NULL Authentication. > > with > > For that reason the INITIAL_CONTACT > notifications MUST NOT be used to delete any other IKE SAs without > verification. OK. > And, yes, the term verification is big vague here, and it is on > purpose. I.e. verification can mean different things in different > cases, but in minimal case it would mean the dead peer check. > > The rest of the section is ok. On the other hand if someone creates > second IKE SA and because it is not only SA does not send > INITIAL_CONTACT notification, it would be quite useless to start dead > peer detection for the IKE SA sharing same IP-address, because the new > IKE SA created did already tell that this is not the only IKE SA... Isn't it already presumed? Do you think we should mention this explicitely? How about: Additionally, the event of creating a new unauthenticated IKE SA containing INITIAL_CONTACT notification can be used to trigger an out-of-order check on existing unauthenticated IKE SAs, possibly limited to identical or close-by IP addresses or to identical identities of the just created IKE SA. (added wods "containing INITIAL_CONTACT notification "). > The section 2.4 is good addition to the draft, and it does clarify > things. > > One problem I have is that in the description there is only one entry > for the NULL authentication, and all NULL authentications use the same > entry. This is fine for cases where we want to do firewall type rules > and restrictions for connections. > > This is not good when we use PAD to select the service where you want > to connect. > > I.e. it would be possible to provide remote ID of server1.example.com > when you want to connect to the server1.example.com and remote ID of > server2.example.com when you want to connect server2.example.com. > Depending which ID you provide different SPD entries are selected. If > both of those are allowed for NULL authentication we still need a way > to select which of the SPD entries are allowed. > > Also now the processing rules of RFC4301 is overwritten when NULL > authentication is used. I think this is wrong. I think better would be > to consider NULL authentication as one type of authentication in PAD. > > Another issue is that I think we should also add ID_NULL as one > identity type which PAD can match against. I.e. add ID_NULL to the > list in 4.4.3.1 in the RFC4301. So ID_NULL can only be used if PAD > entry specifies it to be allowed, and it cannot be used in any other > entry if they do not allow it. > > PAD already specifies which authentication methods are allowed for > which connection, and what IDs can be used for it. I.e. if none of the > PAD entries allows NULL authentication as authentication method and > none of the PAD netries allows ID_NULL as identity type, then NULL > authentication method and ID_NULL cannot be used. > > If you add new PAD entry (in suitable place in ordered PAD) which > allows NULL authentication, then NULL authentication is allowed. If > you limit that entry to only allow ID_NULL then only ID_NULL can be > used with NULL authentication. If you say that any ID can be used with > NULL authentication then clients ID is used to select one of the > multiple PAD entries allowing NULL authentication and the SPD will be > selected based on that. Unfortunately with the current matching rules you cannot specify in PAD that the remote ID can be anything. For example, if ID Type is Key ID, then only exact match is allowed by RFC4301, so you cannot express that for this unauthenticated connection client's ID of type Key ID is irrelevant. > The draft has text: > > When using NULL Authentication, the peer identity is not > authenticated and cannot be used. If ID_NULL is used with NULL > Authentication, there is no ID at all. The processing of PAD > described in Section 4.4.3.4 of [RFC4301] must be updated. > > The first sentence is incorrect. You can use it, you just cannot trust > it. It can be used to select one of the untrusted PAD/SPD entries to > for example select which service the client wants to connect. All of > the identities will have same trust level, i.e. none, but they can > still be used to select things. > > I would change the first sentence to say: > > When using NULL Authentication, the peer identity is not > authenticated and cannot be trusted. OK. > The following text explaining the special search to be done with NULL > authentication is dangeours, specially when you say that it is only > SHOULD to check regular PAD first before going to that special rule. > > I would rewrite that to say that NULL authentication is just one > authentication method, and ID_NULL is just one more identity type that > can be used in PAD to match the rules. In normal case the NULL > authentication would be configured so that it is one of the last PAD > entries which is checked only after all other PAD entries are checked, > and it would then allow unauthenticated connections too. > > But in some situations the PAD might also be configured differently, > and there might be multiple PAD entries for NULL authentication, and > different SPD entries depending on the ID payloads etc. One thing we > need to make sure is that IDs from unauthenticated connections cannot > be mixed with IDs from authenticated connections when matching SPD. > > I.e when using SPD Name parameter, those two IDs needs to be > separated. This can be done in multiple ways depending on the > implementation. In some implementations the pointers from PAD to SPD > do not actually use that kind of names, but PAD has direct pointer to > specific SPD entry to be used with that PAD entry. This works fine > with NULL authentication (and ID NULL). > > In other cases the PAD entry has some kind of star-entry, and in that > case the SPD is looked for matched entry based on the ID. In this case > we need to separate those two SPD entries, one with authenticated IDs > and another with unauthenticated IDs. In your text with PAD you ignore > this second check completely. > > So for PAD checking we do not need to any special rules (execpt than > adding NULL authentication and ID NULL to allowed list of > authentication types and ID types), but for SPD checking we do need > to do special rules. > > So this section needs to be expanded to cover the SPD matching, and I > think the last two paragraphs needs to be replaced with just: > > The PAD described in the Section 4.4.3 of the IPsec Architecture > document [RFC4301] is ordered database consisting information like: > allowed authentication methods, and constraints for the IDs that can > be asserted. To add support for the NULL authentication, the NULL > authentication just needs to be supported as one authentication > method, and to add support for ID_NULL, it needs to be added to the > list of ID types supported by PAD. When using ID_NULL the matching > rule for it is just whether ID_NULL type was used, i.e. no actual ID > mathing is done. > > to cover PAD case, and then add text for SPD separtely. > > For the SPD we need to make sure that authenticated and NULL > authentication SPD entries are not mixed. I.e. if I have PAD rule > saying that ID kivinen@iki.fi can use share-secret authentication and > then SPD rule of kivinen@iki.fi is used, and that SPD rule says that > ID kivinen@iki.fi can create SA between ip-assigned by server <-> > 192.168.0.0/16 tunnel mode. And then I have (lower priority) PAD rule > saying any ID can use NULL authentication, then when we are searching > for the suitable SPD rule for that PAD entry and the remote peer sent > ID kivinen@iki.fi, we must not select the SPD rule meant for > authenticated user of kivinen@iki.fi. > > Instead we can have lower priority SPD rule saying any ID (even > unauthenticated ones) can create transport mode SA (or tunnel mode SA > covering only those endpoint addresses) between the IP-address given > by the server to using PFP (populate from packet) rule matching > exactly one IP address. > > This matching is done by in the section 4.4.1.1 Selectors of the > RFC4301 when using 1st format of "Name" selector. Instead of matching > named SPD entry directly, we also check that the SPD MUST have flag > enabled allowing unauthenticated uses too before "Name" selector can > be matched for that SPD entry. In our example above the first > kivinen@iki.fi entry would be skipped in unauthenticated case, as it > that SPD entry is not allowed for the unauthenticated cases, and later > wildcard entry would be used instead. > > This also allows us to have multiple SPD entries for the > unauthenticated traffic, i.e. we could have one saying ID *@iki.fi > (unauthenticated) can create tunnel mode SA between the IP-address > given to them and 192.168.5.0/8 network, and another one saying that > ID *@acr.fi (unauthenticated) can create tunnel mode SA between the > IP-address given to them and 192.168.8.0/8 network. I.e. this would > allow the client to select whether it wants to talk to the > iki.fi-network or acr.fi-network in the remote end, still doing that > in unauthenticated and anonymous ways. > > This matching is described also section 4.4.3.3 Child SA Authorization > Data of the RFC4301, so we need to add text covering this: > > In section 4.4.3.3 of the IPsec Architecture document [RFC4301] > describes how the IKE ID is matched against the SPD entries. When > using the NULL authentication method those matching rules MUST > include matching of a flag in the SPD specifying whether > unauthenticated users are allowed to use that SPD entry. I.e. each > SPD entry needs to be augmented to have flag specifying whether it > can be used with NULL authentication or not, and only those rules > explictly having that flag turned on can be used with > unauthenticated connections. Is the following text for the entire section 2.4 OK for you? (I've borrowed some of your text): 2.4. Interaction with Peer Authorization Database (PAD) Section 4.4.3 of [RFC4301] defines the Peer Authorization Database (PAD), which provides the link between Security Policy Database (SPD) and the IKEv2. The PAD contains an ordered list of records, with peers' identities along with corresponding authentication data and Child SA authorization data. When the IKE SA is being established the PAD is consulted to determine how the peer should be authenticated and what Child SAs it is authorized to create. When using NULL Authentication, the peer identity is not authenticated and cannot be trusted. If ID_NULL is used with NULL Authentication, there is no ID at all. The processing of PAD described in Section 4.4.3.4 of [RFC4301] must be updated. The NULL authentication needs to be added as one of supported authentication methods. This method MUST contain no authentication data. To add support for ID_NULL, it needs to be included into the list of ID types, specified in Section 4.4.3.1 of [RFC4301]. The matching rule for ID_NULL is just whether this type is used, i.e. no actual ID matching is done, as ID_NULL contains no identity data. Section 4.4.3.3 of the [RFC4301] describes how the IKE ID is matched against the SPD entries. When using the NULL authentication method those matching rules MUST include matching of a flag in the SPD entry specifying whether unauthenticated users are allowed to use that entry. I.e. each SPD entry needs to be augmented to have flag specifying whether it can be used with NULL authentication or not, and only those rules explictly having that flag turned on can be used with unauthenticated connections. Regards, Valery. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Thu Feb 5 06:54:29 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0881A88D3 for ; Thu, 5 Feb 2015 06:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elGVuS9DhON2 for ; Thu, 5 Feb 2015 06:54:16 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C161A88D7 for ; Thu, 5 Feb 2015 06:54:09 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t15Es5NX008259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Feb 2015 16:54:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t15Es5Fx017438; Thu, 5 Feb 2015 16:54:05 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21715.33804.848983.295427@fireball.kivinen.iki.fi> Date: Thu, 5 Feb 2015 16:54:04 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <00A15492FD3948939F4A474664E606E9@buildpc> References: <21715.18003.165707.402734@fireball.kivinen.iki.fi> <00A15492FD3948939F4A474664E606E9@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 6 min Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 14:54:23 -0000 Valery Smyslov writes: > > The rest of the section is ok. On the other hand if someone creates > > second IKE SA and because it is not only SA does not send > > INITIAL_CONTACT notification, it would be quite useless to start dead > > peer detection for the IKE SA sharing same IP-address, because the new > > IKE SA created did already tell that this is not the only IKE SA... > > Isn't it already presumed? Do you think we should mention this > explicitely? No, when you did say that the INITIAL_CONTACT is always ignored :-) If you ignore it you cannot use that information whether it was there not... Thats why I complained about MUST be ignored. > How about: > > Additionally, the event of creating a new unauthenticated IKE SA > containing INITIAL_CONTACT notification can be used to trigger > an out-of-order check on existing unauthenticated IKE SAs, > possibly limited to identical or close-by IP addresses or to identical > identities > of the just created IKE SA. > > (added wods "containing INITIAL_CONTACT notification "). Looks good. > Unfortunately with the current matching rules > you cannot specify in PAD that the remote ID can be anything. Why not? The RFC4301 talks about IKE ID, it does not anywhere specify that you must only use the remote ID when matching PAD. If you support IKEv2 You Tarzan, me Jane feature, you need to do that anyways. Again this is implementation dependant, and you can implement this in multiple ways. One way to implement is to have completely separate SPDs for each local identities, and that would be useful if you want to support virtual routers or similars. In some cases you might simply have some rules giving both local and remote identities, and match both, or some rules having only one. > For example, if ID Type is Key ID, then only exact > match is allowed by RFC4301, so you cannot express that > for this unauthenticated connection client's ID of type > Key ID is irrelevant. Sure you can. The RFC4301 sets the minimum bar for the matching rules. If your implementation wants it can take the Key ID, divide it to factors, and select the SPD entry based on the largist factor the number has :-) And it would still be according to the RFC4301 if you ALSO support exact match. In the RFC4301 it does say: The Key ID field is defined as an OCTET string in IKE. For this name type, only exact-match syntax MUST be supported (since there is no explicit structure for this ID type). Additional matching functions MAY be supported for this ID type. I.e. additional matching functions MAY be supported... Bah, running late again, I will come back to final version 2.4 section tomorrow... -- kivinen@iki.fi From nobody Thu Feb 5 08:12:51 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6201A89A9 for ; Thu, 5 Feb 2015 08:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DWxMlEHSMCX for ; Thu, 5 Feb 2015 08:12:45 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6C3C1A88E3 for ; Thu, 5 Feb 2015 08:12:44 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kdPtJ4bJkz9HH; Thu, 5 Feb 2015 17:12:40 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=UaKec8fS; dkim-adsp=pass X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id T7vpOdrHSmCO; Thu, 5 Feb 2015 17:12:39 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 5 Feb 2015 17:12:39 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 592598324E; Thu, 5 Feb 2015 11:12:38 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1423152758; bh=5dNz6RLsDk0tsq990CVUhqVqpMvO/mWjpVLv+DAoEfk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=UaKec8fSJ1OhiKbkQTKa29New93Y56nd31SE0mczyJK2hmPto1LjleIC+JF/T3XKo BFUzTFWOVScDjUy3BAwQEuJP3TzUqgIAprIkVy3cdN1uFF1NIe5oaFx4eyZdY+Wo+R jmlln7DnrRRSkGRhWj6qSuQThiUv53fqSnsKeXpg= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t15GCbOt001283; Thu, 5 Feb 2015 11:12:37 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 5 Feb 2015 11:12:37 -0500 (EST) From: Paul Wouters To: Tero Kivinen In-Reply-To: <21715.18003.165707.402734@fireball.kivinen.iki.fi> Message-ID: References: <21715.18003.165707.402734@fireball.kivinen.iki.fi> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 16:12:47 -0000 On Thu, 5 Feb 2015, Tero Kivinen wrote: > I.e. replace: > > For that reason the INITIAL_CONTACT > notifications MUST be ignored for IKE SAs using NULL Authentication. > > with > > For that reason the INITIAL_CONTACT > notifications MUST NOT be used to delete any other IKE SAs without > verification. > > And, yes, the term verification is big vague here, and it is on > purpose. I.e. verification can mean different things in different > cases, but in minimal case it would mean the dead peer check. I'm okay with that. > One problem I have is that in the description there is only one entry > for the NULL authentication, and all NULL authentications use the same > entry. This is fine for cases where we want to do firewall type rules > and restrictions for connections. > > This is not good when we use PAD to select the service where you want > to connect. Yes, I had the exact same issue with that part on my TODO list. There can be different "security groups" that all allow AUTH_NULL/ID_NULL. > Also now the processing rules of RFC4301 is overwritten when NULL > authentication is used. I think this is wrong. I think better would be > to consider NULL authentication as one type of authentication in PAD. Exactly! > Another issue is that I think we should also add ID_NULL as one > identity type which PAD can match against. I.e. add ID_NULL to the > list in 4.4.3.1 in the RFC4301. So ID_NULL can only be used if PAD > entry specifies it to be allowed, and it cannot be used in any other > entry if they do not allow it. Yup. > I would change the first sentence to say: > > When using NULL Authentication, the peer identity is not > authenticated and cannot be trusted. Sounds good to me. > I would rewrite that to say that NULL authentication is just one > authentication method, and ID_NULL is just one more identity type that > can be used in PAD to match the rules. Yes. > So this section needs to be expanded to cover the SPD matching, and I > think the last two paragraphs needs to be replaced with just: > > The PAD described in the Section 4.4.3 of the IPsec Architecture > document [RFC4301] is ordered database consisting information like: > allowed authentication methods, and constraints for the IDs that can > be asserted. To add support for the NULL authentication, the NULL > authentication just needs to be supported as one authentication > method, and to add support for ID_NULL, it needs to be added to the > list of ID types supported by PAD. When using ID_NULL the matching > rule for it is just whether ID_NULL type was used, i.e. no actual ID > mathing is done. Okay with some minor changes (like not using the word "just" :) I saw Valery had some feedback too, so will coordinate with him. Paul From nobody Thu Feb 5 22:30:59 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BB41A1A00 for ; Thu, 5 Feb 2015 22:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.908 X-Spam-Level: ** X-Spam-Status: No, score=2.908 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Y7ENSMIfEos for ; Thu, 5 Feb 2015 22:30:52 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (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 A1AB01A0371 for ; Thu, 5 Feb 2015 22:30:51 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id l4so15464814lbv.3 for ; Thu, 05 Feb 2015 22:30:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=xPuhmqZzk1bzLgZEqnvNjQMTwhwqqyDpF2FkNKIS/H0=; b=dwk+pZdkFZgHWPsikcR33I2dMXItkTue/Gb9r8AsTnC5XzOu2ld/bFUcYKqvCk1C9d 2jbi4+o6ERQdCjNiHeNLUanbLCG28DqUUEhiwQ+aW6UP1INjZoC6MSD00NP5TRcTftWc Gz6+QIr/7S0D4PaCzI2IopmvfvejK6LxH3H7HAf1n4IjmAGu/kzwaBPMs5NDln8yt6H+ WHYqa+2YgOLwzBcKlsBPVNRLnD29Qg5sjATAOxKaF04cnOk7zIE4lLVLM0q0RK1O+AwZ lAdWhJ5h2f8CTvVi7GQT1jH1tLOI2CqIdC0GBbx/xMgwyL59R5tnTnlfegHz2+QytVMa Qluw== X-Received: by 10.152.243.44 with SMTP id wv12mr1302582lac.78.1423204250151; Thu, 05 Feb 2015 22:30:50 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id oa1sm244524lbc.24.2015.02.05.22.30.49 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 05 Feb 2015 22:30:49 -0800 (PST) Message-ID: <99696496A6304DE588B99DD6B5E75B1C@buildpc> From: "Valery Smyslov" To: "Yoav Nir" , "Scott Fluhrer \(sfluhrer\)" References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> <54CE6429.2020800@gmail.com> Date: Fri, 6 Feb 2015 09:30:48 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 06:30:54 -0000 I can see two drawbacks with this approach. First, to make it aligned with algorithm agility, we need to negotiate not only PRF, but also the encryption algorithm. And the selection criteria would become more complex. And second - it significantly increases the size of IKE_SA_INIT response message, as the puzzle must include m hashes. With SHA256 and m = 8 it is additional 256 bytes. With SHA512 and m = 16 it is additional 1024 bytes. That is not good as it increases the chance for IP fragmentation. Regards, Valery. > > On Feb 1, 2015, at 8:38 PM, Scott Fluhrer (sfluhrer) > > wrote: > > > > If you want to tighten up the time between worse case and average case > > time taken by the problem solver, might I suggest this: > > > > - When the verifier is asked to generate a problem, it pick a nonce N, > > and use it to compute m k-bit values > S_1, S_2, ..., S_m (for example, S_1 || S_2 || ... || S_m = AES_key(N), > where the AES key is secret to the verifier), > and publish k, N, HASH(N, S_1), HASH(N, S_2), ..., HASH(N, S_m) > > > > - To solve the problem, the solver needs to produce the values S_1, S_2, > > ..., S_m, and send back N, S_1, S_2, ..., S_m > > > > - The verifier verifies that the value N was what was originally given > > (for example, the nonce might include the solver's > IP address and a timestamp), and that the values S_1 || S_2 || ... || S_m > = AES_key(N||0), (or alternatively, > that those values produces the hashes it sent). > > > > The solver can always solve the problem by computing 2**k hashes; with > > moderate m, we can make it unlikely > that it can be done with significantly fewer hashes; I would suggest m=4. > > > > Of course, the cost of doing this is a) larger messages, and b) larger > > up-front cost generating the problem > (which, IMHO, isn't too bad -- one AES encryption, and m hash > computations; however, you are free to disagree). > > > > Hi, Scott. > > Thanks for the suggestion. Let me see if I understand it correctly: > > Responder has a fixed AES key (let’s call it K). > > Let’s assume that N is a COOKIE calculated as in RFC 5996. > > The responder Calculates S1||S2||…||Sm = AES(K, COOKIE). COOKIE can be any > length, > but for simplicity let’s assume 128-bit so that we don’t have to deal with > IVs, ICs or any other artifacts > of modes of operation. Also, let’s set m=8 and all Si as 16-bit. > So the responder now calculates 8 hashes: for each i Hi = SHA256(COOKIE || > Si) or better yet, Hi = PRF(Si, COOKIE). > > The responder sends to the initiator: > - The COOKIE > - Hi for all i. > - The number k, although that can be deduced from the number of His > - An identifier for the PRF algorithm chosen. > > The initiator needs to find Si values such that Hi = PRF(Si, COOKIE). The > silly way to do this is to solve run > through all 2^16 possible Si values once for each Hi (8 times), but a > better way would be to run once through > the possible Si-s and find all of them. There is a small chance of making > an error if two 16-bit values produce > the same result when using the PRF on the cookie. The initiator repeats > the request along with the nonce and Si for all i. > > The responder now needs to do the following: > - Verify the COOKIE > - Encrypt the COOKIE, resulting (hopefully) in the concatenation of the > Si values. > > With the numbers I used in the example, k=16 resulting in 2^16 PRF > calculations on the client. > The puzzle can be made harder by increasing k and breaking the encrypted > COOKIE into larger chunks. > > Did I get this correctly? > > Thanks > > Yoav From nobody Thu Feb 5 23:49:32 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148031A0362 for ; Thu, 5 Feb 2015 23:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 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, J_CHICKENPOX_31=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_41=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9p5SD9Lpc-ff for ; Thu, 5 Feb 2015 23:49:29 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (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 ECD981A0066 for ; Thu, 5 Feb 2015 23:49:28 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id u56so6524138wes.10 for ; Thu, 05 Feb 2015 23:49:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WzvVKSL3btSgSEPjmkfBXfO8MbJ/blYYETmY+Vzdhq8=; b=w6b3q69Xito0rw3X0TdCOwsk5EbzGZPVDBqx54DbpJAIYE8bdXrtlhcaaQOEs5851O pyo8ghpz2CcM/qbIQ/fAPdeGGbpmLVWSVAnAMQAUcLRLvY1uTGWqv1qcYlfv3KN5YLuA hlOBW9fIymIvDrKl7SPWSOKFev22wmYlcrxPJI5cEHZsDI8+jmceWctAeCzKcB7YzQL6 j7nF9t3GD+6Mce+kxuNaEL3+UbHgp9HZsz1gqWLD+/ciE5Jroa9yXnOUpneRSoZ3YwWr tgyU0iFnaa/gEuPagp75k+ppp01fH0XF7/jmcUrKeAENKKotIKbGw9oHOn4McxfiIxkH f+bQ== X-Received: by 10.194.192.167 with SMTP id hh7mr4715612wjc.151.1423208967698; Thu, 05 Feb 2015 23:49:27 -0800 (PST) Received: from [192.168.1.15] ([46.120.13.132]) by mx.google.com with ESMTPSA id ej10sm430839wib.1.2015.02.05.23.49.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Feb 2015 23:49:26 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=utf-8 From: Yoav Nir X-Priority: 3 In-Reply-To: <99696496A6304DE588B99DD6B5E75B1C@buildpc> Date: Fri, 6 Feb 2015 09:49:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0B9A7EB1-2B48-4778-AE82-3B1FBC2103D8@gmail.com> References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> <54CE6429.2020800@gmail.com> <99696496A6304DE588B99DD6B5E75B1C@buildpc> To: Valery Smyslov X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: IPsecME WG , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 07:49:31 -0000 Thinking it over, you don=E2=80=99t really need AES at all, and in any = case it doesn=E2=80=99t matter. The initiator doesn=E2=80=99t know the = key and doesn=E2=80=99t know the algorithm, so it=E2=80=99s entirely a = local matter. For example, the responder could pick HMAC-SHA256 with a fixed key, and = calculate HMAC-SHA256(K,cookie). And it=E2=80=99s not even necessary = for the initiator to solve all of the response. We can limit it to 8 = Si-s (m=3D8), each 16 bits (k=3D16) even though the output of = HMAC-SHA256 is 256 bits. m only serves to force the initiator to go = through most of the 2^k possibilities. Yoav > On Feb 6, 2015, at 8:30 AM, Valery Smyslov wrote: >=20 > I can see two drawbacks with this approach. >=20 > First, to make it aligned with algorithm agility, we need to > negotiate not only PRF, but also the encryption algorithm. > And the selection criteria would become more complex. >=20 > And second - it significantly increases the size of IKE_SA_INIT > response message, as the puzzle must include m hashes. > With SHA256 and m =3D 8 it is additional 256 bytes. > With SHA512 and m =3D 16 it is additional 1024 bytes. > That is not good as it increases the chance for IP fragmentation. >=20 > Regards, > Valery. >=20 >> > On Feb 1, 2015, at 8:38 PM, Scott Fluhrer (sfluhrer) > = wrote: >> > >> > If you want to tighten up the time between worse case and average = case > time taken by the problem solver, might I suggest this: >> > >> > - When the verifier is asked to generate a problem, it pick a nonce = N, > and use it to compute m k-bit values >> S_1, S_2, ..., S_m (for example, S_1 || S_2 || ... || S_m =3D = AES_key(N), where the AES key is secret to the verifier), >> and publish k, N, HASH(N, S_1), HASH(N, S_2), ..., HASH(N, S_m) >> > >> > - To solve the problem, the solver needs to produce the values S_1, = S_2, > ..., S_m, and send back N, S_1, S_2, ..., S_m >> > >> > - The verifier verifies that the value N was what was originally = given > (for example, the nonce might include the solver's >> IP address and a timestamp), and that the values S_1 || S_2 || ... = || S_m =3D AES_key(N||0), (or alternatively, >> that those values produces the hashes it sent). >> > >> > The solver can always solve the problem by computing 2**k hashes; = with > moderate m, we can make it unlikely >> that it can be done with significantly fewer hashes; I would suggest = m=3D4. >> > >> > Of course, the cost of doing this is a) larger messages, and b) = larger > up-front cost generating the problem >> (which, IMHO, isn't too bad -- one AES encryption, and m hash = computations; however, you are free to disagree). >> > >>=20 >> Hi, Scott. >>=20 >> Thanks for the suggestion. Let me see if I understand it correctly: >>=20 >> Responder has a fixed AES key (let=E2=80=99s call it K). >>=20 >> Let=E2=80=99s assume that N is a COOKIE calculated as in RFC 5996. >>=20 >> The responder Calculates S1||S2||=E2=80=A6||Sm =3D AES(K, COOKIE). = COOKIE can be any length, >> but for simplicity let=E2=80=99s assume 128-bit so that we don=E2=80=99= t have to deal with IVs, ICs or any other artifacts >> of modes of operation. Also, let=E2=80=99s set m=3D8 and all Si as = 16-bit. >> So the responder now calculates 8 hashes: for each i Hi =3D = SHA256(COOKIE || Si) or better yet, Hi =3D PRF(Si, COOKIE). >>=20 >> The responder sends to the initiator: >> - The COOKIE >> - Hi for all i. >> - The number k, although that can be deduced from the number of His >> - An identifier for the PRF algorithm chosen. >>=20 >> The initiator needs to find Si values such that Hi =3D PRF(Si, = COOKIE). The silly way to do this is to solve run >> through all 2^16 possible Si values once for each Hi (8 times), but a = better way would be to run once through >> the possible Si-s and find all of them. There is a small chance of = making an error if two 16-bit values produce >> the same result when using the PRF on the cookie. The initiator = repeats the request along with the nonce and Si for all i. >>=20 >> The responder now needs to do the following: >> - Verify the COOKIE >> - Encrypt the COOKIE, resulting (hopefully) in the concatenation of = the Si values. >>=20 >> With the numbers I used in the example, k=3D16 resulting in 2^16 PRF = calculations on the client. >> The puzzle can be made harder by increasing k and breaking the = encrypted COOKIE into larger chunks. >>=20 >> Did I get this correctly? >>=20 >> Thanks >>=20 >> Yoav >=20 >=20 From nobody Fri Feb 6 00:22:40 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D071A017C for ; Fri, 6 Feb 2015 00:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.009 X-Spam-Level: * X-Spam-Status: No, score=1.009 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, J_CHICKENPOX_31=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsvIBcCV5T93 for ; Fri, 6 Feb 2015 00:22:34 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (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 5BA881A1A5F for ; Fri, 6 Feb 2015 00:22:33 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id n10so11960593lbv.6 for ; Fri, 06 Feb 2015 00:22:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=VgBg36Et4HXCPkfNCWsKLT3+rzHlO5fQkredxaHYFtw=; b=oqhX24j5IwRmqrUFYx9qyuBekxMPEJMuesmYgCGlTe0kVRk018ipJQnAo+UI1HOIxF wp9nuqJ/Yihh5CvQbrllkONfQwLBMbUgxgbV5himD+JFFnGS72J/w5nqjKQDNEUk+WMz frRepbccuYdPEEahqyhTRUfFJPETDjWUG7C6zh66TAmpw2Y1PA+wqgK9eJlS8Aem1TkX 5761Ye2J5sjBXmoVzDrJxBBCmtcmv7JQIvARDPILiuyKQJdYgJyAA/o5gf21H37nf0PJ O75FDUrYqY3GYiFWRN5uRF0jch10MNF6T3OZrB7k9Q5ir1qGwPsBCx+uOyffxIOqeymC tpOQ== X-Received: by 10.112.236.36 with SMTP id ur4mr1515753lbc.67.1423210951809; Fri, 06 Feb 2015 00:22:31 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id g5sm291982lag.11.2015.02.06.00.22.30 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 06 Feb 2015 00:22:31 -0800 (PST) Message-ID: <426C21C2944648EA9D0EEA0B07BBADD6@buildpc> From: "Valery Smyslov" To: "Yoav Nir" References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> <54CE6429.2020800@gmail.com> <99696496A6304DE588B99DD6B5E75B1C@buildpc> <0B9A7EB1-2B48-4778-AE82-3B1FBC2103D8@gmail.com> Date: Fri, 6 Feb 2015 11:22:29 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 08:22:35 -0000 > Thinking it over, you don’t really need AES at all, and in any case it > doesn’t matter. > The initiator doesn’t know the key and doesn’t know the algorithm, so it’s > entirely a local matter. You are right, it's a local matter. > For example, the responder could pick HMAC-SHA256 with a fixed key, and > calculate HMAC-SHA256(K,cookie). > And it’s not even necessary for the initiator to solve all of the > response. We can limit it to 8 Si-s (m=8), each 16 bits > (k=16) even though the output of HMAC-SHA256 is 256 bits. m only serves to > force the initiator to go through > most of the 2^k possibilities. And another drawback of this approach is that the responder must do quite a lot of work to prepare puzzle. It must first calculate S1||S2||…||Sm and then for each Si calculate Hi. That is not an enormous work, but comparing with the current "zero bits" proposal, where the puzzle goes for free, it is non insignificant (especially as we're trying to protect responder against DoS attack). And again, my main concern is whether we are solving the right problem. This approah makes time requiring to solve random puzzle more consistent. But it doesn't help weak clients, unless we allow them to return as many Si-s, as they can. But in this case I see no significant advantages of this approach, but I can see its complexity, increased message size and increased load on responder. Valery. > Yoav > On Feb 6, 2015, at 8:30 AM, Valery Smyslov wrote: > > I can see two drawbacks with this approach. > > First, to make it aligned with algorithm agility, we need to > negotiate not only PRF, but also the encryption algorithm. > And the selection criteria would become more complex. > > And second - it significantly increases the size of IKE_SA_INIT > response message, as the puzzle must include m hashes. > With SHA256 and m = 8 it is additional 256 bytes. > With SHA512 and m = 16 it is additional 1024 bytes. > That is not good as it increases the chance for IP fragmentation. > > Regards, > Valery. > >> > On Feb 1, 2015, at 8:38 PM, Scott Fluhrer (sfluhrer) > >> > wrote: >> > >> > If you want to tighten up the time between worse case and average case >> > > time taken by the problem solver, might I suggest this: >> > >> > - When the verifier is asked to generate a problem, it pick a nonce N, >> > > and use it to compute m k-bit values >> S_1, S_2, ..., S_m (for example, S_1 || S_2 || ... || S_m = AES_key(N), >> where the AES key is secret to the verifier), >> and publish k, N, HASH(N, S_1), HASH(N, S_2), ..., HASH(N, S_m) >> > >> > - To solve the problem, the solver needs to produce the values S_1, >> > S_2, > ..., S_m, and send back N, S_1, S_2, ..., S_m >> > >> > - The verifier verifies that the value N was what was originally given >> > > (for example, the nonce might include the solver's >> IP address and a timestamp), and that the values S_1 || S_2 || ... || >> S_m = AES_key(N||0), (or alternatively, >> that those values produces the hashes it sent). >> > >> > The solver can always solve the problem by computing 2**k hashes; with >> > > moderate m, we can make it unlikely >> that it can be done with significantly fewer hashes; I would suggest m=4. >> > >> > Of course, the cost of doing this is a) larger messages, and b) larger >> > > up-front cost generating the problem >> (which, IMHO, isn't too bad -- one AES encryption, and m hash >> computations; however, you are free to disagree). >> > >> >> Hi, Scott. >> >> Thanks for the suggestion. Let me see if I understand it correctly: >> >> Responder has a fixed AES key (let’s call it K). >> >> Let’s assume that N is a COOKIE calculated as in RFC 5996. >> >> The responder Calculates S1||S2||…||Sm = AES(K, COOKIE). COOKIE can be >> any length, >> but for simplicity let’s assume 128-bit so that we don’t have to deal >> with IVs, ICs or any other artifacts >> of modes of operation. Also, let’s set m=8 and all Si as 16-bit. >> So the responder now calculates 8 hashes: for each i Hi = SHA256(COOKIE >> || Si) or better yet, Hi = PRF(Si, COOKIE). >> >> The responder sends to the initiator: >> - The COOKIE >> - Hi for all i. >> - The number k, although that can be deduced from the number of His >> - An identifier for the PRF algorithm chosen. >> >> The initiator needs to find Si values such that Hi = PRF(Si, COOKIE). The >> silly way to do this is to solve run >> through all 2^16 possible Si values once for each Hi (8 times), but a >> better way would be to run once through >> the possible Si-s and find all of them. There is a small chance of making >> an error if two 16-bit values produce >> the same result when using the PRF on the cookie. The initiator repeats >> the request along with the nonce and Si for all i. >> >> The responder now needs to do the following: >> - Verify the COOKIE >> - Encrypt the COOKIE, resulting (hopefully) in the concatenation of the >> Si values. >> >> With the numbers I used in the example, k=16 resulting in 2^16 PRF >> calculations on the client. >> The puzzle can be made harder by increasing k and breaking the encrypted >> COOKIE into larger chunks. >> >> Did I get this correctly? >> >> Thanks >> >> Yoav > > From nobody Fri Feb 6 01:27:59 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF761A19F8 for ; Fri, 6 Feb 2015 01:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QkOfgAKjKXK for ; Fri, 6 Feb 2015 01:27:48 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324991A03FF for ; Fri, 6 Feb 2015 01:27:47 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t169RiC6017625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 Feb 2015 11:27:44 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t169Rhlx007230; Fri, 6 Feb 2015 11:27:43 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21716.35087.351890.60792@fireball.kivinen.iki.fi> Date: Fri, 6 Feb 2015 11:27:43 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <00A15492FD3948939F4A474664E606E9@buildpc> References: <21715.18003.165707.402734@fireball.kivinen.iki.fi> <00A15492FD3948939F4A474664E606E9@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 12 min Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 09:27:50 -0000 Valery Smyslov writes: > Is the following text for the entire section 2.4 OK for you? > (I've borrowed some of your text): Looks mostly ok. > 2.4. Interaction with Peer Authorization Database (PAD) > > Section 4.4.3 of [RFC4301] defines the Peer Authorization Database > (PAD), which provides the link between Security Policy Database (SPD) > and the IKEv2. The PAD contains an ordered list of records, with > peers' identities along with corresponding authentication data and > Child SA authorization data. When the IKE SA is being established > the PAD is consulted to determine how the peer should be > authenticated and what Child SAs it is authorized to create. > > When using NULL Authentication, the peer identity is not > authenticated and cannot be trusted. If ID_NULL is used with NULL > Authentication, there is no ID at all. The processing of PAD > described in Section 4.4.3.4 of [RFC4301] must be updated. > > The NULL authentication needs to be added as one of supported > authentication methods. This method MUST contain no authentication > data. I do not understand why there is MUST NOT for authentication data. Yes, there is no authentication data, but that is not really something that needs to be enforced in MUST level. Perhaps just change This method MUST contain no authentication data. to The NULL authenticaiton method does not have any authentication data. or similar. > To add support for ID_NULL, it needs to be included into the > list of ID types, specified in Section 4.4.3.1 of [RFC4301]. The > matching rule for ID_NULL is just whether this type is used, i.e. no > actual ID matching is done, as ID_NULL contains no identity data. > > Section 4.4.3.3 of the [RFC4301] describes how the IKE ID is matched > against the SPD entries. When using the NULL authentication method > those matching rules MUST include matching of a flag in the SPD entry ^ change "a flag" to "a new flag", so it clearly indicates we are talking about something that is modified in the RFC4301, not something that already is there. > specifying whether unauthenticated users are allowed to use that > entry. I.e. each SPD entry needs to be augmented to have flag > specifying whether it can be used with NULL authentication or not, > and only those rules explictly having that flag turned on can be used > with unauthenticated connections. I wonder should we explitly mention something about dangers which can happen if this flag is not implemented properly, i.e. because the RFC4301 describes that we lookup SPD based on the ID, and that ID is not authenticated when using NULL authentication, we cannot mix it with authenticated IDs. Either here, or in the security considerations section. We do already have section 3.3 which covers this, but it does not go to this kind of lower level details of PAD and SPD. On the other hand we already describe that you need the flag, and we warn that combining authenticated and unauthenticated peers in same host is dangerous, so that might be enough. -- kivinen@iki.fi From nobody Fri Feb 6 03:25:08 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4958A1A00FA for ; Fri, 6 Feb 2015 03:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.091 X-Spam-Level: X-Spam-Status: No, score=-0.091 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihFAvu1jIyH0 for ; Fri, 6 Feb 2015 03:25:05 -0800 (PST) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (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 1AE091A0122 for ; Fri, 6 Feb 2015 03:25:05 -0800 (PST) Received: by labgf13 with SMTP id gf13so490421lab.3 for ; Fri, 06 Feb 2015 03:25:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=yO2Iul28DN9cgIoKzl3V2CakxYpFe2Iq3IfNEyVLT6I=; b=uBtJiZ/xkhtPggceT8slfMUvegYvk7ztCaFTPUCNYgIIbBfjBOPfx3nj28GfhY0Ilc d36ja/h61HSYnZkNccPyRCbOKzOSSGvvRTTYIrVBR1YLZPKFBJO3g+pmDSE1HQfK2b84 Ilzi0/+49mcW2twv/hMjn07enWKEf7I2ts73k+SF7jiR1LIqaDjdl2ZkdC26DNTl2nXI LWi/eWg1709fjXknM+d56eA6GWC2W1MeLQQmQORAWjN3fMXF/raVUzpFYrqqD5Dr1dJo NY+oOP83u0r/XtihUDf+LBKkc4LjwfaASPhWK5t3Ajq8ZDYzS9UU2/slVEVg1puhYnLE J4/w== X-Received: by 10.113.11.12 with SMTP id ee12mr2208069lbd.79.1423221903589; Fri, 06 Feb 2015 03:25:03 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id zz10sm370846lbb.13.2015.02.06.03.25.02 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 06 Feb 2015 03:25:03 -0800 (PST) Message-ID: <358052BBD7FF4191B3C6119595EA7ECB@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" References: <21715.18003.165707.402734@fireball.kivinen.iki.fi><00A15492FD3948939F4A474664E606E9@buildpc> <21716.35087.351890.60792@fireball.kivinen.iki.fi> Date: Fri, 6 Feb 2015 14:25:01 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG , Paul Wouters Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 11:25:07 -0000 >> Is the following text for the entire section 2.4 OK for you? >> (I've borrowed some of your text): > > Looks mostly ok. > >> 2.4. Interaction with Peer Authorization Database (PAD) >> >> Section 4.4.3 of [RFC4301] defines the Peer Authorization Database >> (PAD), which provides the link between Security Policy Database (SPD) >> and the IKEv2. The PAD contains an ordered list of records, with >> peers' identities along with corresponding authentication data and >> Child SA authorization data. When the IKE SA is being established >> the PAD is consulted to determine how the peer should be >> authenticated and what Child SAs it is authorized to create. >> >> When using NULL Authentication, the peer identity is not >> authenticated and cannot be trusted. If ID_NULL is used with NULL >> Authentication, there is no ID at all. The processing of PAD >> described in Section 4.4.3.4 of [RFC4301] must be updated. >> >> The NULL authentication needs to be added as one of supported >> authentication methods. This method MUST contain no authentication >> data. > > I do not understand why there is MUST NOT for authentication data. > Yes, there is no authentication data, but that is not really something > that needs to be enforced in MUST level. Perhaps just change > > This method MUST contain no authentication data. > > to > > The NULL authenticaiton method does not have any authentication > data. > > or similar. OK. >> To add support for ID_NULL, it needs to be included into the >> list of ID types, specified in Section 4.4.3.1 of [RFC4301]. The >> matching rule for ID_NULL is just whether this type is used, i.e. no >> actual ID matching is done, as ID_NULL contains no identity data. >> >> Section 4.4.3.3 of the [RFC4301] describes how the IKE ID is matched >> against the SPD entries. When using the NULL authentication method >> those matching rules MUST include matching of a flag in the SPD entry > ^ > > change "a flag" to "a new flag", so it clearly indicates we are > talking about something that is modified in the RFC4301, not something > that already is there. Done. >> specifying whether unauthenticated users are allowed to use that >> entry. I.e. each SPD entry needs to be augmented to have flag >> specifying whether it can be used with NULL authentication or not, >> and only those rules explictly having that flag turned on can be used >> with unauthenticated connections. > > I wonder should we explitly mention something about dangers which can > happen if this flag is not implemented properly, i.e. because the > RFC4301 describes that we lookup SPD based on the ID, and that ID > is not authenticated when using NULL authentication, we cannot mix it > with authenticated IDs. Either here, or in the security considerations > section. > > > We do already have section 3.3 which covers this, but it does not go > to this kind of lower level details of PAD and SPD. On the other hand > we already describe that you need the flag, and we warn that combining > authenticated and unauthenticated peers in same host is dangerous, so > that might be enough. But it is said that unauthenticated IDs can only be matched if SPD entry has a new flag set. I think it must be enough. Valery. > -- > kivinen@iki.fi From nobody Sun Feb 8 13:21:00 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC971A1A7C for ; Sun, 8 Feb 2015 13:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.699 X-Spam-Level: * X-Spam-Status: No, score=1.699 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_41=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMVDlp_X6Mbv for ; Sun, 8 Feb 2015 13:20:56 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (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 BD27F1A1A8A for ; Sun, 8 Feb 2015 13:20:53 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id w55so11786424wes.4 for ; Sun, 08 Feb 2015 13:20:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=YcYifAe83/ad1kZ13/iZFOiWpVsdrpeCtmyWumXYNO4=; b=zlri/N7RbUwDX0LhVqe9BWbOy9VVlqTiZvH/uW++HXM1C5oVMm9/+p9r1V7W560hU5 NGAQFFA60ytwToyrkI0C0CMXtyWcMiC7m9WRR0rG3rkqGHWsMVpXR/Uss69cd4nL4a74 gP1zu82uwgyrDknuonPsrIZJ+5McPuBqcB9gfCfQz7ULKt58GO/+TVIrHxkYOahoskTE veFKFN9krwrLfW7DXd+p8/oO+Ukd1SHBucYEs/2bV8eBPJO6GsQzh7FEOy6LDVr8srZP oNbqWOVoWL6/xnBRNtkK+8Q5dMeV4zxpht8dKJY6imb2WY+5QX4/Tap4kg1PySE1WLvh 6zhw== X-Received: by 10.194.84.176 with SMTP id a16mr32793320wjz.113.1423430452411; Sun, 08 Feb 2015 13:20:52 -0800 (PST) Received: from [10.0.0.7] ([109.65.10.176]) by mx.google.com with ESMTPSA id p6sm11573714wia.14.2015.02.08.13.20.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Feb 2015 13:20:51 -0800 (PST) Message-ID: <54D7D332.5040604@gmail.com> Date: Sun, 08 Feb 2015 23:20:50 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Valery Smyslov , Yoav Nir References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> <54CE6429.2020800@gmail.com> <99696496A6304DE588B99DD6B5E75B1C@buildpc> <0B9A7EB1-2B48-4778-AE82-3B1FBC2103D8@gmail.com> <426C21C2944648EA9D0EEA0B07BBADD6@buildpc> In-Reply-To: <426C21C2944648EA9D0EEA0B07BBADD6@buildpc> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPsecME WG , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 21:20:58 -0000 I think we've come a full circle. We now have a proposal that makes proof-of-work more deterministic for each type of client (which I find very useful). But the weaker clients will always lose, no matter what POW solution we choose. This has been a problem with this proposal from day one and it's a limitation that we as a group need to decide whether to accept or not. In a world where some clients are 100X more powerful than others, IMHO this result is something we have to live with. The only partial solution I see to this problem is to recommend using RFC 5723 session resumption, so that clients who have recently connected can reconnect even in DoS situations. Thanks, Yaron On 02/06/2015 10:22 AM, Valery Smyslov wrote: >> Thinking it over, you don’t really need AES at all, and in any case it >> doesn’t matter. >> The initiator doesn’t know the key and doesn’t know the algorithm, so >> it’s entirely a local matter. > > You are right, it's a local matter. > >> For example, the responder could pick HMAC-SHA256 with a fixed key, >> and calculate HMAC-SHA256(K,cookie). >> And it’s not even necessary for the initiator to solve all of the >> response. We can limit it to 8 Si-s (m=8), each 16 bits >> (k=16) even though the output of HMAC-SHA256 is 256 bits. m only >> serves to force the initiator to go through >> most of the 2^k possibilities. > > And another drawback of this approach is that the responder must do > quite a lot of work > to prepare puzzle. It must first calculate S1||S2||…||Sm and then for > each Si calculate Hi. > That is not an enormous work, but comparing with the current "zero bits" > proposal, > where the puzzle goes for free, it is non insignificant (especially as > we're trying > to protect responder against DoS attack). > > And again, my main concern is whether we are solving the right problem. > This approah makes time requiring to solve random puzzle more consistent. > But it doesn't help weak clients, unless we allow them to return as many > Si-s, as they can. But in this case I see no significant advantages > of this approach, but I can see its complexity, increased message size > and increased load on responder. > > Valery. > >> Yoav > >> On Feb 6, 2015, at 8:30 AM, Valery Smyslov wrote: >> >> I can see two drawbacks with this approach. >> >> First, to make it aligned with algorithm agility, we need to >> negotiate not only PRF, but also the encryption algorithm. >> And the selection criteria would become more complex. >> >> And second - it significantly increases the size of IKE_SA_INIT >> response message, as the puzzle must include m hashes. >> With SHA256 and m = 8 it is additional 256 bytes. >> With SHA512 and m = 16 it is additional 1024 bytes. >> That is not good as it increases the chance for IP fragmentation. >> >> Regards, >> Valery. >> >>> > On Feb 1, 2015, at 8:38 PM, Scott Fluhrer (sfluhrer) > > >>> wrote: >>> > >>> > If you want to tighten up the time between worse case and average >>> case > > time taken by the problem solver, might I suggest this: >>> > >>> > - When the verifier is asked to generate a problem, it pick a nonce >>> N, > > and use it to compute m k-bit values >>> S_1, S_2, ..., S_m (for example, S_1 || S_2 || ... || S_m = >>> AES_key(N), where the AES key is secret to the verifier), >>> and publish k, N, HASH(N, S_1), HASH(N, S_2), ..., HASH(N, S_m) >>> > >>> > - To solve the problem, the solver needs to produce the values S_1, >>> > S_2, > ..., S_m, and send back N, S_1, S_2, ..., S_m >>> > >>> > - The verifier verifies that the value N was what was originally >>> given > > (for example, the nonce might include the solver's >>> IP address and a timestamp), and that the values S_1 || S_2 || ... >>> || S_m = AES_key(N||0), (or alternatively, >>> that those values produces the hashes it sent). >>> > >>> > The solver can always solve the problem by computing 2**k hashes; >>> with > > moderate m, we can make it unlikely >>> that it can be done with significantly fewer hashes; I would suggest >>> m=4. >>> > >>> > Of course, the cost of doing this is a) larger messages, and b) >>> larger > > up-front cost generating the problem >>> (which, IMHO, isn't too bad -- one AES encryption, and m hash >>> computations; however, you are free to disagree). >>> > >>> >>> Hi, Scott. >>> >>> Thanks for the suggestion. Let me see if I understand it correctly: >>> >>> Responder has a fixed AES key (let’s call it K). >>> >>> Let’s assume that N is a COOKIE calculated as in RFC 5996. >>> >>> The responder Calculates S1||S2||…||Sm = AES(K, COOKIE). COOKIE can >>> be any length, >>> but for simplicity let’s assume 128-bit so that we don’t have to deal >>> with IVs, ICs or any other artifacts >>> of modes of operation. Also, let’s set m=8 and all Si as 16-bit. >>> So the responder now calculates 8 hashes: for each i Hi = >>> SHA256(COOKIE || Si) or better yet, Hi = PRF(Si, COOKIE). >>> >>> The responder sends to the initiator: >>> - The COOKIE >>> - Hi for all i. >>> - The number k, although that can be deduced from the number of His >>> - An identifier for the PRF algorithm chosen. >>> >>> The initiator needs to find Si values such that Hi = PRF(Si, COOKIE). >>> The silly way to do this is to solve run >>> through all 2^16 possible Si values once for each Hi (8 times), but a >>> better way would be to run once through >>> the possible Si-s and find all of them. There is a small chance of >>> making an error if two 16-bit values produce >>> the same result when using the PRF on the cookie. The initiator >>> repeats the request along with the nonce and Si for all i. >>> >>> The responder now needs to do the following: >>> - Verify the COOKIE >>> - Encrypt the COOKIE, resulting (hopefully) in the concatenation of >>> the Si values. >>> >>> With the numbers I used in the example, k=16 resulting in 2^16 PRF >>> calculations on the client. >>> The puzzle can be made harder by increasing k and breaking the >>> encrypted COOKIE into larger chunks. >>> >>> Did I get this correctly? >>> >>> Thanks >>> >>> Yoav >> >> > From nobody Sun Feb 8 14:03:00 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F121A1B35 for ; Sun, 8 Feb 2015 14:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qumMOYg0DO2f for ; Sun, 8 Feb 2015 14:02:56 -0800 (PST) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72F431A1A7C for ; Sun, 8 Feb 2015 14:02:56 -0800 (PST) Received: from [10.20.30.90] (142-254-17-22.dsl.dynamic.fusionbroadband.com [142.254.17.22]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t18M2rj3042305 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Feb 2015 15:02:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-22.dsl.dynamic.fusionbroadband.com [142.254.17.22] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: <54D7D332.5040604@gmail.com> Date: Sun, 8 Feb 2015 14:02:52 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1F395EC4-81EE-4252-865F-AEC940BAF145@vpnc.org> References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> <54CE6429.2020800@gmail.com> <99696496A6304DE588B99DD6B5E75B1C@buildpc> <0B9A7EB1-2B48-4778-AE82-3B1FBC2103D8@gmail.com> <426C21C2944648EA9D0EEA0B07BBADD6@buildpc> <54D7D332.5040604@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 22:02:57 -0000 On Feb 8, 2015, at 1:20 PM, Yaron Sheffer wrote: > I think we've come a full circle. We now have a proposal that makes = proof-of-work more deterministic for each type of client (which I find = very useful). But the weaker clients will always lose, no matter what = POW solution we choose. This has been a problem with this proposal from = day one and it's a limitation that we as a group need to decide whether = to accept or not. In a world where some clients are 100X more powerful = than others, IMHO this result is something we have to live with. >=20 > The only partial solution I see to this problem is to recommend using = RFC 5723 session resumption, so that clients who have recently connected = can reconnect even in DoS situations. Can a gateway sanely do session resumption when it is under DoS attack? = That is, can the gateway safely allocate CPU resources to a purported = session resumption? --Paul Hoffman= From nobody Sun Feb 8 15:21:50 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B85D1A1AF4 for ; Sun, 8 Feb 2015 15:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-wZ-nE8oItB for ; Sun, 8 Feb 2015 15:21:20 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (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 E0D761A1AB4 for ; Sun, 8 Feb 2015 15:21:19 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id p10so12103362wes.7 for ; Sun, 08 Feb 2015 15:21:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=r8WWohQzAQE1IlxWi4Uz4WwZMGidbySnsc83sfrAdc0=; b=L5QfEGkZocwBRFqnKZGBb5dpND2Xmqs7FLa5wab7zHGorzUdL/gwXA9X2LDrWV20kq YHegovL/lfXV6WAq1F+Gw50Dr8ebJiLZ4PAnIkSUj1aBSmrbsXgTHBY1gUm3Nbxzr+2O lv05xGeeRq2e7swE3qovhlwmgDWN6gE3GGcnkb/SpRNnAI4wET1CyM7vpJyI62RmBDfD VE6iuPB1gzeMnwaXQJ1BAVh66RUaOhEwxjkWav8vHLJWDLS3Gd8rDJCi+FAtR5/waVYq 6gDYX1dnZxUQZM+3UNR4VZfn18aRnBbHuDwo+y2ynktvAzryEP5jrOSgeyShzBt/kD+D QSOQ== X-Received: by 10.180.21.162 with SMTP id w2mr29103413wie.42.1423437678687; Sun, 08 Feb 2015 15:21:18 -0800 (PST) Received: from [10.0.0.7] (bzq-109-65-10-176.red.bezeqint.net. [109.65.10.176]) by mx.google.com with ESMTPSA id k20sm11895518wie.14.2015.02.08.15.21.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Feb 2015 15:21:17 -0800 (PST) Message-ID: <54D7EF6B.1020706@gmail.com> Date: Mon, 09 Feb 2015 01:21:15 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Paul Hoffman References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> <54CE6429.2020800@gmail.com> <99696496A6304DE588B99DD6B5E75B1C@buildpc> <0B9A7EB1-2B48-4778-AE82-3B1FBC2103D8@gmail.com> <426C21C2944648EA9D0EEA0B07BBADD6@buildpc> <54D7D332.5040604@gmail.com> <1F395EC4-81EE-4252-865F-AEC940BAF145@vpnc.org> In-Reply-To: <1F395EC4-81EE-4252-865F-AEC940BAF145@vpnc.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 23:21:22 -0000 > On Feb 8, 2015, at 1:20 PM, Yaron Sheffer wrote: >> I think we've come a full circle. We now have a proposal that makes proof-of-work more deterministic for each type of client (which I find very useful). But the weaker clients will always lose, no matter what POW solution we choose. This has been a problem with this proposal from day one and it's a limitation that we as a group need to decide whether to accept or not. In a world where some clients are 100X more powerful than others, IMHO this result is something we have to live with. >> >> The only partial solution I see to this problem is to recommend using RFC 5723 session resumption, so that clients who have recently connected can reconnect even in DoS situations. > > Can a gateway sanely do session resumption when it is under DoS attack? That is, can the gateway safely allocate CPU resources to a purported session resumption? > > --Paul Hoffman > Yes, of course. It just needs to verify the integrity (MAC) of the received ticket (as easy or easier than our proposed puzzle verification), and then the rest of the exchange is lighter-weight than a typical IKE exchange. See http://tools.ietf.org/html/rfc5723#section-4.3.2. Thanks, Yaron From nobody Sun Feb 8 16:44:13 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63D41A6F02 for ; Sun, 8 Feb 2015 16:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIDJQuSx1Gnl for ; Sun, 8 Feb 2015 16:44:10 -0800 (PST) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68391A1B7F for ; Sun, 8 Feb 2015 16:44:10 -0800 (PST) Received: from [10.20.30.90] (142-254-17-146.dsl.dynamic.fusionbroadband.com [142.254.17.146]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t190i7p3070040 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Feb 2015 17:44:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-146.dsl.dynamic.fusionbroadband.com [142.254.17.146] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: <54D7EF6B.1020706@gmail.com> Date: Sun, 8 Feb 2015 16:44:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> <54CE6429.2020800@gmail.com> <99696496A6304DE588B99DD6B5E75B1C@buildpc> <0B9A7EB1-2B48-4778-AE82-3B1FBC2103D8@gmail.com> <426C21C2944648EA9D0EEA0B07BBADD6@buildpc> <54D7D332.5040604@gmail.com> <1F395EC4-81EE-4252-865F-AEC940BAF145@vpnc.org> <54D7EF6B.1020706@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 00:44:12 -0000 On Feb 8, 2015, at 3:21 PM, Yaron Sheffer wrote: > Yes, of course. It just needs to verify the integrity (MAC) of the = received ticket (as easy or easier than our proposed puzzle = verification), and then the rest of the exchange is lighter-weight than = a typical IKE exchange. See = http://tools.ietf.org/html/rfc5723#section-4.3.2. I knew the latter part, but I was more concerned about the former. As = long as the verification is no harder than the proposed puzzles, then = yes, resumption seems like a good addition. I wanted to be sure that it = wasn't harder. --Paul Hoffman= From nobody Sun Feb 8 18:03:44 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524801A86EC for ; Sun, 8 Feb 2015 18:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkYkwZ581GGi for ; Sun, 8 Feb 2015 18:03:39 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 117C71A1A9C for ; Sun, 8 Feb 2015 18:03:39 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kgVrl1kM9z1xf; Mon, 9 Feb 2015 03:03:35 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=KuuaINwc; dkim-adsp=pass X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id BhcBuq3qjE1E; Mon, 9 Feb 2015 03:03:34 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 9 Feb 2015 03:03:34 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AD77583247; Sun, 8 Feb 2015 21:03:33 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1423447413; bh=8htqmSmXEW4SCPkSL3qO5jsc07PvxMApEr4z17UjE3Q=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=KuuaINwcPRSLOA+tzY4K/yB9vtPsubUf6rxUw1IMubJHdi0+EEw+aehSyiTbk4tpf IpfQn/l/gNKPLy4YiL39z+VoCeHPrXu+FNRO63ozH7bW+mMp2NCrV7eA/sQCJhLNj1 LJ8/SY59rms+eyF8++fAa/0bY/38xkOpJyXpm2ec= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t1923Xc8011780; Sun, 8 Feb 2015 21:03:33 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 8 Feb 2015 21:03:33 -0500 (EST) From: Paul Wouters To: Yaron Sheffer In-Reply-To: <54D7D332.5040604@gmail.com> Message-ID: References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> <54CE6429.2020800@gmail.com> <99696496A6304DE588B99DD6B5E75B1C@buildpc> <0B9A7EB1-2B48-4778-AE82-3B1FBC2103D8@gmail.com> <426C21C2944648EA9D0EEA0B07BBADD6@buildpc> <54D7D332.5040604@gmail.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 02:03:42 -0000 On Sun, 8 Feb 2015, Yaron Sheffer wrote: > I think we've come a full circle. We now have a proposal that makes > proof-of-work more deterministic for each type of client (which I find very > useful). But the weaker clients will always lose, no matter what POW solution > we choose. This has been a problem with this proposal from day one and it's a > limitation that we as a group need to decide whether to accept or not. I'm not yet convinced this proposal will provide a working solution to the DDOS problem. Paul From nobody Mon Feb 9 07:14:29 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0460F1A0469 for ; Mon, 9 Feb 2015 06:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-8B4IyIxyPD for ; Mon, 9 Feb 2015 06:52:26 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (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 EC9671A0461 for ; Mon, 9 Feb 2015 06:52:25 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id z2so6308094wiv.0 for ; Mon, 09 Feb 2015 06:52:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PewYKe8fjdpLy2WX/BNTDucKdVsUZQNJC1wtrDbsX8M=; b=Pckz0jNUhD0glXakDmGqy/QRz4Oq1JbKwbEkWAxM82u5gyx0im2GrjDxZc0+Vxb7cA knD8mwOJbVKm9j1MOOerBHYVnysBzvBVZW9tC1j0QG9q5KUJOOeI5soPEFIrusWX4Xza Bseb1sZNfjK02sb5deAAIog2ezjPunYoHD/8E3oQvvlOp/9HsYnk9ufMtvz2oyWVemoY swcfzTtqc/cbLEZupgcyLTzx3oaODPV2dq9HxtKtBqY8Ltj/5K5ml0gZHOxg+8+QMgvt mO8dIML5toBtIL/iLCy8Dh3e7ltcGEHb83omlyoD+Xqac7lrg+jmUdKJNNr0Z9V9zrdu NMew== X-Received: by 10.180.184.132 with SMTP id eu4mr35694100wic.49.1423493544269; Mon, 09 Feb 2015 06:52:24 -0800 (PST) Received: from [172.24.251.208] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id g8sm14762298wiy.6.2015.02.09.06.52.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Feb 2015 06:52:23 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Mon, 9 Feb 2015 16:52:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <84E7E596-B58C-40DC-AB3C-5B9B059A7D08@gmail.com> References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> <54CE6429.2020800@gmail.com> <99696496A6304DE588B99DD6B5E75B1C@buildpc> <0B9A7EB1-2B48-4778-AE82-3B1FBC2103D8@gmail.com> <426C21C2944648EA9D0EEA0B07BBADD6@buildpc> <54D7D332.5040604@gmail.com> To: Paul Wouters X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 14:52:28 -0000 > On Feb 9, 2015, at 4:03 AM, Paul Wouters wrote: >=20 > On Sun, 8 Feb 2015, Yaron Sheffer wrote: >=20 >> I think we've come a full circle. We now have a proposal that makes = proof-of-work more deterministic for each type of client (which I find = very useful). But the weaker clients will always lose, no matter what = POW solution we choose. This has been a problem with this proposal from = day one and it's a limitation that we as a group need to decide whether = to accept or not. >=20 > I'm not yet convinced this proposal will provide a working solution to > the DDOS problem. Hi, Paul =E2=80=9Csolution=E2=80=9D is hard. Whatever we do, an attacker with = unlimited resources can throw more at us.=20 We could block all regular initiations under load, allowing only RFC = 5723 resumptions. But this allows an attacker to force us into this mode = and effectively deny service to all initiators that don=E2=80=99t have a = saved session.=20 So instead we can allow resumptions and also make it more costly for the = attacker to mount the attack on regular initiations. Even an easy = puzzle, one that my 1.2 GHz single-core ARMv5 with C code can solve in a = second is much harder than just the return routability that COOKIE = provides. The draft has text about how to make these puzzles a weapon of = last resort, so legitimate users hardly ever need to solve them, but = even setting the puzzle difficulty to something a strong desktop can do = 20 times a second, it=E2=80=99s still better than the two other = alternatives: allow the strong desktop to create 1000 half-open SAs in a = second, or entirely block the subnet from which the desktop seems to = come. Yoav From nobody Mon Feb 9 08:47:32 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCB61A1A7B for ; Mon, 9 Feb 2015 08:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApKDJtgMX_Tw for ; Mon, 9 Feb 2015 08:37:57 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (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 44F7F1A1ABF for ; Mon, 9 Feb 2015 08:34:51 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hm9so6958804wib.1 for ; Mon, 09 Feb 2015 08:34:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=d8N88wv1bZGHaAsIlDtFAD/fe6Nary2ScotX1k0WzFM=; b=BOKL0wvM4Ps/l4GAPlkvM/AMvXueXFNMMMia7ElQedgSdNnmiT6b5Jixe7iogvLhA3 esLyUAb0SK++sEwTnNvV3noqsKQDkBOIL9R7VdcYbFWylopeq3H4HLZd2qoeV3dCajqs kBsdX7he+rg0rWnnk/s4g/zYIs++xgHxn+f3BminL1JGU4oPmM1AnziR14vWl+Ze7bIX GiSIpDDyxiInQgeeFCGa4wCsh/Ap2Rw4ohHe4CTNZNzE4n4gSHfYc6EM3jJTlYVi+gbN pvrfO4DZisMFvrGdaE+gk0+Ri3u54GbUlj/gLK2rGSobT7AjIKdlYNr69JL32OCvfdhB F1rA== X-Received: by 10.194.2.75 with SMTP id 11mr43989000wjs.78.1423499690040; Mon, 09 Feb 2015 08:34:50 -0800 (PST) Received: from [10.2.0.130] (46-116-120-68.bb.netvision.net.il. [46.116.120.68]) by mx.google.com with ESMTPSA id ej10sm15127312wib.2.2015.02.09.08.34.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Feb 2015 08:34:49 -0800 (PST) Message-ID: <54D8E1A6.5040001@gmail.com> Date: Mon, 09 Feb 2015 18:34:46 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Yoav Nir , Paul Wouters References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> <54C75880-8F6C-40AA-9F30-754D16BAD46D@gmail.com> <22BD2882-D15D-4280-AE2B-07C060FC1DE5@gmail.com> <54CE6429.2020800@gmail.com> <99696496A6304DE588B99DD6B5E75B1C@buildpc> <0B9A7EB1-2B48-4778-AE82-3B1FBC2103D8@gmail.com> <426C21C2944648EA9D0EEA0B07BBADD6@buildpc> <54D7D332.5040604@gmail.com> <84E7E596-B58C-40DC-AB3C-5B9B059A7D08@gmail.com> In-Reply-To: <84E7E596-B58C-40DC-AB3C-5B9B059A7D08@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 16:38:07 -0000 Re: session resumption, I would like to propose the following text: 6.1. Session Resumption When the Responder is under attack, it MAY choose to prefer previously authenticated peers who present a session resumption [RFC 5723] ticket. The Responder MAY require such Initiators to include a return routability ticket in the IKE_SESSION_RESUME message, as allowed by RFC 5723, Sec. 4.3.2. Note that the Responder SHOULD cache tickets for a short time to reject reused tickets (Sec. 4.3.1), and therefore there should be no issue of half-open SAs resulting from replayed IKE_SESSION_RESUME messages. Thanks, Yaron On 02/09/2015 04:52 PM, Yoav Nir wrote: > >> On Feb 9, 2015, at 4:03 AM, Paul Wouters wrote: >> >> On Sun, 8 Feb 2015, Yaron Sheffer wrote: >> >>> I think we've come a full circle. We now have a proposal that makes proof-of-work more deterministic for each type of client (which I find very useful). But the weaker clients will always lose, no matter what POW solution we choose. This has been a problem with this proposal from day one and it's a limitation that we as a group need to decide whether to accept or not. >> >> I'm not yet convinced this proposal will provide a working solution to >> the DDOS problem. > > Hi, Paul > > “solution” is hard. Whatever we do, an attacker with unlimited resources can throw more at us. > > We could block all regular initiations under load, allowing only RFC 5723 resumptions. But this allows an attacker to force us into this mode and effectively deny service to all initiators that don’t have a saved session. > > So instead we can allow resumptions and also make it more costly for the attacker to mount the attack on regular initiations. Even an easy puzzle, one that my 1.2 GHz single-core ARMv5 with C code can solve in a second is much harder than just the return routability that COOKIE provides. The draft has text about how to make these puzzles a weapon of last resort, so legitimate users hardly ever need to solve them, but even setting the puzzle difficulty to something a strong desktop can do 20 times a second, it’s still better than the two other alternatives: allow the strong desktop to create 1000 half-open SAs in a second, or entirely block the subnet from which the desktop seems to come. > > Yoav > From nobody Mon Feb 9 19:59:28 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8741A1BAE for ; Mon, 9 Feb 2015 19:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATRj0islVhrq for ; Mon, 9 Feb 2015 19:59:12 -0800 (PST) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21781A870A for ; Mon, 9 Feb 2015 19:59:12 -0800 (PST) Received: from [10.20.30.90] (50-0-66-154.dsl.dynamic.fusionbroadband.com [50.0.66.154]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t1A3xBtM078969 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Feb 2015 20:59:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-0-66-154.dsl.dynamic.fusionbroadband.com [50.0.66.154] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: <587EB741-0C86-4E70-BAC9-E31D6BF4B060@vpnc.org> Date: Mon, 9 Feb 2015 19:59:10 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <587EB741-0C86-4E70-BAC9-E31D6BF4B060@vpnc.org> To: IPsecME WG X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [IPsec] ANOTHER NUDGE: Re: Second WG Last call, or continuation of WG Last Call, on "The NULL Authentication Method in IKEv2 Protocol" draft-ietf-ipsecme-ikev2-null-auth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 03:59:14 -0000 [[ We really want to hear from everyone who reviewed the draft earlier, = and would love to hear from at least a few new reviewers as well. These = reviews are really a helpful way to participate in the WG! ]] >=20 >> On Jan 28, 2015, at 2:22 PM, Paul Hoffman = wrote: >>=20 >> Greetings again. Please review = draft-ietf-ipsecme-ikev2-null-auth-03.txt: it is now our WG Last Call = item. >>=20 >> If you commented earlier, please look at = = and see if your comments were reflected either by adoption, or by an = adequate comment on the issue you brought up. >>=20 >> If you did not comment during the first part of the WG Last Call, but = you were intrigued by some of the comments in the last call, *please* = read the document and comment, even if just to say "I have reviewed this = document and it is fine" or "I have now reviewed the document and here = are a few things that still deserve comment". >>=20 >> If it looks like there is general agreement, we'll close out this = second/continued WG Last Call in two weeks, on February 11. >>=20 >> --Paul Hoffman From nobody Tue Feb 10 01:14:23 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E150A1A1A9F for ; Tue, 10 Feb 2015 01:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Giecp1aOUKhP for ; Tue, 10 Feb 2015 01:14:06 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410CF1A008F for ; Tue, 10 Feb 2015 01:13:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,549,1418079600"; d="scan'208";a="99509127" Received: from ra178-1-88-163-20-214.fbx.proxad.net (HELO [192.168.0.24]) ([88.163.20.214]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Feb 2015 10:13:51 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Benjamin Beurdouche In-Reply-To: Date: Tue, 10 Feb 2015 10:13:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <587EB741-0C86-4E70-BAC9-E31D6BF4B060@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: ML IETF Ipsecme Subject: Re: [IPsec] ANOTHER NUDGE: Re: Second WG Last call, or continuation of WG Last Call, on "The NULL Authentication Method in IKEv2 Protocol" draft-ietf-ipsecme-ikev2-null-auth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 09:14:15 -0000 Hi Paul, Just reading it.. I think there are typos here : 1 - =E2=80=9Ccan still launch an Man-in-the-Middle=E2=80=9D =E2=80=94 - = > =E2=80=9Ccan still launch a Man-in-the-Middle=E2=80=9D 2 - =E2=80=9Cmay compromise the client=E2=80=99s anonimity in case of=E2=80= =9D =E2=80=94 - > =E2=80=9Cmay compromise the client=E2=80=99s anonymity = in case of=E2=80=9D Other than that I don=E2=80=99t see any major issues, I think the draft = is pretty clear. By the way moving the Drafts to Github like the TLS and HTTP2 WGs do = would be quite nice for pull requests =3D) Cheers, Benjamin > On 10 Feb 2015, at 04:59, Paul Hoffman wrote: >=20 > [[ We really want to hear from everyone who reviewed the draft = earlier, and would love to hear from at least a few new reviewers as = well. These reviews are really a helpful way to participate in the WG! = ]] >>=20 >>> On Jan 28, 2015, at 2:22 PM, Paul Hoffman = wrote: >>>=20 >>> Greetings again. Please review = draft-ietf-ipsecme-ikev2-null-auth-03.txt: it is now our WG Last Call = item. >>>=20 >>> If you commented earlier, please look at = = and see if your comments were reflected either by adoption, or by an = adequate comment on the issue you brought up. >>>=20 >>> If you did not comment during the first part of the WG Last Call, = but you were intrigued by some of the comments in the last call, = *please* read the document and comment, even if just to say "I have = reviewed this document and it is fine" or "I have now reviewed the = document and here are a few things that still deserve comment". >>>=20 >>> If it looks like there is general agreement, we'll close out this = second/continued WG Last Call in two weeks, on February 11. >>>=20 >>> --Paul Hoffman >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Feb 13 06:33:22 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4E01A8701 for ; Fri, 13 Feb 2015 06:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.666 X-Spam-Level: *** X-Spam-Status: No, score=3.666 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, STOX_REPLY_TYPE_WITHOUT_QUOTES=1.757] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6CZdsQwotOL for ; Fri, 13 Feb 2015 06:33:18 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (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 6CBBB1A86FB for ; Fri, 13 Feb 2015 06:33:18 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id w7so15815003lbi.10 for ; Fri, 13 Feb 2015 06:33:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=mKNGPKQdzEVGxORliRSe9B1sWc1fAK6efimKl9u1FOc=; b=pTDCvI4z2k6+0SXP/2kP9PI8X8S+0tVDZsACATDGv/LU0kLXwUpVnNWJt94tizhDbC uNt+FnZrcWvANLlhLbMg2EjTd6dhgsNIfq8W4W1izLV7v4pMayPcYlAhtqzxRLKL6Td2 J+5YRR3He2PcWl6NLY1vclSucan9JpMEkfRfhy1pmglbmzWGKP/GGhh21B4k+yJ/AuAi NA12hZ58ebIJBSHuQe+awrq34Ng1l2YrscLfgAruuZonjOI4sJZqdV0EVJcHqdsPnglL DmkhQxa4E7bhfyxWPxXwqASORnGwW4zVXeIEwHJtkPk0NkjmUkHIZXwVAN3ZwlumtT2n og9g== X-Received: by 10.152.120.225 with SMTP id lf1mr7837434lab.20.1423837996566; Fri, 13 Feb 2015 06:33:16 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id d5sm1397770lab.27.2015.02.13.06.33.15 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 13 Feb 2015 06:33:15 -0800 (PST) Message-ID: <9C28D10A26B74F029D76E0E6811FEF2F@buildpc> From: "Valery Smyslov" To: "IPsecME WG" References: Date: Fri, 13 Feb 2015 17:33:21 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: Yoav Nir Subject: [IPsec] Puzzles in IKE_SA_INIT exchange (and more) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 14:33:20 -0000 Hi all, I've created new pull request (it fact - updated my previous pull request). The source file and changes are available at https://github.com/ietf-ipsecme/drafts/pull/2 It mostly devoted to using puzzles in IKE_SA_INIT exchange. I tried to describe it in details, however a few sections are left blank for now as they are more or less obvious. This pull request also includes the section describing DoS protection measures after IKE SA is created and a short section proposed by Yaron on using resumption in case of DoS attack. There is also a section describing the proposed format for the PUZZLE notification. Regards, Valery Smyslov. From nobody Fri Feb 13 11:35:57 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 680041A0399 for ; Fri, 13 Feb 2015 11:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxSrl8xaw386 for ; Fri, 13 Feb 2015 11:35:43 -0800 (PST) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E0F1A0382 for ; Fri, 13 Feb 2015 11:35:20 -0800 (PST) Received: from [10.20.30.101] (142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t1DJZIY7070539 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 Feb 2015 12:35:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245] claimed to be [10.20.30.101] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8D80A113-4201-412D-A4B7-D5AD45D440DF@vpnc.org> Date: Fri, 13 Feb 2015 11:35:17 -0800 To: IPsecME WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [IPsec] Close of second WG LC on draft-ietf-ipsecme-ikev2-null-auth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 19:35:44 -0000 Greetings again. We didn't get the level of review on the -03 document = we hoped for, but feel that there was sufficient review and little = enough push-back for us to say that the WG LC was successful. The = authors have agreed to a bunch of changes, so we are now waiting for a = -04. When that is published, we'll ask our AD to move the document to = IETF Last Call. --Paul Hoffman= From nobody Mon Feb 16 19:08:09 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D4C1A8953; Mon, 16 Feb 2015 19:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JX0zEwofWnpT; Mon, 16 Feb 2015 19:08:06 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (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 201CD1A86DE; Mon, 16 Feb 2015 19:08:06 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id em10so28729342wid.0; Mon, 16 Feb 2015 19:08:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=pWmNHJMhRGBPYWTwFNrWY+JYUCgZic2S4P9Rf97Zx7I=; b=lm2aoyUblgcbfAU0kMJZbV6pVGq+PkiZDzTLtwcB5PpZ7KMhgG/HM/D1oxYWO7yed0 1h5igppEbVDHHSGN4fsCTTh45yBaCgfJVA9Iu8CVKFvSgzCbhE+rqNTeanVZ/Lx/SEkc vX9BE/nLgRd5pMIBr5u3i2PSPUcAaMb/CbepI2Vsx0W/y1Erb0AXCFz0UCs72DwPhVgC w49SXeiEaeis+NKXlx7tR3KIU3tRrSN0a/WjXZLwTtzh74bMSkhKDpnMoVtgpAgVxRtd GJIAaabwZpIbYdX7/mYDcVLXJiUO0ivJ2NmWZ5Bn9tCouxUkKMbkjCgz3Oyqw2GkONwp XRiw== MIME-Version: 1.0 X-Received: by 10.194.200.68 with SMTP id jq4mr55981623wjc.128.1424142484654; Mon, 16 Feb 2015 19:08:04 -0800 (PST) Received: by 10.194.68.39 with HTTP; Mon, 16 Feb 2015 19:08:04 -0800 (PST) Date: Tue, 17 Feb 2015 04:08:04 +0100 Message-ID: From: Daniel Migault To: 6lo@ietf.org Content-Type: multipart/alternative; boundary=047d7b86ea96e85118050f4002c7 Archived-At: Cc: "ipsec@ietf.org" Subject: [IPsec] Diet-ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 03:08:08 -0000 --047d7b86ea96e85118050f4002c7 Content-Type: text/plain; charset=UTF-8 Please find the new version of Diet-ESP a compress IPsec/ESP for IoT. We have implemented and tested Diet-ESP. Compared to the standard IPsec/ESP, Diet-ESP can reduce the networking overhead added to unprotected data from 100% to a few percent. I will be happy to present these draft next IETF. Feel free to make comments! The drafts includes: 1) draft-mglt-6lo-diet-esp-requirements : lists the requirements for Diet-ESP 2) draft-mglt-6lo-aes-implicit-iv : indicates how to avoid carrying the IV in each ESP packet. It is instead generated by each peers. The protocols described in the draft can be used with the regular IPsec/ESP. 3) draft-mglt-6lo-diet-esp describes the core Diet-ESP protocol, that is how to compress/decompress each fields of the standard IPsec/ESP. Compression is discribed through a Diet-ESP Context. 4) draft-mglt-6lo-diet-esp-payload-compression : describes how the clear text can be compressed before encryption. In fact unless IPsec/ESP is used with NULL encryption, the data in the ESP packet is encrypted. Encryption makes compression hard to perform. Instead compressing before encrypting can be very efficient. This makes possible to remove UDP/TPC/IP tunnel headers. 5) draft-mglt-6lo-diet-esp-context-ikev2-extension : describes how to negociate Diet-ESP with IKEv2. In fact this mostly result in an agreement for the DIet-ESP Context. This exchange may then be extended to Diet-HIP Exchange. BR, Daniel -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7b86ea96e85118050f4002c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Please find the new version of Diet-ESP a compress IP= sec/ESP for IoT. We have implemented and tested Diet-ESP. Compared to the s= tandard IPsec/ESP, Diet-ESP can reduce the networking overhead added to unp= rotected data from 100% to a few percent. I will be happy to present these = draft next IETF.

Feel free to make comments!

The drafts incl= udes:
=C2=A0=C2=A0=C2=A0 1) draft-mglt-6lo-diet-esp-requirements<= /a>: lists the requirements for Diet-ESP
=C2=A0=C2=A0=C2=A0 2= ) draft-mglt-6lo-aes-implicit-iv: indicates how to avoid carrying the = IV in each ESP packet. It is instead generated by each peers. The protocols= described in the draft can be used with the regular IPsec/ESP.
=C2=A0=C2=A0=C2=A0 3) draft-mglt-6lo-diet-esp desc= ribes the core Diet-ESP protocol, that is how to compress/decompress each f= ields of the standard IPsec/ESP. Compression is discribed through a Diet-ES= P Context.
=C2=A0=C2=A0=C2=A0 4) draft-mglt-6lo-diet-esp-p= ayload-compression: describes how the clear text can be compressed befo= re encryption. In fact unless IPsec/ESP is used with NULL encryption, the d= ata in the ESP packet is encrypted. Encryption makes compression hard to pe= rform. Instead compressing before encrypting can be very efficient. This ma= kes possible to remove UDP/TPC/IP tunnel headers.
=C2=A0=C2=A0=C2=A0 5) = draft-mglt-6lo-diet-esp-context-ikev2-extension: desc= ribes how to negociate Diet-ESP with IKEv2. In fact this mostly result in a= n agreement for the DIet-ESP Context. This exchange may then be extended to= Diet-HIP Exchange.

BR,
Daniel
--
Daniel Migault
Orange Labs -- S= ecurity
+33 6 70 72 69 58
--047d7b86ea96e85118050f4002c7-- From nobody Mon Feb 16 19:11:37 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F24CC1A897B for ; Mon, 16 Feb 2015 19:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skzBTYeHGbMd for ; Mon, 16 Feb 2015 19:11:35 -0800 (PST) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (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 431821A86DE for ; Mon, 16 Feb 2015 19:11:35 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id x12so22797681wgg.11 for ; Mon, 16 Feb 2015 19:11:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=QO1FcQXQekscGmEC68zn3mxEom9Bm6/hoNHE2+D05EE=; b=bYkqUVP1EtyMkdU2A2u1HalcFDEAhAZNHeD9EIurB3u/ZMIhjYdJPYBvu2xEYk9aim 2SlDSW3IunnRrUNT0DQF+yfoVxmra1eURsU5l1i2CNqaBYFqCNPH8czHk1wpbHEGCT15 oRoYa04Mae1p1qA77quMjcLMm9tKfrd5s9Ql7WFNbs2S9L8enTraaKNlcgIgDINdGLHV I5p5RYo8jae02NiWe6d9/cariVhbYzJSTKaDNo/xF8kNrjkJVRsv+VVyt/53xKxHnX43 RZqE8ROPeVFG0MKYciF3AMiYyG8chhQJpVXpn5n+XZoViRHWgKq/GbkFnCEl+qODrDqR KuFg== MIME-Version: 1.0 X-Received: by 10.194.61.244 with SMTP id t20mr54515574wjr.83.1424142694009; Mon, 16 Feb 2015 19:11:34 -0800 (PST) Received: by 10.194.68.39 with HTTP; Mon, 16 Feb 2015 19:11:33 -0800 (PST) Date: Tue, 17 Feb 2015 04:11:33 +0100 Message-ID: From: Daniel Migault To: "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=047d7b86e40662d0fc050f400f5f Archived-At: Subject: [IPsec] MOBIKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 03:11:37 -0000 --047d7b86e40662d0fc050f400f5f Content-Type: text/plain; charset=UTF-8 Hi folks, draft-mglt-ipsecme-mobikev2 is the new version for MOBIKEv2, that defines MOBIKE for the transport mode. We added the comments we received off list and on the list. The draft is now much smaller. Feel free to comment it. BR, Daniel -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7b86e40662d0fc050f400f5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi folks,

draft-mglt-ipsecme-mo= bikev2 is the new version for MOBIKEv2, that defines MOBIKE for the tra= nsport mode. We added the comments we received off list and on the list.
The draft is now much smaller. Feel free to comment it.

=
BR,
Daniel

--
Daniel Migault
Orange Labs -- Security
+33 6= 70 72 69 58
--047d7b86e40662d0fc050f400f5f-- From nobody Mon Feb 16 21:28:10 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48D41A1A0C; Mon, 16 Feb 2015 21:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odRMkdDurNjR; Mon, 16 Feb 2015 21:28:06 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16DE81A079D; Mon, 16 Feb 2015 21:28:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14788; q=dns/txt; s=iport; t=1424150887; x=1425360487; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=r3mVOXB5bN/2oXpxe64LNTjAaGmpWUulqrZqzLTGrcQ=; b=MLacwVDm0PcuMnM832JZC/tIL+gwI0YuYZPM7zBx8eO69WMFIwXTmPLe joywZfyvoCxLNPcpq3ikDInxPuXYCJ9ax36W18nosjtsRDWpIG2OOHdAJ EjqXJP88qbbprIl2g8VipM0uIQk2rLiB45/X8jdUeWiDgsuKtM6qbGf0C o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D0BwAA0eJU/5NdJa1bgkNDUloEgn+wDo1DgXCFbwIceUMBAQEBAQF8hAwBAQEEIwpMEAIBCA4DBAEBCx0DAgICMBQJCAIEAQ0FCIglDbcclxoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXiwyEPBYbBgGCaC6BFAWNTIFsg1eGeDiCVY5oIoNub4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,592,1418083200"; d="scan'208,217";a="397064621" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-2.cisco.com with ESMTP; 17 Feb 2015 05:28:06 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t1H5S5vf004426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Feb 2015 05:28:05 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.248]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Mon, 16 Feb 2015 23:28:04 -0600 From: "Scott Fluhrer (sfluhrer)" To: Daniel Migault , "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: [IPsec] Diet-ESP Thread-Index: AQHQSl8D8Q49UimlJk+ag/Gqzu2LiJz0RjGw Date: Tue, 17 Feb 2015 05:28:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.216] Content-Type: multipart/alternative; boundary="_000_A113ACFD9DF8B04F96395BDEACB340420D03A28Exmbrcdx04ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Diet-ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 05:28:09 -0000 --_000_A113ACFD9DF8B04F96395BDEACB340420D03A28Exmbrcdx04ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVyZeKAmXMgYW4gaXNzdWUgd2l0aCB0aGlzIGRyYWZ0OyBpdCBkb2VzbuKAmXQgbWVldCB0aGUg cmVxdWlyZW1lbnRzIHRoYXQgaXQgY2xhaW1zLiAgSW4gcGFydGljdWxhciwgaXQgY2xhaW1zIHRo YXQgaXQgaXMgYmFzZWQgb24gc3RhbmRhcmQgSVBzZWMsIGFuZCB0aGF0IGl0cyBzZWN1cml0eSBp cyBlcXVpdmFsZW50IHRvIElQc2VjIChSMS1SMykuICBIb3dldmVyLCBpdCBhbGxvd3MgKGFuZCwg YXMgZmFyIGFzIEkgYW0gY29uY2VybmVkLCBlbmNvdXJhZ2VzKSB0aGUgdXNlIG9mIHRpbnkgSUNW czsgdGhlc2UgdGlueSBJQ1ZzIGludHJvZHVjZSBzZWN1cml0eSB2dWxuZXJhYmlsaXRpZXMgdGhh dCBkbyBub3Qgb2NjdXIgd2l0aGluIHNhbmUgY29uZmlndXJhdGlvbnMgb2YgSVBzZWMgKHdoZXJl IHNhbmUgaW5jbHVkZXMgdXNpbmcgYW4gaW50ZWdyaXR5IHRyYW5zZm9ybSkuICBJbiBwYXJ0aWN1 bGFyLCB1c2luZyB0aW55IElDVnMgd2l0aCBHQ00gaXMgYSBrbm93biBzZWN1cml0eSBpc3N1ZS4N Cg0KTm93LCBpdCB3b3VsZCBiZSBwb3NzaWJsZSB0byBoYXZlIGFuIGVuY3J5cHRpb24gcHJvdG9j b2wgdGhhdCB3b3VsZCBub3QgaGF2ZSBpc3N1ZXMgd2l0aCBzbWFsbCBJQ1ZzIChzYXksIGJ5IHVz aW5nIGEgd2lkZSBibG9jayBjaXBoZXIpOyBob3dldmVyIHRoaXMgd291bGQgYmUgcmF0aGVyIGRp ZmZlcmVudCB0aGFuIHN0YW5kYXJkIElQc2VjIChpbiBwYXJ0IGJlY2F1c2UgSVBzZWMgd2FzIG5l dmVyIGRlc2lnbmVkIHdpdGggdGhlc2UgbWluaW1hbCBiYW5kd2lkdGggY29uc3RyYWludHMpOyBl aXRoZXIgd2UgbmVlZCB0byBzdGF5IHdpdGggYW4gSVBzZWMtYmFzZWQgcHJvdG9jb2wgKHdoaWNo IGltcGxpZXMgYSBsYXJnaXNoIElDViksIG9yIGdvIHdpdGggc29tZXRoaW5nIGVsc2UgKHdoaWNo IHdvdWxkIGhhdmUgbGVzcyBvdmVyaGVhZCwgYnV0IGRvZXNu4oCZdCBsb29rIHRoYXQgbXVjaCBs aWtlIElQc2VjIGludGVybmFsbHkpLg0KDQoNCk9oLCBhbmQgYSBtaW5vciBub3RlIG9uIHRoZSBJ ViBnZW5lcmF0aW9uOiBpdOKAmXMgYWN0dWFsbHkgc2VjdXJlIHRvIHVzZSB0aGUgc2FtZSBrZXkg eW91IHVzZSB0byBlbmNyeXB0IHRvIGVuY3J5cHQgdGhlIGNvdW50ZXIgZm9yIHRoZSBJVjsgeW91 IGRvbuKAmXQgbmVlZCBhIHNlcGFyYXRlIGtleS4NCg0KRnJvbTogSVBzZWMgW21haWx0bzppcHNl Yy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGFuaWVsIE1pZ2F1bHQNClNlbnQ6IE1v bmRheSwgRmVicnVhcnkgMTYsIDIwMTUgMTA6MDggUE0NClRvOiA2bG9AaWV0Zi5vcmcNCkNjOiBp cHNlY0BpZXRmLm9yZw0KU3ViamVjdDogW0lQc2VjXSBEaWV0LUVTUA0KDQpQbGVhc2UgZmluZCB0 aGUgbmV3IHZlcnNpb24gb2YgRGlldC1FU1AgYSBjb21wcmVzcyBJUHNlYy9FU1AgZm9yIElvVC4g V2UgaGF2ZSBpbXBsZW1lbnRlZCBhbmQgdGVzdGVkIERpZXQtRVNQLiBDb21wYXJlZCB0byB0aGUg c3RhbmRhcmQgSVBzZWMvRVNQLCBEaWV0LUVTUCBjYW4gcmVkdWNlIHRoZSBuZXR3b3JraW5nIG92 ZXJoZWFkIGFkZGVkIHRvIHVucHJvdGVjdGVkIGRhdGEgZnJvbSAxMDAlIHRvIGEgZmV3IHBlcmNl bnQuIEkgd2lsbCBiZSBoYXBweSB0byBwcmVzZW50IHRoZXNlIGRyYWZ0IG5leHQgSUVURi4NCg0K RmVlbCBmcmVlIHRvIG1ha2UgY29tbWVudHMhDQoNClRoZSBkcmFmdHMgaW5jbHVkZXM6DQogICAg MSkgZHJhZnQtbWdsdC02bG8tZGlldC1lc3AtcmVxdWlyZW1lbnRzPGh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtbWdsdC02bG8tZGlldC1lc3AtcmVxdWlyZW1lbnRzLz46IGxp c3RzIHRoZSByZXF1aXJlbWVudHMgZm9yIERpZXQtRVNQDQogICAgMikgZHJhZnQtbWdsdC02bG8t YWVzLWltcGxpY2l0LWl2PGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWds dC02bG8tYWVzLWltcGxpY2l0LWl2Lz46IGluZGljYXRlcyBob3cgdG8gYXZvaWQgY2Fycnlpbmcg dGhlIElWIGluIGVhY2ggRVNQIHBhY2tldC4gSXQgaXMgaW5zdGVhZCBnZW5lcmF0ZWQgYnkgZWFj aCBwZWVycy4gVGhlIHByb3RvY29scyBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0IGNhbiBiZSB1c2Vk IHdpdGggdGhlIHJlZ3VsYXIgSVBzZWMvRVNQLg0KICAgIDMpIGRyYWZ0LW1nbHQtNmxvLWRpZXQt ZXNwPGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWdsdC02bG8tZGlldC1l c3AvPiBkZXNjcmliZXMgdGhlIGNvcmUgRGlldC1FU1AgcHJvdG9jb2wsIHRoYXQgaXMgaG93IHRv IGNvbXByZXNzL2RlY29tcHJlc3MgZWFjaCBmaWVsZHMgb2YgdGhlIHN0YW5kYXJkIElQc2VjL0VT UC4gQ29tcHJlc3Npb24gaXMgZGlzY3JpYmVkIHRocm91Z2ggYSBEaWV0LUVTUCBDb250ZXh0Lg0K ICAgIDQpIGRyYWZ0LW1nbHQtNmxvLWRpZXQtZXNwLXBheWxvYWQtY29tcHJlc3Npb248aHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tZ2x0LTZsby1kaWV0LWVzcC1wYXlsb2Fk LWNvbXByZXNzaW9uLz46IGRlc2NyaWJlcyBob3cgdGhlIGNsZWFyIHRleHQgY2FuIGJlIGNvbXBy ZXNzZWQgYmVmb3JlIGVuY3J5cHRpb24uIEluIGZhY3QgdW5sZXNzIElQc2VjL0VTUCBpcyB1c2Vk IHdpdGggTlVMTCBlbmNyeXB0aW9uLCB0aGUgZGF0YSBpbiB0aGUgRVNQIHBhY2tldCBpcyBlbmNy eXB0ZWQuIEVuY3J5cHRpb24gbWFrZXMgY29tcHJlc3Npb24gaGFyZCB0byBwZXJmb3JtLiBJbnN0 ZWFkIGNvbXByZXNzaW5nIGJlZm9yZSBlbmNyeXB0aW5nIGNhbiBiZSB2ZXJ5IGVmZmljaWVudC4g VGhpcyBtYWtlcyBwb3NzaWJsZSB0byByZW1vdmUgVURQL1RQQy9JUCB0dW5uZWwgaGVhZGVycy4N CiAgICA1KSBkcmFmdC1tZ2x0LTZsby1kaWV0LWVzcC1jb250ZXh0LWlrZXYyLWV4dGVuc2lvbjxo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1nbHQtNmxvLWRpZXQtZXNwLWNv bnRleHQtaWtldjItZXh0ZW5zaW9uLz46IGRlc2NyaWJlcyBob3cgdG8gbmVnb2NpYXRlIERpZXQt RVNQIHdpdGggSUtFdjIuIEluIGZhY3QgdGhpcyBtb3N0bHkgcmVzdWx0IGluIGFuIGFncmVlbWVu dCBmb3IgdGhlIERJZXQtRVNQIENvbnRleHQuIFRoaXMgZXhjaGFuZ2UgbWF5IHRoZW4gYmUgZXh0 ZW5kZWQgdG8gRGlldC1ISVAgRXhjaGFuZ2UuDQpCUiwNCkRhbmllbA0KLS0NCkRhbmllbCBNaWdh dWx0DQpPcmFuZ2UgTGFicyAtLSBTZWN1cml0eQ0KKzMzIDYgNzAgNzIgNjkgNTgNCg== --_000_A113ACFD9DF8B04F96395BDEACB340420D03A28Exmbrcdx04ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SGVyZeKAmXMgYW4gaXNzdWUgd2l0aCB0aGlzIGRyYWZ0OyBpdCBk b2VzbuKAmXQgbWVldCB0aGUgcmVxdWlyZW1lbnRzIHRoYXQgaXQgY2xhaW1zLiZuYnNwOyBJbiBw YXJ0aWN1bGFyLCBpdCBjbGFpbXMgdGhhdCBpdCBpcyBiYXNlZCBvbiBzdGFuZGFyZCBJUHNlYywN CiBhbmQgdGhhdCBpdHMgc2VjdXJpdHkgaXMgZXF1aXZhbGVudCB0byBJUHNlYyAoUjEtUjMpLiZu YnNwOyBIb3dldmVyLCBpdCBhbGxvd3MgKGFuZCwgYXMgZmFyIGFzIEkgYW0gY29uY2VybmVkLCBl bmNvdXJhZ2VzKSB0aGUgdXNlIG9mIHRpbnkgSUNWczsgdGhlc2UgdGlueSBJQ1ZzIGludHJvZHVj ZSBzZWN1cml0eSB2dWxuZXJhYmlsaXRpZXMgdGhhdCBkbyBub3Qgb2NjdXIgd2l0aGluIHNhbmUg Y29uZmlndXJhdGlvbnMgb2YgSVBzZWMgKHdoZXJlIHNhbmUNCiBpbmNsdWRlcyB1c2luZyBhbiBp bnRlZ3JpdHkgdHJhbnNmb3JtKS4mbmJzcDsgSW4gcGFydGljdWxhciwgdXNpbmcgdGlueSBJQ1Zz IHdpdGggR0NNIGlzIGEga25vd24gc2VjdXJpdHkgaXNzdWUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPk5vdywgaXQgd291bGQgYmUgcG9zc2libGUgdG8gaGF2ZSBhbiBlbmNy eXB0aW9uIHByb3RvY29sIHRoYXQgd291bGQgbm90IGhhdmUgaXNzdWVzIHdpdGggc21hbGwgSUNW cyAoc2F5LCBieSB1c2luZyBhIHdpZGUgYmxvY2sgY2lwaGVyKTsgaG93ZXZlcg0KIHRoaXMgd291 bGQgYmUgcmF0aGVyIGRpZmZlcmVudCB0aGFuIHN0YW5kYXJkIElQc2VjIChpbiBwYXJ0IGJlY2F1 c2UgSVBzZWMgd2FzIG5ldmVyIGRlc2lnbmVkIHdpdGggdGhlc2UgbWluaW1hbCBiYW5kd2lkdGgg Y29uc3RyYWludHMpOyBlaXRoZXIgd2UgbmVlZCB0byBzdGF5IHdpdGggYW4gSVBzZWMtYmFzZWQg cHJvdG9jb2wgKHdoaWNoIGltcGxpZXMgYSBsYXJnaXNoIElDViksIG9yIGdvIHdpdGggc29tZXRo aW5nIGVsc2UgKHdoaWNoIHdvdWxkDQogaGF2ZSBsZXNzIG92ZXJoZWFkLCBidXQgZG9lc27igJl0 IGxvb2sgdGhhdCBtdWNoIGxpa2UgSVBzZWMgaW50ZXJuYWxseSkuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+T2gsIGFuZCBhIG1pbm9yIG5vdGUgb24gdGhlIElWIGdlbmVyYXRpb246IGl0 4oCZcyBhY3R1YWxseSBzZWN1cmUgdG8gdXNlIHRoZSBzYW1lIGtleSB5b3UgdXNlIHRvIGVuY3J5 cHQgdG8gZW5jcnlwdCB0aGUgY291bnRlciBmb3IgdGhlIElWOyB5b3UgZG9u4oCZdA0KIG5lZWQg YSBzZXBhcmF0ZSBrZXkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBJUHNlYyBbbWFpbHRvOmlwc2VjLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPkRhbmllbCBNaWdhdWx0PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRmVicnVhcnkgMTYs IDIwMTUgMTA6MDggUE08YnI+DQo8Yj5Ubzo8L2I+IDZsb0BpZXRmLm9yZzxicj4NCjxiPkNjOjwv Yj4gaXBzZWNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0lQc2VjXSBEaWV0LUVTUDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UgZmluZCB0 aGUgbmV3IHZlcnNpb24gb2YgRGlldC1FU1AgYSBjb21wcmVzcyBJUHNlYy9FU1AgZm9yIElvVC4g V2UgaGF2ZSBpbXBsZW1lbnRlZCBhbmQgdGVzdGVkIERpZXQtRVNQLiBDb21wYXJlZCB0byB0aGUg c3RhbmRhcmQgSVBzZWMvRVNQLCBEaWV0LUVTUCBjYW4gcmVkdWNlIHRoZSBuZXR3b3JraW5nIG92 ZXJoZWFkIGFkZGVkIHRvIHVucHJvdGVjdGVkIGRhdGEgZnJvbSAxMDAlIHRvIGEgZmV3DQogcGVy Y2VudC4gSSB3aWxsIGJlIGhhcHB5IHRvIHByZXNlbnQgdGhlc2UgZHJhZnQgbmV4dCBJRVRGLiA8 YnI+DQo8YnI+DQpGZWVsIGZyZWUgdG8gbWFrZSBjb21tZW50cyE8YnI+DQo8YnI+DQpUaGUgZHJh ZnRzIGluY2x1ZGVzOjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAxKSA8YSBocmVmPSJodHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1nbHQtNmxvLWRpZXQtZXNwLXJlcXVpcmVt ZW50cy8iPg0KZHJhZnQtbWdsdC02bG8tZGlldC1lc3AtcmVxdWlyZW1lbnRzPC9hPjogbGlzdHMg dGhlIHJlcXVpcmVtZW50cyBmb3IgRGlldC1FU1A8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyAyKSA8YSBocmVmPSJo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1nbHQtNmxvLWFlcy1pbXBsaWNp dC1pdi8iPg0KZHJhZnQtbWdsdC02bG8tYWVzLWltcGxpY2l0LWl2PC9hPjogaW5kaWNhdGVzIGhv dyB0byBhdm9pZCBjYXJyeWluZyB0aGUgSVYgaW4gZWFjaCBFU1AgcGFja2V0LiBJdCBpcyBpbnN0 ZWFkIGdlbmVyYXRlZCBieSBlYWNoIHBlZXJzLiBUaGUgcHJvdG9jb2xzIGRlc2NyaWJlZCBpbiB0 aGUgZHJhZnQgY2FuIGJlIHVzZWQgd2l0aCB0aGUgcmVndWxhciBJUHNlYy9FU1AuPGJyIGNsZWFy PSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IDMpIDxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtbWdsdC02bG8tZGlldC1lc3AvIj4NCmRyYWZ0LW1nbHQtNmxvLWRpZXQtZXNwPC9hPiBkZXNj cmliZXMgdGhlIGNvcmUgRGlldC1FU1AgcHJvdG9jb2wsIHRoYXQgaXMgaG93IHRvIGNvbXByZXNz L2RlY29tcHJlc3MgZWFjaCBmaWVsZHMgb2YgdGhlIHN0YW5kYXJkIElQc2VjL0VTUC4gQ29tcHJl c3Npb24gaXMgZGlzY3JpYmVkIHRocm91Z2ggYSBEaWV0LUVTUCBDb250ZXh0Ljxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyA0KSA8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LW1nbHQtNmxvLWRpZXQtZXNwLXBheWxvYWQtY29tcHJlc3Npb24vIj4NCmRyYWZ0LW1n bHQtNmxvLWRpZXQtZXNwLXBheWxvYWQtY29tcHJlc3Npb248L2E+OiBkZXNjcmliZXMgaG93IHRo ZSBjbGVhciB0ZXh0IGNhbiBiZSBjb21wcmVzc2VkIGJlZm9yZSBlbmNyeXB0aW9uLiBJbiBmYWN0 IHVubGVzcyBJUHNlYy9FU1AgaXMgdXNlZCB3aXRoIE5VTEwgZW5jcnlwdGlvbiwgdGhlIGRhdGEg aW4gdGhlIEVTUCBwYWNrZXQgaXMgZW5jcnlwdGVkLiBFbmNyeXB0aW9uIG1ha2VzIGNvbXByZXNz aW9uIGhhcmQgdG8gcGVyZm9ybS4NCiBJbnN0ZWFkIGNvbXByZXNzaW5nIGJlZm9yZSBlbmNyeXB0 aW5nIGNhbiBiZSB2ZXJ5IGVmZmljaWVudC4gVGhpcyBtYWtlcyBwb3NzaWJsZSB0byByZW1vdmUg VURQL1RQQy9JUCB0dW5uZWwgaGVhZGVycy48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgNSkgPGEg aHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tZ2x0LTZsby1kaWV0 LWVzcC1jb250ZXh0LWlrZXYyLWV4dGVuc2lvbi8iPg0KZHJhZnQtbWdsdC02bG8tZGlldC1lc3At Y29udGV4dC1pa2V2Mi1leHRlbnNpb248L2E+OiBkZXNjcmliZXMgaG93IHRvIG5lZ29jaWF0ZSBE aWV0LUVTUCB3aXRoIElLRXYyLiBJbiBmYWN0IHRoaXMgbW9zdGx5IHJlc3VsdCBpbiBhbiBhZ3Jl ZW1lbnQgZm9yIHRoZSBESWV0LUVTUCBDb250ZXh0LiBUaGlzIGV4Y2hhbmdlIG1heSB0aGVuIGJl IGV4dGVuZGVkIHRvIERpZXQtSElQIEV4Y2hhbmdlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QlIsIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGFuaWVsPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5EYW5pZWwgTWlnYXVsdDxicj4NCk9yYW5nZSBMYWJzIC0tIFNl Y3VyaXR5PGJyPg0KJiM0MzszMyA2IDcwIDcyIDY5IDU4PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_A113ACFD9DF8B04F96395BDEACB340420D03A28Exmbrcdx04ciscoc_-- From nobody Tue Feb 17 07:48:07 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753771A8A94; Tue, 17 Feb 2015 07:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97c88HYhq1mM; Tue, 17 Feb 2015 07:47:52 -0800 (PST) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (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 07C7D1A8A85; Tue, 17 Feb 2015 07:47:48 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id k14so33612208wgh.4; Tue, 17 Feb 2015 07:47:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F2maoaXMwY/sh3mUvMLo/BYEqNbqJMq1H9xKz1qhe08=; b=XZ58HjwCEl399OVg6RsX9wAKrDJCrXdrrJoG/uWG710NdWgtm0YnSnXnq7X/CL8xZE qrw2xvHi6xPDSB7V+7ViwjQdaTztCU0hEmWk/p5ZAbYUsjOSQZwu1Z/Ldc2Uq6TxHImo jZbzldAgcNFRzc4TlTeRqjMQBysMuZPf4igVHkeobqp9GFU9c1uJMMxuOslHMFLLHKJu kucrsQ7NnxUatX21GaHwMqPGKnQ4qgDELsew59ZLR2HOEVT8hsOlVXzFSZ24dIcPrRj3 +Y2BPx1XpZXSMyggGN7gck9naPF6uXl34w66XuTIl6PgHQvMtjNFzjl8oAGTUxPPTIQL tSHg== MIME-Version: 1.0 X-Received: by 10.180.189.203 with SMTP id gk11mr57881479wic.32.1424188066794; Tue, 17 Feb 2015 07:47:46 -0800 (PST) Received: by 10.194.68.39 with HTTP; Tue, 17 Feb 2015 07:47:46 -0800 (PST) In-Reply-To: References: Date: Tue, 17 Feb 2015 16:47:46 +0100 Message-ID: From: Daniel Migault To: "Scott Fluhrer (sfluhrer)" Content-Type: multipart/alternative; boundary=001a11c32576d09388050f4a9fa6 Archived-At: Cc: "ipsec@ietf.org" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [IPsec] Diet-ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 15:48:00 -0000 --001a11c32576d09388050f4a9fa6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Scott, Thank you for the feed back. I agree that compressing the ICV reduces security related to authentication. Let's call this a "weak authentication". I am not saying it is a valid argument, but since IPsec enables NULL authentication too, we considered that enabling "weak authentication" would be possible with a clear warning in the security consideration. The reason we are looking we are looking for weak authentication is to be able to balance authentication with bandwidth optimization. In fact, suppose you compute the mean/median over a thousand different value, that one or two values are corrupted may not have much impact overall, and we may prefer to extend the life time of the mote for 5 years instead. Regarding you comment I think the issue ou raised is more related to GCM. -- By the way I would be interested to have a description or relevant doc describing why ICV in GCM particularly matters. One way to address the issue you raised would be: - 1) mention the need for weak authentication in the requirement draft - 2) remove ICV compression from Diet-ESP - 3) Define encryption protocols with weak authentication with different sizes of the ICV. For example suppose AES-MODEX has an ICV of N, then we may need to add AES-MODEX_i with i in [0 ... N-1]. The advantage of doing so is that it avoids end user to weaken the protocols especially when one compression is fine with one protocol but not with the others. In that sense it looks a better design. However, I see the following drawbacks: - It requires to create multiple encryption protocols. Unlike compression, implementation cannot use existing implementation of AES-MODEX= . - Negociation for hosts accepting all AES-MODEX_i with i in [0 ... N-1] requires many SA payload in the IKEv2 negotiation. However, we may deal with this with a AES-MODEX_ALL to indicate the responder choses its compression. BR, Daniel On Tue, Feb 17, 2015 at 6:28 AM, Scott Fluhrer (sfluhrer) < sfluhrer@cisco.com> wrote: > Here=E2=80=99s an issue with this draft; it doesn=E2=80=99t meet the req= uirements that > it claims. In particular, it claims that it is based on standard IPsec, > and that its security is equivalent to IPsec (R1-R3). However, it allows > (and, as far as I am concerned, encourages) the use of tiny ICVs; these > tiny ICVs introduce security vulnerabilities that do not occur within san= e > configurations of IPsec (where sane includes using an integrity > transform). In particular, using tiny ICVs with GCM is a known security > issue. > > > > Now, it would be possible to have an encryption protocol that would not > have issues with small ICVs (say, by using a wide block cipher); however > this would be rather different than standard IPsec (in part because IPsec > was never designed with these minimal bandwidth constraints); either we > need to stay with an IPsec-based protocol (which implies a largish ICV), = or > go with something else (which would have less overhead, but doesn=E2=80= =99t look > that much like IPsec internally). > > > > > > Oh, and a minor note on the IV generation: it=E2=80=99s actually secure t= o use the > same key you use to encrypt to encrypt the counter for the IV; you don=E2= =80=99t > need a separate key. > > > > *From:* IPsec [mailto:ipsec-bounces@ietf.org] *On Behalf Of *Daniel > Migault > *Sent:* Monday, February 16, 2015 10:08 PM > *To:* 6lo@ietf.org > *Cc:* ipsec@ietf.org > *Subject:* [IPsec] Diet-ESP > > > > Please find the new version of Diet-ESP a compress IPsec/ESP for IoT. We > have implemented and tested Diet-ESP. Compared to the standard IPsec/ESP, > Diet-ESP can reduce the networking overhead added to unprotected data fro= m > 100% to a few percent. I will be happy to present these draft next IETF. > > Feel free to make comments! > > The drafts includes: > 1) draft-mglt-6lo-diet-esp-requirements > : > lists the requirements for Diet-ESP > > 2) draft-mglt-6lo-aes-implicit-iv > : > indicates how to avoid carrying the IV in each ESP packet. It is instead > generated by each peers. The protocols described in the draft can be used > with the regular IPsec/ESP. > > 3) draft-mglt-6lo-diet-esp > describes the > core Diet-ESP protocol, that is how to compress/decompress each fields of > the standard IPsec/ESP. Compression is discribed through a Diet-ESP Conte= xt. > 4) draft-mglt-6lo-diet-esp-payload-compression > : > describes how the clear text can be compressed before encryption. In fact > unless IPsec/ESP is used with NULL encryption, the data in the ESP packet > is encrypted. Encryption makes compression hard to perform. Instead > compressing before encrypting can be very efficient. This makes possible = to > remove UDP/TPC/IP tunnel headers. > 5) draft-mglt-6lo-diet-esp-context-ikev2-extension > : > describes how to negociate Diet-ESP with IKEv2. In fact this mostly resul= t > in an agreement for the DIet-ESP Context. This exchange may then be > extended to Diet-HIP Exchange. > > BR, > > Daniel > > -- > > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 > --=20 Daniel Migault Ericsson --001a11c32576d09388050f4a9fa6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Scott= ,

Thank you for the feed back. I agree that compressing the I= CV reduces security related to authentication. Let's call this a "= weak authentication".=C2=A0

I am not saying it is a vali= d argument, but since IPsec enables NULL authentication too, we considered = that enabling "weak authentication" would be possible with a clea= r warning in the security consideration.

The reason we a= re looking we are looking for weak authentication is to be able to balance = authentication with bandwidth optimization. In fact, suppose you compute th= e mean/median over a thousand different value, that one or two values are c= orrupted may not have much impact overall, and we may prefer to extend the = life time of the mote for 5 years instead.
=C2=A0
Regarding you= comment I think the issue ou raised is more related to GCM. -- By the way = I would be interested to have a description or relevant doc describing=C2= =A0 why ICV in GCM particularly matters. One way to address the issue you r= aised would be:
=C2=A0=C2=A0=C2=A0 - 1) mention the need for weak = authentication in the requirement draft
=C2=A0=C2=A0=C2=A0 - 2) re= move ICV compression from Diet-ESP
=C2=A0 =C2=A0 - 3) Define encry= ption protocols with weak authentication with different sizes of the ICV. F= or example suppose AES-MODEX has an ICV of N, then we may need to add AES-M= ODEX_i with i in [0 ... N-1].

The advantage of doing so i= s that it avoids end user to weaken the protocols especially when one compr= ession is fine with one protocol but not with the others. In that sense it = looks a better design.

However, I see the following drawbacks:=
=C2=A0=C2=A0=C2=A0 - It requires to create multiple encryption pr= otocols. Unlike compression, implementation cannot use existing implementat= ion of AES-MODEX.
=C2=A0=C2=A0=C2=A0 - Negociation for hosts accep= ting all AES-MODEX_i with i in [0 ... N-1] requires many SA payload in the = IKEv2 negotiation. However, we may deal with this with a AES-MODEX_ALL to i= ndicate the responder choses its compression.
=C2=A0=C2=A0=C2=A0
BR,
Daniel

On Tue, Feb 17, 2015 at 6:28 AM, Scott Fluhrer (sfluhrer) <sflu= hrer@cisco.com> wrote:

Here=E2=80= =99s an issue with this draft; it doesn=E2=80=99t meet the requirements tha= t it claims.=C2=A0 In particular, it claims that it is based on standard IP= sec, and that its security is equivalent to IPsec (R1-R3).=C2=A0 However, it al= lows (and, as far as I am concerned, encourages) the use of tiny ICVs; thes= e tiny ICVs introduce security vulnerabilities that do not occur within san= e configurations of IPsec (where sane includes using an integrity transform).=C2=A0 In particular, using tiny IC= Vs with GCM is a known security issue.

=C2= =A0

Now, it wo= uld be possible to have an encryption protocol that would not have issues w= ith small ICVs (say, by using a wide block cipher); however this would be rather different than standard IPsec (in part because IPsec = was never designed with these minimal bandwidth constraints); either we nee= d to stay with an IPsec-based protocol (which implies a largish ICV), or go= with something else (which would have less overhead, but doesn=E2=80=99t look that much like IPsec internal= ly).

=C2= =A0

=C2= =A0

Oh, and a = minor note on the IV generation: it=E2=80=99s actually secure to use the sa= me key you use to encrypt to encrypt the counter for the IV; you don=E2=80= =99t need a separate key.

=C2=A0

From: IPsec [m= ailto:ipsec-bou= nces@ietf.org] On Behalf Of Daniel Migault
Sent: Monday, February 16, 2015 10:08 PM
To: 6lo@ietf.org
Cc: ipsec@ietf.o= rg
Subject: [IPsec] Diet-ESP

=C2=A0

Please find the new version of Diet-ESP a compress I= Psec/ESP for IoT. We have implemented and tested Diet-ESP. Compared to the = standard IPsec/ESP, Diet-ESP can reduce the networking overhead added to un= protected data from 100% to a few percent. I will be happy to present these draft next IETF.

Feel free to make comments!

The drafts includes:
=C2=A0=C2=A0=C2=A0 1) draft-mglt-6lo-diet-esp-requirements: lists the requirements for Diet-E= SP

=C2=A0=C2=A0=C2=A0 2) draft-mglt-6lo-aes-implicit-iv: indicates how to avoid carrying the IV = in each ESP packet. It is instead generated by each peers. The protocols de= scribed in the draft can be used with the regular IPsec/ESP.

=C2=A0=C2=A0=C2=A0 3)= draft-mglt-6lo-diet-esp describes the core Diet-ESP protocol, that is h= ow to compress/decompress each fields of the standard IPsec/ESP. Compressio= n is discribed through a Diet-ESP Context.
=C2=A0=C2=A0=C2=A0 4) draft-mglt-6lo-diet-esp-payload-compression: describes how the clear te= xt can be compressed before encryption. In fact unless IPsec/ESP is used wi= th NULL encryption, the data in the ESP packet is encrypted. Encryption mak= es compression hard to perform. Instead compressing before encrypting can be very efficient. This makes po= ssible to remove UDP/TPC/IP tunnel headers.
=C2=A0=C2=A0=C2=A0 5) draft-mglt-6lo-diet-esp-context-ikev2-extension: describes how to negoc= iate Diet-ESP with IKEv2. In fact this mostly result in an agreement for th= e DIet-ESP Context. This exchange may then be extended to Diet-HIP Exchange= .

BR,

Daniel

--

Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58




--
Daniel Migault
Ericsson
--001a11c32576d09388050f4a9fa6-- From nobody Tue Feb 17 08:10:06 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC30A1A889C; Tue, 17 Feb 2015 08:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u88A76duFmCv; Tue, 17 Feb 2015 08:10:03 -0800 (PST) Received: from ausxipps301.us.dell.com (ausxipps301.us.dell.com [143.166.148.223]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DACBB1A8ABB; Tue, 17 Feb 2015 08:08:03 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:Return-Path; b=WEzWSDhktlTLTx/ZDojoepGbtrR8xBnwvZu7NB4klK+R3II7qqd9G4Ga ca3/mM7zn9ljnirbktZz8fJ9OJztkUGrM3E+JGIvz6WCs9YW2KhN1YimU d4YbwlJCt/CAuScoI0bGFtA6CWbO72cSfmdrRCOJPMNSUhpGsdQVsIAlV g=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1424189283; x=1455725283; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1JYE7GHeQpy1pmUXopi9fw0xolfp5UXsiOljQCn3LbI=; b=kUWS8NGnWUtGKfbReVasvBarBhwRbmZ0YkdwIBSyjCDJCbYQ/+60ytum 7S+6cjYzC5fvQz0z8eo4hMI6wOuHXqNJTdXJh9+ZGM40x26fgJ21kVLvZ BWm2Z88n7qupcQ5e7xT+5DcxKK8e9LI0KttcF4YnGDkJnqh2FdOwDRywH Q=; X-LoopCount0: from 10.175.216.249 X-IronPort-AV: E=Sophos;i="5.09,595,1418104800"; d="scan'208";a="622861602" From: To: Thread-Topic: [IPsec] Diet-ESP Thread-Index: AQHQSl75xE+o8+vV1EeSaJw0LSQ4lZz0tNgAgACtJQCAAAWYAA== Date: Tue, 17 Feb 2015 16:07:49 +0000 Message-ID: <94FE1E20-DE32-4515-AF79-5B9D8F0769E0@dell.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.132.132] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: ipsec@ietf.org, 6lo@ietf.org, sfluhrer@cisco.com Subject: Re: [IPsec] Diet-ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 16:10:05 -0000 DQo+IE9uIEZlYiAxNywgMjAxNSwgYXQgMTA6NDcgQU0sIERhbmllbCBNaWdhdWx0IDxtZ2x0Lmll dGZAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IEhpIFNjb3R0LCANCj4gDQo+IFRoYW5rIHlvdSBm b3IgdGhlIGZlZWQgYmFjay4gSSBhZ3JlZSB0aGF0IGNvbXByZXNzaW5nIHRoZSBJQ1YgcmVkdWNl cyBzZWN1cml0eSByZWxhdGVkIHRvIGF1dGhlbnRpY2F0aW9uLiBMZXQncyBjYWxsIHRoaXMgYSAi d2VhayBhdXRoZW50aWNhdGlvbiIuICANCj4gDQo+IEkgYW0gbm90IHNheWluZyBpdCBpcyBhIHZh bGlkIGFyZ3VtZW50LCBidXQgc2luY2UgSVBzZWMgZW5hYmxlcyBOVUxMIGF1dGhlbnRpY2F0aW9u IHRvbywgd2UgY29uc2lkZXJlZCB0aGF0IGVuYWJsaW5nICJ3ZWFrIGF1dGhlbnRpY2F0aW9uIiB3 b3VsZCBiZSBwb3NzaWJsZSB3aXRoIGEgY2xlYXIgd2FybmluZyBpbiB0aGUgc2VjdXJpdHkgY29u c2lkZXJhdGlvbi4gDQoNClRoYXQgaXMgbm90IGEgdmFsaWQgYW5hbG9neS4gIE5VTEwgYXV0aGVu dGljYXRpb24gc3BlY2lmaWNhbGx5IGRlbGl2ZXJzIG5vIGF1dGhlbnRpY2F0aW9uIGF0IGFsbC4g IFRoZSBzZWN1cml0eSBwcm9wZXJ0aWVzIG9mIOKAnG5vIGF1dGhlbnRpY2F0aW9u4oCdIGFyZSBy ZWFzb25hYmx5IG9idmlvdXMgZXZlbiB0byBwZW9wbGUgbm90IHNraWxsZWQgaW4gY3J5cHRvZ3Jh cGh5Lg0KDQpPbiB0aGUgb3RoZXIgaGFuZCwgd2VhayBhdXRoZW50aWNhdGlvbiBjYW4gZWFzaWx5 IGJlIG1pc3Rha2VuIGZvciByZWFsIGF1dGhlbnRpY2F0aW9uLCBpbiB0aGUgc2FtZSB3YXkgdGhh dCBERVMgKG9yIHdvcnNlIHlldCwgREVTLTQwKSB3YXMgaW4gdGhlIHBhc3QgbWlzdGFrZW4gZm9y IHJlYWwgY29uZmlkZW50aWFsaXR5LiAgSWYgd2UgYnVpbGQgYSBzeXN0ZW0gd2l0aCB3ZWFrIHNl Y3VyaXR5IHByb3BlcnRpZXMsIHdlIHJ1biB0aGUgdmVyeSByZWFsIHJpc2sgdGhhdCBpdCBtYXkg ZW5kIHVwIGJlaW5nIHdpZGVseSB1c2VkIOKAnHRvIHNhdmUgYmFuZHdpZHRo4oCdLCB3aGVuIGlu IGZhY3QgaXQgc2hvdWxkIGJlIGNvbnNpZGVyZWQgYXMgYSBuaWNoZSBzb2x1dGlvbiB0aGF0IGlz IG9ubHkgdmFsaWQgZm9yIGV4dHJlbWVseSB1bnVzdWFsIHNjZW5hcmlvcy4gIEl04oCZcyBub3Qg Y2xlYXIgdG8gbWUgdGhhdCBhIG5vdGUgaW4gdGVoIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNl Y3Rpb24gd2lsbCBiZSBzdWZmaWNpZW50Lg0KDQoJcGF1bA0KDQo= From nobody Tue Feb 17 08:30:38 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27EA21A8904; Tue, 17 Feb 2015 08:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqcqxKrjJLyA; Tue, 17 Feb 2015 08:30:35 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (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 473031A1B13; Tue, 17 Feb 2015 08:30:35 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id r20so34898289wiv.2; Tue, 17 Feb 2015 08:30:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mF3HurQSYvSCLMrz7lhpdpPS9G+Vhb5gTUxGmQ7t1RM=; b=uH7IpbYWXpp9SGlIn1Rxj25Bi0jW4ZK977BNngF0hf+znZeRQkcT6C5pTsxx29dduO ueZuZoPqkHOT6nTIhuPjNx7Iz6aLnGjD51aLSDoYa/XLF4gDdZZ87cbV6MFRq7n70bn/ CtkoeQQbaLUky2fJwo+7VN7nlwXS19aYyrBra+SVKsAZcqISoQpjW9FUMizcAC0bFFu4 0ieIsTkLlvYHUOZKMEFTs6G7BST/Cb4e/8DhWy6v0WhX0+daVRi1gsWawhp6+jRGHigW WZuDxR5l4t565NCruYAiRibqFr3hcSd/GBK3bU6nRBRjbGrgb9sqJYUvzRJF/flYtiS8 x/hw== MIME-Version: 1.0 X-Received: by 10.180.189.203 with SMTP id gk11mr58239194wic.32.1424190633911; Tue, 17 Feb 2015 08:30:33 -0800 (PST) Received: by 10.194.68.39 with HTTP; Tue, 17 Feb 2015 08:30:33 -0800 (PST) In-Reply-To: <94FE1E20-DE32-4515-AF79-5B9D8F0769E0@dell.com> References: <94FE1E20-DE32-4515-AF79-5B9D8F0769E0@dell.com> Date: Tue, 17 Feb 2015 17:30:33 +0100 Message-ID: From: Daniel Migault To: Paul_Koning@dell.com Content-Type: multipart/alternative; boundary=001a11c32576d3b056050f4b3873 Archived-At: Cc: "ipsec@ietf.org" , "6lo@ietf.org" <6lo@ietf.org>, "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Diet-ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 16:30:37 -0000 --001a11c32576d3b056050f4b3873 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Do you have any opinion on the proposed alternative? - 1) mention the need for weak authentication in the requirement draft - 2) remove ICV compression from Diet-ESP - 3) Define encryption protocols with "weak authentication" with different sizes of the ICV. For example suppose AES-MODEX has an ICV of N, then we may need to add AES-MODEX_i with i in [0 ... N-1]. BR, Daniel On Tue, Feb 17, 2015 at 5:07 PM, wrote: > > > On Feb 17, 2015, at 10:47 AM, Daniel Migault > wrote: > > > > Hi Scott, > > > > Thank you for the feed back. I agree that compressing the ICV reduces > security related to authentication. Let's call this a "weak authenticatio= n". > > > > I am not saying it is a valid argument, but since IPsec enables NULL > authentication too, we considered that enabling "weak authentication" wou= ld > be possible with a clear warning in the security consideration. > > That is not a valid analogy. NULL authentication specifically delivers n= o > authentication at all. The security properties of =E2=80=9Cno authentica= tion=E2=80=9D are > reasonably obvious even to people not skilled in cryptography. > > On the other hand, weak authentication can easily be mistaken for real > authentication, in the same way that DES (or worse yet, DES-40) was in th= e > past mistaken for real confidentiality. If we build a system with weak > security properties, we run the very real risk that it may end up being > widely used =E2=80=9Cto save bandwidth=E2=80=9D, when in fact it should b= e considered as a > niche solution that is only valid for extremely unusual scenarios. It=E2= =80=99s > not clear to me that a note in teh security considerations section will b= e > sufficient. > > paul > > --=20 Daniel Migault Ericsson --001a11c32576d3b056050f4b3873 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Do you have any opinion o= n the proposed alternative?

=C2=A0=C2=A0=C2=A0 - 1) mention the need= for weak authentication in the requirement draft
=C2=A0=C2=A0=C2=A0 - 2= ) remove ICV compression from Diet-ESP
=C2=A0 =C2=A0 - 3) Define encryption protocols with "weak authentication&quo= t; with=20 different sizes of the ICV. For example suppose AES-MODEX has an ICV of=20 N, then we may need to add AES-MODEX_i with i in [0 ... N-1].

= BR,
Daniel

On Tue, Feb 17, 2015 at 5:07 PM, <Paul_Koning@dell.com> wrote:

> On Feb 17, 2015, at 10:47 AM, Daniel Migault <mglt.ietf@gmail.com> wrote:
>
> Hi Scott,
>
> Thank you for the feed back. I agree that compressing the ICV reduces = security related to authentication. Let's call this a "weak authen= tication".
>
> I am not saying it is a valid argument, but since IPsec enables NULL a= uthentication too, we considered that enabling "weak authentication&qu= ot; would be possible with a clear warning in the security consideration.
That is not a valid analogy.=C2=A0 NULL authentication specifically = delivers no authentication at all.=C2=A0 The security properties of =E2=80= =9Cno authentication=E2=80=9D are reasonably obvious even to people not ski= lled in cryptography.

On the other hand, weak authentication can easily be mistaken for real auth= entication, in the same way that DES (or worse yet, DES-40) was in the past= mistaken for real confidentiality.=C2=A0 If we build a system with weak se= curity properties, we run the very real risk that it may end up being widel= y used =E2=80=9Cto save bandwidth=E2=80=9D, when in fact it should be consi= dered as a niche solution that is only valid for extremely unusual scenario= s.=C2=A0 It=E2=80=99s not clear to me that a note in teh security considera= tions section will be sufficient.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 paul




--
Daniel Migault
Ericsson
--001a11c32576d3b056050f4b3873-- From nobody Tue Feb 17 08:37:59 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198A11A8893; Tue, 17 Feb 2015 08:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvNJ16G7yOxW; Tue, 17 Feb 2015 08:37:56 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11E9E1A1EF4; Tue, 17 Feb 2015 08:37:55 -0800 (PST) Received: from [192.168.131.128] ([80.92.119.127]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LdHLB-1Xfalc2DlR-00iPVq; Tue, 17 Feb 2015 17:37:53 +0100 Message-ID: <54E36E1F.60203@gmx.net> Date: Tue, 17 Feb 2015 17:36:47 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: 6lo@ietf.org, ipsec@ietf.org References: In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cnENBWtvgo849icUfbTH6unTu2QtcWidK" X-Provags-ID: V03:K0:JyBNNr2vtPhjRuTIamh4bP+sFwLkItNR8qEvs68pTTKsrVpCvE1 KvQJdheFvmVzCZWJJpsp1OEnVH41Ey9WnMTFxN1fF6ROXfG6VyZJ8T/GKE9NkQejl/CUW5c nkS0XCGBQcpLxzg6cn41WmsL0xOP9qEG9P40qo1zdfnvokuI/+lQasJNxOPEKAlj1gp3ks2 B/TQLaTybCUuJKMvw9gWQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Daniel Migault Subject: Re: [IPsec] Diet-ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 16:37:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cnENBWtvgo849icUfbTH6unTu2QtcWidK Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Daniel, I understand that you spend a lot of time in writing these specifications but, as mentioned in the past I just do not see the need for this type of standardization activity. Nobody I have spoken with asks for this functionality. If there is indeed a need for IPsec ESP use in IoT then I am not sure that the proposed optimizations are so useful given the impact for security. Ciao Hannes On 02/17/2015 04:08 AM, Daniel Migault wrote: > Please find the new version of Diet-ESP a compress IPsec/ESP for IoT. W= e > have implemented and tested Diet-ESP. Compared to the standard > IPsec/ESP, Diet-ESP can reduce the networking overhead added to > unprotected data from 100% to a few percent. I will be happy to present= > these draft next IETF. >=20 > Feel free to make comments! >=20 > The drafts includes: > 1) draft-mglt-6lo-diet-esp-requirements > = : > lists the requirements for Diet-ESP > 2) draft-mglt-6lo-aes-implicit-iv > : > indicates how to avoid carrying the IV in each ESP packet. It is instea= d > generated by each peers. The protocols described in the draft can be > used with the regular IPsec/ESP. > 3) draft-mglt-6lo-diet-esp > describes th= e > core Diet-ESP protocol, that is how to compress/decompress each fields > of the standard IPsec/ESP. Compression is discribed through a Diet-ESP > Context. > 4) draft-mglt-6lo-diet-esp-payload-compression > : > describes how the clear text can be compressed before encryption. In > fact unless IPsec/ESP is used with NULL encryption, the data in the ESP= > packet is encrypted. Encryption makes compression hard to perform. > Instead compressing before encrypting can be very efficient. This makes= > possible to remove UDP/TPC/IP tunnel headers. > 5) draft-mglt-6lo-diet-esp-context-ikev2-extension > : > describes how to negociate Diet-ESP with IKEv2. In fact this mostly > result in an agreement for the DIet-ESP Context. This exchange may then= > be extended to Diet-HIP Exchange. >=20 > BR, > Daniel > --=20 > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 --cnENBWtvgo849icUfbTH6unTu2QtcWidK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU424fAAoJEGhJURNOOiAt4AQIAJywcOxUJosy9SuXXSUq2VcC haXcpnMLtraClPFiah45cOQVwTpPlG/4J+D3dIW8mA6LncZYY4lLoKSN/wCm92mb OrjknncFoXRqe16PEfoXTPyRJNq4FJMS+0gQrPxdsyQwRB0YdHhBjFSmzlppVre2 rFdksvAZ1kgdP8XI8O3UiL3rkVs/Ni4IaquoqLgFcR2ElXF3LOvCAdmnd2kfC5e6 cURnNNGCE4FZPWQXK22WfrhUCfEuMrAidJBnHGs4EM1HUUmnQ3t6sY4GYihr3Z/9 NqG3As7WLjGJgWwThlERq49RE6MP4iH65FnfGZkC8cakglW8TGLt2qAyCZruxWg= =7Xi8 -----END PGP SIGNATURE----- --cnENBWtvgo849icUfbTH6unTu2QtcWidK-- From nobody Tue Feb 17 10:33:10 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F013B1A900B; Tue, 17 Feb 2015 10:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBJm9QMGHSI2; Tue, 17 Feb 2015 10:33:06 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A42B71A9008; Tue, 17 Feb 2015 10:33:02 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kmrQg6gRbzCg9; Tue, 17 Feb 2015 19:32:59 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=UK1iLBva; dkim-adsp=pass X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id b2_hwG0ti81h; Tue, 17 Feb 2015 19:32:59 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 17 Feb 2015 19:32:59 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 233DD8324E; Tue, 17 Feb 2015 13:32:58 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1424197978; bh=atDvjhic0tQ2nGPNJI4D1UMh3DtXDBTu8cl8E+dcH/U=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=UK1iLBvaVZI/Q0cwYWJt1nykLf5FUmJm96nfrjykqhhd3hhQ4OH2AcCsd2vCLfsNh NRwogkI0c9xBsD1PB5+qV00WzMsYR1hov6SVGJlB3++2imzL/k06wJ16yM+ng6oZ/S +X9hbdhJTIfbL49knjaFy0bVgEZ13z1fuFlcM7q0= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t1HIWvI5013589; Tue, 17 Feb 2015 13:32:57 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 17 Feb 2015 13:32:57 -0500 (EST) From: Paul Wouters To: Hannes Tschofenig In-Reply-To: <54E36E1F.60203@gmx.net> Message-ID: References: <54E36E1F.60203@gmx.net> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org, Daniel Migault , 6lo@ietf.org Subject: Re: [IPsec] Diet-ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 18:33:09 -0000 On Tue, 17 Feb 2015, Hannes Tschofenig wrote: > If there is indeed a need for IPsec ESP use in IoT then I am not sure > that the proposed optimizations are so useful given the impact for > security. I agree. I think it would be very useful to describe a barebones minimal IKEv2 feature set and even an ESP minimal set for such use, but tweaking a byte here and there of the ESP protocol parameters makes we very nervous. Paul From nobody Tue Feb 17 13:17:28 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58B51A90C4; Tue, 17 Feb 2015 13:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOyIz0slwvIO; Tue, 17 Feb 2015 13:17:14 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65BD21A90BC; Tue, 17 Feb 2015 13:17:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35802; q=dns/txt; s=iport; t=1424207833; x=1425417433; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tTYFMn85SuGKj+GwZ05efvvU4SsM8gjAlGcGegjc748=; b=VV8+gezSPhnTEELnIhudE5wrBYsBP6vEihLKFYXsSvk9y0Kgr7PPbHbF tbsxrSKMqZ47tAYGDzV/2IjbFLGtEfg18UPmlAlG1hi6ZjBSWGjgmokzh 9YD8ve+E7jPxN/V4O3pDiqNFQJ80c4XA+N20lP9dX/CGnHfitj32blbsk 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AHBwCrruNU/4cNJK1bgkNDUloEgn+wHo1DgXCFbwIcf0MBAQEBAQF8hAwBAQECAg4VCjgUEAIBCA4DBAEBCxYHAwICAh8RFAkIAgQOBQgRBod8AxENuTOSMQ2FNAEBAQEBAQEBAQEBAQEBAQEBAQEBAReLD4JEgUcyFhsGAYJoLoEUBY1MgWyDV4Qagl44glWIZIYEIoNubwEBAQGBQH8BAQE X-IronPort-AV: E=Sophos;i="5.09,595,1418083200"; d="scan'208,217";a="124398236" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-8.cisco.com with ESMTP; 17 Feb 2015 21:17:12 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t1HLHCXX017269 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Feb 2015 21:17:12 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.248]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Tue, 17 Feb 2015 15:17:12 -0600 From: "Scott Fluhrer (sfluhrer)" To: Daniel Migault Thread-Topic: [IPsec] Diet-ESP Thread-Index: AQHQSl8D8Q49UimlJk+ag/Gqzu2LiJz0RjGwgAEbzAD//++owA== Date: Tue, 17 Feb 2015 21:17:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.216] Content-Type: multipart/alternative; boundary="_000_A113ACFD9DF8B04F96395BDEACB340420D03A72Fxmbrcdx04ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [IPsec] Diet-ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 21:17:21 -0000 --_000_A113ACFD9DF8B04F96395BDEACB340420D03A72Fxmbrcdx04ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T3RoZXJzIGhhdmUgYWRkcmVzc2VkIG15IG90aGVyIHBvaW50czsgbGV0IG1lIHRhbGsgYWJvdXQg dGhlIHNwZWNpZmljIGlzc3VlcyB3aXRoIEdDTS4NCg0KT25lIHN1bW1hcnkgb2YgdGhlIGlzc3Vl cyBmb3VuZCBpcyBodHRwOi8vY2l0ZXNlZXJ4LmlzdC5wc3UuZWR1L3ZpZXdkb2MvZG93bmxvYWQ/ ZG9pPTEwLjEuMS4yOTcuOTU2OCZyZXA9cmVwMSZ0eXBlPXBkZiA7IHRoZSBwcm9ibGVtIHdpdGgg R0NNIGlzIHRoYXQ6DQoNCi0gICAgICAgICAgV2l0aCBvbmUgc3VjY2Vzc2Z1bCBmb3JnZXJ5LCB0 aGUgYXR0YWNrZXIgY2FuIG1vZGlmeSBvdGhlciBwYWNrZXRzIHRoZSBzYW1lIHdheSB3aXRob3V0 IGRldGVjdGlvbi4NCg0KLSAgICAgICAgICBXaXRoIGEgaGFuZGZ1bCBvZiBzdWNjZXNzZnVsIGZv cmdlcmllcywgdGhlIGF0dGFja2VyIGNhbiBsZWFybiBlbm91Z2ggdG8gYmUgYWJsZSB0byBmb3Jn ZSBhcmJpdHJhcnkgbWVzc2FnZXMuDQpOb3csIHdpdGggdGhlIGZ1bGwgMTYgYnl0ZSBJQ1YsIHRo aXMgaXMgbm90IGEgY29uY2VybiAoYmVjYXVzZSB0aGUgcHJvYmFiaWxpdHkgb2YgdGhlIGF0dGFj a2VyIGZpbmRpbmcgb25lIHN1Y2Nlc3NmdWwgZm9yZ2VyeSBpcyB0aW55KTsgaG93ZXZlciBvbmNl IHlvdSBzdGFydCByZWR1Y2luZyB0aGUgSUNWIHZhbHVlLCB3ZWxsLCB2YXJpb3VzIGd1ZXNzaW5n IHN0cmF0ZWdpZXMgc3RhcnQgd29ya2luZyBiZXR0ZXIuDQoNCk5vdywgbmVpdGhlciBITUFDIG5v ciBDTUFDIGhhcyB0aGlzIHByb2JsZW07IHllcywgd2l0aCBhIHRpbnkgSUNWLCBzb21lb25lIGNh biBnZW5lcmF0ZSBhIGZvcmdlcnkgYnkgYmxpbmRseSBndWVzc2luZzsgaG93ZXZlciBhIHN1Y2Nl c3NmdWwgZm9yZ2VyeSBkb2VzbuKAmXQgZ2l2ZSB0aGUgYXR0YWNrZXIgYW55IGluZm9ybWF0aW9u IGFib3V0IGhvdyB0byBnZW5lcmF0ZSBhIHNlY29uZCBzdWNjZXNzZnVsIGZvcmdlcnksIG9yIGFu eSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgaW50ZXJuYWwgc3RhdGUuICBJbnN0ZWFkLCBnZW5lcmF0 aW5nIGEgc2Vjb25kIGZvcmdlcnkgcmVxdWlyZXMganVzdCBhcyBtdWNoIHdvcmsgYXMgeW914oCZ ZCBleHBlY3QgKHRoYXQgaXMsIHRoZSBzYW1lIGFtb3VudCBvZiB3b3JrIHRha2VuIHRvIGdlbmVy YXRlIHRoZSBmaXJzdCBmb3JnZXJ5KS4NCg0KSGVuY2UsIHdoaWxlIEkgd291bGQgc3VnZ2VzdCB0 aGF0IHlvdSByZXRoaW5rIHRoZSBzdHJhdGVneSBvZiBhbGxvd2luZyB0aW55IElDVnMsIGlmIHlv dSBkbyBnbyBhaGVhZCwgSSB3b3VsZCBzdHJvbmdseSB1cmdlIHlvdSB0byBtYW5kYXRlIHRoZSB1 c2Ugb2YgZWl0aGVyIEhNQUMgb3IgQ01BQyB0byBnZW5lcmF0ZSB0aG9zZSB0aW55IElDVnMg4oCT IHRob3NlIHdvbuKAmXQgbWFrZSBhIHBvb3Igc2l0dWF0aW9uIGV2ZW4gd29yc2UuDQoNCg0KRnJv bTogRGFuaWVsIE1pZ2F1bHQgW21haWx0bzptZ2x0LmlldGZAZ21haWwuY29tXQ0KU2VudDogVHVl c2RheSwgRmVicnVhcnkgMTcsIDIwMTUgMTA6NDggQU0NClRvOiBTY290dCBGbHVocmVyIChzZmx1 aHJlcikNCkNjOiA2bG9AaWV0Zi5vcmc7IGlwc2VjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0lQ c2VjXSBEaWV0LUVTUA0KDQpIaSBTY290dCwNClRoYW5rIHlvdSBmb3IgdGhlIGZlZWQgYmFjay4g SSBhZ3JlZSB0aGF0IGNvbXByZXNzaW5nIHRoZSBJQ1YgcmVkdWNlcyBzZWN1cml0eSByZWxhdGVk IHRvIGF1dGhlbnRpY2F0aW9uLiBMZXQncyBjYWxsIHRoaXMgYSAid2VhayBhdXRoZW50aWNhdGlv biIuDQpJIGFtIG5vdCBzYXlpbmcgaXQgaXMgYSB2YWxpZCBhcmd1bWVudCwgYnV0IHNpbmNlIElQ c2VjIGVuYWJsZXMgTlVMTCBhdXRoZW50aWNhdGlvbiB0b28sIHdlIGNvbnNpZGVyZWQgdGhhdCBl bmFibGluZyAid2VhayBhdXRoZW50aWNhdGlvbiIgd291bGQgYmUgcG9zc2libGUgd2l0aCBhIGNs ZWFyIHdhcm5pbmcgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24uDQpUaGUgcmVhc29uIHdl IGFyZSBsb29raW5nIHdlIGFyZSBsb29raW5nIGZvciB3ZWFrIGF1dGhlbnRpY2F0aW9uIGlzIHRv IGJlIGFibGUgdG8gYmFsYW5jZSBhdXRoZW50aWNhdGlvbiB3aXRoIGJhbmR3aWR0aCBvcHRpbWl6 YXRpb24uIEluIGZhY3QsIHN1cHBvc2UgeW91IGNvbXB1dGUgdGhlIG1lYW4vbWVkaWFuIG92ZXIg YSB0aG91c2FuZCBkaWZmZXJlbnQgdmFsdWUsIHRoYXQgb25lIG9yIHR3byB2YWx1ZXMgYXJlIGNv cnJ1cHRlZCBtYXkgbm90IGhhdmUgbXVjaCBpbXBhY3Qgb3ZlcmFsbCwgYW5kIHdlIG1heSBwcmVm ZXIgdG8gZXh0ZW5kIHRoZSBsaWZlIHRpbWUgb2YgdGhlIG1vdGUgZm9yIDUgeWVhcnMgaW5zdGVh ZC4NCg0KUmVnYXJkaW5nIHlvdSBjb21tZW50IEkgdGhpbmsgdGhlIGlzc3VlIG91IHJhaXNlZCBp cyBtb3JlIHJlbGF0ZWQgdG8gR0NNLiAtLSBCeSB0aGUgd2F5IEkgd291bGQgYmUgaW50ZXJlc3Rl ZCB0byBoYXZlIGEgZGVzY3JpcHRpb24gb3IgcmVsZXZhbnQgZG9jIGRlc2NyaWJpbmcgIHdoeSBJ Q1YgaW4gR0NNIHBhcnRpY3VsYXJseSBtYXR0ZXJzLiBPbmUgd2F5IHRvIGFkZHJlc3MgdGhlIGlz c3VlIHlvdSByYWlzZWQgd291bGQgYmU6DQogICAgLSAxKSBtZW50aW9uIHRoZSBuZWVkIGZvciB3 ZWFrIGF1dGhlbnRpY2F0aW9uIGluIHRoZSByZXF1aXJlbWVudCBkcmFmdA0KICAgIC0gMikgcmVt b3ZlIElDViBjb21wcmVzc2lvbiBmcm9tIERpZXQtRVNQDQogICAgLSAzKSBEZWZpbmUgZW5jcnlw dGlvbiBwcm90b2NvbHMgd2l0aCB3ZWFrIGF1dGhlbnRpY2F0aW9uIHdpdGggZGlmZmVyZW50IHNp emVzIG9mIHRoZSBJQ1YuIEZvciBleGFtcGxlIHN1cHBvc2UgQUVTLU1PREVYIGhhcyBhbiBJQ1Yg b2YgTiwgdGhlbiB3ZSBtYXkgbmVlZCB0byBhZGQgQUVTLU1PREVYX2kgd2l0aCBpIGluIFswIC4u LiBOLTFdLg0KVGhlIGFkdmFudGFnZSBvZiBkb2luZyBzbyBpcyB0aGF0IGl0IGF2b2lkcyBlbmQg dXNlciB0byB3ZWFrZW4gdGhlIHByb3RvY29scyBlc3BlY2lhbGx5IHdoZW4gb25lIGNvbXByZXNz aW9uIGlzIGZpbmUgd2l0aCBvbmUgcHJvdG9jb2wgYnV0IG5vdCB3aXRoIHRoZSBvdGhlcnMuIElu IHRoYXQgc2Vuc2UgaXQgbG9va3MgYSBiZXR0ZXIgZGVzaWduLg0KSG93ZXZlciwgSSBzZWUgdGhl IGZvbGxvd2luZyBkcmF3YmFja3M6DQogICAgLSBJdCByZXF1aXJlcyB0byBjcmVhdGUgbXVsdGlw bGUgZW5jcnlwdGlvbiBwcm90b2NvbHMuIFVubGlrZSBjb21wcmVzc2lvbiwgaW1wbGVtZW50YXRp b24gY2Fubm90IHVzZSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbiBvZiBBRVMtTU9ERVguDQogICAg LSBOZWdvY2lhdGlvbiBmb3IgaG9zdHMgYWNjZXB0aW5nIGFsbCBBRVMtTU9ERVhfaSB3aXRoIGkg aW4gWzAgLi4uIE4tMV0gcmVxdWlyZXMgbWFueSBTQSBwYXlsb2FkIGluIHRoZSBJS0V2MiBuZWdv dGlhdGlvbi4gSG93ZXZlciwgd2UgbWF5IGRlYWwgd2l0aCB0aGlzIHdpdGggYSBBRVMtTU9ERVhf QUxMIHRvIGluZGljYXRlIHRoZSByZXNwb25kZXIgY2hvc2VzIGl0cyBjb21wcmVzc2lvbi4NCg0K QlIsDQpEYW5pZWwNCg0KT24gVHVlLCBGZWIgMTcsIDIwMTUgYXQgNjoyOCBBTSwgU2NvdHQgRmx1 aHJlciAoc2ZsdWhyZXIpIDxzZmx1aHJlckBjaXNjby5jb208bWFpbHRvOnNmbHVocmVyQGNpc2Nv LmNvbT4+IHdyb3RlOg0KSGVyZeKAmXMgYW4gaXNzdWUgd2l0aCB0aGlzIGRyYWZ0OyBpdCBkb2Vz buKAmXQgbWVldCB0aGUgcmVxdWlyZW1lbnRzIHRoYXQgaXQgY2xhaW1zLiAgSW4gcGFydGljdWxh ciwgaXQgY2xhaW1zIHRoYXQgaXQgaXMgYmFzZWQgb24gc3RhbmRhcmQgSVBzZWMsIGFuZCB0aGF0 IGl0cyBzZWN1cml0eSBpcyBlcXVpdmFsZW50IHRvIElQc2VjIChSMS1SMykuICBIb3dldmVyLCBp dCBhbGxvd3MgKGFuZCwgYXMgZmFyIGFzIEkgYW0gY29uY2VybmVkLCBlbmNvdXJhZ2VzKSB0aGUg dXNlIG9mIHRpbnkgSUNWczsgdGhlc2UgdGlueSBJQ1ZzIGludHJvZHVjZSBzZWN1cml0eSB2dWxu ZXJhYmlsaXRpZXMgdGhhdCBkbyBub3Qgb2NjdXIgd2l0aGluIHNhbmUgY29uZmlndXJhdGlvbnMg b2YgSVBzZWMgKHdoZXJlIHNhbmUgaW5jbHVkZXMgdXNpbmcgYW4gaW50ZWdyaXR5IHRyYW5zZm9y bSkuICBJbiBwYXJ0aWN1bGFyLCB1c2luZyB0aW55IElDVnMgd2l0aCBHQ00gaXMgYSBrbm93biBz ZWN1cml0eSBpc3N1ZS4NCg0KTm93LCBpdCB3b3VsZCBiZSBwb3NzaWJsZSB0byBoYXZlIGFuIGVu Y3J5cHRpb24gcHJvdG9jb2wgdGhhdCB3b3VsZCBub3QgaGF2ZSBpc3N1ZXMgd2l0aCBzbWFsbCBJ Q1ZzIChzYXksIGJ5IHVzaW5nIGEgd2lkZSBibG9jayBjaXBoZXIpOyBob3dldmVyIHRoaXMgd291 bGQgYmUgcmF0aGVyIGRpZmZlcmVudCB0aGFuIHN0YW5kYXJkIElQc2VjIChpbiBwYXJ0IGJlY2F1 c2UgSVBzZWMgd2FzIG5ldmVyIGRlc2lnbmVkIHdpdGggdGhlc2UgbWluaW1hbCBiYW5kd2lkdGgg Y29uc3RyYWludHMpOyBlaXRoZXIgd2UgbmVlZCB0byBzdGF5IHdpdGggYW4gSVBzZWMtYmFzZWQg cHJvdG9jb2wgKHdoaWNoIGltcGxpZXMgYSBsYXJnaXNoIElDViksIG9yIGdvIHdpdGggc29tZXRo aW5nIGVsc2UgKHdoaWNoIHdvdWxkIGhhdmUgbGVzcyBvdmVyaGVhZCwgYnV0IGRvZXNu4oCZdCBs b29rIHRoYXQgbXVjaCBsaWtlIElQc2VjIGludGVybmFsbHkpLg0KDQoNCk9oLCBhbmQgYSBtaW5v ciBub3RlIG9uIHRoZSBJViBnZW5lcmF0aW9uOiBpdOKAmXMgYWN0dWFsbHkgc2VjdXJlIHRvIHVz ZSB0aGUgc2FtZSBrZXkgeW91IHVzZSB0byBlbmNyeXB0IHRvIGVuY3J5cHQgdGhlIGNvdW50ZXIg Zm9yIHRoZSBJVjsgeW91IGRvbuKAmXQgbmVlZCBhIHNlcGFyYXRlIGtleS4NCg0KRnJvbTogSVBz ZWMgW21haWx0bzppcHNlYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppcHNlYy1ib3VuY2VzQGll dGYub3JnPl0gT24gQmVoYWxmIE9mIERhbmllbCBNaWdhdWx0DQpTZW50OiBNb25kYXksIEZlYnJ1 YXJ5IDE2LCAyMDE1IDEwOjA4IFBNDQpUbzogNmxvQGlldGYub3JnPG1haWx0bzo2bG9AaWV0Zi5v cmc+DQpDYzogaXBzZWNAaWV0Zi5vcmc8bWFpbHRvOmlwc2VjQGlldGYub3JnPg0KU3ViamVjdDog W0lQc2VjXSBEaWV0LUVTUA0KDQpQbGVhc2UgZmluZCB0aGUgbmV3IHZlcnNpb24gb2YgRGlldC1F U1AgYSBjb21wcmVzcyBJUHNlYy9FU1AgZm9yIElvVC4gV2UgaGF2ZSBpbXBsZW1lbnRlZCBhbmQg dGVzdGVkIERpZXQtRVNQLiBDb21wYXJlZCB0byB0aGUgc3RhbmRhcmQgSVBzZWMvRVNQLCBEaWV0 LUVTUCBjYW4gcmVkdWNlIHRoZSBuZXR3b3JraW5nIG92ZXJoZWFkIGFkZGVkIHRvIHVucHJvdGVj dGVkIGRhdGEgZnJvbSAxMDAlIHRvIGEgZmV3IHBlcmNlbnQuIEkgd2lsbCBiZSBoYXBweSB0byBw cmVzZW50IHRoZXNlIGRyYWZ0IG5leHQgSUVURi4NCg0KRmVlbCBmcmVlIHRvIG1ha2UgY29tbWVu dHMhDQoNClRoZSBkcmFmdHMgaW5jbHVkZXM6DQogICAgMSkgZHJhZnQtbWdsdC02bG8tZGlldC1l c3AtcmVxdWlyZW1lbnRzPGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWds dC02bG8tZGlldC1lc3AtcmVxdWlyZW1lbnRzLz46IGxpc3RzIHRoZSByZXF1aXJlbWVudHMgZm9y IERpZXQtRVNQDQogICAgMikgZHJhZnQtbWdsdC02bG8tYWVzLWltcGxpY2l0LWl2PGh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWdsdC02bG8tYWVzLWltcGxpY2l0LWl2Lz46 IGluZGljYXRlcyBob3cgdG8gYXZvaWQgY2FycnlpbmcgdGhlIElWIGluIGVhY2ggRVNQIHBhY2tl dC4gSXQgaXMgaW5zdGVhZCBnZW5lcmF0ZWQgYnkgZWFjaCBwZWVycy4gVGhlIHByb3RvY29scyBk ZXNjcmliZWQgaW4gdGhlIGRyYWZ0IGNhbiBiZSB1c2VkIHdpdGggdGhlIHJlZ3VsYXIgSVBzZWMv RVNQLg0KICAgIDMpIGRyYWZ0LW1nbHQtNmxvLWRpZXQtZXNwPGh0dHA6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtbWdsdC02bG8tZGlldC1lc3AvPiBkZXNjcmliZXMgdGhlIGNvcmUg RGlldC1FU1AgcHJvdG9jb2wsIHRoYXQgaXMgaG93IHRvIGNvbXByZXNzL2RlY29tcHJlc3MgZWFj aCBmaWVsZHMgb2YgdGhlIHN0YW5kYXJkIElQc2VjL0VTUC4gQ29tcHJlc3Npb24gaXMgZGlzY3Jp YmVkIHRocm91Z2ggYSBEaWV0LUVTUCBDb250ZXh0Lg0KICAgIDQpIGRyYWZ0LW1nbHQtNmxvLWRp ZXQtZXNwLXBheWxvYWQtY29tcHJlc3Npb248aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1tZ2x0LTZsby1kaWV0LWVzcC1wYXlsb2FkLWNvbXByZXNzaW9uLz46IGRlc2NyaWJl cyBob3cgdGhlIGNsZWFyIHRleHQgY2FuIGJlIGNvbXByZXNzZWQgYmVmb3JlIGVuY3J5cHRpb24u IEluIGZhY3QgdW5sZXNzIElQc2VjL0VTUCBpcyB1c2VkIHdpdGggTlVMTCBlbmNyeXB0aW9uLCB0 aGUgZGF0YSBpbiB0aGUgRVNQIHBhY2tldCBpcyBlbmNyeXB0ZWQuIEVuY3J5cHRpb24gbWFrZXMg Y29tcHJlc3Npb24gaGFyZCB0byBwZXJmb3JtLiBJbnN0ZWFkIGNvbXByZXNzaW5nIGJlZm9yZSBl bmNyeXB0aW5nIGNhbiBiZSB2ZXJ5IGVmZmljaWVudC4gVGhpcyBtYWtlcyBwb3NzaWJsZSB0byBy ZW1vdmUgVURQL1RQQy9JUCB0dW5uZWwgaGVhZGVycy4NCiAgICA1KSBkcmFmdC1tZ2x0LTZsby1k aWV0LWVzcC1jb250ZXh0LWlrZXYyLWV4dGVuc2lvbjxodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LW1nbHQtNmxvLWRpZXQtZXNwLWNvbnRleHQtaWtldjItZXh0ZW5zaW9uLz46 IGRlc2NyaWJlcyBob3cgdG8gbmVnb2NpYXRlIERpZXQtRVNQIHdpdGggSUtFdjIuIEluIGZhY3Qg dGhpcyBtb3N0bHkgcmVzdWx0IGluIGFuIGFncmVlbWVudCBmb3IgdGhlIERJZXQtRVNQIENvbnRl eHQuIFRoaXMgZXhjaGFuZ2UgbWF5IHRoZW4gYmUgZXh0ZW5kZWQgdG8gRGlldC1ISVAgRXhjaGFu Z2UuDQpCUiwNCkRhbmllbA0KLS0NCkRhbmllbCBNaWdhdWx0DQpPcmFuZ2UgTGFicyAtLSBTZWN1 cml0eQ0KKzMzIDYgNzAgNzIgNjkgNTg8dGVsOiUyQjMzJTIwNiUyMDcwJTIwNzIlMjA2OSUyMDU4 Pg0KDQoNCg0KLS0NCkRhbmllbCBNaWdhdWx0DQpFcmljc3Nvbg0K --_000_A113ACFD9DF8B04F96395BDEACB340420D03A72Fxmbrcdx04ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdp bi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24g VGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjEzODQ4NjM2MjM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOi02MjkzNzcyNDQgLTE3NTg1Njc5NzAgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0K QGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFz dC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21h cmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T3RoZXJzIGhhdmUgYWRkcmVzc2VkIG15IG90aGVy IHBvaW50czsgbGV0IG1lIHRhbGsgYWJvdXQgdGhlIHNwZWNpZmljIGlzc3VlcyB3aXRoIEdDTS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPk9uZSBzdW1tYXJ5IG9mIHRoZSBpc3N1ZXMgZm91bmQgaXMNCjxhIGhyZWY9Imh0 dHA6Ly9jaXRlc2VlcnguaXN0LnBzdS5lZHUvdmlld2RvYy9kb3dubG9hZD9kb2k9MTAuMS4xLjI5 Ny45NTY4JmFtcDtyZXA9cmVwMSZhbXA7dHlwZT1wZGYiPg0KaHR0cDovL2NpdGVzZWVyeC5pc3Qu cHN1LmVkdS92aWV3ZG9jL2Rvd25sb2FkP2RvaT0xMC4xLjEuMjk3Ljk1NjgmYW1wO3JlcD1yZXAx JmFtcDt0eXBlPXBkZjwvYT4gOyB0aGUgcHJvYmxlbSB3aXRoIEdDTSBpcyB0aGF0OjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1p bmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldpdGggb25lIHN1Y2Nlc3NmdWwgZm9yZ2Vy eSwgdGhlIGF0dGFja2VyIGNhbiBtb2RpZnkgb3RoZXIgcGFja2V0cyB0aGUgc2FtZSB3YXkgd2l0 aG91dCBkZXRlY3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2l0 aCBhIGhhbmRmdWwgb2Ygc3VjY2Vzc2Z1bCBmb3JnZXJpZXMsIHRoZSBhdHRhY2tlciBjYW4gbGVh cm4gZW5vdWdoIHRvIGJlIGFibGUgdG8gZm9yZ2UgYXJiaXRyYXJ5IG1lc3NhZ2VzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ob3csIHdpdGggdGhlIGZ1bGwgMTYgYnl0ZSBJQ1YsIHRo aXMgaXMgbm90IGEgY29uY2VybiAoYmVjYXVzZSB0aGUgcHJvYmFiaWxpdHkgb2YgdGhlIGF0dGFj a2VyIGZpbmRpbmcgb25lIHN1Y2Nlc3NmdWwgZm9yZ2VyeSBpcyB0aW55KTsgaG93ZXZlciBvbmNl IHlvdSBzdGFydA0KIHJlZHVjaW5nIHRoZSBJQ1YgdmFsdWUsIHdlbGwsIHZhcmlvdXMgZ3Vlc3Np bmcgc3RyYXRlZ2llcyBzdGFydCB3b3JraW5nIGJldHRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5vdywgbmVpdGhl ciBITUFDIG5vciBDTUFDIGhhcyB0aGlzIHByb2JsZW07IHllcywgd2l0aCBhIHRpbnkgSUNWLCBz b21lb25lIGNhbiBnZW5lcmF0ZSBhIGZvcmdlcnkgYnkgYmxpbmRseSBndWVzc2luZzsgaG93ZXZl ciBhIHN1Y2Nlc3NmdWwgZm9yZ2VyeSBkb2VzbuKAmXQNCiBnaXZlIHRoZSBhdHRhY2tlciBhbnkg aW5mb3JtYXRpb24gYWJvdXQgaG93IHRvIGdlbmVyYXRlIGEgc2Vjb25kIHN1Y2Nlc3NmdWwgZm9y Z2VyeSwgb3IgYW55IGluZm9ybWF0aW9uIGFib3V0IHRoZSBpbnRlcm5hbCBzdGF0ZS4mbmJzcDsg SW5zdGVhZCwgZ2VuZXJhdGluZyBhIHNlY29uZCBmb3JnZXJ5IHJlcXVpcmVzIGp1c3QgYXMgbXVj aCB3b3JrIGFzIHlvdeKAmWQgZXhwZWN0ICh0aGF0IGlzLCB0aGUgc2FtZSBhbW91bnQgb2Ygd29y ayB0YWtlbiB0byBnZW5lcmF0ZQ0KIHRoZSBmaXJzdCBmb3JnZXJ5KS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhlbmNl LCB3aGlsZSBJIHdvdWxkIHN1Z2dlc3QgdGhhdCB5b3UgcmV0aGluayB0aGUgc3RyYXRlZ3kgb2Yg YWxsb3dpbmcgdGlueSBJQ1ZzLCBpZiB5b3UgZG8gZ28gYWhlYWQsIEkgd291bGQgc3Ryb25nbHkg dXJnZSB5b3UgdG8gbWFuZGF0ZSB0aGUgdXNlIG9mIGVpdGhlcg0KIEhNQUMgb3IgQ01BQyB0byBn ZW5lcmF0ZSB0aG9zZSB0aW55IElDVnMg4oCTIHRob3NlIHdvbuKAmXQgbWFrZSBhIHBvb3Igc2l0 dWF0aW9uIGV2ZW4gd29yc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gRGFuaWVsIE1pZ2F1bHQg W21haWx0bzptZ2x0LmlldGZAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXks IEZlYnJ1YXJ5IDE3LCAyMDE1IDEwOjQ4IEFNPGJyPg0KPGI+VG86PC9iPiBTY290dCBGbHVocmVy IChzZmx1aHJlcik8YnI+DQo8Yj5DYzo8L2I+IDZsb0BpZXRmLm9yZzsgaXBzZWNAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJUHNlY10gRGlldC1FU1A8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij5IaSBTY290dCwgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhhbmsgeW91IGZvciB0aGUgZmVl ZCBiYWNrLiBJIGFncmVlIHRoYXQgY29tcHJlc3NpbmcgdGhlIElDViByZWR1Y2VzIHNlY3VyaXR5 IHJlbGF0ZWQgdG8gYXV0aGVudGljYXRpb24uIExldCdzIGNhbGwgdGhpcyBhICZxdW90O3dlYWsg YXV0aGVudGljYXRpb24mcXVvdDsuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JIGFtIG5vdCBz YXlpbmcgaXQgaXMgYSB2YWxpZCBhcmd1bWVudCwgYnV0IHNpbmNlIElQc2VjIGVuYWJsZXMgTlVM TCBhdXRoZW50aWNhdGlvbiB0b28sIHdlIGNvbnNpZGVyZWQgdGhhdCBlbmFibGluZyAmcXVvdDt3 ZWFrIGF1dGhlbnRpY2F0aW9uJnF1b3Q7IHdvdWxkIGJlIHBvc3NpYmxlIHdpdGggYSBjbGVhciB3 YXJuaW5nIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uLg0KPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcmVhc29uIHdlIGFyZSBsb29r aW5nIHdlIGFyZSBsb29raW5nIGZvciB3ZWFrIGF1dGhlbnRpY2F0aW9uIGlzIHRvIGJlIGFibGUg dG8gYmFsYW5jZSBhdXRoZW50aWNhdGlvbiB3aXRoIGJhbmR3aWR0aCBvcHRpbWl6YXRpb24uIElu IGZhY3QsIHN1cHBvc2UgeW91IGNvbXB1dGUgdGhlIG1lYW4vbWVkaWFuIG92ZXIgYSB0aG91c2Fu ZCBkaWZmZXJlbnQgdmFsdWUsIHRoYXQgb25lIG9yIHR3byB2YWx1ZXMgYXJlDQogY29ycnVwdGVk IG1heSBub3QgaGF2ZSBtdWNoIGltcGFjdCBvdmVyYWxsLCBhbmQgd2UgbWF5IHByZWZlciB0byBl eHRlbmQgdGhlIGxpZmUgdGltZSBvZiB0aGUgbW90ZSBmb3IgNSB5ZWFycyBpbnN0ZWFkLjxicj4N CiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdh cmRpbmcgeW91IGNvbW1lbnQgSSB0aGluayB0aGUgaXNzdWUgb3UgcmFpc2VkIGlzIG1vcmUgcmVs YXRlZCB0byBHQ00uIC0tIEJ5IHRoZSB3YXkgSSB3b3VsZCBiZSBpbnRlcmVzdGVkIHRvIGhhdmUg YSBkZXNjcmlwdGlvbiBvciByZWxldmFudCBkb2MgZGVzY3JpYmluZyZuYnNwOyB3aHkgSUNWIGlu IEdDTSBwYXJ0aWN1bGFybHkgbWF0dGVycy4gT25lIHdheSB0byBhZGRyZXNzIHRoZSBpc3N1ZSB5 b3UgcmFpc2VkDQogd291bGQgYmU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyAtIDEpIG1lbnRpb24gdGhlIG5lZWQgZm9yIHdl YWsgYXV0aGVudGljYXRpb24gaW4gdGhlIHJlcXVpcmVtZW50IGRyYWZ0PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyAtIDIpIHJl bW92ZSBJQ1YgY29tcHJlc3Npb24gZnJvbSBEaWV0LUVTUDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNw OyAmbmJzcDsgLSAzKSBEZWZpbmUgZW5jcnlwdGlvbiBwcm90b2NvbHMgd2l0aCB3ZWFrIGF1dGhl bnRpY2F0aW9uIHdpdGggZGlmZmVyZW50IHNpemVzIG9mIHRoZSBJQ1YuIEZvciBleGFtcGxlIHN1 cHBvc2UgQUVTLU1PREVYIGhhcyBhbiBJQ1Ygb2YgTiwgdGhlbiB3ZSBtYXkgbmVlZCB0byBhZGQg QUVTLU1PREVYX2kgd2l0aCBpIGluIFswIC4uLiBOLTFdLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij5UaGUgYWR2YW50YWdlIG9mIGRvaW5nIHNvIGlzIHRoYXQgaXQgYXZvaWRzIGVuZCB1c2VyIHRv IHdlYWtlbiB0aGUgcHJvdG9jb2xzIGVzcGVjaWFsbHkgd2hlbiBvbmUgY29tcHJlc3Npb24gaXMg ZmluZSB3aXRoIG9uZSBwcm90b2NvbCBidXQgbm90IHdpdGggdGhlIG90aGVycy4gSW4gdGhhdCBz ZW5zZSBpdCBsb29rcyBhIGJldHRlciBkZXNpZ24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIsIEkgc2VlIHRoZSBmb2xsb3dpbmcgZHJhd2JhY2tz OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJz cDsmbmJzcDsgLSBJdCByZXF1aXJlcyB0byBjcmVhdGUgbXVsdGlwbGUgZW5jcnlwdGlvbiBwcm90 b2NvbHMuIFVubGlrZSBjb21wcmVzc2lvbiwgaW1wbGVtZW50YXRpb24gY2Fubm90IHVzZSBleGlz dGluZyBpbXBsZW1lbnRhdGlvbiBvZiBBRVMtTU9ERVguPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyAtIE5lZ29jaWF0aW9uIGZv ciBob3N0cyBhY2NlcHRpbmcgYWxsIEFFUy1NT0RFWF9pIHdpdGggaSBpbiBbMCAuLi4gTi0xXSBy ZXF1aXJlcyBtYW55IFNBIHBheWxvYWQgaW4gdGhlIElLRXYyIG5lZ290aWF0aW9uLiBIb3dldmVy LCB3ZSBtYXkgZGVhbCB3aXRoIHRoaXMgd2l0aCBhIEFFUy1NT0RFWF9BTEwgdG8gaW5kaWNhdGUg dGhlIHJlc3BvbmRlciBjaG9zZXMgaXRzIGNvbXByZXNzaW9uLjxicj4NCiZuYnNwOyZuYnNwOyZu YnNwOyA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QlIsIDxi cj4NCkRhbmllbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gVHVlLCBGZWIgMTcsIDIwMTUgYXQgNjoyOCBBTSwgU2NvdHQgRmx1aHJlciAoc2ZsdWhyZXIp ICZsdDs8YSBocmVmPSJtYWlsdG86c2ZsdWhyZXJAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ c2ZsdWhyZXJAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IZXJl4oCZcyBhbiBpc3N1ZSB3aXRoIHRoaXMg ZHJhZnQ7IGl0IGRvZXNu4oCZdCBtZWV0IHRoZSByZXF1aXJlbWVudHMgdGhhdCBpdCBjbGFpbXMu Jm5ic3A7IEluDQogcGFydGljdWxhciwgaXQgY2xhaW1zIHRoYXQgaXQgaXMgYmFzZWQgb24gc3Rh bmRhcmQgSVBzZWMsIGFuZCB0aGF0IGl0cyBzZWN1cml0eSBpcyBlcXVpdmFsZW50IHRvIElQc2Vj IChSMS1SMykuJm5ic3A7IEhvd2V2ZXIsIGl0IGFsbG93cyAoYW5kLCBhcyBmYXIgYXMgSSBhbSBj b25jZXJuZWQsIGVuY291cmFnZXMpIHRoZSB1c2Ugb2YgdGlueSBJQ1ZzOyB0aGVzZSB0aW55IElD VnMgaW50cm9kdWNlIHNlY3VyaXR5IHZ1bG5lcmFiaWxpdGllcyB0aGF0IGRvDQogbm90IG9jY3Vy IHdpdGhpbiBzYW5lIGNvbmZpZ3VyYXRpb25zIG9mIElQc2VjICh3aGVyZSBzYW5lIGluY2x1ZGVz IHVzaW5nIGFuIGludGVncml0eSB0cmFuc2Zvcm0pLiZuYnNwOyBJbiBwYXJ0aWN1bGFyLCB1c2lu ZyB0aW55IElDVnMgd2l0aCBHQ00gaXMgYSBrbm93biBzZWN1cml0eSBpc3N1ZS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5vdywgaXQgd291bGQgYmUgcG9zc2libGUg dG8gaGF2ZSBhbiBlbmNyeXB0aW9uIHByb3RvY29sIHRoYXQgd291bGQgbm90IGhhdmUgaXNzdWVz DQogd2l0aCBzbWFsbCBJQ1ZzIChzYXksIGJ5IHVzaW5nIGEgd2lkZSBibG9jayBjaXBoZXIpOyBo b3dldmVyIHRoaXMgd291bGQgYmUgcmF0aGVyIGRpZmZlcmVudCB0aGFuIHN0YW5kYXJkIElQc2Vj IChpbiBwYXJ0IGJlY2F1c2UgSVBzZWMgd2FzIG5ldmVyIGRlc2lnbmVkIHdpdGggdGhlc2UgbWlu aW1hbCBiYW5kd2lkdGggY29uc3RyYWludHMpOyBlaXRoZXIgd2UgbmVlZCB0byBzdGF5IHdpdGgg YW4gSVBzZWMtYmFzZWQgcHJvdG9jb2wgKHdoaWNoDQogaW1wbGllcyBhIGxhcmdpc2ggSUNWKSwg b3IgZ28gd2l0aCBzb21ldGhpbmcgZWxzZSAod2hpY2ggd291bGQgaGF2ZSBsZXNzIG92ZXJoZWFk LCBidXQgZG9lc27igJl0IGxvb2sgdGhhdCBtdWNoIGxpa2UgSVBzZWMgaW50ZXJuYWxseSkuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T2gsIGFuZCBhIG1pbm9yIG5vdGUgb24g dGhlIElWIGdlbmVyYXRpb246IGl04oCZcyBhY3R1YWxseSBzZWN1cmUgdG8gdXNlIHRoZSBzYW1l IGtleQ0KIHlvdSB1c2UgdG8gZW5jcnlwdCB0byBlbmNyeXB0IHRoZSBjb3VudGVyIGZvciB0aGUg SVY7IHlvdSBkb27igJl0IG5lZWQgYSBzZXBhcmF0ZSBrZXkuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSVBzZWMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86 aXBzZWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlwc2VjLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5EYW5pZWwgTWlnYXVsdDxicj4NCjxiPlNl bnQ6PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDE2LCAyMDE1IDEwOjA4IFBNPGJyPg0KPGI+VG86PC9i PiA8YSBocmVmPSJtYWlsdG86NmxvQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NmxvQGlldGYu b3JnPC9hPjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmlwc2VjQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+aXBzZWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtJ UHNlY10gRGlldC1FU1A8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+UGxlYXNlIGZpbmQgdGhlIG5ldyB2ZXJzaW9uIG9mIERpZXQt RVNQIGEgY29tcHJlc3MgSVBzZWMvRVNQIGZvciBJb1QuIFdlIGhhdmUgaW1wbGVtZW50ZWQgYW5k IHRlc3RlZCBEaWV0LUVTUC4gQ29tcGFyZWQgdG8gdGhlIHN0YW5kYXJkIElQc2VjL0VTUCwgRGll dC1FU1AgY2FuIHJlZHVjZSB0aGUgbmV0d29ya2luZw0KIG92ZXJoZWFkIGFkZGVkIHRvIHVucHJv dGVjdGVkIGRhdGEgZnJvbSAxMDAlIHRvIGEgZmV3IHBlcmNlbnQuIEkgd2lsbCBiZSBoYXBweSB0 byBwcmVzZW50IHRoZXNlIGRyYWZ0IG5leHQgSUVURi4NCjxicj4NCjxicj4NCkZlZWwgZnJlZSB0 byBtYWtlIGNvbW1lbnRzITxicj4NCjxicj4NClRoZSBkcmFmdHMgaW5jbHVkZXM6PGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7IDEpIDxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtbWdsdC02bG8tZGlldC1lc3AtcmVxdWlyZW1lbnRzLyIgdGFyZ2V0PSJfYmxhbmsi Pg0KZHJhZnQtbWdsdC02bG8tZGlldC1lc3AtcmVxdWlyZW1lbnRzPC9hPjogbGlzdHMgdGhlIHJl cXVpcmVtZW50cyBmb3IgRGlldC1FU1A8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIpDQo8YSBocmVmPSJodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1nbHQtNmxvLWFlcy1pbXBsaWNpdC1p di8iIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LW1nbHQtNmxvLWFlcy1pbXBsaWNpdC1pdjwvYT46 IGluZGljYXRlcyBob3cgdG8gYXZvaWQgY2FycnlpbmcgdGhlIElWIGluIGVhY2ggRVNQIHBhY2tl dC4gSXQgaXMgaW5zdGVhZCBnZW5lcmF0ZWQgYnkgZWFjaCBwZWVycy4gVGhlIHByb3RvY29scyBk ZXNjcmliZWQgaW4gdGhlIGRyYWZ0IGNhbiBiZSB1c2VkIHdpdGggdGhlIHJlZ3VsYXIgSVBzZWMv RVNQLjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAzKSA8YSBocmVm PSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1nbHQtNmxvLWRpZXQtZXNw LyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQtbWdsdC02bG8tZGlldC1lc3A8L2E+IGRlc2NyaWJl cyB0aGUgY29yZSBEaWV0LUVTUCBwcm90b2NvbCwgdGhhdCBpcyBob3cgdG8gY29tcHJlc3MvZGVj b21wcmVzcyBlYWNoIGZpZWxkcyBvZiB0aGUgc3RhbmRhcmQgSVBzZWMvRVNQLiBDb21wcmVzc2lv biBpcyBkaXNjcmliZWQgdGhyb3VnaCBhIERpZXQtRVNQIENvbnRleHQuPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7IDQpIDxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtbWdsdC02bG8tZGlldC1lc3AtcGF5bG9hZC1jb21wcmVzc2lvbi8iIHRhcmdldD0iX2JsYW5r Ij4NCmRyYWZ0LW1nbHQtNmxvLWRpZXQtZXNwLXBheWxvYWQtY29tcHJlc3Npb248L2E+OiBkZXNj cmliZXMgaG93IHRoZSBjbGVhciB0ZXh0IGNhbiBiZSBjb21wcmVzc2VkIGJlZm9yZSBlbmNyeXB0 aW9uLiBJbiBmYWN0IHVubGVzcyBJUHNlYy9FU1AgaXMgdXNlZCB3aXRoIE5VTEwgZW5jcnlwdGlv biwgdGhlIGRhdGEgaW4gdGhlIEVTUCBwYWNrZXQgaXMgZW5jcnlwdGVkLiBFbmNyeXB0aW9uIG1h a2VzIGNvbXByZXNzaW9uIGhhcmQgdG8gcGVyZm9ybS4NCiBJbnN0ZWFkIGNvbXByZXNzaW5nIGJl Zm9yZSBlbmNyeXB0aW5nIGNhbiBiZSB2ZXJ5IGVmZmljaWVudC4gVGhpcyBtYWtlcyBwb3NzaWJs ZSB0byByZW1vdmUgVURQL1RQQy9JUCB0dW5uZWwgaGVhZGVycy48YnI+DQombmJzcDsmbmJzcDsm bmJzcDsgNSkgPGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1t Z2x0LTZsby1kaWV0LWVzcC1jb250ZXh0LWlrZXYyLWV4dGVuc2lvbi8iIHRhcmdldD0iX2JsYW5r Ij4NCmRyYWZ0LW1nbHQtNmxvLWRpZXQtZXNwLWNvbnRleHQtaWtldjItZXh0ZW5zaW9uPC9hPjog ZGVzY3JpYmVzIGhvdyB0byBuZWdvY2lhdGUgRGlldC1FU1Agd2l0aCBJS0V2Mi4gSW4gZmFjdCB0 aGlzIG1vc3RseSByZXN1bHQgaW4gYW4gYWdyZWVtZW50IGZvciB0aGUgRElldC1FU1AgQ29udGV4 dC4gVGhpcyBleGNoYW5nZSBtYXkgdGhlbiBiZSBleHRlbmRlZCB0byBEaWV0LUhJUCBFeGNoYW5n ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ QlIsDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+RGFuaWVsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPi0tDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkRhbmllbCBNaWdhdWx0PGJyPg0KT3JhbmdlIExhYnMgLS0gU2VjdXJpdHk8YnI+DQo8YSBocmVm PSJ0ZWw6JTJCMzMlMjA2JTIwNzAlMjA3MiUyMDY5JTIwNTgiIHRhcmdldD0iX2JsYW5rIj4mIzQz OzMzIDYgNzAgNzIgNjkgNTg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxicj4NCi0t IDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+RGFuaWVsIE1pZ2F1bHQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkVyaWNzc29uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A113ACFD9DF8B04F96395BDEACB340420D03A72Fxmbrcdx04ciscoc_-- From nobody Tue Feb 17 18:38:16 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92121A8955; Tue, 17 Feb 2015 18:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2qJoncgEs03; Tue, 17 Feb 2015 18:38:10 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (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 89AED1A702B; Tue, 17 Feb 2015 18:38:09 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id l15so37930395wiw.5; Tue, 17 Feb 2015 18:38:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gPV5jLLFefuzI1YKvncHFyc7RdoLh8oU2bSkxW9Bzq4=; b=YsfSQnGscjXt7EQObcHwTJ4XWyWNl/IY+XhxeAjt0rEHXL2o09ILj3ODlJZj7hhPTb VeKonom6S+3QXeH+Np+4al+VOejtJgWVXhWDPpXO59yeX4cACAmhx7RJbua+/6fInlun +eBjUOzCZq2qafCI114Ldv7va8I4qnijl3AhCT6a7jDeaJYoyoW0ishg/xpc6r6/i+1+ JcV2e87XFhbNf2qjfr4e1fypJGk9bXyO1hVq/ILtofPj7rLOge7Y7sIVghIdlplAy4ds FJFRo0fxY9lPsZUkSVxrF8D7mxLU3mDKH/IFsvENS5PyTrlO20GaTRjKjS1TChD2vd8u uklw== MIME-Version: 1.0 X-Received: by 10.181.13.39 with SMTP id ev7mr366748wid.3.1424227088291; Tue, 17 Feb 2015 18:38:08 -0800 (PST) Received: by 10.194.68.39 with HTTP; Tue, 17 Feb 2015 18:38:08 -0800 (PST) In-Reply-To: References: Date: Wed, 18 Feb 2015 03:38:08 +0100 Message-ID: From: Daniel Migault To: "Scott Fluhrer (sfluhrer)" Content-Type: multipart/alternative; boundary=f46d043be268ad59ec050f53b573 Archived-At: Cc: "ipsec@ietf.org" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [IPsec] Diet-ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 02:38:13 -0000 --f46d043be268ad59ec050f53b573 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Scott, Thanks for the feed back, this is clearly some text that needs to be added to draft. So options to deal with the compression of the ICV are: - a) Allowing ICV compression with some restrictions like the ones you mention. - b) Not allowing ICV compression and explicitly listing encryption algorithms with small ICV BR, Daniel On Tue, Feb 17, 2015 at 10:17 PM, Scott Fluhrer (sfluhrer) < sfluhrer@cisco.com> wrote: > Others have addressed my other points; let me talk about the specific > issues with GCM. > > > > One summary of the issues found is > http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.297.9568&rep= =3Drep1&type=3Dpdf > ; the problem with GCM is that: > > - With one successful forgery, the attacker can modify other > packets the same way without detection. > > - With a handful of successful forgeries, the attacker can learn > enough to be able to forge arbitrary messages. > > Now, with the full 16 byte ICV, this is not a concern (because the > probability of the attacker finding one successful forgery is tiny); > however once you start reducing the ICV value, well, various guessing > strategies start working better. > > > > Now, neither HMAC nor CMAC has this problem; yes, with a tiny ICV, someon= e > can generate a forgery by blindly guessing; however a successful forgery > doesn=E2=80=99t give the attacker any information about how to generate a= second > successful forgery, or any information about the internal state. Instead= , > generating a second forgery requires just as much work as you=E2=80=99d e= xpect > (that is, the same amount of work taken to generate the first forgery). > > > > Hence, while I would suggest that you rethink the strategy of allowing > tiny ICVs, if you do go ahead, I would strongly urge you to mandate the u= se > of either HMAC or CMAC to generate those tiny ICVs =E2=80=93 those won=E2= =80=99t make a > poor situation even worse. > > > > > > *From:* Daniel Migault [mailto:mglt.ietf@gmail.com] > *Sent:* Tuesday, February 17, 2015 10:48 AM > *To:* Scott Fluhrer (sfluhrer) > *Cc:* 6lo@ietf.org; ipsec@ietf.org > *Subject:* Re: [IPsec] Diet-ESP > > > > Hi Scott, > > Thank you for the feed back. I agree that compressing the ICV reduces > security related to authentication. Let's call this a "weak > authentication". > > I am not saying it is a valid argument, but since IPsec enables NULL > authentication too, we considered that enabling "weak authentication" wou= ld > be possible with a clear warning in the security consideration. > > The reason we are looking we are looking for weak authentication is to be > able to balance authentication with bandwidth optimization. In fact, > suppose you compute the mean/median over a thousand different value, that > one or two values are corrupted may not have much impact overall, and we > may prefer to extend the life time of the mote for 5 years instead. > > > Regarding you comment I think the issue ou raised is more related to GCM. > -- By the way I would be interested to have a description or relevant doc > describing why ICV in GCM particularly matters. One way to address the > issue you raised would be: > > - 1) mention the need for weak authentication in the requirement draf= t > > - 2) remove ICV compression from Diet-ESP > > - 3) Define encryption protocols with weak authentication with > different sizes of the ICV. For example suppose AES-MODEX has an ICV of N= , > then we may need to add AES-MODEX_i with i in [0 ... N-1]. > > The advantage of doing so is that it avoids end user to weaken the > protocols especially when one compression is fine with one protocol but n= ot > with the others. In that sense it looks a better design. > > However, I see the following drawbacks: > > - It requires to create multiple encryption protocols. Unlike > compression, implementation cannot use existing implementation of AES-MOD= EX. > > - Negociation for hosts accepting all AES-MODEX_i with i in [0 ... > N-1] requires many SA payload in the IKEv2 negotiation. However, we may > deal with this with a AES-MODEX_ALL to indicate the responder choses its > compression. > > > BR, > Daniel > > > > On Tue, Feb 17, 2015 at 6:28 AM, Scott Fluhrer (sfluhrer) < > sfluhrer@cisco.com> wrote: > > Here=E2=80=99s an issue with this draft; it doesn=E2=80=99t meet the requ= irements that it > claims. In particular, it claims that it is based on standard IPsec, and > that its security is equivalent to IPsec (R1-R3). However, it allows (an= d, > as far as I am concerned, encourages) the use of tiny ICVs; these tiny IC= Vs > introduce security vulnerabilities that do not occur within sane > configurations of IPsec (where sane includes using an integrity > transform). In particular, using tiny ICVs with GCM is a known security > issue. > > > > Now, it would be possible to have an encryption protocol that would not > have issues with small ICVs (say, by using a wide block cipher); however > this would be rather different than standard IPsec (in part because IPsec > was never designed with these minimal bandwidth constraints); either we > need to stay with an IPsec-based protocol (which implies a largish ICV), = or > go with something else (which would have less overhead, but doesn=E2=80= =99t look > that much like IPsec internally). > > > > > > Oh, and a minor note on the IV generation: it=E2=80=99s actually secure t= o use the > same key you use to encrypt to encrypt the counter for the IV; you don=E2= =80=99t > need a separate key. > > > > *From:* IPsec [mailto:ipsec-bounces@ietf.org] *On Behalf Of *Daniel > Migault > *Sent:* Monday, February 16, 2015 10:08 PM > *To:* 6lo@ietf.org > *Cc:* ipsec@ietf.org > *Subject:* [IPsec] Diet-ESP > > > > Please find the new version of Diet-ESP a compress IPsec/ESP for IoT. We > have implemented and tested Diet-ESP. Compared to the standard IPsec/ESP, > Diet-ESP can reduce the networking overhead added to unprotected data fro= m > 100% to a few percent. I will be happy to present these draft next IETF. > > Feel free to make comments! > > The drafts includes: > 1) draft-mglt-6lo-diet-esp-requirements > : > lists the requirements for Diet-ESP > > 2) draft-mglt-6lo-aes-implicit-iv > : > indicates how to avoid carrying the IV in each ESP packet. It is instead > generated by each peers. The protocols described in the draft can be used > with the regular IPsec/ESP. > > 3) draft-mglt-6lo-diet-esp > describes the > core Diet-ESP protocol, that is how to compress/decompress each fields of > the standard IPsec/ESP. Compression is discribed through a Diet-ESP Conte= xt. > 4) draft-mglt-6lo-diet-esp-payload-compression > : > describes how the clear text can be compressed before encryption. In fact > unless IPsec/ESP is used with NULL encryption, the data in the ESP packet > is encrypted. Encryption makes compression hard to perform. Instead > compressing before encrypting can be very efficient. This makes possible = to > remove UDP/TPC/IP tunnel headers. > 5) draft-mglt-6lo-diet-esp-context-ikev2-extension > : > describes how to negociate Diet-ESP with IKEv2. In fact this mostly resul= t > in an agreement for the DIet-ESP Context. This exchange may then be > extended to Diet-HIP Exchange. > > BR, > > Daniel > > -- > > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 > > > > > -- > > Daniel Migault > > Ericsson > --=20 Daniel Migault Ericsson --f46d043be268ad59ec050f53b573 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Scott,

Thanks for the feed back,= this is clearly some text that needs to be added to draft. So options to d= eal with the compression of the ICV are:
=C2=A0 =C2=A0 - a) Allowi= ng ICV compression with some restrictions like the ones you mention.
=C2=A0 =C2=A0 - b) Not allowing ICV compression and explicitly listing = encryption algorithms with small ICV

BR,
Daniel
=C2=A0=C2=A0=C2=A0



On Tue, Feb 17, 2015 at 10:= 17 PM, Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com> wrote:=

Others have addressed my = other points; let me talk about the specific issues with GCM.=

=C2=A0

One summary of the issues= found is http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.297.9568&rep= =3Drep1&type=3Dpdf ; the problem with GCM is that:

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 With one successful = forgery, the attacker can modify other packets the same way without detecti= on.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 With a handful of su= ccessful forgeries, the attacker can learn enough to be able to forge arbit= rary messages.

Now, with the full 16 byt= e ICV, this is not a concern (because the probability of the attacker findi= ng one successful forgery is tiny); however once you start reducing the ICV value, well, various guessing strategies start working be= tter.

=C2=A0

Now, neither HMAC nor CMA= C has this problem; yes, with a tiny ICV, someone can generate a forgery by= blindly guessing; however a successful forgery doesn=E2=80=99t give the attacker any information about how to generate a second successfu= l forgery, or any information about the internal state.=C2=A0 Instead, gene= rating a second forgery requires just as much work as you=E2=80=99d expect = (that is, the same amount of work taken to generate the first forgery).

=C2=A0

Hence, while I would sugg= est that you rethink the strategy of allowing tiny ICVs, if you do go ahead= , I would strongly urge you to mandate the use of either HMAC or CMAC to generate those tiny ICVs =E2=80=93 those won=E2=80=99t mak= e a poor situation even worse.

=C2=A0

=C2=A0

From: Daniel M= igault [mailto:mgl= t.ietf@gmail.com]
Sent: Tuesday, February 17, 2015 10:48 AM
To: Scott Fluhrer (sfluhrer)
Cc: 6lo@ietf.org; ipsec@ietf.org<= br> Subject: Re: [IPsec] Diet-ESP

=C2=A0

Hi Scott, <= /u>

Thank you for the fee= d back. I agree that compressing the ICV reduces security related to authen= tication. Let's call this a "weak authentication".=C2=A0

I am not saying it is= a valid argument, but since IPsec enables NULL authentication too, we cons= idered that enabling "weak authentication" would be possible with= a clear warning in the security consideration.

The reason we are looking we are looking for weak au= thentication is to be able to balance authentication with bandwidth optimiz= ation. In fact, suppose you compute the mean/median over a thousand differe= nt value, that one or two values are corrupted may not have much impact overall, and we may prefer to extend th= e life time of the mote for 5 years instead.
=C2=A0

Regarding you comment I think the issue ou raised is= more related to GCM. -- By the way I would be interested to have a descrip= tion or relevant doc describing=C2=A0 why ICV in GCM particularly matters. = One way to address the issue you raised would be:

=C2=A0=C2=A0=C2=A0 - 1) mention the need for weak au= thentication in the requirement draft

=C2=A0=C2=A0=C2=A0 - 2) remove ICV compression from = Diet-ESP

=C2=A0 =C2=A0 - 3) De= fine encryption protocols with weak authentication with different sizes of = the ICV. For example suppose AES-MODEX has an ICV of N, then we may need to= add AES-MODEX_i with i in [0 ... N-1].

The advantage of doin= g so is that it avoids end user to weaken the protocols especially when one= compression is fine with one protocol but not with the others. In that sen= se it looks a better design.

However, I see the following drawbacks:

=C2=A0=C2=A0=C2=A0 - It requires to create multiple = encryption protocols. Unlike compression, implementation cannot use existin= g implementation of AES-MODEX.

=C2=A0=C2=A0=C2=A0 - Negociation for hosts accepting= all AES-MODEX_i with i in [0 ... N-1] requires many SA payload in the IKEv= 2 negotiation. However, we may deal with this with a AES-MODEX_ALL to indic= ate the responder choses its compression.
=C2=A0=C2=A0=C2=A0

BR,
Daniel

=C2=A0

On Tue, Feb 17, 2015 at 6:28 AM, Scott Fluhrer (sflu= hrer) <sfluhrer@= cisco.com> wrote:

Here=E2=80= =99s an issue with this draft; it doesn=E2=80=99t meet the requirements tha= t it claims.=C2=A0 In particular, it claims that it is based on standard IPsec, and that its sec= urity is equivalent to IPsec (R1-R3).=C2=A0 However, it allows (and, as far= as I am concerned, encourages) the use of tiny ICVs; these tiny ICVs intro= duce security vulnerabilities that do not occur within sane configurations of IPsec (where sane includes using a= n integrity transform).=C2=A0 In particular, using tiny ICVs with GCM is a = known security issue.

=C2=A0

Now, it wo= uld be possible to have an encryption protocol that would not have issues with small ICVs (say, by using a wide block cipher); however this would be= rather different than standard IPsec (in part because IPsec was never desi= gned with these minimal bandwidth constraints); either we need to stay with= an IPsec-based protocol (which implies a largish ICV), or go with something else (which would have less o= verhead, but doesn=E2=80=99t look that much like IPsec internally).<= u>

=C2=A0

=C2=A0

Oh, and a = minor note on the IV generation: it=E2=80=99s actually secure to use the sa= me key you use to encrypt to encrypt the counter for the IV; you don=E2=80=99t ne= ed a separate key.

=C2=A0

From: IPsec [m= ailto:ipsec-bou= nces@ietf.org] On Behalf Of Daniel Migault
Sent: Monday, February 16, 2015 10:08 PM
To: 6lo@ietf.org
Cc: ipsec@ietf.o= rg
Subject: [IPsec] Diet-ESP

=C2=A0

Please find the new version of Diet-ESP a compress I= Psec/ESP for IoT. We have implemented and tested Diet-ESP. Compared to the = standard IPsec/ESP, Diet-ESP can reduce the networking overhead added to unprotected data from 100% to a few percent. I will be h= appy to present these draft next IETF.

Feel free to make comments!

The drafts includes:
=C2=A0=C2=A0=C2=A0 1) draft-mglt-6lo-diet-esp-requirements: lists the requirements for Diet-E= SP

=C2=A0=C2=A0=C2=A0 2) draft-mglt-6lo-aes-implicit-iv: indicates how to avoid carrying the IV = in each ESP packet. It is instead generated by each peers. The protocols de= scribed in the draft can be used with the regular IPsec/ESP.

=C2=A0=C2=A0=C2=A0 3)= draft-mglt-6lo-diet-esp describes the core Diet-ESP protocol, that is h= ow to compress/decompress each fields of the standard IPsec/ESP. Compressio= n is discribed through a Diet-ESP Context.
=C2=A0=C2=A0=C2=A0 4) draft-mglt-6lo-diet-esp-payload-compression: describes how the clear te= xt can be compressed before encryption. In fact unless IPsec/ESP is used wi= th NULL encryption, the data in the ESP packet is encrypted. Encryption mak= es compression hard to perform. Instead compressing before encrypting can be very efficient. This makes po= ssible to remove UDP/TPC/IP tunnel headers.
=C2=A0=C2=A0=C2=A0 5) draft-mglt-6lo-diet-esp-context-ikev2-extension: describes how to negoc= iate Diet-ESP with IKEv2. In fact this mostly result in an agreement for th= e DIet-ESP Context. This exchange may then be extended to Diet-HIP Exchange= .

BR,

Daniel

--

Daniel Migault
Orange Labs -- Security
+33 6 70 72= 69 58




--

Daniel Migault

Ericsson




--
Daniel Migault
Ericsson
--f46d043be268ad59ec050f53b573-- From nobody Tue Feb 17 19:44:49 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6FD1A802C; Tue, 17 Feb 2015 19:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSHssa2afQkM; Tue, 17 Feb 2015 19:44:42 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (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 38B5A1A8029; Tue, 17 Feb 2015 19:44:42 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id a1so23175582wgh.12; Tue, 17 Feb 2015 19:44:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wK2jZKPpDJLb2CpLWxbxf4iq9bZeIN4E7lKSEhq5Hlo=; b=jwan7hsi9zhQcmD3etf2Xokirl+h5iB76mlyHPrsUrDCLbFjxFSsessj8kD+rBlSNM l3DgLrNJy7Y+kM+7qMGRgQq/WcmXkohsffRskHbtg80mpktcNkxbnjk70vUx5OIYJvqa HjPmEFdk2Gw9CQ1229sflIhaFD3AINZfcj3Ay+zh7VLcOozs76jKEg4UaLbE0v0xVsIe Cjzg/WLS0WrUFcsUFNDFqGTQ/uia43C3ok7STIEvFh1EwVJCMgsNc/rlKCV8dv+7ubPF O83DfVVthkCwgfCwqHNBORxlFlNrpyiRyH8AE4J/ky0tQ6uUvWliBnNrMhsvy5AHf5gU 6bdg== MIME-Version: 1.0 X-Received: by 10.180.109.193 with SMTP id hu1mr694588wib.25.1424231080981; Tue, 17 Feb 2015 19:44:40 -0800 (PST) Received: by 10.194.68.39 with HTTP; Tue, 17 Feb 2015 19:44:40 -0800 (PST) In-Reply-To: <54E36E1F.60203@gmx.net> References: <54E36E1F.60203@gmx.net> Date: Wed, 18 Feb 2015 04:44:40 +0100 Message-ID: From: Daniel Migault To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=e89a8f3ba7eda8f7df050f54a320 Archived-At: Cc: "ipsec@ietf.org" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [IPsec] Diet-ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 03:44:47 -0000 --e89a8f3ba7eda8f7df050f54a320 Content-Type: text/plain; charset=UTF-8 Hi Hannes, We designing Diet-ESP was to enable motes to secure their communications and provide end-to-end security. This function is important for us and I guess we are not the only one interested in this functionality. We believe it is worth exposing how IPsec can be use to fit the IoT constraints, regardless of what other protocols are providing. There are probably other alternatives (like DTLS), however : - a) DTLS/IPsec address different use cases - b) no real comparison have been made possible between these security protocols designed for IoT, and we believe IPsec is pretty efficient. Current spec may not be perfect. However, the impact on security can largely be under control. First of all Diet-ESP results in the combination of ROHC ROHCoverIPsec which are already standard with deep security reviews. Then most of the compressed fields are not security related. Padding, Pad Len, Next Header have nothing to deal with security. Security related fields are SN, ICV, SPI. SN and SPI are compressed means that they have to be decompressed before applying IPsec/ESP. Because of the compression/decompression these fields are not altered and from an IPsec/ESP perspective compression is transparent. On the other hand, appropriate values MUST be chosen so compression/decompression can occur. In the case of the ICV, this value cannot be decompressed, and thus we have to make things right. Two alternatives are proposed and I would be happy to update the draft with the best one. If you have specific security impacts in mind, please let us know. BR, Daniel On Tue, Feb 17, 2015 at 5:36 PM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Daniel, > > I understand that you spend a lot of time in writing these > specifications but, as mentioned in the past I just do not see the need > for this type of standardization activity. Nobody I have spoken with > asks for this functionality. > > If there is indeed a need for IPsec ESP use in IoT then I am not sure > that the proposed optimizations are so useful given the impact for > security. > > Ciao > Hannes > > On 02/17/2015 04:08 AM, Daniel Migault wrote: > > Please find the new version of Diet-ESP a compress IPsec/ESP for IoT. We > > have implemented and tested Diet-ESP. Compared to the standard > > IPsec/ESP, Diet-ESP can reduce the networking overhead added to > > unprotected data from 100% to a few percent. I will be happy to present > > these draft next IETF. > > > > Feel free to make comments! > > > > The drafts includes: > > 1) draft-mglt-6lo-diet-esp-requirements > > : > > lists the requirements for Diet-ESP > > 2) draft-mglt-6lo-aes-implicit-iv > > : > > indicates how to avoid carrying the IV in each ESP packet. It is instead > > generated by each peers. The protocols described in the draft can be > > used with the regular IPsec/ESP. > > 3) draft-mglt-6lo-diet-esp > > describes the > > core Diet-ESP protocol, that is how to compress/decompress each fields > > of the standard IPsec/ESP. Compression is discribed through a Diet-ESP > > Context. > > 4) draft-mglt-6lo-diet-esp-payload-compression > > < > http://datatracker.ietf.org/doc/draft-mglt-6lo-diet-esp-payload-compression/ > >: > > describes how the clear text can be compressed before encryption. In > > fact unless IPsec/ESP is used with NULL encryption, the data in the ESP > > packet is encrypted. Encryption makes compression hard to perform. > > Instead compressing before encrypting can be very efficient. This makes > > possible to remove UDP/TPC/IP tunnel headers. > > 5) draft-mglt-6lo-diet-esp-context-ikev2-extension > > < > http://datatracker.ietf.org/doc/draft-mglt-6lo-diet-esp-context-ikev2-extension/ > >: > > describes how to negociate Diet-ESP with IKEv2. In fact this mostly > > result in an agreement for the DIet-ESP Context. This exchange may then > > be extended to Diet-HIP Exchange. > > > > BR, > > Daniel > > -- > > Daniel Migault > > Orange Labs -- Security > > +33 6 70 72 69 58 > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > -- Daniel Migault Ericsson --e89a8f3ba7eda8f7df050f54a320 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Hannes,

We designing = Diet-ESP was to enable motes to secure their communications and provide end= -to-end security. This function is important for us and I guess we are not = the only one interested in this functionality.

We believe= it is worth exposing how IPsec can be use to fit the IoT constraints, rega= rdless of what other protocols are providing.

There are proba= bly other alternatives (like DTLS), however :
=C2=A0=C2=A0=C2=A0 - a) DT= LS/IPsec address different use cases
=C2=A0=C2=A0=C2=A0 - b) = no real comparison have been made possible between these security protocols= designed for IoT, and we believe IPsec is pretty efficient.

<= div>Current spec may not be perfect. However, the impact on security can la= rgely be under control. First of all Diet-ESP results in the combination of= ROHC ROHCoverIPsec which are already standard with deep security reviews. = Then most of the compressed fields are not security related. Padding, Pad L= en, Next Header have nothing to deal with security.

Secur= ity related fields are SN, ICV, SPI. SN and SPI are compressed means that t= hey have to be decompressed before applying IPsec/ESP. Because of the compr= ession/decompression these fields are not altered and from an IPsec/ESP per= spective compression is transparent. On the other hand, appropriate values = MUST be chosen so compression/decompression can occur.

In the case o= f the ICV, this value cannot be decompressed, and thus we have to make thin= gs right. Two alternatives are proposed and I would be happy to update the = draft with the best one.

If you have specific security im= pacts in mind, please let us know.

BR,
Daniel


On Tue, Feb 17, 2015 at 5:36 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Daniel,

I understand that you spend a lot of time in writing these
specifications but, as mentioned in the past I just do not see the need
for this type of standardization activity. Nobody I have spoken with
asks for this functionality.

If there is indeed a need for IPsec ESP use in IoT then I am not sure
that the proposed optimizations are so useful given the impact for
security.

Ciao
Hannes

On 02/17/2015 04:08 AM, Daniel Migault wrote:
> Please find the new version of Diet-ESP a compress IPsec/ESP for IoT. = We
> have implemented and tested Diet-ESP. Compared to the standard
> IPsec/ESP, Diet-ESP can reduce the networking overhead added to
> unprotected data from 100% to a few percent. I will be happy to presen= t
> these draft next IETF.
>
> Feel free to make comments!
>
> The drafts includes:
>=C2=A0 =C2=A0 =C2=A01) draft-mglt-6lo-diet-esp-requirements
> <http://datatracker.ietf.org/doc/dr= aft-mglt-6lo-diet-esp-requirements/>:
> lists the requirements for Diet-ESP
>=C2=A0 =C2=A0 =C2=A02) draft-mglt-6lo-aes-implicit-iv
> <http://datatracker.ietf.org/doc/draft-mg= lt-6lo-aes-implicit-iv/>:
> indicates how to avoid carrying the IV in each ESP pa= cket. It is instead
> generated by each peers. The protocols described in the draft can be > used with the regular IPsec/ESP.
>=C2=A0 =C2=A0 =C2=A03) draft-mglt-6lo-diet-esp
> <http://datatracker.ietf.org/doc/draft-mglt-6lo-= diet-esp/> describes the
> core Diet-ESP protocol, that is how to compress/decom= press each fields
> of the standard IPsec/ESP. Compression is discribed through a Diet-ESP=
> Context.
>=C2=A0 =C2=A0 =C2=A04) draft-mglt-6lo-diet-esp-payload-compression
> <http://datatracker.ietf.org= /doc/draft-mglt-6lo-diet-esp-payload-compression/>:
> describes how the clear text can be compressed before= encryption. In
> fact unless IPsec/ESP is used with NULL encryption, the data in the ES= P
> packet is encrypted. Encryption makes compression hard to perform.
> Instead compressing before encrypting can be very efficient. This make= s
> possible to remove UDP/TPC/IP tunnel headers.
>=C2=A0 =C2=A0 =C2=A05) draft-mglt-6lo-diet-esp-context-ikev2-extension<= br> > <http://datatracker.ietf= .org/doc/draft-mglt-6lo-diet-esp-context-ikev2-extension/>:
> describes how to negociate Diet-ESP with IKEv2. In fa= ct this mostly
> result in an agreement for the DIet-ESP Context. This exchange may the= n
> be extended to Diet-HIP Exchange.
>
> BR,
> Daniel
> --
> Daniel Migault
> Orange Labs -- Security
> += 33 6 70 72 69 58
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>




--
Daniel Migault
Ericsson
--e89a8f3ba7eda8f7df050f54a320-- From nobody Tue Feb 17 20:08:37 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD251A8989; Tue, 17 Feb 2015 20:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YP0XLbHjTGEQ; Tue, 17 Feb 2015 20:08:34 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (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 26F2A1A0187; Tue, 17 Feb 2015 20:08:34 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id bs8so38211144wib.0; Tue, 17 Feb 2015 20:08:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CVzqYj+9frGL1ywipxJyAjouI4PTk6Ij+G0NYg+TC+M=; b=e1yTHpwUmtFf1oiZEspFah9gd0xy0I98Pc7ykbwZBPXxLe1wRttA4kRuPLOGETN4h2 LOqhCXlP4qjRDG00Las2Xd7Lt0WLpySbS9QN8GTrFf3iQGfMoZfEIkNWGDE2v5MNJQyl 1F1F4pyFVJJhXOPERCqrHJIYRG0B4QpVmtTlrEmd54lAx0Qgj/ibp8cfJfpD4VsEcB0b hoYLxstd7J096fKOJvjA/jwo4SJ30s2vl7ivxAIgUtRA78D6KyeLg/V0GEhIw0k8TErs KYnv4bfGMi5ICHo3w1TOnq+P5opRO/CqwOszdcpfPQpCBifrlKgpsdLTGISV2XXO+8rl x/NA== MIME-Version: 1.0 X-Received: by 10.181.13.39 with SMTP id ev7mr870128wid.3.1424232513012; Tue, 17 Feb 2015 20:08:33 -0800 (PST) Received: by 10.194.68.39 with HTTP; Tue, 17 Feb 2015 20:08:32 -0800 (PST) In-Reply-To: References: <54E36E1F.60203@gmx.net> Date: Wed, 18 Feb 2015 05:08:32 +0100 Message-ID: From: Daniel Migault To: Paul Wouters Content-Type: multipart/alternative; boundary=f46d043be268040a4a050f54f9f5 Archived-At: Cc: "ipsec@ietf.org" , Hannes Tschofenig , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [IPsec] Diet-ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 04:08:36 -0000 --f46d043be268040a4a050f54f9f5 Content-Type: text/plain; charset=UTF-8 Hi Paul, The bare minimal implementation of IKEv2 and IPsec/ESP have been proposed in lwig WG: draft-ietf-lwig-ikev2-minimal-01.txt and draft-mglt-lwig-minimal-esp-01.txt Diet-ESP is definitely not "tweaking a byte here and there". Instead, it combines ROHC ROHCoverIPsec and IPsec/ESP. This provides the necessary flexibility to provide the appropriated security in any situation. I appreciate you provide feed back, however, I need more technical argument to make you less nervous. BR, Daniel BR, Daniel On Tue, Feb 17, 2015 at 7:32 PM, Paul Wouters wrote: > On Tue, 17 Feb 2015, Hannes Tschofenig wrote: > > If there is indeed a need for IPsec ESP use in IoT then I am not sure >> that the proposed optimizations are so useful given the impact for >> security. >> > > I agree. I think it would be very useful to describe a barebones minimal > IKEv2 feature set and even an ESP minimal set for such use, but tweaking > a byte here and there of the ESP protocol parameters makes we very > nervous. > > Paul > -- Daniel Migault Ericsson --f46d043be268040a4a050f54f9f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Paul,

The bare minimal implemen= tation of IKEv2 and IPsec/ESP have been proposed in lwig WG: draft-ietf-lwig-= ikev2-minimal-01.txt and=C2=A0 draft-mglt-lwig-minimal-esp-01.txt=C2= =A0

Diet-ESP is definitely not "tweaking a byte = here and there". Instead, it combines ROHC ROHCoverIPsec and IPsec/ESP= . This provides the necessary flexibility to provide the appropriated secur= ity in any situation.

I appreciate you provide feed back, however, I= need more technical argument to make you less nervous.

B= R,
Daniel

BR,
Daniel
<= div class=3D"gmail_extra">
On Tue, Feb 17, 20= 15 at 7:32 PM, Paul Wouters <paul@nohats.ca> wrote:
On Tue, 17 Feb 2015, Hannes Tschofe= nig wrote:

If there is indeed a need for IPsec ESP use in IoT then I am not sure
that the proposed optimizations are so useful given the impact for
security.

 I agree. I think it would be very useful to describe a barebones minimal IKEv2 feature set and even an ESP minimal set for such use, but tweaking a byte here and there of the ESP protocol parameters makes we very
nervous.

Paul



--
Daniel Migault
Er= icsson
--f46d043be268040a4a050f54f9f5-- From nobody Tue Feb 17 20:12:43 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BC31A924A; Tue, 17 Feb 2015 20:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXY4Tr1NmNpL; Tue, 17 Feb 2015 20:12:39 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (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 72B7F1A9237; Tue, 17 Feb 2015 20:12:39 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id em10so38505808wid.5; Tue, 17 Feb 2015 20:12:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+/mBLMU66S0STfNUAs+VWT6sLV0iL4TjFzfo6iLpEgM=; b=tgYD2lUx86/DO2CwoeL+/HtZuIqz+QiwS79qjOvlCA0Yx5FBMevU4M74KhEOyo7eeH R1up75GqEXSryYuCxbt6il3En85/E8AjWZPqb3yZmIVz+RJGUoozJTdBhyyfbsZ7oQVj VSsxPlxCD0KMi4mf68kpJBgbFT6kqi2LLFsfVTGv+CnaK3s4CtaOswldzXNVeetsYOaD /k1fL0M9ysT7RimXpjq/JW720pTUYmqwsokNAOnuIRzOopZVgP4tJOeIw0IVQbSW9eex oKO95AQbgsUpihNYfPSDmGQHuMObAkDeXs7Y5w7wiQKHOfBizRQOoD4+FVK/qZRtP5DQ FL/g== MIME-Version: 1.0 X-Received: by 10.180.189.203 with SMTP id gk11mr961837wic.32.1424232758009; Tue, 17 Feb 2015 20:12:38 -0800 (PST) Received: by 10.194.68.39 with HTTP; Tue, 17 Feb 2015 20:12:37 -0800 (PST) In-Reply-To: References: <54E36E1F.60203@gmx.net> Date: Wed, 18 Feb 2015 05:12:37 +0100 Message-ID: From: Daniel Migault To: Paul Wouters Content-Type: multipart/alternative; boundary=001a11c325769e66b6050f550773 Archived-At: Cc: "ipsec@ietf.org" , Hannes Tschofenig , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [IPsec] Diet-ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 04:12:41 -0000 --001a11c325769e66b6050f550773 Content-Type: text/plain; charset=UTF-8 Hi Paul, I click send too quickly. I agree that providing the minimal description for ESP and IKEv2 is useful, however Diet-ESP and minimal implementations have different goals. BR, Daniel On Wed, Feb 18, 2015 at 5:08 AM, Daniel Migault wrote: > Hi Paul, > > The bare minimal implementation of IKEv2 and IPsec/ESP have been proposed > in lwig WG: draft-ietf-lwig-ikev2-minimal-01.txt > and > draft-mglt-lwig-minimal-esp-01.txt > > > Diet-ESP is definitely not "tweaking a byte here and there". Instead, it > combines ROHC ROHCoverIPsec and IPsec/ESP. This provides the necessary > flexibility to provide the appropriated security in any situation. > > I appreciate you provide feed back, however, I need more technical > argument to make you less nervous. > > BR, > Daniel > > BR, > Daniel > > On Tue, Feb 17, 2015 at 7:32 PM, Paul Wouters wrote: > >> On Tue, 17 Feb 2015, Hannes Tschofenig wrote: >> >> If there is indeed a need for IPsec ESP use in IoT then I am not sure >>> that the proposed optimizations are so useful given the impact for >>> security. >>> >> >> I agree. I think it would be very useful to describe a barebones minimal >> IKEv2 feature set and even an ESP minimal set for such use, but tweaking >> a byte here and there of the ESP protocol parameters makes we very >> nervous. >> >> Paul >> > > > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson --001a11c325769e66b6050f550773 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Paul,

I click send too qui= ckly. I agree that providing the minimal description for ESP and IKEv2 is u= seful, however Diet-ESP and minimal implementations have different goals.
BR,
Daniel

<= div class=3D"gmail_quote">On Wed, Feb 18, 2015 at 5:08 AM, Daniel Migault <= span dir=3D"ltr"><mglt.ietf@gmail.com> wrote:
Hi Paul,

The bare minimal impl= ementation of IKEv2 and IPsec/ESP have been proposed in lwig WG: draft-ietf-lwig-ikev2-minimal-01.txt and=C2=A0 draft-mglt-lwig-minimal-esp-01.txt=C2=A0

Diet-ESP = is definitely not "tweaking a byte here and there". Instead, it c= ombines ROHC ROHCoverIPsec and IPsec/ESP. This provides the necessary flexi= bility to provide the appropriated security in any situation.

I appr= eciate you provide feed back, however, I need more technical argument to ma= ke you less nervous.

BR,
Daniel

BR,
Daniel

On Tue, Feb 17, 2015 at 7:32 P= M, Paul Wouters <paul@nohats.ca> wrote:
On Tue, 17 Feb 2015, Hannes Tschofenig wrote:

If there is indeed a need for IPsec ESP use in IoT then I am not sure
that the proposed optimizations are so useful given the impact for
security.

 I agree. I think it would be very useful to describe a barebones minimal IKEv2 feature set and even an ESP minimal set for such use, but tweaking a byte here and there of the ESP protocol parameters makes we very
nervous.

Paul



--
Daniel Migault
Ericsson



--
Daniel Migault
Ericsson
--001a11c325769e66b6050f550773-- From nobody Wed Feb 18 00:26:25 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF5D1A911D; Wed, 18 Feb 2015 00:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mop1teDHsNfk; Wed, 18 Feb 2015 00:26:17 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9380C1A9105; Wed, 18 Feb 2015 00:26:17 -0800 (PST) Received: from [192.168.131.129] ([80.92.119.127]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MEtba-1YMOSa3U7e-00G12a; Wed, 18 Feb 2015 09:26:15 +0100 Message-ID: <54E44C51.3070800@gmx.net> Date: Wed, 18 Feb 2015 09:24:49 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Daniel Migault References: <54E36E1F.60203@gmx.net> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FnBvP4Hkksch2As2kMqFwNIhMFmQnFecS" X-Provags-ID: V03:K0:2vpVSgOREUYfzjWo2scf2S3jsilwh8kbwFHRCli5NHVqdNC6eVk KEoJpUgThxqQ+cv/5J5Bbjafqp1o/uKeqVpnT1b9ZlM+C8p7cADeSVrnQkzDvkJjgCNEDDr 2IFBU1w7qfiTWYdAYvhLYaLIXUU2WmiVTb7P6ogWqtXlAgt7Lt0FTliw1YnqFg3d4d6DKbT gILFu4jrdEBXyzjD0i05w== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "ipsec@ietf.org" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [IPsec] Diet-ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 08:26:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FnBvP4Hkksch2As2kMqFwNIhMFmQnFecS Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Daniel, I would like to understand your use case a bit better. Just securing sensor communication is not enough. What application layer protocols do you expect to run on these devices? What radio technologies do you assume are going to be used? How does the envisioned stack on these devices look like? Ciao Hannes On 02/18/2015 04:44 AM, Daniel Migault wrote: > Hi Hannes, >=20 > We designing Diet-ESP was to enable motes to secure their communication= s > and provide end-to-end security. This function is important for us and = I > guess we are not the only one interested in this functionality. >=20 > We believe it is worth exposing how IPsec can be use to fit the IoT > constraints, regardless of what other protocols are providing. >=20 > There are probably other alternatives (like DTLS), however : > - a) DTLS/IPsec address different use cases > - b) no real comparison have been made possible between these > security protocols designed for IoT, and we believe IPsec is pretty > efficient. >=20 > Current spec may not be perfect. However, the impact on security can > largely be under control. First of all Diet-ESP results in the > combination of ROHC ROHCoverIPsec which are already standard with deep > security reviews. Then most of the compressed fields are not security > related. Padding, Pad Len, Next Header have nothing to deal with securi= ty. >=20 > Security related fields are SN, ICV, SPI. SN and SPI are compressed > means that they have to be decompressed before applying IPsec/ESP. > Because of the compression/decompression these fields are not altered > and from an IPsec/ESP perspective compression is transparent. On the > other hand, appropriate values MUST be chosen so > compression/decompression can occur. >=20 > In the case of the ICV, this value cannot be decompressed, and thus we > have to make things right. Two alternatives are proposed and I would be= > happy to update the draft with the best one. >=20 > If you have specific security impacts in mind, please let us know. >=20 > BR, > Daniel >=20 >=20 > On Tue, Feb 17, 2015 at 5:36 PM, Hannes Tschofenig > > wrote: >=20 > Daniel, >=20 > I understand that you spend a lot of time in writing these > specifications but, as mentioned in the past I just do not see the = need > for this type of standardization activity. Nobody I have spoken wit= h > asks for this functionality. >=20 > If there is indeed a need for IPsec ESP use in IoT then I am not su= re > that the proposed optimizations are so useful given the impact for > security. >=20 > Ciao > Hannes >=20 > On 02/17/2015 04:08 AM, Daniel Migault wrote: > > Please find the new version of Diet-ESP a compress IPsec/ESP for = IoT. We > > have implemented and tested Diet-ESP. Compared to the standard > > IPsec/ESP, Diet-ESP can reduce the networking overhead added to > > unprotected data from 100% to a few percent. I will be happy to p= resent > > these draft next IETF. > > > > Feel free to make comments! > > > > The drafts includes: > > 1) draft-mglt-6lo-diet-esp-requirements > > > : > > lists the requirements for Diet-ESP > > 2) draft-mglt-6lo-aes-implicit-iv > > = : > > indicates how to avoid carrying the IV in each ESP packet. It is = instead > > generated by each peers. The protocols described in the draft can= be > > used with the regular IPsec/ESP. > > 3) draft-mglt-6lo-diet-esp > > > describes the > > core Diet-ESP protocol, that is how to compress/decompress each f= ields > > of the standard IPsec/ESP. Compression is discribed through a Die= t-ESP > > Context. > > 4) draft-mglt-6lo-diet-esp-payload-compression > > > : > > describes how the clear text can be compressed before encryption.= In > > fact unless IPsec/ESP is used with NULL encryption, the data in t= he ESP > > packet is encrypted. Encryption makes compression hard to perform= =2E > > Instead compressing before encrypting can be very efficient. This= makes > > possible to remove UDP/TPC/IP tunnel headers. > > 5) draft-mglt-6lo-diet-esp-context-ikev2-extension > > > : > > describes how to negociate Diet-ESP with IKEv2. In fact this most= ly > > result in an agreement for the DIet-ESP Context. This exchange ma= y then > > be extended to Diet-HIP Exchange. > > > > BR, > > Daniel > > -- > > Daniel Migault > > Orange Labs -- Security > > +33 6 70 72 69 58 > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > >=20 >=20 >=20 >=20 > --=20 > Daniel Migault > Ericsson >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 --FnBvP4Hkksch2As2kMqFwNIhMFmQnFecS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU5ExRAAoJEGhJURNOOiAtbBEH/R3NPyljgO4Y8hLZswXGLfWW VZkE01QHy2jX0UZ02XJdpHb6Fu6OD8dcai2OMeEmqBb08JxM2TlUg6cHeiDrWSWY RtpclvmGBCkVKUF0ewx70xb/n0CexobyPCgL3Ag9yapy0bgkUIyDFvRUf8KNySIQ sB9RDUrvAPNSVjmn3UNi+P3Cxr++pw/1SX7qYVNt/DfT1k9y/XPaRyYIf5Mb8d/n 9W+fJXmA0YE8RCh6YcliYm/Q1Ti0ARmZ4YCFAtqSsuV3qd/02IIhbft3jeX8/NLq +nqWV0cMVAOY74MpybaviwxkCcXoojtvrkX4f/B+CQQZe1NzT3mSmntpwyNy00s= =Xyb2 -----END PGP SIGNATURE----- --FnBvP4Hkksch2As2kMqFwNIhMFmQnFecS-- From nobody Wed Feb 18 06:46:12 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8B11A87A1; Wed, 18 Feb 2015 06:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPX8vf3ThWvN; Wed, 18 Feb 2015 06:46:10 -0800 (PST) Received: from ausxipps310.us.dell.com (AUSXIPPS310.us.dell.com [143.166.148.211]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3DB1A87F0; Wed, 18 Feb 2015 06:46:09 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:Return-Path; b=BGx/AyesvN6biJe56p/n6qmK+eC04OaAudZBd63ee2qC+SatPOrmK9D2 umdkaUG/YOQDgeCsp+0uJWnFbybe91xKwD0VD9pZ8FkioMiH4G4qr7yrB lXpijtU4PpfLWuL3V04NaYwt1ZkX7/BbiLMVu1KtgUXVcPsgWHFdZzSOk M=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1424270769; x=1455806769; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SI7Fdi4sDEcIZTmyh24k65sJFFkhVLF3ICpOW+Exet4=; b=eY8L/9i4rxJxAEABa7B7go2c60uDW4tE6KKw1rlybL+IqGRBSgE4oUX9 IaeitEWV9TfsB/cVT6rkf6T0ijvudCejiiW4VKovQBSPe/6RluOMljtSt VnzaIHihveNe9KCJ6caquDBNAiY3E5eiwahvLR0Begzyju8HPy1xjx+OW o=; X-LoopCount0: from 10.175.216.249 X-IronPort-AV: E=Sophos;i="5.09,602,1418104800"; d="scan'208";a="139576383" From: To: Thread-Topic: [IPsec] Diet-ESP Thread-Index: AQHQSl75xE+o8+vV1EeSaJw0LSQ4lZz0tNgAgACtJQCAAFwJgIAAWawAgADLX4A= Date: Wed, 18 Feb 2015 14:46:02 +0000 Message-ID: <842E87C5-5E05-44DA-AAD7-50E92B456825@dell.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.132.132] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: ipsec@ietf.org, 6lo@ietf.org, sfluhrer@cisco.com Subject: Re: [IPsec] Diet-ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 14:46:11 -0000 DQo+IE9uIEZlYiAxNywgMjAxNSwgYXQgOTozOCBQTSwgRGFuaWVsIE1pZ2F1bHQgPG1nbHQuaWV0 ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gSGkgU2NvdHQsIA0KPiANCj4gVGhhbmtzIGZvciB0 aGUgZmVlZCBiYWNrLCB0aGlzIGlzIGNsZWFybHkgc29tZSB0ZXh0IHRoYXQgbmVlZHMgdG8gYmUg YWRkZWQgdG8gZHJhZnQuIFNvIG9wdGlvbnMgdG8gZGVhbCB3aXRoIHRoZSBjb21wcmVzc2lvbiBv ZiB0aGUgSUNWIGFyZToNCj4gICAgIC0gYSkgQWxsb3dpbmcgSUNWIGNvbXByZXNzaW9uIHdpdGgg c29tZSByZXN0cmljdGlvbnMgbGlrZSB0aGUgb25lcyB5b3UgbWVudGlvbi4gDQo+ICAgICAtIGIp IE5vdCBhbGxvd2luZyBJQ1YgY29tcHJlc3Npb24gYW5kIGV4cGxpY2l0bHkgbGlzdGluZyBlbmNy eXB0aW9uIGFsZ29yaXRobXMgd2l0aCBzbWFsbCBJQ1YNCg0KSSBhbSBvcHBvc2VkIHRvIGFueSDi gJxkaWV0IEVTUOKAnSBwcm9wb3NhbCB0aGF0IHdlYWtlbnMgdGhlIHNlY3VyaXR5IHByb3BlcnRp ZXMgb2YgdGhlIHByb3RvY29sLiAgQmFuZHdpZHRoIHJlZHVjdGlvbiBpcyBhIHNvbWV3aGF0IGlu dGVyZXN0aW5nIGdvYWwsIGFuZCBpZiB5b3UgY2FuIHRyaW0gZG93biBFU1Agd2hpbGUgbGVhdmlu ZyBpdHMgc3RyZW5ndGggdW5jaGFuZ2VkIChvciBpbXByb3ZlZCBvZiBjb3Vyc2UpLCBmaW5lLiAg SWYgaXQgd2Vha2VucyBpdCwgSSBkaXNhcHByb3ZlLg0KDQoJcGF1bA0K From nobody Thu Feb 19 22:40:53 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFF71A6FF5; Thu, 19 Feb 2015 22:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K91cP1NHBs95; Thu, 19 Feb 2015 22:40:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2BA1A2130; Thu, 19 Feb 2015 22:40:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150220064049.31224.23511.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 22:40:49 -0800 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-null-auth-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 06:40:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : The NULL Authentication Method in IKEv2 Protocol Authors : Valery Smyslov Paul Wouters Filename : draft-ietf-ipsecme-ikev2-null-auth-04.txt Pages : 13 Date : 2015-02-19 Abstract: This document specifies the NULL Authentication method and the ID_NULL Identification Payload ID Type for the IKEv2 Protocol. This allows two IKE peers to establish single-side authenticated or mutual unauthenticated IKE sessions for those use cases where a peer is unwilling or unable to authenticate or identify itself. This ensures IKEv2 can be used for Opportunistic Security (also known as Opportunistic Encryption) to defend against Pervasive Monitoring attacks without the need to sacrifice anonymity. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-null-auth-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 19 22:45:14 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCA41A1AB3 for ; Thu, 19 Feb 2015 22:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.791 X-Spam-Level: X-Spam-Status: No, score=-0.791 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, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAmOnsoelhln for ; Thu, 19 Feb 2015 22:45:11 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::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 050001A1A19 for ; Thu, 19 Feb 2015 22:45:11 -0800 (PST) Received: by lbiw7 with SMTP id w7so4421019lbi.9 for ; Thu, 19 Feb 2015 22:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=+a2e0m1JTVHU4k3w7yFZ1cvB9TzULLec+H5CoTaS+Ek=; b=NtdFp8vDqXDem5/Mm9hcub54YRgKglmp7USgG3s8bVRxbepajOvWem43RSilXnc6YX wecC16zTapJV66rJpfv9XIVstpjWvjy6xcY9EiDp8JloHv07ZZVZYPL8jKohKh/riwOn bUrcKZaRS5C+Rc6BhU0Ox0IoPWyXSkfAZq8S6AQ3rTNoGPNKG+6sIdgUeT30bMJYkNUY JEtQsjDvyn86y93XoN1tst+lKEzUqRUlwYhrJ+a27gu5ItL9DY/xvaRk7Qw6C+wtv1WF lqEWeQtOZxwMhnryFl8hCPNImhdusTaIFz2YahEEr1PTg9F0Y31ulSkUrMkKRA5JnZqa 84wg== X-Received: by 10.112.14.196 with SMTP id r4mr7242467lbc.86.1424414709504; Thu, 19 Feb 2015 22:45:09 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id r3sm5288899lar.35.2015.02.19.22.45.08 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 19 Feb 2015 22:45:08 -0800 (PST) Message-ID: <2CD32CDA9D124F898F45B715F5FF6F79@buildpc> From: "Valery Smyslov" To: References: <20150220064049.31224.23511.idtracker@ietfa.amsl.com> Date: Fri, 20 Feb 2015 09:45:06 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: Paul Wouters Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-null-auth-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 06:45:13 -0000 Hi all, new version of the draft is published. It addresses the comments received during the second WGLC. Valery & Paul. ----- Original Message ----- From: To: Cc: Sent: Friday, February 20, 2015 9:40 AM Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-null-auth-04.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Security Maintenance and Extensions > Working Group of the IETF. > > Title : The NULL Authentication Method in IKEv2 Protocol > Authors : Valery Smyslov > Paul Wouters > Filename : draft-ietf-ipsecme-ikev2-null-auth-04.txt > Pages : 13 > Date : 2015-02-19 > > Abstract: > This document specifies the NULL Authentication method and the > ID_NULL Identification Payload ID Type for the IKEv2 Protocol. This > allows two IKE peers to establish single-side authenticated or mutual > unauthenticated IKE sessions for those use cases where a peer is > unwilling or unable to authenticate or identify itself. This ensures > IKEv2 can be used for Opportunistic Security (also known as > Opportunistic Encryption) to defend against Pervasive Monitoring > attacks without the need to sacrifice anonymity. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-null-auth-04 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Feb 20 15:05:21 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA311A028A for ; Fri, 20 Feb 2015 15:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J_85T3lmB2-r for ; Fri, 20 Feb 2015 15:05:18 -0800 (PST) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4725B1A0276 for ; Fri, 20 Feb 2015 15:05:18 -0800 (PST) Received: from [10.20.30.101] (142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t1KN5GmB085318 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 Feb 2015 16:05:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245] claimed to be [10.20.30.101] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9B180462-E4E7-4BD1-9ED2-C88DED87A377@vpnc.org> Date: Fri, 20 Feb 2015 15:05:16 -0800 To: IPsecME WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [IPsec] Dallas meeting, likely in the last slot on Friday X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 23:05:19 -0000 Greetings again. The preliminary schedule for the Dallas meeting has = been published (https://datatracker.ietf.org/meeting/92/agenda.html) and = IPsecME WG is in the last slot on Friday. If you haven't made your air = reservations yet (I don't think we have any active participants who = actually live in Dallas...), please don't assume you can leave the IETF = "early". --Paul Hoffman= From nobody Tue Feb 24 03:21:37 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A6E1A07BD for ; Tue, 24 Feb 2015 03:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qySosbUzufTp for ; Tue, 24 Feb 2015 03:21:34 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::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 CEC101A079D for ; Tue, 24 Feb 2015 03:21:33 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id l15so24238169wiw.3 for ; Tue, 24 Feb 2015 03:21:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=i06Mkq2edSnIA0O4eW3z+WT0+ybsntI085htqpcEOZk=; b=BqnA4PTr7j340OtYlL0Jvw7a/y9esjaI3KM3YjVUkIlBLonCv2A+JQg+mroW+ZSAd2 yfGQli96xWT4qDO77k5Z//uoJij5+P9nhhFCebulsJu/51Ae7aMLCP9Wejcfw3MlPNAJ 8I82QoXNYCLU1mBaCBZT9ILcedo+KxxwT+M2TJqtULNGn0hQOkyBJ0LUsndG/yGarLO7 TGuiK0DeWZZSKGXLaMxPmglKwMxpVy+rkDia28IEHJwbJQAunPGtlDBQIPHHC6jnYUnP QFUeFQtfYZA+ame4KNpO8172sbOOm7NYi9yEWk9bLzkNDs2qG6eNbM8uodeAd2m6ct3g AgJA== X-Received: by 10.180.72.98 with SMTP id c2mr29719677wiv.87.1424776892669; Tue, 24 Feb 2015 03:21:32 -0800 (PST) Received: from [172.24.251.208] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id hi6sm59771851wjc.34.2015.02.24.03.21.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Feb 2015 03:21:31 -0800 (PST) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_0E3E7D4C-CDDE-4381-853B-BF204DCF2C95" Message-Id: <798DAF77-94CB-4AF4-AECC-5039808F147F@gmail.com> Date: Tue, 24 Feb 2015 13:21:29 +0200 To: IPsecME WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [IPsec] ChaCha20 + Poly1305 for IKE and IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 11:21:35 -0000 --Apple-Mail=_0E3E7D4C-CDDE-4381-853B-BF204DCF2C95 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi A little over a year ago I proposed to define the ChaCha20 cipher and = Poly1305 authenticators for IKE and IPsec both as standalone documents = and as an AEAD. At the same time Adam Langley proposed the same to the = TLS working group. We were told two things: First, the groups preferred only the AEAD, and = second, we were requested to get CFRG=E2=80=99s stamp of approval. This resulted in a CFRG document defining the algorithms, and offering = implementation advice and test vectors. This document has just been = approved and has been sent to the RFC editor [1]. In the meantime, I have updated my draft to only define the AEAD. Since = we not have CFRG=E2=80=99s =E2=80=9Cstamp of approval=E2=80=9D if not = yet an RFC number, I would like to renew my request to have the = ChaCha20+Poly1305 for IKE and IPsec document [2] accepted by this = working group with the intent of having it published as a standard-track = document. Thanks Yoav [1] = https://datatracker.ietf.org/doc/draft-irtf-cfrg-chacha20-poly1305/history= / = [2] https://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305-05 = --Apple-Mail=_0E3E7D4C-CDDE-4381-853B-BF204DCF2C95 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi

A little over a year ago I proposed to = define the ChaCha20 cipher and Poly1305 authenticators for IKE and IPsec = both as standalone documents and as an AEAD. At the same time Adam = Langley proposed the same to the TLS working group.

We were told two things: = First, the groups preferred only the AEAD, and second, we were requested = to get CFRG=E2=80=99s stamp of approval.

This resulted in a CFRG document = defining the algorithms, and offering implementation advice and test = vectors. This document has just been approved and has been sent to the = RFC editor [1].

In the meantime, I have updated my draft to only define the = AEAD. Since we not have CFRG=E2=80=99s =E2=80=9Cstamp of approval=E2=80=9D= if not yet an RFC number, I would like to renew my request to have the = ChaCha20+Poly1305 for IKE and IPsec document [2] accepted by this = working group with the intent of having it published as a standard-track = document.

Thanks

Yoav

[1] https://datatracker.ietf.org/doc/draft-irtf-cfrg-chacha20-poly1= 305/history/
[2] https://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305= -05

= --Apple-Mail=_0E3E7D4C-CDDE-4381-853B-BF204DCF2C95-- From nobody Tue Feb 24 05:26:46 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF241A1A99 for ; Tue, 24 Feb 2015 05:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRJZ-KJvZtpZ for ; Tue, 24 Feb 2015 05:26:42 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (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 825F81A1A82 for ; Tue, 24 Feb 2015 05:26:42 -0800 (PST) Received: by wgha1 with SMTP id a1so5249751wgh.12 for ; Tue, 24 Feb 2015 05:26:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=eFhrmO1WYwqpUOGMGqtZH5i4Bs411y5gx8qlYcBA30I=; b=qdBTKzqgusxp+S2O9/9ZxlkQ02geWePk1d7G4YWXuPZXUDaY2jvTM32ageeP/7pBW6 5nWg0IQY3b4RRzBWjvCT3EgkrYbbVkDB+hRhd4CzSB+sAX/+bCi+A5Mbka0+uSRWs7sh 5ksF7AL69effDztvWD7bwXrGU51HYUExPoWsCE6bMxHLwZ0zWpHo4gVfaoAn9RDpjQZl vtk/zYy8zgUhqwZQwph+oYAKVz9z2x7sVKU+uUMZWHp9ASQr18qEYHeae6OEGzgPAqRk 5HfjF63KnD5JB8GvcxjmtdLqUKL6YBm0X+hnXzttcsE21oMZ7UvfRloy3RruMQq80YqB /FGQ== X-Received: by 10.194.87.100 with SMTP id w4mr31545455wjz.65.1424784401362; Tue, 24 Feb 2015 05:26:41 -0800 (PST) Received: from [172.24.251.208] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id v16sm20549986wib.5.2015.02.24.05.26.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Feb 2015 05:26:40 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <798DAF77-94CB-4AF4-AECC-5039808F147F@gmail.com> Date: Tue, 24 Feb 2015 15:26:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <798DAF77-94CB-4AF4-AECC-5039808F147F@gmail.com> To: IPsecME WG X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [IPsec] ChaCha20 + Poly1305 for IKE and IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 13:26:44 -0000 > On Feb 24, 2015, at 1:21 PM, Yoav Nir wrote: >=20 > In the meantime, I have updated my draft to only define the AEAD. = Since we not have CFRG=E2=80=99s =E2=80=9Cstamp of approval=E2=80=9D =E2=80= =A6 * Since we **now** have...= From nobody Tue Feb 24 06:24:22 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3EC71A1BB7 for ; Tue, 24 Feb 2015 06:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xMIlkX2LWZZ for ; Tue, 24 Feb 2015 06:24:19 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8098B1A1B64 for ; Tue, 24 Feb 2015 06:24:19 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7022F20098 for ; Tue, 24 Feb 2015 09:32:30 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 4497163A21; Tue, 24 Feb 2015 09:24:18 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 29D93637F4 for ; Tue, 24 Feb 2015 09:24:18 -0500 (EST) From: Michael Richardson To: IPsecME WG In-Reply-To: References: <798DAF77-94CB-4AF4-AECC-5039808F147F@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: Re: [IPsec] ChaCha20 + Poly1305 for IKE and IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 14:24:21 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: >> On Feb 24, 2015, at 1:21 PM, Yoav Nir wrote: >> >> In the meantime, I have updated my draft to only define the >> AEAD. Since we now have CFRG=E2=80=99s =E2=80=9Cstamp of approval=E2= =80=9D =E2=80=A6 I needed to read up on these things, and I read: ChaCha20+Poly1305 can be as much as 300% faster than AES-256-GCM with SHA= -1 authentication. and claims that Poly1305 is faster than SHA1/2/3. This is certainly interesting to me. {I'm very concerned in the IoT space (not really IPsec related at all), that we are cooking too much AES-GCM in as the one and only choice, and may lose algorithm agility in protocols.} I am supportive of defining code points for these. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVOyJkYCLcPvd0N1lAQKpSAf9EGie9z13ma3kHlGdCEPFBKzg5JJr+79N 7M6B+WT+tJ3/pKYTFrjOtoWpFXVNz8io1v/OEKrXuPOWbJQIof1AiZqDUUSaWl3G qOHdbn/9M75LpjrM4vW1Ryu/d607HyHYuyU+rZrwstXxkYEOPJAxEhV8n3xZi6oN VgHnbbDhzn53LNN/+AaQVOk5bw/lZPVsDbrLKFi/ArTE5kblaHQQQZBawgLCdYsc 61rZy2s9jcFssJ3bH3Ew4lWcxY/p3xuwsuF8Oqgd2ALG5t+RS/mVV1s9EqOmAl08 pYtK2Uas4t4AeUJzudBvDJ+GWhD3+0Rq8T9grhM4olQRKS1pU5M0MA== =95gV -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 24 06:49:13 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAFB1A1BB3 for ; Tue, 24 Feb 2015 06:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBpTFK-9kPIB for ; Tue, 24 Feb 2015 06:49:10 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (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 5CA181A06E9 for ; Tue, 24 Feb 2015 06:49:10 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id em10so25704129wid.5 for ; Tue, 24 Feb 2015 06:49:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+hpt7zz2K5wn8/XmAxJUCSD64ZHCMJOULOqF4pYL8c0=; b=tfc56udtDnqSuo5Y5++W/fRd72csVPY0L643X6rDnv1QK1t+CiHFoArqm9fJByKHKJ q9TgYdr4KMqjgyT+6ycW+6sVxfWfxNle+IDEXI+++IUpM98Xe7C5NinevIcsYzytDx5h 6RPTQWL/cqOuvQ9uS8Y3yXKcrEM725gqJz+a/CWdHdqJN8fWedq34XKncqUEIRIo90cU 3sfZCbYWJVdBFbbZQATpFZT9Q9cmZucjPTZBKmOl7Aq6GmF0OrrggHy87HSWZiVvy2uv Jr2wrMgfUYVk+T4hnlsMka1ZhpFARWuaIpRkjGHbLDnB16qeZ/bXY02nCUvBm5L4dJ4J vtSg== X-Received: by 10.194.242.6 with SMTP id wm6mr32589508wjc.7.1424789347568; Tue, 24 Feb 2015 06:49:07 -0800 (PST) Received: from [172.24.251.208] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id nb9sm20877262wic.3.2015.02.24.06.49.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Feb 2015 06:49:06 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <30671.1424787858@sandelman.ca> Date: Tue, 24 Feb 2015 16:49:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <798DAF77-94CB-4AF4-AECC-5039808F147F@gmail.com> <30671.1424787858@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] ChaCha20 + Poly1305 for IKE and IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 14:49:12 -0000 > On Feb 24, 2015, at 4:24 PM, Michael Richardson = wrote: >=20 >=20 > Yoav Nir wrote: >>> On Feb 24, 2015, at 1:21 PM, Yoav Nir wrote: >>>=20 >>> In the meantime, I have updated my draft to only define the >>> AEAD. Since we now have CFRG=E2=80=99s =E2=80=9Cstamp of approval=E2=80= =9D =E2=80=A6 >=20 > I needed to read up on these things, and I read: > ChaCha20+Poly1305 can be as much as 300% faster than AES-256-GCM with = SHA-1 > authentication. I=E2=80=99m guessing you mean AES-256-CBC, because if you use GCM, you = don=E2=80=99t need SHA-1. Either way, these values are right for older = Intel chips as well as ARM and whatever is it that runs in the IoT = space. Newer Intel chips with the AESENC opcode have faster AES-GCM than = ChaCha20+Poly1305. > and claims that Poly1305 is faster than SHA1/2/3. > This is certainly interesting to me. >=20 > {I'm very concerned in the IoT space (not really IPsec related at = all), that > we are cooking too much AES-GCM in as the one and only choice, and may = lose > algorithm agility in protocols.} Interesting. I thought they were baking AES-CCM into IoT standards. = ChaCha20+Poly1305 are attractive options because of a very small code = base, and a 64-byte workspace for ChaCha (16 x 32-bit ints). Can=E2=80=99t= get below ~500 bytes for AES. > I am supportive of defining code points for these. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- Thanks Yoav From nobody Tue Feb 24 07:47:16 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA5F1A8746 for ; Tue, 24 Feb 2015 07:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAkShczV40LT for ; Tue, 24 Feb 2015 07:47:12 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00C8E1A87E6 for ; Tue, 24 Feb 2015 07:47:02 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t1OFkwKX008474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 24 Feb 2015 17:46:58 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t1OFkvOE025596; Tue, 24 Feb 2015 17:46:57 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <21740.40177.565261.763871@fireball.kivinen.iki.fi> Date: Tue, 24 Feb 2015 17:46:57 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <798DAF77-94CB-4AF4-AECC-5039808F147F@gmail.com> <30671.1424787858@sandelman.ca> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 9 min Archived-At: Cc: IPsecME WG , Michael Richardson Subject: Re: [IPsec] ChaCha20 + Poly1305 for IKE and IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 15:47:14 -0000 Yoav Nir writes: > Interesting. I thought they were baking AES-CCM into IoT standards. > ChaCha20+Poly1305 are attractive options because of a very small > code base, and a 64-byte workspace for ChaCha (16 x 32-bit ints). > Can=E2=80=99t get below ~500 bytes for AES.=20 IEEE 802.15.4 has AES-CCM* in the MAC, and there is no algorithm agility there at all, i.e. no other ciphers are possible. There is possibility to message authentication only, or both message authentication and encryption, and there is possibility to do it with either 32, 64, or 128 bit MIC (message integrity code) lengths. Other radio interfaces might of course use something else, and upper layers running over IEEE 802.15.4 or similar might use their own security methods. In the 802.15.4 chipsets there is quite often AES hardware accelerator that can do the AES modes needed for AES-CCM, and because of that the upper layers might also want to use AES-CCM instead of ChaCha20+Poly1305. Anyways I think adding ChaCha20+Poly1305 to algorithms usable in IPsec is good thing, and I support this work. --=20 kivinen@iki.fi From nobody Thu Feb 26 06:48:15 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1653E1A017D for ; Thu, 26 Feb 2015 06:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjXsGBzusHBw for ; Thu, 26 Feb 2015 06:48:12 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A525E1A0199 for ; Thu, 26 Feb 2015 06:48:12 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ktH15622Nz5FY; Thu, 26 Feb 2015 15:48:09 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=K5+n3bP3; dkim-adsp=pass X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id mGn0ZXCvons6; Thu, 26 Feb 2015 15:48:08 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 26 Feb 2015 15:48:08 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D8FE3813B1; Thu, 26 Feb 2015 09:48:07 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1424962087; bh=JCgU1Df/0IcZGNuAm8iJV+XD04aYSVIxcBvVe/Tz20s=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=K5+n3bP36l9Zz6j3YhB+Ni3lyJaezZEbiHE79HGJ3GWVytzbtS3OssNLQmK3ryfsm 3OU7GFA2HKKdY5hfIi3R4iiBok8lURFa3WbJayq+aIKIwwv9KVYVaxe+QXdz/at0QS K7SPv36/+D5Yx0oQjgARodIa+yT+D1BjADgMYOXU= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t1QEm7Zp029462; Thu, 26 Feb 2015 09:48:07 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 26 Feb 2015 09:48:07 -0500 (EST) From: Paul Wouters To: Yoav Nir In-Reply-To: <798DAF77-94CB-4AF4-AECC-5039808F147F@gmail.com> Message-ID: References: <798DAF77-94CB-4AF4-AECC-5039808F147F@gmail.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] ChaCha20 + Poly1305 for IKE and IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 14:48:14 -0000 On Tue, 24 Feb 2015, Yoav Nir wrote: > In the meantime, I have updated my draft to only define the AEAD. Since we not have CFRG’s “stamp of approval” if not yet an RFC number, > I would like to renew my request to have the ChaCha20+Poly1305 for IKE and IPsec document [2] accepted by this working group with the > intent of having it published as a standard-track document. I am in favour of adopting this document for the WG. > [2] https://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305-05 Can we rename ESP_ChaCha20-Poly1305 to ESP_ChaCha20_Poly1305 ? That allows implementors to match the literal IANA string into C-code, which does not allow a "-" symbol. The problem is that if future advances in cryptanalysis reveal a weakness in AES, VPN users will be in an unenviable position. With the only other widely supported cipher being the much slower 3DES, I'm not sure if that is completely true. We do have Camellia, although I'm not a cryptographer and it might be too similar to AES. So I still agree with the sentiment of the text. The length of the ciphertext as a 32-bit network order quantity. Can we clarify the number of octets used here without needing to go into another reference document? I kind of dislike using HMAC-SHA-256 but I understand we don't have much choice right now: https://tools.ietf.org/html/draft-irtf-cfrg-chacha20-poly1305-10#section-2.7 Although perhaps we can go back to CRFG and ask if they can give us something that is not based on the SHA2 family? I have no strong opinions about Diffie-Hellman groups. Paul From nobody Thu Feb 26 14:11:34 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754D21A8828 for ; Thu, 26 Feb 2015 14:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eo_qo0E75G0v for ; Thu, 26 Feb 2015 14:11:31 -0800 (PST) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB0611A8783 for ; Thu, 26 Feb 2015 14:11:31 -0800 (PST) Received: from [10.20.30.109] (142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t1QMBUYr005000 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Feb 2015 15:11:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245] claimed to be [10.20.30.109] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <86AC7585-93BD-456D-B75E-F85D2D2A2D7F@vpnc.org> Date: Thu, 26 Feb 2015 14:11:30 -0800 To: IPsecME WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [IPsec] Call for WG adoption: draft-nir-ipsecme-chacha20-poly1305 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 22:11:32 -0000 Greetings again. A few people have expressed interest in having = https://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305 as a WG = item for IPsecME. If you want this as a WG document, and you are willing = to review drafts as they move through, please say so on this thread. If = you are opposed to this being a WG document, please say so (and say = why). Thanks in advance. --Paul Hoffman= From nobody Thu Feb 26 14:38:03 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4C01A8547 for ; Thu, 26 Feb 2015 14:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMYAgP4gnXlK for ; Thu, 26 Feb 2015 14:38:00 -0800 (PST) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (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 A21701A016B for ; Thu, 26 Feb 2015 14:37:59 -0800 (PST) Received: by wghl18 with SMTP id l18so15429493wgh.8 for ; Thu, 26 Feb 2015 14:37:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SiIinotpBNacZAqgV+Ih6mHWuWFbHgvb1LLqLhe6cpo=; b=lB+UBovTS3L/YnfLgI8aoXGC9Ra+7aPLPH4Ipns0892h7mSYDT2O8FIQms1sSIYnTw 52gjkAAf057p2Ro0ckh6giU+ZkDLOOlio5Rripy8LIJMTbHn9R1ooTD+DA3xcS/GS6AR JZsvTDJfP+lfdin+Ei8mm6eZ/CrTX8QwmQUmcWWw3+mIBvncoZVwYxKOry6GU9ab22Um fzW48NSRn1pvtpe5nVDPqUttae4OCziOi5lZra+h5tGg8BIHj94ocC5Rgu3B+oGUD5iV fmR70fugdH0TDBUInYB3qHPPH4H5+jdhmbhnGTOSHoyaRYb2t6pWPNpwverTOuu8oGDn lFyw== X-Received: by 10.194.110.38 with SMTP id hx6mr20995687wjb.128.1424990278384; Thu, 26 Feb 2015 14:37:58 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by mx.google.com with ESMTPSA id m4sm3323697wjb.25.2015.02.26.14.37.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Feb 2015 14:37:57 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Fri, 27 Feb 2015 00:37:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4D31B839-3CC7-4499-AC14-533DCF8EC4B3@gmail.com> References: <798DAF77-94CB-4AF4-AECC-5039808F147F@gmail.com> To: Paul Wouters X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] ChaCha20 + Poly1305 for IKE and IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 22:38:02 -0000 > On Feb 26, 2015, at 4:48 PM, Paul Wouters wrote: >=20 > On Tue, 24 Feb 2015, Yoav Nir wrote: >=20 >> In the meantime, I have updated my draft to only define the AEAD. = Since we not have CFRG=E2=80=99s =E2=80=9Cstamp of approval=E2=80=9D if = not yet an RFC number, >> I would like to renew my request to have the ChaCha20+Poly1305 for = IKE and IPsec document [2] accepted by this working group with the >> intent of having it published as a standard-track document. >=20 > I am in favour of adopting this document for the WG. >=20 >> [2] = https://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305-05 >=20 > Can we rename ESP_ChaCha20-Poly1305 to ESP_ChaCha20_Poly1305 ? That > allows implementors to match the literal IANA string into C-code, = which > does not allow a "-" symbol. Hmm, it=E2=80=99s like version -10 all over again: = http://www.ietf.org/rfcdiff?url1=3Ddraft-irtf-cfrg-chacha20-poly1305-09&ur= l2=3Ddraft-irtf-cfrg-chacha20-poly1305-10 > The problem is that if future advances in cryptanalysis reveal a > weakness in AES, VPN users will be in an unenviable position. = With > the only other widely supported cipher being the much slower = 3DES, >=20 > I'm not sure if that is completely true. We do have Camellia, although > I'm not a cryptographer and it might be too similar to AES. So I still > agree with the sentiment of the text. There are several algorithms that exist, and even quite a few that are = defined for IPsec. But none are as universally implemented as 3DES and = AES. So as a developer I can implement Camellia (and I have no idea = about its speed relative to AES), but as a user with an existing version = of some software that has to interoperate with some other user of some = other version of some other software, only with AES and 3DES it=E2=80=99s = safe to assume that we can achieve interoperability. > The length of the ciphertext as a 32-bit network order quantity. >=20 > Can we clarify the number of octets used here without needing to go = into > another reference document? Mmm, 4? Network order is the controversial part, because everything = else in ChaCha20 is little-endian. > I kind of dislike using HMAC-SHA-256 but I understand we don't have = much > choice right now: For PRF? What=E2=80=99s wrong with HMAC-SHA-256? I would have preferred = to use these algorithms for the PRF. Poly1305 is not suitable as a PRF. = ChaCha20 is a block cipher in counter mode and is very suitable as a = PRF, but it doesn=E2=80=99t fit the definition of a PRF in section 2.13 = of RFC 7296. > = https://tools.ietf.org/html/draft-irtf-cfrg-chacha20-poly1305-10#section-2= .7 >=20 > Although perhaps we can go back to CRFG and ask if they can give us > something that is not based on the SHA2 family? Why don=E2=80=99t you like SHA2? Is it about the performance or just a = general dislike of NIST algorithms? Anyway, perhaps you=E2=80=99d like blake2 better: http://tools.ietf.org/html/draft-saarinen-blake2-01 Still seems like a shame to brink that in just for the PRF. > I have no strong opinions about Diffie-Hellman groups. Perhaps Curve25519 after CFRG finish recommending it. Yoav From nobody Thu Feb 26 22:16:46 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C966E1A892A for ; Thu, 26 Feb 2015 22:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.791 X-Spam-Level: X-Spam-Status: No, score=-0.791 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, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMq7kzNVY9eH for ; Thu, 26 Feb 2015 22:16:44 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (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 386951A8919 for ; Thu, 26 Feb 2015 22:16:44 -0800 (PST) Received: by lbvp9 with SMTP id p9so15346570lbv.0 for ; Thu, 26 Feb 2015 22:16:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=OC3XxE19DODhxKgyxFMSV3vnc+CasrRB/6/2/YkCY9Q=; b=RhzyNo31WEvkl1SqiT2ijhhTLZZqG3TUE170ltyMVroT8Uq7/QRw3PWowxQPOq2J+R 5j5ItLlzN1XK4J/nPku5zIY9lcc7w/xcK5vX1hDIBUvih0AtP7C9yoqirHgMzFOkNKyy fMWmI4LDwa2AonTKo/W7fvPs4fUV8MF6gkzRVLY49wvEAIDinBAKqmf76DgLLBig29zF gm4AqNvFqQj2otQ5LQG9MhA2ag0qH0OPV9ucLsVtarZP8t2LTxVbkQjo0Uy8Rtzjo7Ev Hfz9RoNwfn8Tj78zr/u4U3be/kYv604kJmvXjRHG8Fv0gPAWdEuZJJ3QAf1wVXVSTBRb ugpQ== X-Received: by 10.112.171.65 with SMTP id as1mr10994606lbc.45.1425017802423; Thu, 26 Feb 2015 22:16:42 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id f7sm630498lam.17.2015.02.26.22.16.41 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 26 Feb 2015 22:16:41 -0800 (PST) Message-ID: <4F716BB0A63148AC8613F5C1DDDECA8B@buildpc> From: "Valery Smyslov" To: "Paul Hoffman" , "IPsecME WG" References: <86AC7585-93BD-456D-B75E-F85D2D2A2D7F@vpnc.org> Date: Fri, 27 Feb 2015 09:16:54 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Subject: Re: [IPsec] Call for WG adoption: draft-nir-ipsecme-chacha20-poly1305 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 06:16:46 -0000 Hi, I support adoption this draft as WG document. Valery Smyslov. ----- Original Message ----- From: "Paul Hoffman" To: "IPsecME WG" Sent: Friday, February 27, 2015 1:11 AM Subject: [IPsec] Call for WG adoption: draft-nir-ipsecme-chacha20-poly1305 > Greetings again. A few people have expressed interest in having > https://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305 as a WG > item for IPsecME. If you want this as a WG document, and you are willing > to review drafts as they move through, please say so on this thread. If > you are opposed to this being a WG document, please say so (and say why). > Thanks in advance. > > --Paul Hoffman > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Feb 27 09:06:25 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6492B1ACE2E for ; Fri, 27 Feb 2015 09:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-iHDLbamr3J for ; Fri, 27 Feb 2015 09:06:23 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (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 18BBB1ACE28 for ; Fri, 27 Feb 2015 09:05:53 -0800 (PST) Received: by lbiz11 with SMTP id z11so18624507lbi.8 for ; Fri, 27 Feb 2015 09:05:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=0JoZcs4tQMl7WmozLwsasiXnvleN2kGwJDkBK5jw8l0=; b=nqmL1gfAiT40hg0BBRx5/DdAgCVoP0AsEtJlEP6BfPevu3hmh6QCD+c1qxBNppI1AP PLY7zgTZnI/lrdfnh0ZAZWLO+sR5qsDoqzS79G+Y9iRibGFQUoOWZr9A69RRDTTcR9lr Ya4PnDIw4uEfgjPUkfMNgRPa2AL7a869S5UqamoGpNzqYww3fM/3ZJBH1PdMXMW62sC2 cIm6Xyt2Hl9Asyt/B2wzpfHZQVIPTnLyFDTtjIkQwBWbQHFCQ1I9UhkN8zd7bHLdAmVv lwxB1swcX4dSWH5e12WKMcqMerfz2ykHZ0DGmcj2v3hSWC+jwSpeSxPS9fFMcgy30ehv PGRg== MIME-Version: 1.0 X-Received: by 10.112.97.106 with SMTP id dz10mr13585993lbb.4.1425056751575; Fri, 27 Feb 2015 09:05:51 -0800 (PST) Received: by 10.112.167.101 with HTTP; Fri, 27 Feb 2015 09:05:51 -0800 (PST) Date: Fri, 27 Feb 2015 12:05:51 -0500 Message-ID: From: Kathleen Moriarty To: "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=001a11345b127666a3051014e1c4 Archived-At: Subject: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 17:06:24 -0000 --001a11345b127666a3051014e1c4 Content-Type: text/plain; charset=UTF-8 Hello, Thank you very much to the authors and WG for your efforts on this draft! It's good to see some of the OS work coming through as options in protocols. I just have a couple of comments/questions to clarify before we progress this into IETF last call. The introduction is very well written, thank you for that. Section 2.4 I see that this draft does not update RFC4301, but in reading this section, should it? -- Best regards, Kathleen --001a11345b127666a3051014e1c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Thank you very much to the autho= rs and WG for your efforts on this draft!=C2=A0 It's good to see some o= f the OS work coming through as options in protocols.

<= div>I just have a couple of comments/questions to clarify before we progres= s this into IETF last call.

The introduction = is very well written, thank you for that.

Section = 2.4
I see that this draft does not update RFC4301, but in reading= this section, should it?


--

Best regards,
K= athleen
--001a11345b127666a3051014e1c4-- From nobody Fri Feb 27 11:55:25 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9960F1A1A5D for ; Fri, 27 Feb 2015 11:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TnLRDGMTYbE for ; Fri, 27 Feb 2015 11:55:22 -0800 (PST) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6343B1A0470 for ; Fri, 27 Feb 2015 11:55:22 -0800 (PST) Received: from [10.20.30.109] (142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t1RJtLIB086346 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Feb 2015 12:55:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245] claimed to be [10.20.30.109] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: Date: Fri, 27 Feb 2015 11:55:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <55B72ED0-2A97-4BD5-AFB9-CA71F7FDAAA6@vpnc.org> References: To: "ipsec@ietf.org" X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 19:55:23 -0000 On Feb 27, 2015, at 9:05 AM, Kathleen Moriarty = wrote: >=20 > Hello, >=20 > Thank you very much to the authors and WG for your efforts on this = draft! It's good to see some of the OS work coming through as options = in protocols. >=20 > I just have a couple of comments/questions to clarify before we = progress this into IETF last call. >=20 > The introduction is very well written, thank you for that. >=20 > Section 2.4 > I see that this draft does not update RFC4301, but in reading this = section, should it? That's a good question, and you can see it both ways. - The draft says that the PAD processing in RFC 4301 needs to be updated = for this draft, so the draft updates RFC 4301. - Implementations of RFC 4301 that do not care about IKEv2 using this = draft should not be updated, so this draft doesn't update 4301, just the = 4301 processing when using IKEv2 and this draft. I tend toward the second interpretation, but am happy either way. What = do others think? --Paul Hoffman= From nobody Fri Feb 27 13:58:17 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707E91A035F for ; Fri, 27 Feb 2015 13:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6T2f9ZzqXZy for ; Fri, 27 Feb 2015 13:58:15 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (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 751DF1A034C for ; Fri, 27 Feb 2015 13:58:14 -0800 (PST) Received: by widex7 with SMTP id ex7so3286630wid.0 for ; Fri, 27 Feb 2015 13:58:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=8DHIxN675q18wbtYW6GPOTl5Rjes4s3GcUFnIq3k7yc=; b=KoSAbSs+9Gh1mBOcCjocGFXvwfsHofUAbrYwwzCAk5s0bpWlHDZHp4oASn3BGrREcT geeahVRCMVRxD9uY4l1i6fOdRTD7ua398yXdk71dEroipy9TQtFqgqM/WryIuJFlImJb sF9TFXZe7fWrbziV8EA0ZzLBnwk0PAJxnqmQbCtb2D382Qt3Vl9XsJiFJ/90a+5MH0TH qU1/MEiWJ8cXc+7zhyU9OGPJsRk+peRC/r8+44/VeOpeN9mwijRhdo81BmLX6Rr8hNlY l1oWxCdMoUn5bI+311fM2w76UMaoB71uBru8qcrsHohNi+2rQLcNpVvnfoitiSlN77nk jIAw== X-Received: by 10.180.189.37 with SMTP id gf5mr10889026wic.86.1425074293262; Fri, 27 Feb 2015 13:58:13 -0800 (PST) Received: from [10.0.0.6] (bzq-79-181-109-60.red.bezeqint.net. [79.181.109.60]) by mx.google.com with ESMTPSA id 18sm7665470wjr.46.2015.02.27.13.58.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Feb 2015 13:58:12 -0800 (PST) Message-ID: <54F0E873.2020508@gmail.com> Date: Fri, 27 Feb 2015 23:58:11 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Paul Hoffman , "ipsec@ietf.org" References: <55B72ED0-2A97-4BD5-AFB9-CA71F7FDAAA6@vpnc.org> In-Reply-To: <55B72ED0-2A97-4BD5-AFB9-CA71F7FDAAA6@vpnc.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 21:58:16 -0000 > > That's a good question, and you can see it both ways. > > - The draft says that the PAD processing in RFC 4301 needs to be updated for this draft, so the draft updates RFC 4301. > > - Implementations of RFC 4301 that do not care about IKEv2 using this draft should not be updated, so this draft doesn't update 4301, just the 4301 processing when using IKEv2 and this draft. > > I tend toward the second interpretation, but am happy either way. What do others think? > > --Paul Hoffman I tend the other way, so we need an example or two. If you read the abstract of RFC 6040, it says: "On decapsulation, [RFC 6040] updates both RFC 3168 and RFC 4301 to add new behaviours for previously unused combinations of inner and outer headers." Which means that even though existing implementations are not affected until they encounter these new message variants, we use "Updates" because new implementations are expected to include the new behavior. Thanks, Yaron From nobody Fri Feb 27 14:21:25 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34BE1A0393 for ; Fri, 27 Feb 2015 14:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ez-Xx2b0GgwP for ; Fri, 27 Feb 2015 14:21:24 -0800 (PST) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF601A0378 for ; Fri, 27 Feb 2015 14:21:24 -0800 (PST) Received: from [10.20.30.109] (142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t1RMLLVG097422 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Feb 2015 15:21:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245] claimed to be [10.20.30.109] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: <54F0E873.2020508@gmail.com> Date: Fri, 27 Feb 2015 14:21:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <80906232-2112-40D6-ADBA-95A23137C513@vpnc.org> References: <55B72ED0-2A97-4BD5-AFB9-CA71F7FDAAA6@vpnc.org> <54F0E873.2020508@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 22:21:24 -0000 On Feb 27, 2015, at 1:58 PM, Yaron Sheffer = wrote: >=20 >>=20 >> That's a good question, and you can see it both ways. >>=20 >> - The draft says that the PAD processing in RFC 4301 needs to be = updated for this draft, so the draft updates RFC 4301. >>=20 >> - Implementations of RFC 4301 that do not care about IKEv2 using this = draft should not be updated, so this draft doesn't update 4301, just the = 4301 processing when using IKEv2 and this draft. >>=20 >> I tend toward the second interpretation, but am happy either way. = What do others think? >>=20 >> --Paul Hoffman >=20 > I tend the other way, so we need an example or two. If you read the = abstract of RFC 6040, it says: "On decapsulation, [RFC 6040] updates = both RFC 3168 and RFC 4301 to add new behaviours for previously unused = combinations of inner and outer headers." Which means that even though = existing implementations are not affected until they encounter these new = message variants, we use "Updates" because new implementations are = expected to include the new behavior. That's an interesting example, one from outside our WG. Note, however, = that RFC 6040 is the *only* RFC that updates RFC 4301 so far. It seems = odd that it is the only one like this draft that says "and you need to = change your PAD processing for this new thing". --Paul Hoffman= From nobody Fri Feb 27 22:24:57 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF14F1A1BA3 for ; Fri, 27 Feb 2015 22:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LK6MggTBRGNj for ; Fri, 27 Feb 2015 22:24:54 -0800 (PST) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (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 279C21A1AE8 for ; Fri, 27 Feb 2015 22:24:54 -0800 (PST) Received: by wevk48 with SMTP id k48so24122334wev.0 for ; Fri, 27 Feb 2015 22:24:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+ZIY9QUVUwsWZdDiB55EUiZFBm50pLKrttlfKrmp1IQ=; b=qRcepbHoRXStlRcGR6MGIi62yQvuArvGkz+Laxiyp1yL1amAmJdRQlt05AStXp+fQX EnPPKnntcciZDJ4rDGzMfjyZYk/TcxZmHeLJz+hd1km33S93emrg1TJoLUsDdkdxP1WE z2NrZ7il+qddE+RdlfobNro8rjmkW2gUSOEe6CHe8+URUwiuo2F8YYFMB55RGvOe7MJB r3KT/yeBVgSoFUro/pJkJTvrR2WRyAajReZAjuCFZMp8cS1eYtIuwKbqSd2Ce4Dyf2T2 JdvqDTecd0/8R+SwLki0FWRXOJgiUJvzqtjTX8Bz37JJ+wlKTjh2J1DGGhcQHzGXi9B1 L5qg== X-Received: by 10.180.102.73 with SMTP id fm9mr14171854wib.12.1425104692931; Fri, 27 Feb 2015 22:24:52 -0800 (PST) Received: from [192.168.1.199] ([109.253.110.54]) by mx.google.com with ESMTPSA id ch6sm8979851wjc.3.2015.02.27.22.24.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Feb 2015 22:24:52 -0800 (PST) Message-ID: <54F15F31.2090109@gmail.com> Date: Sat, 28 Feb 2015 08:24:49 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Paul Hoffman References: <55B72ED0-2A97-4BD5-AFB9-CA71F7FDAAA6@vpnc.org> <54F0E873.2020508@gmail.com> <80906232-2112-40D6-ADBA-95A23137C513@vpnc.org> In-Reply-To: <80906232-2112-40D6-ADBA-95A23137C513@vpnc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2015 06:24:55 -0000 > On Feb 27, 2015, at 1:58 PM, Yaron Sheffer wrote: >> >>> >>> That's a good question, and you can see it both ways. >>> >>> - The draft says that the PAD processing in RFC 4301 needs to be updated for this draft, so the draft updates RFC 4301. >>> >>> - Implementations of RFC 4301 that do not care about IKEv2 using this draft should not be updated, so this draft doesn't update 4301, just the 4301 processing when using IKEv2 and this draft. >>> >>> I tend toward the second interpretation, but am happy either way. What do others think? >>> >>> --Paul Hoffman >> >> I tend the other way, so we need an example or two. If you read the abstract of RFC 6040, it says: "On decapsulation, [RFC 6040] updates both RFC 3168 and RFC 4301 to add new behaviours for previously unused combinations of inner and outer headers." Which means that even though existing implementations are not affected until they encounter these new message variants, we use "Updates" because new implementations are expected to include the new behavior. > > That's an interesting example, one from outside our WG. Note, however, that RFC 6040 is the *only* RFC that updates RFC 4301 so far. It seems odd that it is the only one like this draft that says "and you need to change your PAD processing for this new thing". > Similarly, RFC 5282 Updates RFC 4306. Even though you only needed to change your implementation if you added AEAD. But it's not very important either way. Thanks, Yaron From nobody Sat Feb 28 13:36:56 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5FC1A001B for ; Sat, 28 Feb 2015 13:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mprmAYLDyLGg for ; Sat, 28 Feb 2015 13:36:54 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28AF01A001A for ; Sat, 28 Feb 2015 13:36:54 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kvgzm6H1Yz7v; Sat, 28 Feb 2015 22:36:52 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=p3l67R0Y; dkim-adsp=pass X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id HmSwk5xqJ4FO; Sat, 28 Feb 2015 22:36:52 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 28 Feb 2015 22:36:51 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1E8CA82A1E; Sat, 28 Feb 2015 16:36:51 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1425159411; bh=7aNRHBNWC2npAW98SfFLP/QJlWmkdqRDZGBKDZEsjdc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=p3l67R0YGHrKzQ8mxPqPPgH5WsQkrM11hyY2LjkvLz2kcsuXlOe5Iq2YdB8G9MsFM tPT4QMF0cxhIZOMsz196iZFwq0OhTfrXGhBpmKERNLwOg/In3Q0gjKRQBs93hwG4XH P6uhCHLGHo7OUK2+GM4agBrGbfH1JkEgyn4PtXxY= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t1SLaoVh009763; Sat, 28 Feb 2015 16:36:50 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sat, 28 Feb 2015 16:36:50 -0500 (EST) From: Paul Wouters To: Yaron Sheffer In-Reply-To: <54F15F31.2090109@gmail.com> Message-ID: References: <55B72ED0-2A97-4BD5-AFB9-CA71F7FDAAA6@vpnc.org> <54F0E873.2020508@gmail.com> <80906232-2112-40D6-ADBA-95A23137C513@vpnc.org> <54F15F31.2090109@gmail.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org" , Paul Hoffman Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2015 21:36:55 -0000 On Sat, 28 Feb 2015, Yaron Sheffer wrote: >>> I tend the other way, so we need an example or two. If you read the >>> abstract of RFC 6040, it says: "On decapsulation, [RFC 6040] updates both >>> RFC 3168 and RFC 4301 to add new behaviours for previously unused >>> combinations of inner and outer headers." Which means that even though >>> existing implementations are not affected until they encounter these new >>> message variants, we use "Updates" because new implementations are >>> expected to include the new behavior. >> >> That's an interesting example, one from outside our WG. Note, however, that >> RFC 6040 is the *only* RFC that updates RFC 4301 so far. It seems odd that >> it is the only one like this draft that says "and you need to change your >> PAD processing for this new thing". >> > Similarly, RFC 5282 Updates RFC 4306. Even though you only needed to change > your implementation if you added AEAD. But it's not very important either > way. I'm not sure what the IETF definition is for "Update an RFC". I would say this RFC only adds to 4306. That is, if you do not implement this document you do not need to know about this "update". I would expect an "updated by" to be mandatory reading material for an implementor of the RFC being updated. I'm fine either way, but I am leaning towards not specifying updated by. Paul From nobody Sat Feb 28 22:59:28 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0C71A87DF for ; Sat, 28 Feb 2015 22:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_6KBEvxH-z6 for ; Sat, 28 Feb 2015 22:59:26 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (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 09F891A87DE for ; Sat, 28 Feb 2015 22:59:26 -0800 (PST) Received: by lbjf15 with SMTP id f15so3392181lbj.3 for ; Sat, 28 Feb 2015 22:59:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=Wj09dyeCqiqH0K5uzZClaczhQe/EZQMw7ERy7KPdKoA=; b=kEqaM+7RtesAxEhAqE++UlasjikfB5EickhnoDLVE+1lMFRiuRulNQ6Al7hyl0Qj3q SZmJXgkg+mdjE0ZQVd0IbIcGPpm1YFWQj8DqrTBkvNPIdF21tlk4QBVFzVhHevO3NJKl yiwzZ8rlKnZ0U6YeLxzTAAY++r3whfrizyGTu9zCU6AUuTfFYq6/qhzVe69I28nNfspl gHiXs08LrPO7rbtOagwNSzrv+gLXZDGo7AHelm0l8cxNyWnLwJZ6BjpQBv25QPeigQqM ImWbavU9Zo0+Xw2oS2WFjy5mUxjctb6NeHozT89twlTII80mklcf1aiUWUJKsIjlnM3h XYEA== X-Received: by 10.112.126.130 with SMTP id my2mr19769583lbb.55.1425193164521; Sat, 28 Feb 2015 22:59:24 -0800 (PST) Received: from chichi (ppp85-141-204-169.pppoe.mtu-net.ru. [85.141.204.169]) by mx.google.com with ESMTPSA id ca7sm1250905lad.15.2015.02.28.22.59.23 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 28 Feb 2015 22:59:23 -0800 (PST) Message-ID: <1553E5156D3B446696D77AF1F3F012DB@chichi> From: "Valery Smyslov" To: "Paul Wouters" , "Yaron Sheffer" References: <55B72ED0-2A97-4BD5-AFB9-CA71F7FDAAA6@vpnc.org> <54F0E873.2020508@gmail.com> <80906232-2112-40D6-ADBA-95A23137C513@vpnc.org> <54F15F31.2090109@gmail.com> In-Reply-To: Date: Sun, 1 Mar 2015 09:59:22 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org, Paul Hoffman Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2015 06:59:27 -0000 > I'm not sure what the IETF definition is for "Update an RFC". I would > say this RFC only adds to 4306. That is, if you do not implement this > document you do not need to know about this "update". I would expect an > "updated by" to be mandatory reading material for an implementor of the > RFC being updated. I agree with Paul that the term "update an RFC" is not clear enough and could be treated differently. BTW is there some formal definition of this term (like definitios of uppercase words in RFC2119)? This would clarify the situation. > I'm fine either way, but I am leaning towards not specifying updated by. I'm also fine with either way. Valery. > Paul