From nobody Wed Dec 1 00:43:00 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951DE3A0813; Wed, 1 Dec 2021 00:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl 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 03elbWRX0u6O; Wed, 1 Dec 2021 00:42:53 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:65::8:228]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39ED33A080F; Wed, 1 Dec 2021 00:42:52 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 20BDD51; Wed, 1 Dec 2021 08:42:50 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1638348168; bh=dTs2cd9PWLNDwlwt/TPMJCLOOVuCQk/Dib0idQAdv5I=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Qh0xz2sZg445NQG5JkfaTDEhhwQXYVzaa4iIHbQ6Gmoj2Te30nlnDwRZEkkcKz2FZ 7wLJcPTkU20Qi4LZHSQS+OpHRUN1NWFNTGPnZ/u/cavO3lMyIdQXkTu6gfpW9QZrM9 YguXBK9xYtHPxsUL+qdNEYKiZU46zvvCEoAwuFeXyz1WUOiiiemSIf0/DFPQwFS4A3 H/KXVZj5t9xYcbASbMJUXu9+9mvP6wEYOHna2mZOHlC59YIHp/GKF78UsbRmDoqi4l KDBzBc/cX2vt96SFDidcD8NOolrhzJb1a47DMGSrc/mZ0H2w/ZRd5Tl07mjKVo9LTA jhwdqr4wsBMVA== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Tim Bruijnzeels In-Reply-To: <20211130193034.344F62EA0102@minas-ithil.hactrn.net> Date: Wed, 1 Dec 2021 09:42:45 +0100 Cc: Warren Kumari , SIDR Operations WG , draft-ietf-sidrops-6486bis@ietf.org, Stephen Kent Content-Transfer-Encoding: 7bit Message-Id: References: <813d1599-fc9d-18b6-a76c-b550855b1186@verizon.net> <20211130193034.344F62EA0102@minas-ithil.hactrn.net> To: Rob Austein Archived-At: Subject: Re: [Sidrops] AD Review of: draft-ietf-sidrops-6486bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2021 08:42:59 -0000 Hi, > On 30 Nov 2021, at 20:30, Rob Austein wrote: > > One thing that may not be immediately obvious to Warren: there's a big > difference between NotBefore in certificates and ThisUpdate in CRLs > and manifests. Backdating NotBefore by some small amount makes sense > given the possibility that clock skew might cause a certificate to be > interpreted as invalid at the time it's issued, which could be bad. > ThisUpdate is more of a tick mark recording the passage of time in the > evolving history of a manifest or CRL: nothing terrible should happen > in the case of clock skew, so as Steve suggests it's probably best to > tell the truth about the time of publication. > > Manifests have this extra twist in that the manifest CMS contains an > embedded EE certificate which has a NotBefore, so one gets to invoke > both of these rules at once while generating the same object, yay. So, section 6.3 says: "If the current time is earlier than thisUpdate, the CA has made an error" It is also RECOMMENDED earlier that the EE certificate notBefore matches thisUpdate. As a CA I have every intention not to be sloppy and manage my own NTP, but I feel vulnerable to RPs with sloppy NTP. I do not see what the big deal is with back-dating five minutes. The object did not exist five minutes ago, but if an RP lives 2 minutes in the past - why should they reject me? What if my parent issued a covering ROA and I try to publish a more specific, and it is rejected for this reason? NOTE: For manifest and other RPKI Signed Objects there is also the option of using the Signing-Time Attribute (section 2.1.6.4.3 of RFC 6488). In my mind this is where the CA tells the truth about the time of signing. Also note that there are different components involved in the chain. When a CA signs a new manifest and uses *now* for notBefore, then there will still be some delay before it is actually published by its Publication Server (seconds to minutes). And then there is a further delay before an individual RP picks it up. So, assuming that the CA and RP NTP are in sync, the latter will always find things after the fact. Speaking for my own implementation publication happens within seconds after signing and that is when the first RPs will pick it up. For others it may take minutes between signing and publications and therefore they may be less afraid of RPs living in the very recent past. Tim > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Dec 1 01:59:31 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC603A0907 for ; Wed, 1 Dec 2021 01:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=massar.ch 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 dl_vy0We6AAk for ; Wed, 1 Dec 2021 01:59:22 -0800 (PST) Received: from citadel.ch.unfix.org (citadel.ch.unfix.org [IPv6:2001:1620:20b0::50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15A223A0902 for ; Wed, 1 Dec 2021 01:59:20 -0800 (PST) Received: from [IPv6:2a10:fc42:a:1042:ca2a:14ff:fe1f:2b7b] (unknown [IPv6:2a10:fc42:a:1042:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen@massar.ch) by citadel.ch.unfix.org (Postfix) with ESMTPSA id 3FBEC22B056B9; Wed, 1 Dec 2021 09:59:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1638352756; bh=IERHg9TNFFKN946xRWrGmZbiIHEqTbk/vwe5pE3m6hw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=tx2Lm/Xibnph4m3MR3rlpgoPO+VdrJ9pNaRTyZNUV6cJadLFoPjuTZzJH5C1tWypp HUMnywjinBWlLAWfg7c/b+dBSyvUXfyfq1UnuhEPyTBotZ0422Pnqnl5eFhz7yqUIw ZK3tlDTe4Rh3tho00Mif1S5UkFmUlTWHURYBiyWcDDRxTcJ8tHpovDdo/p12HR4P11 4x7uljyZ3gkm4N5fjwlH7vNcGmvbB0prvz0GHb54z6lMsKVLw4v2Y5aBIYOd2lakcz TAhEC+rb+OyXU0ixIiifDouuQQjQFwcliMpRN9WBmC3h27y5HiJL/8cmoj0rUlRmwi FOrvy6X/NCP7A== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) From: Jeroen Massar In-Reply-To: <001b01d7e638$0f34baf0$2d9e30d0$@student.utwente.nl> Date: Wed, 1 Dec 2021 10:59:15 +0100 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <001b01d7e638$0f34baf0$2d9e30d0$@student.utwente.nl> To: Koen van Hove X-Mailer: Apple Mail (2.3445.9.7) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2021 09:59:29 -0000 TLDR: Fix problems, instead of putting everything into HTTP.... the = Internet is not just the Web Hi Koen, > On 20211130, at 23:17, Koen van Hove = wrote: >=20 > Dear Tim, all, >=20 > I have looked at your motivation, particularly: >> * rsync is CPU and memory heavy on the server side, and easy to = DoS >=20 > I decided to test your hypothesis, as RFC 6480 says otherwise, and = created a > small program that aims to DoS an rsync daemon using many simultaneous > connections from different IP addresses (but the same machine). My > conclusion is the same as yours - with the old computer (4 cores, 16 = GB of > RAM, home fiber connection) underneath my desk I can currently take = down my > own test rsync server (8 cores, 16 GB RAM, 1 Gbps connection, = different > network). 8 cores? 16 GB? My phone has better CPU/mem and connectivity than = that... that is literally puny. Heck, your university of utwente has way more connectivity than that, = and they where DoSed easily off-net too: https://status.snt.utwente.io/incidents/42 (the answer is always 42) "Major outage effecting (nearly) all systems of SNT" Please realize that ANYTHING can be (D)DoSsed given enough resources. And as we have a LOT of people on the Internet and many that do not = properly maintain their connected devices (IoT but also for instance = Wordpress, or ManageEngine ADSelfService or soooo many problems), = botnets in the order of 100.000's times 100mbit are common today and you = go to any "Booter" or "Stresser" service and you get 50Gbit/s for a few = dollars. But, heck for 666CHF/year I can even have 25GBit/s at home from = init7.net as a single link... Of course, it would require you to sustain that DoS for a week, possibly = two, to actually do any real damage. But centralisation is bad (even = though one always have to go through the RIR) thus many orgs will want = to host themselves (also makes some processes easier). [and the init7 = example they will have complained and kick you off net by then ;) ] As such, any infrastructure that does not want to be (D)DoSsed should be = redundant, likely anycasted, and appropriately scaled as per the RFC. It is also why many people opt for Hosted RPKI at the RIRs and why that = setup will cost them a dear cent. Fortunately both rsync and RRDP require TCP connections. Most UDP can be = filtered at the border, that helps quite a bit. But then as noted a 100k botnet can just do legit connections.... for a = bit, as ISPs do band together and contact each other and try to resolve = at least swaths of those botnets. Hence... the longer the DDoS, the more annoyance, more fixes (or blocks) = will be applied and at least the size of the botnet and the attack = reduces. I personally also advise doing the rpki-client part from disjunct = networks, heck do it from random ASNs, just in case an operator wants to = specifically target a specific ASN. > Discussions with operators from RIRs seem to show that this would > also work for their rsync servers. I believe this would even allow = one to > take down all rsync servers currently running in the RPKI with a = handful of > computers, but I have not tested that as I do not want to disrupt = actual > operations. Just in case you did not know yet: Please realize that it would be = illegal to do it under the Dutch law you fall under (and other countries = have bilateral agreements and will find you too). I bet there is a law professor at your university that can explain to = you if it is criminal or civil law that it will fall under and what the = penalties would be. [..] > Rsync was not created to be used with a possibly malicious server. > Therefore, there are currently simple things everyone could do that = would > disrupt a relying party over rsync, which are difficult to solve: > 1. One can set a motd file that is several gigabytes in size. Rsync = will > wait until this is received (the --no-motd switch only hides it on the > client) and the timeout set in rsync does not affect the maximum time = this > may take. I can only suggest to fix the code. Every piece of code in the world will have problems somewhere: please = report and people will fix. (Though as rpki.exposed shows, some of the problems (J+K) you have = reported are still not resolved in some clients, things take time). Also remember the original motto of the IETF: running code and rough = consensus... The running code so that one has experience in operating something, as = one learns a lot from it. Easy fix: if a server sends an overlong MOTD (eg >1MiB can already be = considered that) put it on a blacklist and ignore it. The only resources DDoSed that way are their own. You'll have a 'delay' = once, but after that your client is happy. > 2. One can create an rsync repository with many folders (I tested it = with 27 > million folders). This fills up the maximum amount of inodes on most = Linux > and *BSD filesystems within minutes whilst bypassing any size limits = or > --includes and --excludes, as a folder has a size of 0, and folders = are used > in non-malicious repositories.=20 I don't know about you, but filesystem quotas are things that have = existed for well over 4 decades by now. Thus that is really a non-issue. Simpler version: have a filesystem specifically where you retrieve = things. Cooler version: have a filesystem per CA one fetches -- could use = loopback FS or LVM-alike. Heck, the latter one could even nicely have versioning on the filesystem = and lots of other cool features allowing rollback etc etc with minimal = overhead in storage. Note that code has already solved that specific problem too: https://manpages.debian.org/buster/rsync/rsync.1.en.html 8<----------------- --prune-empty-dirs, -m This option tells the receiving rsync to get rid of empty directories from the file-list, including nested directories that have no non-directory children. This is useful for avoiding the creation of a bunch of useless directories when the sending rsync is recursively scanning a hierarchy of files using include/exclude/filter rules. ------------------>8 Indeed, you are right, a malicious operator will be able to cause some = kind of problems. Blacklisting that operator is very easy and would only affect the = resources for that operator. And all other things, when discovered, report them, patch them and keep = on running. It is extremely easy to be on the "red team", and so many people think = they are cool playing attacker. It is a lot more fun to play the blue = team and defend against things. But as it is a game, both sides will = change tactics, red will find something, blue will fix it... that is the = way of life on the Internet. Btw, for RRDP, you do not want to know how much fun I can have with = HTTP/1.0... let alone with HTTP/2 or QUIC... so many evil server = possibilities... the RFCs have comments on many of these techniques and = the clients and servers address many too; can't stop them all though, at = one point "that server is malicious" and you need to disconnect. Greets, Jeroen From nobody Wed Dec 1 09:06:56 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262F33A07D1 for ; Wed, 1 Dec 2021 09:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net 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 YiWkDyiiyIHp for ; Wed, 1 Dec 2021 09:06:46 -0800 (PST) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 D2CB23A07CD for ; Wed, 1 Dec 2021 09:06:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Cc:Date:Subject:Mime-Version:Content-Type:Message-Id:From ; bh=T34VPMnDFAaofFLI2WbiULROLhvK4drBmwyDyBzYKn0=; b=qAcCJxsH/8pUz/R8q2n86+ne 8h98Z8wZRN9KVc0ko0YRj5jNgaKEq5q4pXElap3+zxe9tkgfq01ORFzIdgeJD5VxYMlMX+ACh96Xu u6gRuw842roLQ17ubHE/zIxgzoJd99ZmmAUW3187oto1DU1LT1GjbBSeno3RAUUUtjUszqFHkNoUm sfdSKTUTvn7XJ3i3vbLEAKtoao67QHJ5kzuEQD8uRDLf16atgBWOyppVKiG6hXMwOrv9CBa7NRilD JqjNbf9WT03+jq8RGlFlEsBXbwVGr1OvTOmgyZAsUwD+GLIvCB7hjr5VD4m0Pro3B4Y+yqe6fM5uR FSzdpVmC+w==; Received: from bufobufo.ripe.net ([2001:67c:2e8:23::c100:170d]:34130) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1msT42-000AoU-HU; Wed, 01 Dec 2021 18:06:38 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=smtpclient.apple) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1msT42-0007j5-7f; Wed, 01 Dec 2021 18:06:38 +0100 From: Ties de Kock Message-Id: <51448777-038D-4B0D-97D9-129053B5115F@ripe.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_12BFD7B5-0799-4448-93C7-99842BC70CEB" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Wed, 1 Dec 2021 18:06:37 +0100 In-Reply-To: Cc: Koen van Hove , SIDR Operations WG To: Jeroen Massar References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <001b01d7e638$0f34baf0$2d9e30d0$@student.utwente.nl> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e10d21c75899454450d4fbed0ebc0d0625 Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2021 17:06:54 -0000 --Apple-Mail=_12BFD7B5-0799-4448-93C7-99842BC70CEB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jeroen, > On 1 Dec 2021, at 10:59, Jeroen Massar = wrote: >=20 > TLDR: Fix problems, instead of putting everything into HTTP.... the = Internet is not just the Web >=20 >=20 > Hi Koen, >=20 >> On 20211130, at 23:17, Koen van Hove = wrote: >>=20 >> Dear Tim, all, >>=20 >> I have looked at your motivation, particularly: >>> * rsync is CPU and memory heavy on the server side, and easy to = DoS >>=20 >> I decided to test your hypothesis, as RFC 6480 says otherwise, and = created a >> small program that aims to DoS an rsync daemon using many = simultaneous >> connections from different IP addresses (but the same machine). My >> conclusion is the same as yours - with the old computer (4 cores, 16 = GB of >> RAM, home fiber connection) underneath my desk I can currently take = down my >> own test rsync server (8 cores, 16 GB RAM, 1 Gbps connection, = different >> network). >=20 > 8 cores? 16 GB? My phone has better CPU/mem and connectivity than = that... that is literally puny. >=20 > Heck, your university of utwente has way more connectivity than that, = and they where DoSed easily off-net too: Remember that rsyncd is not a =E2=80=9Cmodern=E2=80=9D evented server. = Real rsync deployments have an extremely limited number of connections which is trivial to = exceed. Volumetric attacks are not needed. During a short discussion on the risk posed by rsync in February 2020 at = the RIPE NCC, we listed at least the following risks with rsync: a: rsync - big repo b: rsync - inode exhaustion c: rsync - slowloris d: rsync - exhausting client their connection pool (this is a partial list and resource exhaustion attacks on the server = are much easier than for modern http servers - even without considering CDN = usage) I think that Koen's earlier responsible disclosure/CVD (managed by NCSC) = covered a and d. c hit the RIPE NCC [0]. And practically you can only monitor against = this and play whack-a-mole. b was just mentioned in the thread. >=20 > https://status.snt.utwente.io/incidents/42 = (the answer is always 42) > "Major outage effecting (nearly) all systems of SNT" >=20 >=20 > Please realize that ANYTHING can be (D)DoSsed given enough resources. >=20 > And as we have a LOT of people on the Internet and many that do not = properly maintain their connected devices (IoT but also for instance = Wordpress, or ManageEngine ADSelfService or soooo many problems), = botnets in the order of 100.000's times 100mbit are common today and you = go to any "Booter" or "Stresser" service and you get 50Gbit/s for a few = dollars. > But, heck for 666CHF/year I can even have 25GBit/s at home from = init7.net as a single link... >=20 > Of course, it would require you to sustain that DoS for a week, = possibly two, to actually do any real damage. But centralisation is bad = (even though one always have to go through the RIR) thus many orgs will = want to host themselves (also makes some processes easier). [and the = init7 example they will have complained and kick you off net by then ;) = ] Eight (? - 16 for the RIPE NCC) hours before manifests expire. Not an = big issue at the moment, but a material risk if (a) have a standard that = forces compliant RPs to downgrade and open their RP up to trivial attacks and = (b) you deploy a protocol based on RPKI certificates that fails closed. But that material risk would likely not exist in practice - I would = expect operators to opt out of deploying a security protocol with such a hole. >=20 > As such, any infrastructure that does not want to be (D)DoSsed should = be redundant, likely anycasted, and appropriately scaled as per the RFC. >=20 > It is also why many people opt for Hosted RPKI at the RIRs and why = that setup will cost them a dear cent. >=20 >=20 > Fortunately both rsync and RRDP require TCP connections. Most UDP can = be filtered at the border, that helps quite a bit. >=20 > But then as noted a 100k botnet can just do legit connections.... for = a bit, as ISPs do band together and contact each other and try to = resolve at least swaths of those botnets. > Hence... the longer the DDoS, the more annoyance, more fixes (or = blocks) will be applied and at least the size of the botnet and the = attack reduces. >=20 >=20 > I personally also advise doing the rpki-client part from disjunct = networks, heck do it from random ASNs, just in case an operator wants to = specifically target a specific ASN. You can test what ASN an RP is used by. This actually is an interesting experiment to see how much centralisation and re-use of RPs is happens = :). >=20 >=20 >> Discussions with operators from RIRs seem to show that this would >> also work for their rsync servers. I believe this would even allow = one to >> take down all rsync servers currently running in the RPKI with a = handful of >> computers, but I have not tested that as I do not want to disrupt = actual >> operations. >=20 > Just in case you did not know yet: Please realize that it would be = illegal to do it under the Dutch law you fall under (and other countries = have bilateral agreements and will find you too). > I bet there is a law professor at your university that can explain to = you if it is criminal or civil law that it will fall under and what the = penalties would be. My attacker model includes _malicious_ attackers (i.e. "this is illegal" = does not prevent the attack). Requiring signed objects is a road-bump = (furthermore, possession of private key does not prove the created hosted CA is = legitimate). > [..] >> Rsync was not created to be used with a possibly malicious server. >> Therefore, there are currently simple things everyone could do that = would >> disrupt a relying party over rsync, which are difficult to solve: >> 1. One can set a motd file that is several gigabytes in size. Rsync = will >> wait until this is received (the --no-motd switch only hides it on = the >> client) and the timeout set in rsync does not affect the maximum time = this >> may take. >=20 > I can only suggest to fix the code. >=20 > Every piece of code in the world will have problems somewhere: please = report and people will fix. > (Though as rpki.exposed shows, some of the problems (J+K) you have = reported are still not resolved in some clients, things take time). >=20 > Also remember the original motto of the IETF: running code and rough = consensus... >=20 > The running code so that one has experience in operating something, as = one learns a lot from it. >=20 >=20 > Easy fix: if a server sends an overlong MOTD (eg >1MiB can already be = considered that) put it on a blacklist and ignore it. > The only resources DDoSed that way are their own. You'll have a = 'delay' once, but after that your client is happy. I strongly discourage that tactic, that is way for an on-path attacker = to persistently blackhole a repository. I think rsync clients should have a flag that: * aborts after a set number of objects received. * aborts after a set amount of bytes transferred by the connection. And after aborting, the initial state should be restored, a partial = transfer breaks a repo. Here the behaviour of rsync implementations also differs. Transfering files alphabetically instead of per directory majorly = increases the time window for a failed fetch. >> 2. One can create an rsync repository with many folders (I tested it = with 27 >> million folders). This fills up the maximum amount of inodes on most = Linux >> and *BSD filesystems within minutes whilst bypassing any size limits = or >> --includes and --excludes, as a folder has a size of 0, and folders = are used >> in non-malicious repositories.=20 >=20 > I don't know about you, but filesystem quotas are things that have = existed for well over 4 decades by now. >=20 > Thus that is really a non-issue. >=20 > Simpler version: have a filesystem specifically where you retrieve = things. If you run an RP in a container I recommend running the storage on = tmpfs, especially if you have more memory than IOPs. > Cooler version: have a filesystem per CA one fetches -- could use = loopback FS or LVM-alike. >=20 > Heck, the latter one could even nicely have versioning on the = filesystem and lots of other cool features allowing rollback etc etc = with minimal overhead in storage. >=20 >=20 > Note that code has already solved that specific problem too: >=20 > https://manpages.debian.org/buster/rsync/rsync.1.en.html = >=20 > 8<----------------- > --prune-empty-dirs, -m >=20 > This option tells the receiving rsync to get rid of empty > directories from the file-list, including nested > directories that have no non-directory children. This is > useful for avoiding the creation of a bunch of useless > directories when the sending rsync is recursively = scanning > a hierarchy of files using include/exclude/filter rules. > ------------------>8 You can transfer empty files instead. >=20 >=20 > Indeed, you are right, a malicious operator will be able to cause some = kind of problems. > Blacklisting that operator is very easy and would only affect the = resources for that operator. >=20 > And all other things, when discovered, report them, patch them and = keep on running. >=20 >=20 > It is extremely easy to be on the "red team", and so many people think = they are cool playing attacker. It is a lot more fun to play the blue = team and defend against things. But as it is a game, both sides will = change tactics, red will find something, blue will fix it... that is the = way of life on the Internet. >=20 >=20 > Btw, for RRDP, you do not want to know how much fun I can have with = HTTP/1.0... let alone with HTTP/2 or QUIC... so many evil server = possibilities... the RFCs have comments on many of these techniques and = the clients and servers address many too; can't stop them all though, at = one point "that server is malicious" and you need to disconnect. And both attackers and defenders can only spend the energy once. I think = that HTTP(S) is where we should spend the energy, and also where a lot of = research has been performed already. And to all the readers: if I missed a "modern" evented rsyncd = implementation please let me know. I would be extremely happy to evaluate that. Kind regards, Ties [0]: = https://www.ripe.net/ripe/mail/archives/routing-wg/2020-April/004084.html -- >=20 > Greets, > Jeroen >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops = --Apple-Mail=_12BFD7B5-0799-4448-93C7-99842BC70CEB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Jeroen,

On 1 Dec 2021, at 10:59, Jeroen Massar <jeroen=3D40massar.ch@dmarc.ietf.org> wrote:

TLDR: Fix problems, instead of putting everything into = HTTP.... the Internet is not just the Web


Hi Koen,

On 20211130, at 23:17, Koen van Hove = <k.w.vanhove@student.utwente.nl> wrote:
Dear Tim, all,

I have looked at = your motivation, particularly:
 *  rsync is CPU and memory heavy on the server = side, and easy to DoS

I = decided to test your hypothesis, as RFC 6480 says otherwise, and created = a
small program that aims to DoS an rsync daemon using = many simultaneous
connections from different IP addresses = (but the same machine). My
conclusion is the same as yours = - with the old computer (4 cores, 16 GB of
RAM, home fiber = connection) underneath my desk I can currently take down my
own test rsync server (8 cores, 16 GB RAM, 1 Gbps connection, = different
network).

8 cores? 16 GB? My phone has = better CPU/mem and connectivity than that... that is literally = puny.

Heck, your = university of utwente has way more connectivity than that, and they = where DoSed easily off-net too:

Remember that rsyncd is not a =E2=80=9Cmodern=E2=80=9D= evented server. Real rsync deployments
have an extremely = limited number of connections which is trivial to = exceed.
Volumetric attacks are not = needed.

During a short = discussion on the risk posed by rsync in February 2020 at = the
RIPE NCC, we listed at least the following risks with = rsync:
  a: rsync - big = repo
  b: rsync - inode = exhaustion
  c: rsync - slowloris
  d: = rsync - exhausting client their connection pool

(this is a partial list = and resource exhaustion attacks on the server are much
easier than for modern http servers - even without = considering CDN usage)

I = think that Koen's earlier responsible disclosure/CVD (managed by NCSC) = covered
a and d.
c hit the RIPE NCC [0]. And = practically you can only monitor against this and
play = whack-a-mole.
b was just mentioned in the thread.


https://status.snt.utwente.io/incidents/42   (the answer is = always 42)
"Major outage = effecting (nearly) all systems of SNT"


Please realize that ANYTHING can be (D)DoSsed given enough = resources.

And as we = have a LOT of people on the Internet and many that do not properly = maintain their connected devices (IoT but also for instance Wordpress, = or ManageEngine ADSelfService or soooo many problems), botnets in the = order of 100.000's times 100mbit are common today and you go to any = "Booter" or "Stresser" service and you get 50Gbit/s for a few = dollars.
But, heck for = 666CHF/year I can even have 25GBit/s at home from init7.net as a single = link...


Of course, it would require you to sustain that DoS for a = week, possibly two, to actually do any real damage. But centralisation = is bad (even though one always have to go through the RIR) thus many = orgs will want to host themselves (also makes some processes easier). = [and the init7 example they will have complained and kick you off net by = then ;) ]

Eight (? - 16 for the RIPE NCC)  hours = before manifests expire. Not an big
issue at the moment, but a = material risk if (a) have a standard that forces
compliant RPs = to downgrade and open their RP up to trivial attacks and (b) = you
deploy a protocol based on RPKI certificates that fails = closed.

But that material risk = would likely not exist in practice - I would expect
operators = to opt out of deploying a security protocol with such a = hole.


As such, any infrastructure that does not want to be = (D)DoSsed should be redundant, likely anycasted, and appropriately = scaled as per the RFC.

It is also why many people opt for Hosted RPKI at the RIRs = and why that setup will cost them a dear cent.


Fortunately both rsync and RRDP = require TCP connections. Most UDP can be filtered at the border, that = helps quite a bit.

But then as noted a 100k botnet can just do legit = connections.... for a bit, as ISPs do band together and contact each = other and try to resolve at least swaths of those botnets.
Hence... the longer the DDoS, = the more annoyance, more fixes (or blocks) will be applied and at least = the size of the botnet and the attack reduces.


I personally also advise doing = the rpki-client part from disjunct networks, heck do it from random = ASNs, just in case an operator wants to specifically target a specific = ASN.

You can = test what ASN an RP is used by. This actually is an = interesting
experiment to see how much centralisation and = re-use of RPs is happens :).



Discussions with operators from RIRs seem to show that this = would
also work for their rsync servers.  I believe = this would even allow one to
take down all rsync servers = currently running in the RPKI with a handful of
computers, = but I have not tested that as I do not want to disrupt actual
operations.

Just in case you did not know = yet: Please realize that it would be illegal to do it under the Dutch = law you fall under (and other countries have bilateral agreements and = will find you too).
I bet there is a law professor at your university that can = explain to you if it is criminal or civil law that it will fall under = and what the penalties would be.

My attacker model includes _malicious_ attackers = (i.e. "this is illegal" does
not prevent the attack). = Requiring signed objects is a road-bump = (furthermore,
possession of private key does not prove the = created hosted CA is legitimate).

[..]
Rsync = was not created to be used with a possibly malicious server.
Therefore, there are currently simple things everyone could = do that would
disrupt a relying party over rsync, which = are difficult to solve:
1. One can set a motd file that is = several gigabytes in size. Rsync will
wait until this is = received (the --no-motd switch only hides it on the
client) = and the timeout set in rsync does not affect the maximum time this
may take.

I can only suggest to fix the code.

Every piece of code in the world = will have problems somewhere: please report and people will = fix.
(Though as = rpki.exposed shows, some of the problems (J+K) you have reported are = still not resolved in some clients, things take time).

Also remember the original motto = of the IETF: running code and rough consensus...

The running code so that one has = experience in operating something, as one learns a lot from = it.


Easy fix: if = a server sends an overlong MOTD (eg >1MiB can already be considered = that) put it on a blacklist and ignore it.
The only resources DDoSed that way are their own. You'll have = a 'delay' once, but after that your client is happy.

I strongly = discourage that tactic, that is way for an on-path attacker = to
persistently blackhole a repository.

I think rsync clients should have a flag = that:
  * aborts after a set number of objects = received.
  * aborts after a set amount of bytes = transferred by the connection.

And after aborting, the initial state should = be restored, a partial transfer
breaks a repo. Here the = behaviour of rsync implementations also differs.
Transfering = files alphabetically instead of per directory majorly increases = the
time window for a failed fetch.

2. = One can create an rsync repository with many folders (I tested it with = 27
million folders). This fills up the maximum amount of = inodes on most Linux
and *BSD filesystems within minutes = whilst bypassing any size limits or
--includes and = --excludes, as a folder has a size of 0, and folders are used
in non-malicious repositories. 

I don't know about you, but filesystem quotas are things that = have existed for well over 4 decades by now.

Thus that is really a = non-issue.

Simpler version: have a filesystem specifically where you = retrieve things.

If you run an RP in a container I recommend = running the storage on tmpfs,
especially if you have more = memory than IOPs.

Cooler = version: have a filesystem per CA one fetches -- could use loopback FS = or LVM-alike.

Heck, the = latter one could even nicely have versioning on the filesystem and lots = of other cool features allowing rollback etc etc with minimal overhead = in storage.


Note that = code has already solved that specific problem too:

https://manpages.debian.org/buster/rsync/rsync.1.en.html
8<-----------------
--prune-empty-dirs, -m

          &nb= sp;  This option tells the receiving rsync to get rid of = empty
          &nb= sp;  directories from the file-list, including = nested
          &nb= sp;  directories that have no non-directory children. =  This is
          &nb= sp;  useful for avoiding the creation of a bunch of = useless
          &nb= sp;  directories when the sending rsync is recursively = scanning
          &nb= sp;  a hierarchy of files using include/exclude/filter = rules.
------------------>8

You can transfer empty files instead.


Indeed, you are right, a = malicious operator will be able to cause some kind of = problems.
Blacklisting = that operator is very easy and would only affect the resources for that = operator.

And all other = things, when discovered, report them, patch them and keep on = running.


It is = extremely easy to be on the "red team", and so many people think they = are cool playing attacker. It is a lot more fun to play the blue team = and defend against things. But as it is a game, both sides will change = tactics, red will find something, blue will fix it... that is the way of = life on the Internet.


Btw, for RRDP, you do not want to know how much fun I can = have with HTTP/1.0... let alone with HTTP/2 or QUIC... so many evil = server possibilities... the RFCs have comments on many of these = techniques and the clients and servers address many too; can't stop them = all though, at one point "that server is malicious" and you need to = disconnect.

And = both attackers and defenders can only spend the energy once. I think = that
HTTP(S) is where we should spend the energy, and also = where a lot of research
has been performed = already.

And to all the = readers: if I missed a "modern" evented rsyncd = implementation
please let me know. I would be extremely happy = to evaluate that.

Kind regards,
Ties

--


Greets,
Jeroen

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

= --Apple-Mail=_12BFD7B5-0799-4448-93C7-99842BC70CEB-- From nobody Wed Dec 1 09:25:35 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE753A0787; Wed, 1 Dec 2021 09:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net 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 G-vkUejpXL-r; Wed, 1 Dec 2021 09:25:29 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 5DF3F3A0788; Wed, 1 Dec 2021 09:25:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Cc:Date:Subject:Mime-Version:Content-Type:Message-Id:From ; bh=c9yszB6YmiKjuuOQYVDRdGN7sP2X8/caRhWjqsU4gWw=; b=mBeDiM0NFVdxoROunwnA+S3U RxhUrCd4W6dYkIkFDjHPPX7Y0PAR2R012K7sLcn6+e7keH+eJJggpwx4L73C7W2SeCklR9TdkcmlE fRK1XtgfoLG5wJdvpZXk+sgdlTmN3s0W+xcOsAJsegrBLTRZKUZQ69vukvtNw8oPOrixO9sve/jva ud6M0BEnbtou7+F4rsBFzqfnawY10fzX1W7JPTJC8u9zEWv2Zb7CT+Lcps/a+dzM4hkwWMeho1Aaq 3+Xm7f1iwPmSFRmdW0tFMBoOVJC1wE61GrDiaLSMGDiq4I6Jksl2PHPpHBZjg4drXH7MNk0kpv4xp 5Zuq23yNeA==; Received: from bufobufo.ripe.net ([2001:67c:2e8:23::c100:170d]:37370) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1msTM7-0000f6-Uc; Wed, 01 Dec 2021 18:25:19 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=smtpclient.apple) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1msTM7-0008MI-O4; Wed, 01 Dec 2021 18:25:19 +0100 From: Ties de Kock Message-Id: <3DDA5BF5-A890-4223-B554-352758EB8705@ripe.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_3ACB2C34-4A39-49B2-8879-0CDB28316BA5" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Wed, 1 Dec 2021 18:25:18 +0100 In-Reply-To: Cc: stephen.kent=40verizon.net@dmarc.ietf.org, SIDR Operations WG , Warren Kumari , draft-ietf-sidrops-6486bis@ietf.org To: Job Snijders References: <813d1599-fc9d-18b6-a76c-b550855b1186@verizon.net> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e1aaf1046558286aefff50754294b731a3 Archived-At: Subject: Re: [Sidrops] AD Review of: draft-ietf-sidrops-6486bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2021 17:25:35 -0000 --Apple-Mail=_3ACB2C34-4A39-49B2-8879-0CDB28316BA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, > On 30 Nov 2021, at 23:16, Job Snijders = wrote: >=20 > Hi all. >=20 > Thank you Warren for your review, thanks Stephen Kent for responding. >=20 > On Tue, 30 Nov 2021 at 19:44, Stephen Kent = > wrote: >=20 > > 2: S 4.2.2. Names in FileAndHash objects > > "As an example, =E2=80=99vixxBTS_TVXQ-2pmGOT7.cer=E2=80=99 is a = valid filename." > > I'm not sure where to make this comment (here or in the validation=20= > > section), but I'm *assuming* that the case is "important" --=20 > > vixxBTS.cer !=3D VIXXBTS.CER? There are some operating systems which = are=20 > > case insensitive for filenames (e.g: Mac OS can format a device as=20= > > "Mac OS Extended (Journaled)" or "Mac OS Extended (Case-sensitive,=20= > > Journaled)". I'm suspecting that this might be a corner case, and / = or=20 > > not really an issue for this document, but it seems like it may be=20= > > worth having a reminder / note. >=20 > This text first appeared in version 3 of 6496bis, published in = November=20 > 2020, over a year ago. The text was proposed by Job Snijders. The = topic=20 > of case sensitivity, as well as some other aspects of the proposed = text,=20 > were discussed on the list from 11/19-11/24/20, by several WG=20 > participants. I'm happy to add further clarification re case=20 > sensitivity, if the WG agrees on what that clarification should be. >=20 >=20 > I would like to suggest to leave this part of the document as-is. >=20 > I don=E2=80=99t recall there ever having been any ambiguity in the = minds of either RP developers, or CA operators, on the topic of case = sensitivity. >=20 > A contextual aspect is that each file (listed by name), also is = addressable by its SHA256 hash, also listed on the manifest. There also was some off-list discussion about edge-cases (such as RPs = truncating file names where the IA5String contains a null-byte). In the end the = signature on such a manifest shows the CAs intent. It is extremely hard to get rules about file names right (length, null = bytes, name collisions) and I don't think these rules should be a major section = here. Perhaps there is another document we can refer to? Kind regards Ties >=20 > Kind regards, >=20 > Job > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops --Apple-Mail=_3ACB2C34-4A39-49B2-8879-0CDB28316BA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = all,

On 30 Nov 2021, at 23:16, Job Snijders <job=3D40fastly.com@dmarc.ietf.org> wrote:

Hi all.

Thank you Warren for your = review, thanks Stephen Kent for responding.

On Tue, 30 Nov 2021 at = 19:44, Stephen Kent <stephen.kent=3D40verizon.net@dmarc.ietf.org> wrote:

> 2: S 4.2.2. Names in FileAndHash objects
> "As an example, =E2=80=99vixxBTS_TVXQ-2pmGOT7.cer=E2=80=99 is a = valid filename."
> I'm not sure where to make this comment (here or in the validation =
> section), but I'm *assuming* that the case is "important" --
> vixxBTS.cer !=3D VIXXBTS.CER? There are some operating systems = which are
> case insensitive for filenames (e.g: Mac OS can format a device as =
> "Mac OS Extended (Journaled)" or "Mac OS Extended (Case-sensitive, =
> Journaled)". I'm suspecting that this might be a corner case, and / = or
> not really an issue for this document, but it seems like it may be =
> worth having a reminder / note.

This text first appeared in version 3 of 6496bis, published in November =
2020, over a year ago. The text was proposed by Job Snijders. The topic =
of case sensitivity, as well as some other aspects of the proposed text, =
were discussed on the list from 11/19-11/24/20, by several WG
participants. I'm happy to add further clarification re case
sensitivity, if the WG agrees on what that clarification should = be.


I would like to suggest to leave this part of = the document as-is.

I don=E2=80=99t recall = there ever having been any ambiguity in the minds of either RP = developers, or CA operators, on the topic of case sensitivity.

A contextual aspect is that each file (listed by name), also = is addressable by its SHA256 hash, also listed on the = manifest.

There also was some off-list discussion about = edge-cases (such as RPs truncating
file names where the = IA5String contains a null-byte). In the end the signature
on = such a manifest shows the CAs intent.

It is extremely hard to get rules about file names = right (length, null bytes,
name collisions) and I don't think = these rules should be a major section here.
Perhaps there is = another document we can refer to?

Kind= regards
Ties


Kind regards,

Job
_______________________________________________
Sidrops = mailing list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

= --Apple-Mail=_3ACB2C34-4A39-49B2-8879-0CDB28316BA5-- From nobody Thu Dec 2 08:46:35 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408833A1202 for ; Thu, 2 Dec 2021 08:46:33 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyZd_8E7HbZF for ; Thu, 2 Dec 2021 08:46:30 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 D11873A1200 for ; Thu, 2 Dec 2021 08:46:28 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mspE0-0005Mf-HG; Thu, 02 Dec 2021 16:46:24 +0000 Date: Thu, 02 Dec 2021 08:46:23 -0800 Message-ID: From: Randy Bush To: Tim Bruijnzeels Cc: "sidrops@ietf.org" In-Reply-To: <14BFC0A3-0352-47C7-86CF-23223F0E660E@nlnetlabs.nl> References: <0B2DE27E-B67F-413B-806B-7131B90F3333@arrcus.com> <14BFC0A3-0352-47C7-86CF-23223F0E660E@nlnetlabs.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2021 16:46:33 -0000 tim, i am confused, so i keep going back to your messages on ASPA. i just don't get it. you'll have to try a new clue bat. the RP cache's job is to deal with all the RPKI cruft, crypto, alg rolls, transfers, whatever. the job of the cache is to insulate the router from all that. in the ASPA case, the cache takes what it knows, sums it up (as in set union), and whacks it off to the router in completely processed form. what am i missing here? randy From nobody Thu Dec 2 10:15:33 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB2B3A135C; Thu, 2 Dec 2021 10:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.306 X-Spam-Level: X-Spam-Status: No, score=-0.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFpqtEP8aSSX; Thu, 2 Dec 2021 10:15:28 -0800 (PST) Received: from relay.ops-netman.net (unknown [IPv6:2606:700:e:550:5c82:28ff:fe4c:9503]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 028F83A1360; Thu, 2 Dec 2021 10:15:27 -0800 (PST) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by relay.ops-netman.net (Postfix) with ESMTPS id 8C7E23C1EEA; Thu, 2 Dec 2021 18:15:23 +0000 (UTC) Received: from mailserver.ops-netman.net.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 0FC60221; Thu, 2 Dec 2021 18:15:23 +0000 (UTC) Date: Thu, 02 Dec 2021 18:15:22 +0000 Message-ID: <87y252j2kl.wl-morrowc@ops-netman.net> From: Chris Morrow To: sidrops@ietf.org, sidrops-chairs@ietf.org,sidrops-ads@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] WG-ADOPTION: draft-ymbk-sidrops-rov-no-rr - ENDS: 12/16/2021 (2021 Dec 16) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2021 18:15:31 -0000 Howdy WG Folks! The Author(s) of: https://datatracker.ietf.org/doc/draft-ymbk-sidrops-rov-no-rr/ have requested that a Working-Group Adoption Call be made for their draft. The abstract of said draft is: "A BGP Speaker performing RPKI-based policy should not issue Route Refresh to its neighbors when receiving new RPKI data. A method for avoiding doing so is described." Please take a moment to read the 3 pages of content at: https://datatracker.ietf.org/doc/draft-ymbk-sidrops-rov-no-rr/ and express your opinion on Adoption as a WG Draft or not, in the coming 2 wk period which should end on/about 12/16/2021 (Dec 16th 2021). Thanks! -chris co-chair-persona From nobody Thu Dec 2 10:16:59 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCB63A1365 for ; Thu, 2 Dec 2021 10:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0xU8YQmxWG8 for ; Thu, 2 Dec 2021 10:16:53 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 6947D3A1366 for ; Thu, 2 Dec 2021 10:16:53 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id k21so596732ioh.4 for ; Thu, 02 Dec 2021 10:16:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3W1zUXx9VcANkDxk39sYf1Tj5zb4kbpHXDZSnQ+Zln4=; b=OPPzWAd9P4xJ0WyXHcfRoAcNlYlYnbRWM2UXwF40AImywRkZ+Qwa7PLmCo5Ic7If6N 7Mw1kNNk/KAqt5Dvz8l01+qIMJUax7DQbQrIH4FlcbLHSLQfP4IY6LVlHmm4FQuKeU5N LqQ+yQxomgVDOrLgeLK1Nf18RJUwpJXnkPFKk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3W1zUXx9VcANkDxk39sYf1Tj5zb4kbpHXDZSnQ+Zln4=; b=u866XZ8IRuYe5Pbwt2BQyPWV35VBtPv1YPpBKly0D6GEAOsLfobj0gzOFCmuU5Jq2S NcTT+k8V4BVzHDmB7ne9tzB/J8hyM+D/kdipSzmToY+w6wi1jUDfCPLXiIzp8gaVLVfj uT644/aJHpek86+d2uPob9YxNqtxz9z0oQT/SEq5bja2w7IiJmjrzmeptrZ2B6+7k4pF 2c6y9ti6jKUSqeWOrTx2p3jHFi2k0vrLqx7u/KyqM/Vy1Z+5rdpIcM1Ud/hMkKpeD4o0 cakV5gG1DqR2yYXPJX/Es5slLrTXA+5kcgY1g/mxZWqsuTHBi6CJ8K44KKuIgSY1XSgn VRFA== X-Gm-Message-State: AOAM532CYHGYDn/VR6NtbTcbTewBdsStO5XvSaRshuExItqLnK2iZz3u gNTNzoY9g48GkSytcaSXgRLnEkffmAc2mP6+Votb8baY0t0= X-Google-Smtp-Source: ABdhPJw8ebtEhAZE/V6U2P3+2nZHuCY7mJmpNoRRRX+zcy+44YBe5dRK5K6dBZj0Xt/2dUHCwx2wuO14iHWdPfZCqs4= X-Received: by 2002:a05:6602:2e90:: with SMTP id m16mr17148002iow.92.1638469012011; Thu, 02 Dec 2021 10:16:52 -0800 (PST) MIME-Version: 1.0 References: <87y252j2kl.wl-morrowc@ops-netman.net> In-Reply-To: <87y252j2kl.wl-morrowc@ops-netman.net> From: Job Snijders Date: Thu, 2 Dec 2021 19:16:41 +0100 Message-ID: To: Chris Morrow Cc: sidrops@ietf.org, sidrops-ads@ietf.org, sidrops-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000006fd00905d22dcb4c" Archived-At: Subject: Re: [Sidrops] WG-ADOPTION: draft-ymbk-sidrops-rov-no-rr - ENDS: 12/16/2021 (2021 Dec 16) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2021 18:16:58 -0000 --0000000000006fd00905d22dcb4c Content-Type: text/plain; charset="UTF-8" Hi, I support WG adoption of this draft. Thanks Kind regards, Job On Thu, 2 Dec 2021 at 19:15, Chris Morrow wrote: > > Howdy WG Folks! > > The Author(s) of: > https://datatracker.ietf.org/doc/draft-ymbk-sidrops-rov-no-rr/ > > have requested that a Working-Group Adoption Call be made for their draft. > The abstract of said draft is: > "A BGP Speaker performing RPKI-based policy should not issue Route > Refresh to its neighbors when receiving new RPKI data. A method for > avoiding doing so is described." > > Please take a moment to read the 3 pages of content at: > https://datatracker.ietf.org/doc/draft-ymbk-sidrops-rov-no-rr/ > > and express your opinion on Adoption as a WG Draft or not, in the coming > 2 wk period which should end on/about 12/16/2021 (Dec 16th 2021). > > Thanks! > -chris > co-chair-persona > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --0000000000006fd00905d22dcb4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I = support WG adoption of this draft. Thanks

=
Kind regards,

Job

On Thu, 2 Dec 2021 at 19:15, Chris Morrow <morrowc@ops-netman.net> wrote:

Howdy WG Folks!

The Author(s) of:
=C2=A0 https://datatracker.ietf.org/do= c/draft-ymbk-sidrops-rov-no-rr/

have requested that a Working-Group Adoption Call be made for their draft.<= br> The abstract of said draft is:
=C2=A0 "A BGP Speaker performing RPKI-based policy should not issue Ro= ute
=C2=A0 =C2=A0Refresh to its neighbors when receiving new RPKI data.=C2=A0 A= method for
=C2=A0 =C2=A0avoiding doing so is described."

Please take a moment to read the 3 pages of content at:
=C2=A0 https://datatracker.ietf.org/do= c/draft-ymbk-sidrops-rov-no-rr/

and express your opinion on Adoption as a WG Draft or not, in the coming 2 wk period which should end on/about 12/16/2021 (Dec 16th 2021).

Thanks!
-chris
co-chair-persona

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops
--0000000000006fd00905d22dcb4c-- From nobody Thu Dec 2 10:20:18 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDF33A1375; Thu, 2 Dec 2021 10:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2tM-vSCHU9v; Thu, 2 Dec 2021 10:20:12 -0800 (PST) Received: from relay.ops-netman.net (relay.ops-netman.net [192.110.255.59]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDE693A1374; Thu, 2 Dec 2021 10:20:11 -0800 (PST) Received: from mail.ops-netman.net (mail.ops-netman.net [199.168.90.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by relay.ops-netman.net (Postfix) with ESMTPS id 38CD23C1EEA; Thu, 2 Dec 2021 18:20:10 +0000 (UTC) Received: from mailserver.ops-netman.net.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 0037F221; Thu, 2 Dec 2021 18:20:09 +0000 (UTC) Date: Thu, 02 Dec 2021 18:20:09 +0000 Message-ID: <87v906j2cm.wl-morrowc@ops-netman.net> From: Chris Morrow To: sidrops@ietf.org, sidrops-chairs@ietf.org, sidrops-ads@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] WGLC - draft-ietf-sidrops-rpki-has-no-identity - ENDS 12/16/2021 (Dec 16 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2021 18:20:17 -0000 Howdy WG Folks! The Author(s) of: draft-ietf-sidrops-rpki-has-no-identity have requested a WGLC be made for their draft: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-has-no-identity-02 with abstract content: "There is a false notion that Internet Number Resources (INRs) in the RPKI can be associated with the real world identity of the 'owner' of an INR. This document attempts to put that notion to rest." Please take some time to read the ~3 pages of content at: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-has-no-identity-02 and provide you considered opinion on whether or not this document is prepared for evaluation by the great and powerful OZ (IESG). Deadline for reply is softly set at 12/16/2021 - Dec 16, 2021. Thanks! -chris co-chair-persona From nobody Thu Dec 2 10:47:35 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741C23A13A0; Thu, 2 Dec 2021 10:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.752 X-Spam-Level: X-Spam-Status: No, score=-3.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.852, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZfgCIWYGq-S; Thu, 2 Dec 2021 10:47:27 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C28673A13C0; Thu, 2 Dec 2021 10:47:25 -0800 (PST) Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) by mail.netability.ie (Postfix) with ESMTPSA id 9F8E69CC12; Thu, 2 Dec 2021 18:47:18 +0000 (GMT) To: Chris Morrow Cc: sidrops@ietf.org, sidrops-chairs@ietf.org, sidrops-ads@ietf.org References: <87y252j2kl.wl-morrowc@ops-netman.net> From: Nick Hilliard Message-ID: <6142e9ff-6383-003a-a4e7-644d22b0c66b@foobar.org> Date: Thu, 2 Dec 2021 18:47:17 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.52 MIME-Version: 1.0 In-Reply-To: <87y252j2kl.wl-morrowc@ops-netman.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] WG-ADOPTION: draft-ymbk-sidrops-rov-no-rr - ENDS: 12/16/2021 (2021 Dec 16) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2021 18:47:32 -0000 Chris Morrow wrote on 02/12/2021 18:15: > and express your opinion on Adoption as a WG Draft or not, in the coming > 2 wk period which should end on/about 12/16/2021 (Dec 16th 2021). yes please. Good ops material in this. Nick From nobody Thu Dec 2 12:05:11 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9953A082A; Thu, 2 Dec 2021 12:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.net 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 4KrhOrE8td0V; Thu, 2 Dec 2021 12:05:04 -0800 (PST) Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01on20617.outbound.protection.outlook.com [IPv6:2a01:111:f403:7004::617]) (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 4FE973A0822; Thu, 2 Dec 2021 12:04:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NTAQgaQk5u7Zg3Hc/59zlz4Jaqo9Ek2U2ymFO+fUMNf8SXV+iJG3I6wPHRnYe7JXPuBInysEt7S/6WBbjUdSjuYSqHFZ8JbG6362tLiObkZD4e0pshH6lejGj1g1bN17dqGmiaUw7zT+ks96zGtvLdhd65SnoSQ3UNJPJ/kUZY8q80QPtb4QF8YGPUP4xtnAdGqwr6Dai/rJ+W5IDmTSp4pyG71YsvdJEw/lcJNGsXkh+zxxzL9HHPKsnzHVm+k9qz19U0BnZSCFxjGWRAtE/eObsj0ofSTSKsci5zjVL9gmZVE9TjaFJWc9tjDC4xmbhjmZk4weo1k2yhq17C9eNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SHm1VyUmasx0kLGmrZ/MCHTv8IN2aIUzB3eAWtdBHGg=; b=HIbCflyGarCDqQ2SjDh0i4Cy7dUT+NaDJvFHhmCnJczwwOcEyJ1Hc6ahUIRkEbLfDxy7fGjGaa1BGltRzNFit/McrGTr31AivbBL0cMNH3PNrXjo1Fz8+O2pprGPOzpZMbje/DVloc9UntCftVn+JJTPXV4jE7ASGne6lmcxe0cYMu9vrzB3VMG3J8El9a9VkBl8B1XoLZfOzMHohnKwtHYoA9RWddLfYKG0l/Ku8GAMgu22gv0LmltAHEFrLtyYXqzbmtg+xJoCkvhg4fL+/jBZbmVq/6FyWDhLUvwBDjyISfV3tQo2spWXKPvcX3xnHr3+XccJSBXLJkQchxYm8w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=apnic.net; dmarc=pass action=none header.from=apnic.net; dkim=pass header.d=apnic.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SHm1VyUmasx0kLGmrZ/MCHTv8IN2aIUzB3eAWtdBHGg=; b=R2xVlvrtwU+Pk5yUOQdCmj5Ob3cw3YFAQG+TcgG3j2QBOcv8rdaFPUaA15ZGJZ5UMF9u9W/pwZkUQ0X0/mt9jLa9W1aJ6xa1LEGu3oAli8nXr0JA/GmBgGTBNEH3W1KmxttVWupKRFQ44/KtorZYVNMp94qFylvH2eaOhUFq+2w= Received: from SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:176::18) by SY4P282MB3031.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:160::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.21; Thu, 2 Dec 2021 20:04:40 +0000 Received: from SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM ([fe80::c834:8e45:135b:15d6]) by SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM ([fe80::c834:8e45:135b:15d6%6]) with mapi id 15.20.4713.030; Thu, 2 Dec 2021 20:04:39 +0000 From: Geoff Huston To: Chris Morrow CC: "sidrops@ietf.org" , "sidrops-chairs@ietf.org" , "sidrops-ads@ietf.org" Thread-Topic: [Sidrops] WGLC - draft-ietf-sidrops-rpki-has-no-identity - ENDS 12/16/2021 (Dec 16 2021) Thread-Index: AQHX56lIek54tNT0FU60UhtchksHS6wfoFmA Date: Thu, 2 Dec 2021 20:04:39 +0000 Message-ID: <1F30B4DD-F34A-40C2-89C4-6F84D7F83291@apnic.net> References: <87v906j2cm.wl-morrowc@ops-netman.net> In-Reply-To: <87v906j2cm.wl-morrowc@ops-netman.net> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3693.20.0.1.32) authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=apnic.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c2cf160a-7d95-4054-cfa1-08d9b5cef949 x-ms-traffictypediagnostic: SY4P282MB3031: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZQZlgXXC0rUIOV7fVrej6XPhAsnitg4NRIICS/NZB/wLjA2p4sS7Bykc/zhYhhxowNpzaB23A/h9RkkFA+HRv0zhKi+JZ/KoCzC1294iSQaa8ZYB235Qu5Rel1NfPN5Ug172eLL7+f87AWPZZZ2ntjQJ9V/C2pBCVc+K4EQJn75tWU/WDxbMJgr9x1r8XVYSRo+JGE+RAnvxY+HGwJqJFdp+r56Sil/DruiPRdnkXyG/ZRmxbhSV28PujAAdCnofurZTRm83PdAr7KpnjF6ATiikcr007iAiXRb+aTuliLDGQPAP5x5zvqxIbycfbti4G6QA1TSAmXKRbJL7xm1Mj3Vs9DrFx0eBtiUrkF186GiECYvbfZ2jQ+bpgh/hMyCymEesEeI+YyB3FLyqqj+NCV+3s6rroE2KLjZogkmXsp8VgnCD5xd4L8EEKkGEHWG2JqSlJEuKrf15Y/TZdQdHpwh8n80rqiqPwxJicJrTS0Hhx/J1raH+SmZKGiWO/rIBfPuLHcicba8I4SQzENZwSJ8y0/gXzW59DrBxQvUwScAgDm9TewY6yn7u8WcS1heMoeLvxpeI6g3KkIhG0ol8eAmApGF2AoNcoeI3N8iw+UMzX3TqC3DabbS0umZdAkyXvQ0ZTBVK3XYNCG7M6AqklPmbClXEQHeqSrsf73A/biUCho0l+dFy6siWPETgVyFMXibyL50BPG4ZB7eHSeHIvw0Nc7HxDrK7k7NP5bhgdy1JTVdvb1UXG0MxJLUW1lILERbvx0haEtKjTP1UUF+zCR5iYDAD86WnlqSs7lzRbxR9a9QyO4zdj6RyvLjOsMvg x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(136003)(39840400004)(396003)(366004)(346002)(66946007)(6506007)(53546011)(186003)(76116006)(64756008)(8676002)(66556008)(66446008)(2906002)(66476007)(508600001)(966005)(66574015)(33656002)(38070700005)(36756003)(4326008)(6486002)(8936002)(6512007)(54906003)(316002)(38100700002)(2616005)(83380400001)(6916009)(5660300002)(86362001)(71200400001)(122000001)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?d2lrR3NqY2Q1WjdHTHBYdS9BbWU3K2ZjQWFiUW1yNmZnZUZMVlhRd3lrWlZi?= =?utf-8?B?UFVpVHVQZzd5L3FJL0l5Q09hQ1lIYXNWTGpRSmVpQloxSFNHMzhhQnVacEsz?= =?utf-8?B?cjBUTVZZSTM1cWdyTTlqZU9BaFVVM0dCNkdIS3FNU3hMVUdjQU42cFVSelY1?= =?utf-8?B?N1lBQjhPOXNOOU9MdGNZQ2RqWVhXejkzU1orTzVJcS9hOGxVSy9HaVd6MTBy?= =?utf-8?B?bm9RU08vK3VZUUJmVkp5eXYraFRGUTdlY1ZaMzY4czgyTzFlMkJCMFFld01R?= =?utf-8?B?RVVrS1BpRlBWMlRpWnU2OWF6cUluOG1xTyt4TklqcFNiTmlGZFpBb3NGbXlE?= =?utf-8?B?NzVVSGtkYlJ2TVJJb2VyVEUzajVtRFdvYnFhZGQzQ2FKWTZmOEZyTENNcUZk?= =?utf-8?B?TzVuNXMzVHByR0hidFlTL3BoYnlvaXc3bXhPTnFESnE1cUlnQTRrWFk4U2F4?= =?utf-8?B?c2EyY3JRQkxjcU5rTDNQRmxsRURnek5hTHdKZEJyZmNSbjB1aXhUMnZ5T3BF?= =?utf-8?B?K2dIY0J4RlFMbjI5S0NlbzJXeHRIVTFHSGpMdU9sdjBlRFh6NkM2Z3lzRzlC?= =?utf-8?B?c0RRRmx6RkFaSURxUUpzZGpVSzM1M3BIYXBSeHI5SW1KdWhETDQxTkJZT2U2?= =?utf-8?B?U0pwK1kvSS9YMXlWYW5oZ2dQT0huUEwyRlowTFZ2OFhzS3lFYmxJTzN6SFkw?= =?utf-8?B?cm02U2V6ZEMwalRDN2NlYVgzcU5iVGFQMktyNzROYXZVVFE3OXF2VUNnWjRB?= =?utf-8?B?T1dCWkNqT2k4ZnN4NWNBbENNMlk5Sm4yb28rWWs4UkQwcEtxd0ZrRW12RThJ?= =?utf-8?B?cFNkMWpRdE1zK0lnWlhLZmJtUGJ5d0E4L2x4cWJsSXo4WXhBOGhaM25sNFc4?= =?utf-8?B?Tk0zd25jYmpIb0VsUU1GOTZjRWVkb2ppNkE2MzBjZEI4dHd5WUoyUCtHWDgy?= =?utf-8?B?MGR3SVZBVlRzUm9NeGkyVk9Xb01JOHo1dlFGSHkzQU55REMrbHpKaFFOSnUr?= =?utf-8?B?WFRRUXpRdnpOaGNFZjllVEFVTEtSbkU4S0RUWEVBUWxkdENCR0h5OEErVlVR?= =?utf-8?B?eGpBeFVLeFdKTzhxU2w1L1VsN203RGdIeG9yeXY0SXYwZ2JiVy8wNXdiejdn?= =?utf-8?B?OUFsL0VJQ3NSSzFHQ1hqdTNqVW4rR3Ava1gwbTJPazcyZjBnYzFaSkxOZ013?= =?utf-8?B?ZG1zeTRZSkhhZkI2NmhMaWJ4d0FQbHM0TkFpVmFvUXR0QWhZcExHbTdXRXNK?= =?utf-8?B?bEN2dSsvbHNJYWIxdjlvS3FndjRNMmdnNVcxTGlTcTNQaEJOMTlVU0VRTzFE?= =?utf-8?B?VWluWUpEYW5SdnVtQTdOTkVsenpzYlJJaG5veWY4QTZ4bHJ2NHQ3VkZGWnh5?= =?utf-8?B?cVFHUnJieGNVakVKWDhTbkV4WFNxSi94V1pJRUtFdFFqUkRhcWpDSXU0ZUl4?= =?utf-8?B?WjlEUUs0Z3RhcWdMc2JWZXpzdHBTVllheVJZMlhYTXhqR3J2em5jK3ZsK0do?= =?utf-8?B?d1p4NUd0amNmbWZVSmYzaW5jZUFaOUtHM2tQV1Q3QW9BVDBrQlpmRHc0Y3gr?= =?utf-8?B?TzAyU2FCVDBnQUloanFUaG02NG1KMGFnU0IrMlJsQVBBbUtuYStGd1duYSs3?= =?utf-8?B?bk1IbElGTjE1NjNyMUYwdUZ3WHFHL0JwUkVwZHdCMlNWcW5NajhhcmNkN0Uw?= =?utf-8?B?RUJ2MFQ2dGFLSUZuT2RyV01Sc0Z3QkYxVU5uZlNGNUtVbjRyLzdoQWh4VFJr?= =?utf-8?B?WkdZdnZEdXVGOFFBYnZzS2RMM2ZaRjZUTStrR29qSXdDV1pWN043cWhJVkM3?= =?utf-8?B?d0dUb1crTzBFVGdwTFpmbWFUSkRIQk1aNk1rdGNGNkZDeFJGdE1UVW02cis0?= =?utf-8?B?NkVDRktzYzRIb2puT2Fha202c05CV2ZWY3ZUU0MrRThXTENvbDMzZUpsL0Vm?= =?utf-8?B?N0t4WS9wU1hWdHBCU2hrQ1FTWjlhVDdSSXZVY1g2STNkVFFwbzlOWThYWmZ2?= =?utf-8?B?azlHbWU2TjU1d1l4RDl3MWVRQmQ5M2VWSnB1UTZDbFI1bnpSbUc5WUlQbk9F?= =?utf-8?B?dkhRUkZBYlJrYzBXQ1VCK1pVK0w5OEwrWmFSYmdkaG5xV2VyUkwrK3lHY1Bn?= =?utf-8?B?Vk9YVi9QKzF0Tk1tSnVVWGJaZjZ2Z1JiSXh4U0cwT1M2Y0VoblVHSzVGZEcx?= =?utf-8?Q?PGgE6BfVvTfaER3RRkOY0dPGRIbiyvfXhqtKTi2BDiXP?= Content-Type: text/plain; charset="utf-8" Content-ID: <298FCA208FBB034188F6229DD3AF948A@AUSP282.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: c2cf160a-7d95-4054-cfa1-08d9b5cef949 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2021 20:04:39.8964 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6ixQrgEmX5WAfNfpMNrnDKasvsM/sUCVm7a9ekj2MCK1Sznz5676gaRLVjGSCRx1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY4P282MB3031 Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-rpki-has-no-identity - ENDS 12/16/2021 (Dec 16 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2021 20:05:10 -0000 SSB0aGluayB0aGUgYXNzZXJ0aW9uIGluIHRoaXMgZHJhZnQgaXMgaW5jb3JyZWN0LCBvciBhdCBs ZWFzdCBzZW1hbnRpY2FsbHkgaW1wcmVjaXNlLg0KDQpXaGF0IGFuIFJQS0kgY2VydGlmaWNhdGUg aXMgYXR0ZXN0aW5nIGlzIHRoYXQgYXMgZmFyIGFzIHRoZSBjZXJ0aWZpY2F0ZSBpc3N1ZXIgaXMg Y29uY2VybmVkIHRoZSBob2xkZXIgb2YgdGhlIHByaXZhdGUga2V5IHdob3NlIHB1YmxpYyBrZXkg aXMgZ2l2ZW4gaW4gdGhpcyBjZXJ0aWZpY2F0ZSBpcyB0aGUgdW5pcXVlIGhvbGRlciAob3Ig4oCY b3duZXLigJkpIG9mIHRoZSByZXNvdXJjZXMgbGlzdGVkIGluIHRoZSBjZXJ0aWZpY2F0ZS4gDQoN Ck1vcmVvdmVyLCB0aGUgc2FtZSBzdWJqZWN0IG5hbWUgd2lsbCBOT1QgYmUgdXNlZCBieSBhIENB IHRvIGFzc29jaWF0ZSB0aGUgcmVzb3VyY2UgaG9sZGluZ3Mgb3IgdHdvIG9yIG1vcmUgZGlmZmVy ZW50IGFuZCBkaXN0aW5jdCBlbnRpdGllcy4NCg0KQW5kIGl0J3MgY2xlYXIgdGhhdCBhbnlvbmUg Y2FuIHVzZSBvdGhlciBkYXRhIHNvdXJjZXMgKHN1Y2ggYXMgcmVnaXN0cnkgcXVlcmllcykgdG8g YXNzb2NpYXRlIGEgY2VydGlmaWNhdGUgc3ViamVjdCBuYW1lIHdpdGggYSByZWdpc3RyeS1saXN0 ZWQgZW50aXR5J3MgaWRlbnRpdHksIGFuZCB0aGlzIGRyYWZ0IGlzIE5PVCBzYXlpbmcgdGhhdCBz dWNoIGEgcHJhY3RpY2UgaXMgZm9vbGhhcmR5IG9yIHdyb25nIGluIGFueSB3YXkuDQoNCnJlZ2Fy ZHMsDQoNCiAgIEdlb2ZmDQoNCiAgDQoNCj4gT24gMyBEZWMgMjAyMSwgYXQgNToyMCBhbSwgQ2hy aXMgTW9ycm93IDxtb3Jyb3djQG9wcy1uZXRtYW4ubmV0PiB3cm90ZToNCj4gDQo+IA0KPiBIb3dk eSBXRyBGb2xrcyENCj4gDQo+IFRoZSBBdXRob3Iocykgb2Y6DQo+ICBkcmFmdC1pZXRmLXNpZHJv cHMtcnBraS1oYXMtbm8taWRlbnRpdHkNCj4gDQo+IGhhdmUgcmVxdWVzdGVkIGEgV0dMQyBiZSBt YWRlIGZvciB0aGVpciBkcmFmdDoNCj4gIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtaWV0Zi1zaWRyb3BzLXJwa2ktaGFzLW5vLWlkZW50aXR5LTAyDQo+IA0KPiB3 aXRoIGFic3RyYWN0IGNvbnRlbnQ6DQo+ICAiVGhlcmUgaXMgYSBmYWxzZSBub3Rpb24gdGhhdCBJ bnRlcm5ldCBOdW1iZXIgUmVzb3VyY2VzIChJTlJzKSBpbiB0aGUNCj4gICBSUEtJIGNhbiBiZSBh c3NvY2lhdGVkIHdpdGggdGhlIHJlYWwgd29ybGQgaWRlbnRpdHkgb2YgdGhlICdvd25lcicgb2YN Cj4gICBhbiBJTlIuICBUaGlzIGRvY3VtZW50IGF0dGVtcHRzIHRvIHB1dCB0aGF0IG5vdGlvbiB0 byByZXN0LiINCj4gDQo+IFBsZWFzZSB0YWtlIHNvbWUgdGltZSB0byByZWFkIHRoZSB+MyBwYWdl cyBvZiBjb250ZW50IGF0Og0KPiAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC1pZXRmLXNpZHJvcHMtcnBraS1oYXMtbm8taWRlbnRpdHktMDINCj4gDQo+IGFuZCBw cm92aWRlIHlvdSBjb25zaWRlcmVkIG9waW5pb24gb24gd2hldGhlciBvciBub3QgdGhpcyBkb2N1 bWVudCBpcyBwcmVwYXJlZA0KPiBmb3IgZXZhbHVhdGlvbiBieSB0aGUgZ3JlYXQgYW5kIHBvd2Vy ZnVsIE9aIChJRVNHKS4gRGVhZGxpbmUgZm9yIHJlcGx5IGlzDQo+IHNvZnRseSBzZXQgYXQgMTIv MTYvMjAyMSAtIERlYyAxNiwgMjAyMS4NCj4gDQo+IFRoYW5rcyENCj4gLWNocmlzDQo+IGNvLWNo YWlyLXBlcnNvbmENCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IFNpZHJvcHMgbWFpbGluZyBsaXN0DQo+IFNpZHJvcHNAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRyb3BzDQoNCg== From nobody Thu Dec 2 12:44:08 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A7B3A096A for ; Thu, 2 Dec 2021 12:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfOF-yC_7JcQ for ; Thu, 2 Dec 2021 12:44:01 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 165F33A096B for ; Thu, 2 Dec 2021 12:44:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3BC12300BDA for ; Thu, 2 Dec 2021 15:44:03 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id J8_cfW-eS9id for ; Thu, 2 Dec 2021 15:44:01 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 1C80B3005D7; Thu, 2 Dec 2021 15:44:01 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Russ Housley In-Reply-To: <1F30B4DD-F34A-40C2-89C4-6F84D7F83291@apnic.net> Date: Thu, 2 Dec 2021 15:43:57 -0500 Cc: "sidrops@ietf.org" , "sidrops-ads@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0E6ED68D-46F0-4303-8FF4-1932847E43DC@vigilsec.com> References: <87v906j2cm.wl-morrowc@ops-netman.net> <1F30B4DD-F34A-40C2-89C4-6F84D7F83291@apnic.net> To: Geoff Huston X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-rpki-has-no-identity - ENDS 12/16/2021 (Dec 16 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2021 20:44:07 -0000 Geoff: I do not think you mean that it is appropriate for the private key = associated with an RPKI certificate to sign a legal document or an email = message. What semantic imprecision needs to be resolved in your mind? Russ > On Dec 2, 2021, at 3:04 PM, Geoff Huston wrote: >=20 > I think the assertion in this draft is incorrect, or at least = semantically imprecise. >=20 > What an RPKI certificate is attesting is that as far as the = certificate issuer is concerned the holder of the private key whose = public key is given in this certificate is the unique holder (or = =E2=80=98owner=E2=80=99) of the resources listed in the certificate.=20 >=20 > Moreover, the same subject name will NOT be used by a CA to associate = the resource holdings or two or more different and distinct entities. >=20 > And it's clear that anyone can use other data sources (such as = registry queries) to associate a certificate subject name with a = registry-listed entity's identity, and this draft is NOT saying that = such a practice is foolhardy or wrong in any way. >=20 > regards, >=20 > Geoff >=20 >=20 >=20 >> On 3 Dec 2021, at 5:20 am, Chris Morrow = wrote: >>=20 >>=20 >> Howdy WG Folks! >>=20 >> The Author(s) of: >> draft-ietf-sidrops-rpki-has-no-identity >>=20 >> have requested a WGLC be made for their draft: >> = https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-has-no-ident= ity-02 >>=20 >> with abstract content: >> "There is a false notion that Internet Number Resources (INRs) in the >> RPKI can be associated with the real world identity of the 'owner' = of >> an INR. This document attempts to put that notion to rest." >>=20 >> Please take some time to read the ~3 pages of content at: >> = https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-has-no-ident= ity-02 >>=20 >> and provide you considered opinion on whether or not this document is = prepared >> for evaluation by the great and powerful OZ (IESG). Deadline for = reply is >> softly set at 12/16/2021 - Dec 16, 2021. >>=20 >> Thanks! >> -chris >> co-chair-persona >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Dec 2 13:48:14 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FFE3A00E9 for ; Thu, 2 Dec 2021 13:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net 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 dS6l_r31eycb for ; Thu, 2 Dec 2021 13:48:08 -0800 (PST) Received: from sonic309-21.consmr.mail.ne1.yahoo.com (sonic309-21.consmr.mail.ne1.yahoo.com [66.163.184.147]) (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 D76D63A00E1 for ; Thu, 2 Dec 2021 13:48:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1638481687; bh=zdcX5iO5nGk0nzsCVUmeQUeIhUCiYsYCU18p8FpVOWU=; h=Date:Subject:To:References:From:In-Reply-To:From:Subject:Reply-To; b=RTwpkb86zO0ReS+hkrqAte7mqs7cnYdwiv8FEHZ7fFCU8ZVGsfoQRsa+VLj/PrpkyFMO/k7d+rj2mydl+fQ08IOgMR5UGOmScQZeFBKgb7zJGrnmrW/1jcjqGscB2jJaMe3qrsq2d0bUxHdL9PHc+5NOwUc7jJCqO+7QhDqmvNoFuklF2Xir/WT0Yr5X9FDgckozqm1M7CvovMKAS4D0J4XjcfGn3ObkVcaqdamDJoppLGVkfznqn6exR4use1JWwAKZOu3ZfTDAMV7oAUFVAUTugVBRbOetb9peMODPKrocVU+63b9Xt0neFT8dv0XOEjgNwN56DbJlcXw+9nJm2A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638481687; bh=rkVBBk0aLvRziSZTnHXZmVzjAJ1+zoeCJJ1e9qeOH9y=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=CB8NVq10zTev/LjX1IKBMghKje8LVbdVCIJk04m79eFPYiMyBBMw7BQv4ePZ+hh8apk782QhX1Cev8oZDWFcnyYkrJjK+yM+HNPK8fggBiSkCSZGu+xSloXSOdD84Nc4NBIhg+b3DXHL9Gwy1ID9RPdV/erpZ78Kc2UoSZ5jJ3Dn1Sy3juLaR10HZoPInbOqUG54Kah5FOgvIZKonHX7f6F2G58yOS0s8t/73cyROmTL1HGVKLbFulYxfpCDAoMFr5Y8KOi4pIoZb0cyIoe0P7FbbdnwI2B02S7T+ln8Zi/znKaQyxX4z/BlTm6k4qqjd7uoJdSJ3ze9RaZL85nkfw== X-YMail-OSG: tu_jr0YVM1m7hBaoFBYzIRr8IfT2BGQNA4rG0dUZiX6kACU5mIKEIsBpTbxczkt yejtlDexAzQCkKlNkitbwegdgX3hNC6sfqEMxhqIUKmDcX0l8qtsKp9aHbSsg15Ek6_SFG4blrIu aln6IzIaPwq9FFDYBVcMkYUuxcp9ye_4nTuhKYBiePjYJTehtSWbhxEaMqwXPGGD3e.eH84Tz4Iz 2x0LUPOiFP7Qgk80xCE.zEmABqUcvk_fLMTaZNn4iXZDbqDmiz7drvbPk9WaXpuk6jn6FpHJEDBI kzSTakgXLjvDnc2aIvGxKZqgH7n.zzfDof1cm0wora4ls5C_R.WT.rngKat2zRFdAU2Q7sBSMXqu UTm8jLgi0WCC5jzDmNUlDHQJeeAsltee7NCGH9IEYyeOkhVSur7QiMlnbXx3r9uaVXfMAa83fFPN NCrm0ecn4ctsS9pK1p1rmWCb0Z62U3O7CGANt_9R.RV9mWy8qGGTVjzUMAH8Qm2j07r1_x1SeMwl j1bsVrmhlG6z7maVe9MsFitUxpKxIzlI0wJTcSOQhpMPWkK8YkPkmi8y_4MPcR5VR4xl1eW9aSVI PY5FTfW.L93GmhW9znRJ0A4wPO0_SlveRr5CblDFtWx1YDLA.jGpByiyp9rEPg7AP8tA4bLWeOCa EaqlJE5US_BPsZoVUqifzxkvHZhnpI7xSu4GWbfD7WFYjFikRQ7GANpmGuG68170QCxE8qT9etO3 yAACaiJxA2sxFcbYG9nUZBiocZNh_97YtrGtt5o6IQT6eU99QLyWkYFYL_0lxCbmY1QSJfWCLHq0 dsfmpVlVcKHyO9A6mgeMzU..l1du6XkJZSL3Vn5vxtCzG5FrsIAGUycLjb35PGeVbUIHrXy35qx7 1DtA8qQ8kAsqoda3C1lnGcWdSVWWtM.tvgT7tAkxgG4FBTlaJK7quP4A3qbrlihIndIzCYZUcI1C IFOy5fHRGZyvVcwJJ7s20vML3ejuojmxkD0GxygMaJBgv0.4moP4UJsICmm7UXi7BaFSCBiA5l62 VPSUx0m6NJPW7LaRisNRgwZ97qVEkKcGh_SR6fiMhTr5Z_Yg3RR8QRVo9VT2SkIkmlmEIINjAmGt N0D7bGFfPCs01bAobdWfRHibX_KCfysphHqAf7z3xKJhNGlbzn.1K6iktciN4dtOdN66xFnuH4nG lw2s9Z.vggRmW8jK0HUWEHX2B6uqDufRpwpMk7YX2aZ09OmuSlBRI9cy0cHtWnOmNfV5enA7wz1u 183mqK6zmiPHnHvk90qdDAWCD4OgDN9iTfDV4Fg.vjRaI_Lq4Eof_ixqCYBaNj.Vvg82lftOpcbJ IYb4nEf_QUfCdqKPqUBLZiKHCB52bIO8VvyAJV_dCU.cXSs3.shDys5rS4_qUti7SMGteyFZ6BBo AZeLiyRLPlPfDm761EUPLt9WztkG4s9mVUac0GC.DsiIhsFRbTQ2Fgc.JBmVARqb7TOl45OCNgBB RT0xmPioYPhu3GUr3tEHCgAtlHmyhCdi52xtHehu4jDMDPCsuWX6ycOIyBtg_FsgcDh8F7J2zeaf u5hyKupfGHrzwsTKFQzk6hPa5tCkKtzUbLFxjoH4ZoLJjywprdGs1g73ikoiM0AvQM_6cZ.FyhBI eUE0n0x_eNYlDlXxm4cZOZ4IbzNwlA1n6Onwvhb.CVRk_uFQHEZcCGf6op8r0lWd3gbbCCGaMnCH frjWvl3.uoDtBSdGqDDbKeT.O377xToO0A04DSTD7SjlZCQGU6JfJSITBZ1RYdMXvdv7Uur110CS Ef_XWmkoSB6ShGp51F5Xgpx75l2tKwSMIjKMjYJ7f9wnqJVUHvmE8MHS1W5Rt0LJ8F.1smy.It3b thzd_ypjET4FXRmiqBo9ppF0R_mn7wOOu9ccf0.CpUjcqDN7hFRiynNuPR.DVn6BqW.nqvTtiR86 L5M_qpSBeaEETYbcTXgjyBOGaJd7JxCFC70z4ChYEti7XkTTiFEOQD0B2DNlm_IWvgk76T2jan6a hMgTnnTe3uEc96qMDbzIYQSj9vsby6yU2VW2IM8TFN_VeJ5nZmd7zgixpSi337.iJf7UcVZq2AB5 1qzQs8bhdYKGuCKygXkZy3Be_Ua3Ps7bv2KuVAourN_ihvaHxWYRPRn1KasnlwyIAbExSUZuBxkC bVT_ppDGibw8- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Thu, 2 Dec 2021 21:48:07 +0000 Received: by kubenode542.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID bfd7b1597d7e5c66d81e7c3c4becbab3; Thu, 02 Dec 2021 21:48:06 +0000 (UTC) Message-ID: Date: Thu, 2 Dec 2021 16:48:06 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: sidrops@ietf.org References: <87v906j2cm.wl-morrowc@ops-netman.net> <1F30B4DD-F34A-40C2-89C4-6F84D7F83291@apnic.net> From: Stephen Kent In-Reply-To: <1F30B4DD-F34A-40C2-89C4-6F84D7F83291@apnic.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: WebService/1.1.19306 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-rpki-has-no-identity - ENDS 12/16/2021 (Dec 16 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2021 21:48:13 -0000 Geoff, In the security arena, objects that attest to identity are viewed as different from those that attest to authorization, and I think that is the message this document is trying to convey. In the historical context, an RPKI cert would be viewed as a "capability" conferring authorization to the holder of the private key associated with the public key in the cert, irrespective of the identity of that private key holder. In the RPKI, an RP makes decisions about the validity of assertions about INR holdings based on this characteristic of the RPKI cert. This is in stark contrast to the Web PKI, where CAs assert that the name embedded in a cert is the identity of the private key holder. RPs in that context make value judgements about "trusting" a specified web site, based in large part on the asserted identity. because of this very significant difference, I think it';s appropriate to document the difference for users of the RPKI, who will, in general, be tempted to think about certs in the context of the Web PKI, with which they are more familiar. Steve > I think the assertion in this draft is incorrect, or at least semantically imprecise. > > What an RPKI certificate is attesting is that as far as the certificate issuer is concerned the holder of the private key whose public key is given in this certificate is the unique holder (or ‘owner’) of the resources listed in the certificate. > > Moreover, the same subject name will NOT be used by a CA to associate the resource holdings or two or more different and distinct entities. > > And it's clear that anyone can use other data sources (such as registry queries) to associate a certificate subject name with a registry-listed entity's identity, and this draft is NOT saying that such a practice is foolhardy or wrong in any way. > > regards, > > Geoff > > > https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Dec 2 14:09:33 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E9B3A07D3 for ; Thu, 2 Dec 2021 14:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.net 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 VxKQ4oB5aRfT for ; Thu, 2 Dec 2021 14:09:24 -0800 (PST) Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01on2061c.outbound.protection.outlook.com [IPv6:2a01:111:f403:7005::61c]) (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 6EF663A07D0 for ; Thu, 2 Dec 2021 14:09:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gEZftOcAgKRQPDsHG/zbOGHbDwXUJjgal1ZU7C8Q31K6vAC2jQ92mI0ZdMlMIOHmUYrhGA5ivXaFR9Y7FWZLqf10ubYkkjxhsFmAOx46HnheJ7NwtA+YWgjaMr7H581HW06v6SYal25FzAFFMgbSKMFjcQKU7RfurZ+otYS51nqCFJFVzk3xv9X2b8wQ8YuAFrUkgExT7XBB/G+gRNPKgYSfNAyNTDtAUQcDqby+tHr5FPzuol4yJsdru4ZpY3Nufuldc9POLmoeRgABnzqvDb0qWR2PYsnVUrk22R2Pf+Fkz76ac7dYmLKpOBki5hLvl8sRedwopGGbZTW53syv2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=v07Ax8NJduAsgedw4VmdN+tDXtkzMQpygpgHxnR2/yU=; b=m1jwWOxMo2t0Y5IGWn77qSG/VTzP6vRW1bX1xvDJeWcajdUvViWhVcHMEbGj7IdI/4WpUb4gorm7brgi/5EpgQhM7MSntUwEuZSJGwUl9QVwejmgkgj5XvxnbtUr16Wo8AS56/jD+iusb7nNML7cEJ/IsdNzLAfzPUCm/56bd1jx/DsocwsP4lDPRpOPssyfZ2m5r6ia0l/eaFcTh+ZH8XuixuF9+iArbwHaaNp8SVWDwzdQUqdhER71JpRCk8fGZTOtHhaEXhHYsR4XfTBHnPvcuve3sjXp+93u3KQ0pkGYmJP/pj7mWbIPNCPlu1LZPQeax7luLbBMboeDVhFOIA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=apnic.net; dmarc=pass action=none header.from=apnic.net; dkim=pass header.d=apnic.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v07Ax8NJduAsgedw4VmdN+tDXtkzMQpygpgHxnR2/yU=; b=dVTh7/SuuSYDGneahw/6nryewjepT+YQgWjNZkFg2sOoIrdkWcFBir+Tmp2/npUgzYYq8sVYQWYm//BogrAMUSWD1woaBmxA9BSjN5UtbkKhm2qrf/CIXPU+XZ83IstwmZZfjHGQl3nUhpEK6rola47pSrAixsehdcHAIkiLo+U= Received: from SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:176::18) by SY6P282MB3473.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:171::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.22; Thu, 2 Dec 2021 22:09:06 +0000 Received: from SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM ([fe80::c834:8e45:135b:15d6]) by SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM ([fe80::c834:8e45:135b:15d6%6]) with mapi id 15.20.4713.030; Thu, 2 Dec 2021 22:09:06 +0000 From: Geoff Huston To: Stephen Kent CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] WGLC - draft-ietf-sidrops-rpki-has-no-identity - ENDS 12/16/2021 (Dec 16 2021) Thread-Index: AQHX56lIek54tNT0FU60UhtchksHS6wfoFmAgAAc6ACAAAXdgA== Date: Thu, 2 Dec 2021 22:09:06 +0000 Message-ID: <6EBB2980-1315-4C14-8FBC-68368B91BBC9@apnic.net> References: <87v906j2cm.wl-morrowc@ops-netman.net> <1F30B4DD-F34A-40C2-89C4-6F84D7F83291@apnic.net> In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3693.20.0.1.32) authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=apnic.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3d48884f-26ba-4b3d-9b79-08d9b5e05bd4 x-ms-traffictypediagnostic: SY6P282MB3473: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /FBMY4vEtecbrBfaQGYGmf5BO+nR3fBnrdTg0Iacu/m0/wQrQuIww61bp1zCJCa6omzpS8rhBaN7LH2RKOaMNZjCUn53VsS9Mscc8OQM418a5vSHSUP5K9U2huzKO41py+nsCj1gpVPHrcTZIW9JmNj4kyEFwmDnxiZ6K13HQUdPE9KyUvsHb6F96bJe7J4FRDlPizlKxxYCsmyE71xRI2weKvd90DxI0VSRbRRmdGBoNkYPWKg5G4UYBtoP23wdUnXUJp2aImJY8yEqFrT6Pbxlwquu5NjNYpMg+48xw87/tbVf9WXI67Azez5zQkV6o1MkjVT+gIGeYf3SopdrKPae6jPBU4iYQrBCATD9ObbVAVPanwUVCzJDC71FhBZIasKlXsmhE+5RqLy8b0Th0NJ8g76a0LSSXYIYXfFrSjaAkD55H5cYN6N+13JhLvUhEjAsnN9LpllaQww7Rxx9tnDRUoj3LVV1MZhE6LUknvZoiaViBak4lSCNtg1EFfz1UnCa6X2QGfO5K23h/58hBJoZlrifPqvIu33sNMagWlXVNlKU55+//pGvH/DUYmZfcZ4IWiuViWFyG9IPiCF6Mcpg0lR08TT+Oc8uUu+zMwc+p4Sqox8CrVqOC2PdhRH9KLPyaQtjF2ltPRebbVeL/xIyklTccFEp4sBlCKwv483WfXLQjMSDojZ73JdZXrHe5VEK//XAAS1bFG3A+9R+h8Upwt9tFd6eWOeS+2ldo6wKzHJeaL9GiUgodBDSgDYy x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(136003)(366004)(396003)(39840400004)(8936002)(36756003)(508600001)(6486002)(6512007)(8676002)(66446008)(83380400001)(5660300002)(71200400001)(64756008)(66556008)(66476007)(66946007)(76116006)(2906002)(2616005)(33656002)(6506007)(53546011)(4326008)(186003)(38100700002)(86362001)(38070700005)(122000001)(316002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?ltgO0uMm95b3vMu6kRnliMs4aF1A7F42F8QwK7X48Fp2Trj8u9iMFPPiXlBq?= =?us-ascii?Q?mq+kQ12hhqPKVOAuoQwK2aKXewwiAxROFNyNmutmFd4j2tu6kiMgZddV5gm2?= =?us-ascii?Q?HMt+usvRwlVWX3sV/KA4Ap/94r6zbm0APCE9JgRiajult9+SyiO4TbYSHPPK?= =?us-ascii?Q?S76HMtb59l/DBk4LzsMsZXypbr7wNGbDk/9VQbnGHcgGmJkjy37p2tCDp9Dp?= =?us-ascii?Q?uKLzuA48gfTfK25uqWisAXosE56WZtHy7UyVsuKMw19lbTse7LJ27LfADEXf?= =?us-ascii?Q?Kxe+97QZUFyCN/SUM3Pc+Ry5WTSw+xLMpK+nibFAnPX35Sldljr3g486A1gp?= =?us-ascii?Q?Vo5zm7MgyqmCUzjyjF2gJsiAEXNScn6e1/qhovNXxewEfyXVf/Ix1EGkzuIB?= =?us-ascii?Q?mP/wHNvacnf8lMi0KTojB2tjQuVqtJa7G/chmtJBK23UiMl3yJ6iBbtk1Tj5?= =?us-ascii?Q?ApjmYivwj5GkHtwQhrsMgcGChA94GIafCxjoJhYkNSgagw37AwxIHnAQHVKR?= =?us-ascii?Q?BfF9g/TsXte719pUlJPE+63QzcBL5PpEX/5zg2DRGvqedAOaJdyuAezrtoSD?= =?us-ascii?Q?xL56cSdkiU+KAvWOF7X1o0LrhYx6kjNwa9RNLAYGIcb0H2yTbsuPR7cwuVno?= =?us-ascii?Q?FuL0h2EMBTU+lmwCSyClbrF1oqvDYoM9Ex6JYfy9IQ2xyKC1FQgJm2hwRCd1?= =?us-ascii?Q?UjpZUVw9oDm2/IMdBqLYwCOz5nDa8kZf2NpIO33Ru1m3rDsJr2/Fwg+NX4Js?= =?us-ascii?Q?P95V9yiWd1kW5sVuG0Fi/CrJtqbzLKEBMhnnqg39P4iIoXS2PaDvLmuGcDp3?= =?us-ascii?Q?Hsan1cEVRVo1ebaxteLoHQ7p3/MW4QmmIUR6Kl0Qb4oO0feQcLsnqiBHrWKa?= =?us-ascii?Q?mwi3fNVi1M6EhII2RRy0qrOsoEpL20rFlmUSVWvf6d3I19QtVnTCOov3tKoi?= =?us-ascii?Q?Ui+9Ff0U/FkfaNIP7qb2NPFhkCmizechbv1apkRBcBV6G0vIky3R/zGN709n?= =?us-ascii?Q?TIFSZPV67zOOGO8rMbHAXzDu5AEd+7y1CfdYGjhChhIyjayqktUfexsyOZoO?= =?us-ascii?Q?YPxLT2TfiV0GOc3are6uPHLTbgGBcUz/ia4t/WznaP3G42V2TahPykfMn/Uk?= =?us-ascii?Q?wyf6O1xzeXg5cAgPu2Zp6m9Dqi0gdIuL1kr+v7EfM3a7kAe7iWBd1/GU4EKp?= =?us-ascii?Q?Bg2dOmddxWvqUH+uwNWBe0DSw9dsU73WpN4tuPe2PKABczVlehKGyCrC5YG/?= =?us-ascii?Q?tOHLUyeAkaEqGknjnRhQr8Q+fvWs3PIpcs3pEKv3nPHFRnlbAWY4jujuaCns?= =?us-ascii?Q?7wUyMGQW4h4zLTps15fzH0Hoo5x0ReK1fTLs+Con15jCPv4z6AaDVBFu75Ne?= =?us-ascii?Q?gxGlsXLBY8QncBgF1iQ8Ei/AOQlLSChTPrOLrML/jOL3vxr9/Hs2idq0Fv1F?= =?us-ascii?Q?LrqNv1e6olFZs/z0jTfVVc6vYBcqT+C0+PBhi2FAi1eTSO+W0a/NvRhaOYoP?= =?us-ascii?Q?argDb2xHv+JmktR8WPXFLNYjIHkxbA30H2Nwak7aJnXEWSTUK292dVlYediH?= =?us-ascii?Q?fVnsbEsechgOgGqCQfxXhKi8xfwmjmxWj6hT26FKjSReU7LG4Pdh/9PiP1UT?= =?us-ascii?Q?qLhXXpUiVwec7QQAuPRnqDGG0VdQjyU5fjaUAggNuUal?= Content-Type: text/plain; charset="us-ascii" Content-ID: <0F02F92F84CF594EBB351BE40517D1A5@AUSP282.PROD.OUTLOOK.COM> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 3d48884f-26ba-4b3d-9b79-08d9b5e05bd4 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2021 22:09:06.7040 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CdY0EjyUg0gEFbkfHaqPG9hts+csdSyCJdRh0us/dXed2WSud8GLj63EadMb5STZ X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY6P282MB3473 Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-rpki-has-no-identity - ENDS 12/16/2021 (Dec 16 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2021 22:09:32 -0000 Hi Steve and WG folk, If I may, please excuse my interleaved comments in response. > On 3 Dec 2021, at 8:48 am, Stephen Kent wrote: >=20 > Geoff, >=20 > In the security arena, objects that attest to identity are viewed as diff= erent from those that attest to authorization, and I think that is the mess= age this document is trying to convey. I have absolutely no problems with this characterisation of the different a= ttestations between an authority and an attestation of corroboration of ide= ntification of identity. But in such a case it would be helpful if the word= s in the draft actually said precisely that. > In the historical context, an RPKI cert would be viewed as a "capability"= conferring authorization to the holder of the private key associated with = the public key in the cert, irrespective of the identity of that private ke= y holder. In the RPKI, an RP makes decisions about the validity of assertio= ns about INR holdings based on this characteristic of the RPKI cert. >=20 > This is in stark contrast to the Web PKI, where CAs assert that the name = embedded in a cert is the identity of the private key holder. Opinions differ as to the precise intent of a domain name certificate, but = that is perhaps a horse (?) of a different colour in the context of this di= scussion. > RPs in that context make value judgements about "trusting" a specified we= b site, based in large part on the asserted identity. >=20 > because of this very significant difference, I think it';s appropriate to= document the difference for users of the RPKI, who will, in general, be te= mpted to think about certs in the context of the Web PKI, with which they a= re more familiar. I don't think we differ here Steve, aside from my discomfort about the draf= t leaving a bunch of things that are unsaid, and my previously tated desire= to see a document be way more explicit and well defined. regards, Geoff From nobody Thu Dec 2 14:34:13 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7DC83A083D for ; Thu, 2 Dec 2021 14:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtRMzVIFGDP3 for ; Thu, 2 Dec 2021 14:34:07 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 5A0D53A083B for ; Thu, 2 Dec 2021 14:34:07 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id p23so1432264iod.7 for ; Thu, 02 Dec 2021 14:34:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gGJyP3G8yJG0vjIPFkL7OMY83K9X6r13tbWNPd5B5bM=; b=FaAKdSfLJX6S16umJuFaQoUsCi7gQHVUhWnVc6ZuTPYL4lPkXHFukVL5NcX5UwLIf6 EZ0e2o841cYvBdEEV0RWN1aXnozMxWJV1vFi8pnX0KB6OB3bql6ytjyIW0DBCdPs4w+g xVEWcupAS49IeatZGpwtJQrmU0HqkuZNMYJ2Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gGJyP3G8yJG0vjIPFkL7OMY83K9X6r13tbWNPd5B5bM=; b=u+oAT0x8sdqF8rO0vLAt68qAjym1ubOSGZYFa1HZXf51wU2WD50Cg2dxJbULbyUcm9 B/xrnw6OhhoAJsJoGD3vHj9cGUfT06M+M/jx9JZIX/d5GeADs5QNDvUqCBAOBVmvblGS YxmjIM9ZDAKMr3cDF25CZnq3P0tMHCARFjYGWUoYdzeenbXNAgBapXuY0u4BrQZii3JL ly0z/s3+9Ax71fcbGGkUZ997YZmwHLW6TcHFmQpTMA2BJ/pI6pw0MvpTc+nfmVMbywq7 oX7P9CytV/xo4qES8hJ1R+GA1hi2vywouBdPzUMckqQNeZ+TmqLrqgJ/Zh+0aAi6M1jw VJPg== X-Gm-Message-State: AOAM533LT/QvEFZA57qf5/iO4t2B02m2SlU8i2mYgFmtbQP2jidgomrz MjIeo0KuYuZx7ihgJFu9ny93q4KXKQGEdneUl2Y9RB5nIzo= X-Google-Smtp-Source: ABdhPJyr6IxcwpP/TJAOaqs2gQQL3r/JhFOZ2HEnrKanpqAyyBoov38G3Uhmx3uKQhWjo29GKZFpktKUWJYKf8lgKsM= X-Received: by 2002:a05:6602:25d4:: with SMTP id d20mr18379440iop.72.1638484446194; Thu, 02 Dec 2021 14:34:06 -0800 (PST) MIME-Version: 1.0 References: <87v906j2cm.wl-morrowc@ops-netman.net> <1F30B4DD-F34A-40C2-89C4-6F84D7F83291@apnic.net> In-Reply-To: From: Job Snijders Date: Thu, 2 Dec 2021 23:33:55 +0100 Message-ID: To: Stephen Kent Cc: sidrops@ietf.org Content-Type: multipart/alternative; boundary="00000000000062c67a05d231630d" Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-rpki-has-no-identity - ENDS 12/16/2021 (Dec 16 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2021 22:34:12 -0000 --00000000000062c67a05d231630d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Does the document in its current form succinctly edifice the general public about the contrast between RPKI and WebPKI applicability, aptly denoted by Stephen Kent? To me the current draft appears somewhat comprehensible for =E2=80=9CRPKI i= nsiders=E2=80=9D (if one squints their eyes to ignore the somewhat testy title, abstract, and introduction paragraphs), but is perhaps less informative to the wider IETF community. I believe there are real world business processes in which the ability to produce a valid RSC Signed Object will suffice for the RP to proceed certain process steps. Processes in which *who* issued the object doesn=E2= =80=99t matter - just like with ROAs, or BGPsec certs. Producing RSC objects is not like signing via DocuSign, we know. The current RSC draft links =E2=80=9Cno-identity=E2=80=9D as WIP informativ= e reference (because it is!), I=E2=80=99m happy to keep doing so - but I can also see h= ow the =E2=80=9Cno-real-world-identity=E2=80=9D draft would benefit from significa= nt restructuring. I=E2=80=99m not volunteering. :-) Kind regards, Job --00000000000062c67a05d231630d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Does the document in its current form succinctly edifice = the general public about the contrast between RPKI and WebPKI applicability= , aptly denoted by Stephen Kent?

To me the current draft appears somewhat comprehensible for =E2=80=9CRPK= I insiders=E2=80=9D (if one squints their eyes to ignore the somewhat testy= title, abstract, and introduction paragraphs), but is perhaps less informa= tive to the wider IETF community.

I believe there are real world business processes in which the ab= ility to produce a valid RSC Signed Object will suffice for the RP to proce= ed certain process steps. Processes in which *who* issued the object doesn= =E2=80=99t matter - just like with ROAs, or BGPsec certs. Producing RSC obj= ects is not like signing via DocuSign, we know.

=
The current RSC draft links =E2=80=9Cno-identity=E2= =80=9D as WIP informative reference (because it is!), I=E2=80=99m happy to = keep doing so - but I can also see how the =E2=80=9Cno-real-world-identity= =E2=80=9D draft would benefit from significant restructuring. I=E2=80=99m n= ot volunteering. :-)

Kin= d regards,

Job
--00000000000062c67a05d231630d-- From nobody Thu Dec 2 16:49:19 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0B93A0CF8; Thu, 2 Dec 2021 16:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.net 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 P3Kv7WDqRdvi; Thu, 2 Dec 2021 16:49:10 -0800 (PST) Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01on20613.outbound.protection.outlook.com [IPv6:2a01:111:f403:7005::613]) (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 C92663A0CF7; Thu, 2 Dec 2021 16:48:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I/QjfmYJK6YmSxgsZo0XVb/+BdINjOxc4mJx4BWTCq/yPXtN90Krutum1qxrgyrkpvZe3puEUI6yhjcbDAaHzjOH3VbpCuIXhnPDcN/jHVg16V3EL0qfnx34/K1otG5JJ2fEywy2BalJGLih06pbo7fsYVa+IM8qivlda4iv7p/Ie5M8nfmK9Llj2PPmezJMk76dioIdmdt/JIcsLYN5rBvxJZYukgoRcEoMQ/1XGfJv9kSEFnukoam5gC5Uat39FsfeqqsV/ztZ+g1a7qFZhBRDiZCXSTQF5qVfxoA9nxwzikhsbSr6mWUma3+5LeioqmSM0e5yCFDdTNX57SLVJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tCmstfEDqfPQkKlDQYDOFYmjhAxWoKX47RKg0DSIOmo=; b=a5/jVViYHt/7I8P2UGfMOHGfRUoLPiGjEKdUddPoAObXEZz9WOV+kaSQH7OvRB0PlZKMLDk+jDbnusK/l4GB9EkBzuiyOg4/dxrbi2fT1Zftz/Fi1F0YyURyruTJQ1WhnNkmT0a7a775XBou6rT3mxttpanq7BhYn77vU43/5cezXlhivvuZDt7cXH4Sb0ESVEM8U0IcGYBEh1E2vCla8IakBIsEZ+H4LT0DVLiWM2Z7fVZBPJUGmF4ciDmAyY00u/o/2RqnhCx3K92nMRYRwOoKhHshMgzI78wHfQb/ust6IGDZGDSXMAArqG+z2GjCUJxx5Jv2ruzWxmaQuh4gSQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=apnic.net; dmarc=pass action=none header.from=apnic.net; dkim=pass header.d=apnic.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tCmstfEDqfPQkKlDQYDOFYmjhAxWoKX47RKg0DSIOmo=; b=iYwo1AopTJif8GmotwDOzeQosKot+VQIDtGY3q/HgjL4Fja9uwruditq93khQtYZcP37p5mfdjApuTQgCpodmc7eKuzRCX8VJSFGIIs5WM37hHSXW9RM6XPJFqyZKguQAZ2bIxQ1Vs3ukhZueZ9IG7LRI7IdZ+bGRgd/4oNmccA= Received: from SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:176::18) by SYZP282MB3211.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:168::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.22; Fri, 3 Dec 2021 00:48:46 +0000 Received: from SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM ([fe80::c834:8e45:135b:15d6]) by SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM ([fe80::c834:8e45:135b:15d6%6]) with mapi id 15.20.4713.030; Fri, 3 Dec 2021 00:48:46 +0000 From: Geoff Huston To: Russ Housley CC: "sidrops@ietf.org" , "sidrops-ads@ietf.org" Thread-Topic: [Sidrops] WGLC - draft-ietf-sidrops-rpki-has-no-identity - ENDS 12/16/2021 (Dec 16 2021) Thread-Index: AQHX56lIek54tNT0FU60UhtchksHS6wfoFmAgAAK+4CAAERnAA== Date: Fri, 3 Dec 2021 00:48:46 +0000 Message-ID: References: <87v906j2cm.wl-morrowc@ops-netman.net> <1F30B4DD-F34A-40C2-89C4-6F84D7F83291@apnic.net> <0E6ED68D-46F0-4303-8FF4-1932847E43DC@vigilsec.com> In-Reply-To: <0E6ED68D-46F0-4303-8FF4-1932847E43DC@vigilsec.com> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3693.20.0.1.32) authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=apnic.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cd752109-91ca-4ac8-9d49-08d9b5f6a9f2 x-ms-traffictypediagnostic: SYZP282MB3211: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QCAQpTucHfhTm8gSSgudrVTa8pRgN2RVNWsLsJb6Ecpc3CdrI8i73ql4+kErocsqKwMiGG2yUfV/IJB8pE+6L8oqrVmXWur6QPr8d/NKFkRvTKFlVIKV0YrZt1gtWLWsEVQ3m9FITaiVQgCPdkT/mw3wMHCBe19WEWpX8JBVpaBkZhs0xlIyQLOeRHBzo5vmqVaJfbFZB/R6aZMCcXHS8RetffbW2meAcc6N093l9xMYF7mTjxbgKNx0hGjl/zndMVm3z+bdOSRFn+d+ycw3gymU78k1muk0KtLVrAm78cOZdLucUg4y1kUtRJLXawe0zgnrCPO83ReEeLWQODFuW2tI1uwcGhqA23x9oQ8305a+rkB+YRrBc4ehRjF2hkmjii2llVQYvKyGPjPPQn15Wnfe96oLmH6GorngRaAidB1lmBUWtszayzBsfUpghKr0c+BwOeOtNyjsmP7HjSP7addhYILKzQAmgrL09rRoSqJ5q7UoSmoUTNS7dQyCMhEdWzWLuvquPFttkLalrO6tPUOZZzUUpFO6Uswzx5PxUDZQD3r+vnZBJVCLnLOunj0TeD2NKXrr/r2yhgKCyv4Hoqxh6znp2MObcTtywiYzDZpZUmSMXHfdg8nXyI5gIhA7R1k9z1AbMDgZ0MSX8SJ6bH/sW0WtufuoTLvziXnm1H+wIRd69wupyfMU6rP25ozDUfQznItRV5eD0BQ1MWJI73ctaXTi+7AzDrmLLU+ObiHaeT6mHH39lkmP+lKnV+zzfGofLzopOU62qbW9FHYSlAvbVES1kDFHieAxMKi+p17tixo1AF/RT4aKjjUK3yQa x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(136003)(39840400004)(366004)(376002)(346002)(396003)(86362001)(4326008)(6512007)(966005)(71200400001)(2906002)(5660300002)(6506007)(36756003)(53546011)(122000001)(186003)(8676002)(38070700005)(38100700002)(508600001)(64756008)(66476007)(66574015)(66946007)(76116006)(2616005)(6486002)(66556008)(6916009)(316002)(33656002)(8936002)(66446008)(54906003)(83380400001)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?emFoM20yc0hLenVEVU9RTXVuTmxsKzlKQjYzdklNbWtQYWFGY2tYUElpN05O?= =?utf-8?B?VzdQKzFVMEM5RWRyVFZ3cnpyazdHbjdZekR5K1gvVHMzY2ZtYkVCWTJZRm1u?= =?utf-8?B?bk5NSk8xVmdYRk85UGFIMHpSWkdzekMyUFE3SmFMWkRuTFh6VHJwWVVDak5V?= =?utf-8?B?R0hhbFdtMnJFNGYzdmtDT0dCYWV6VWYxeWVxU3Jwalo3YndMd2VIU2s5SG1E?= =?utf-8?B?Sk8yZlVkOWJtUWlwYkp3UG9JNUh3NlIzME40TGFlZGl3SUVLaEoxbno3VGRN?= =?utf-8?B?NWpKc2MvMmVIU3pYTTkyQ0QzbXBXUTZUUFVlcllnYVZBMGxLeXd3dG5XTjNj?= =?utf-8?B?TERoOGJJeHdPd0ZiQVhHRG1ob1pRWWxXSEpycldyK05LdnRGOHloamlDQXNa?= =?utf-8?B?Y2V6RHFYd3U4ZDNvSVAxYVBtb2V4SnNHUWgva01vS1VSbTFnMm1VZFhORTJw?= =?utf-8?B?TXhjTkhEZFc0Y0dCOUx6WWtBdkJTOUcwMlowNEJlbWNqOTVYT3lXMlErQ1Zr?= =?utf-8?B?TGdMOCthWGlROHM4Y1daTm1QQ3BRVmtmbWw1aFdZTWh2dGVzM3hNWGJYNjda?= =?utf-8?B?UnRaa2MrdVpBMTNDZk5QYUpCVVJsQk5GMlVUQWxEYk4wNXRVNmtNMmFCc3Zi?= =?utf-8?B?L2xIWjdhR01oK1czWEJkZDRVQmRLU0NHWXhoK3VyS2VxVWUxTjl5clEvcm4v?= =?utf-8?B?RVNSbzZLZE1nNUFURDJnVVZQL1M3bVloTUtGaExQOHJZbUtMS09zSHZ0VDRW?= =?utf-8?B?eEFoQjRYY21hcVpOM1N6Ykx0Tm83RDAxK2U4R3JOa1cxQ2ozYitBdlpHeUlV?= =?utf-8?B?T21mbkxXUFkyeTUvWGJJT2J1VjZyOG93aUhwNkhxc0t2c1IrSWY4ZGd2clRu?= =?utf-8?B?ZVh6N2ZjWHVxazI1N0t1RGkreXMxQXBXcmV2ZGZnaHdDbWdWVFZVdHdOUVRG?= =?utf-8?B?TExhdWV2S09lYVhYSXRCOTFWN2JwVEdianVLUmFjT012TmdXeE5rbUZMUlpO?= =?utf-8?B?RHZQb2MydUQ1ZGcwMUxmK2NqQ3hvQW5mUEhMdXI2d0doUTFYY0J0Qkw1WUdO?= =?utf-8?B?eG5OWTRYUEl2cVJDZTZtdyt6VS9TMUptcndrTHlNcUk2b2tJZmFSY3d6bDIx?= =?utf-8?B?MXNIRW5JOGNJc0hSOE1WQnVFQ1RHYUlMc1RJTVlVbUVsWTd6ZFdyNVE4ZDBV?= =?utf-8?B?WmFMR29QSXBlYnc3eDFJUGVjeWJZVk1DMkYzTnJQQnl4cDVLeW9SREFXa0pS?= =?utf-8?B?S1p3TEZwcHgrWEJJOWx3ODlTUXZ3MEJOY09DNVdOLzBTdFRhcHBnL2tzOVdF?= =?utf-8?B?US8xV2l0N2E5cTRqb3FrUEI0VEY5aXRBSURTVyt5RTZBUDZDd012TVE4N1JH?= =?utf-8?B?TTJIK3ZBemREN083M0ZOMXphU2dudEpUR0VXSVhUT2N1Z0JPRVI0L1NoMUMz?= =?utf-8?B?SUlwV2FNenVkdzA0anNhOFFlRGhjSCtoS1VHK2FCSWV6TGJFWHd2ZFgwbTlL?= =?utf-8?B?WEFMMnNtUm5weGNiak91MjBnSy9VT1VIbitIOXBvQ2h1eUVqNnVRUkVuUm93?= =?utf-8?B?OURCRHkvZjZXZW1NVHVQYktiN0N0OXpvN1I5RTQveDg2M0szd1RYcHV3Sy96?= =?utf-8?B?UHJsZjJiZzZlcGtRTnFDTGlZUHZ1eTRrTElzTERaWC8wbHp6eGw2UUpLVEFa?= =?utf-8?B?RS9ibTg4S1lFMlV4NVU1NTArWTlvSklKcXk5K0lQNjREZGJNMzdKVEk3d0di?= =?utf-8?B?ejBKcTlxeFRkR2lMRmFUQUZnSUoxcW5GSExkQUI2bnFjdlh0b29Gbk5GU0oz?= =?utf-8?B?WEhGdVFqN3lwc3V6dVhZZDh4Snk0dTlvc3N3cGVvSFlqcTBKVVQ4TEVhMVgr?= =?utf-8?B?RkR6bUdOY2E1aFhtWHBGR2lHU295YzZTL2laeGlvSUU3TWVqbG10RzdQUTNo?= =?utf-8?B?Vk9GaDYvR05pL09xRDQ3U0QvcHpTNVlIdEN5cXZCeGdkVjNnZ1ArVUFTZWc4?= =?utf-8?B?b2Z6UktGTVVySWd4QmhYeGFSeSt6Z2NTZG9NWkNHanVaQkkrMjR1di8vYVRm?= =?utf-8?B?S3pSRjRMbFpjcmltOStLbm9tMkF1OGtybUh6OEJNaU9MN3IvVjVjLzVGa0tD?= =?utf-8?B?TExPVlptWW9YS2Rtb2dFcnd0NE5pMzhIK0haQkorM0NxNzNZbThQM2QwbnJs?= =?utf-8?Q?OdbBQav//FI9lK31l3Cfaz49/XuBHR1cm/H81EpEFj1G?= Content-Type: text/plain; charset="utf-8" Content-ID: <772760D49533A14FB07D9FFDFC1F5F4B@AUSP282.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: cd752109-91ca-4ac8-9d49-08d9b5f6a9f2 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2021 00:48:46.6312 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YebbJWLdOvklLQHRx5VTTk4C9OGi3WdorLRgCKxUPc9Cib2vPSC2R/atFiRs+h/O X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYZP282MB3211 Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-rpki-has-no-identity - ENDS 12/16/2021 (Dec 16 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 00:49:18 -0000 SGkgUnVzcywNCg0KTXkgcG9pbnQgd2FzIHRoYXQgdGhlIHRleHQgaXMgaGFuZHdhdmluZyBhbmQg aW1wcmVjaXNlLg0KDQpFdmVuIHlvdXIgdGV4dCB0aGF0IHNheXMgdGhhdCBJIGRvbid0IGludGVu ZCB0byBzYXkgdGhhdCAiaXQgaXMgYXBwcm9wcmlhdGUgZm9yIHRoZSBwcml2YXRlIGtleSBhc3Nv Y2lhdGVkIHdpdGggYW4gUlBLSSBjZXJ0aWZpY2F0ZSB0byBzaWduIGEgbGVnYWwgZG9jdW1lbnQg b3IgYW4gZW1haWwgbWVzc2FnZeKAnSBzZWVtcyB0byBtZSB0byBiZSBsYWNraW5nIGluIHByZWNp c2lvbi4gWWVzIEkgY2FuIHVzZSB0ZSBzYW1lIHByaXZhdGUga2V5IGZvciBhIHdob2xlIGJ1bmNo IG9mIGRpZmZlcmVudCB1c2VzLCBidXQgSSB0aGluayB3aGF0IHlvdSBtZWFuIGlzIHRoYXQgdGhl IFBLSSB0aGF0IGlzIGJlaW5nIHVzZWQgdG8gdmFsaWRhdGUgYSBwYXJ0aWN1bGFyIHVzZSBvZiB0 aGUga2V5IHByb3ZpZGVzIGEgY29udGV4dCBvZiB2YWxpZCB1c2UuIEl0J3Mgbm90IHRoZSBrZXkg cGVyIHNlIHlvdSBhcmUgcmVmZXJyaW5nIHRvLCBidXQgdGhlIHRlcm1zIGFuZCBjb25kaXRpb25z IHdoZXJlIGEgQ0Egd2FzIHdpbGxpbmcgdG8gaXNzdWUgYSBjZXJ0aWZpY2F0ZSBmb3IgdGhpcyBr ZXkgdGhhdCBkZWZpbmVzIGl0cyBzY29wZSBvZiB1c2UuIElmIEkgdXNlZCB0aGUgc2FtZSBwcml2 YXRlIGtleSB0byBnZW5lcmF0ZSBhIENTUiBmcm9tIG15IGdvdmVybm1lbnQgZm9yIHNvbWUgaWRl bnRpdHkgY2VydGlmaWNhdGUgYXMgSSBoYWQgdXNlZCB0byBjZXJ0aWZ5IHNvbWUgcmVzb3VyY2Vz IHVuZGVyIHRoZSBSUEtJLiBJdCdzIG5vdCB0aGUga2V5IHZhbHVlIGl0c2VsZiB0aGF0IGlzIHRo ZSBjb25zdHJhaW50IGhlcmUsIGJ1dCB0aGUgY29udGV4dCBvZiBjZXJ0aWZpY2F0aW9uIGJ5IHRo aXJkIHBhcnRpZXMgYXMgdG8gdGhlIHVuaXZlcnNlIG9mIGFwcGxpY2FiaWxpdHkgb2YgdmVyaWZp Y2F0aW9uIG9mIHByb2R1Y3RzIHNpZ25lZCB3aXRoIHRoYXQga2V5IHRoYXQgaW1wbGljaXRseSAo b3IgZXhwbGljaXRseSkgcmVmZXJlbmNlIHRoYXQgUEtJLiBOb3cgeW91IG1pZ2h0IGxpdmUgYW5k IGJyZWF0aCB0aGlzIHNwYWNlIHRvIHRoZSBleHRlbnQgdGhhdCB5b3UgYXJlIGFibGUgZXF1YXRl IGEgdGVybSBsaWtlIOKAnHByaXZhdGUga2V54oCdIHdpdGggdGhlIFBLSSB1c2VkIHRvIHZhbGlk YXRlIGl0LCBidXQgSSBmb3Igb25lIGFwcHJlY2lhdGUgdGhlIHVzZSBvZiBhIGZldyBtb3JlIHdv cmRzIHRvIGRlZmluZSB0aGVzZSB0ZXJtcyBhbmQgdGhlaXIgaW50ZW5kZWQgbWVhbmluZyB3aXRo IGEgbGl0dGxlIG1vcmUgZGV0YWlsLg0KDQoNCnJlZ2FyZHMsDQoNCkdlb2ZmDQoNCg0KDQoNCj4g T24gMyBEZWMgMjAyMSwgYXQgNzo0MyBhbSwgUnVzcyBIb3VzbGV5IDxob3VzbGV5QHZpZ2lsc2Vj LmNvbT4gd3JvdGU6DQo+IA0KPiBHZW9mZjoNCj4gDQo+IEkgZG8gbm90IHRoaW5rIHlvdSBtZWFu IHRoYXQgaXQgaXMgYXBwcm9wcmlhdGUgZm9yIHRoZSBwcml2YXRlIGtleSBhc3NvY2lhdGVkIHdp dGggYW4gUlBLSSBjZXJ0aWZpY2F0ZSB0byBzaWduIGEgbGVnYWwgZG9jdW1lbnQgb3IgYW4gZW1h aWwgbWVzc2FnZS4gIFdoYXQgc2VtYW50aWMgaW1wcmVjaXNpb24gbmVlZHMgdG8gYmUgcmVzb2x2 ZWQgaW4geW91ciBtaW5kPw0KPiANCj4gUnVzcw0KPiANCj4gDQo+PiBPbiBEZWMgMiwgMjAyMSwg YXQgMzowNCBQTSwgR2VvZmYgSHVzdG9uIDxnaWhAYXBuaWMubmV0PiB3cm90ZToNCj4+IA0KPj4g SSB0aGluayB0aGUgYXNzZXJ0aW9uIGluIHRoaXMgZHJhZnQgaXMgaW5jb3JyZWN0LCBvciBhdCBs ZWFzdCBzZW1hbnRpY2FsbHkgaW1wcmVjaXNlLg0KPj4gDQo+PiBXaGF0IGFuIFJQS0kgY2VydGlm aWNhdGUgaXMgYXR0ZXN0aW5nIGlzIHRoYXQgYXMgZmFyIGFzIHRoZSBjZXJ0aWZpY2F0ZSBpc3N1 ZXIgaXMgY29uY2VybmVkIHRoZSBob2xkZXIgb2YgdGhlIHByaXZhdGUga2V5IHdob3NlIHB1Ymxp YyBrZXkgaXMgZ2l2ZW4gaW4gdGhpcyBjZXJ0aWZpY2F0ZSBpcyB0aGUgdW5pcXVlIGhvbGRlciAo b3Ig4oCYb3duZXLigJkpIG9mIHRoZSByZXNvdXJjZXMgbGlzdGVkIGluIHRoZSBjZXJ0aWZpY2F0 ZS4gDQo+PiANCj4+IE1vcmVvdmVyLCB0aGUgc2FtZSBzdWJqZWN0IG5hbWUgd2lsbCBOT1QgYmUg dXNlZCBieSBhIENBIHRvIGFzc29jaWF0ZSB0aGUgcmVzb3VyY2UgaG9sZGluZ3Mgb3IgdHdvIG9y IG1vcmUgZGlmZmVyZW50IGFuZCBkaXN0aW5jdCBlbnRpdGllcy4NCj4+IA0KPj4gQW5kIGl0J3Mg Y2xlYXIgdGhhdCBhbnlvbmUgY2FuIHVzZSBvdGhlciBkYXRhIHNvdXJjZXMgKHN1Y2ggYXMgcmVn aXN0cnkgcXVlcmllcykgdG8gYXNzb2NpYXRlIGEgY2VydGlmaWNhdGUgc3ViamVjdCBuYW1lIHdp dGggYSByZWdpc3RyeS1saXN0ZWQgZW50aXR5J3MgaWRlbnRpdHksIGFuZCB0aGlzIGRyYWZ0IGlz IE5PVCBzYXlpbmcgdGhhdCBzdWNoIGEgcHJhY3RpY2UgaXMgZm9vbGhhcmR5IG9yIHdyb25nIGlu IGFueSB3YXkuDQo+PiANCj4+IHJlZ2FyZHMsDQo+PiANCj4+ICBHZW9mZg0KPj4gDQo+PiANCj4+ IA0KPj4+IE9uIDMgRGVjIDIwMjEsIGF0IDU6MjAgYW0sIENocmlzIE1vcnJvdyA8bW9ycm93Y0Bv cHMtbmV0bWFuLm5ldD4gd3JvdGU6DQo+Pj4gDQo+Pj4gDQo+Pj4gSG93ZHkgV0cgRm9sa3MhDQo+ Pj4gDQo+Pj4gVGhlIEF1dGhvcihzKSBvZjoNCj4+PiBkcmFmdC1pZXRmLXNpZHJvcHMtcnBraS1o YXMtbm8taWRlbnRpdHkNCj4+PiANCj4+PiBoYXZlIHJlcXVlc3RlZCBhIFdHTEMgYmUgbWFkZSBm b3IgdGhlaXIgZHJhZnQ6DQo+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC1pZXRmLXNpZHJvcHMtcnBraS1oYXMtbm8taWRlbnRpdHktMDINCj4+PiANCj4+PiB3 aXRoIGFic3RyYWN0IGNvbnRlbnQ6DQo+Pj4gIlRoZXJlIGlzIGEgZmFsc2Ugbm90aW9uIHRoYXQg SW50ZXJuZXQgTnVtYmVyIFJlc291cmNlcyAoSU5ScykgaW4gdGhlDQo+Pj4gUlBLSSBjYW4gYmUg YXNzb2NpYXRlZCB3aXRoIHRoZSByZWFsIHdvcmxkIGlkZW50aXR5IG9mIHRoZSAnb3duZXInIG9m DQo+Pj4gYW4gSU5SLiAgVGhpcyBkb2N1bWVudCBhdHRlbXB0cyB0byBwdXQgdGhhdCBub3Rpb24g dG8gcmVzdC4iDQo+Pj4gDQo+Pj4gUGxlYXNlIHRha2Ugc29tZSB0aW1lIHRvIHJlYWQgdGhlIH4z IHBhZ2VzIG9mIGNvbnRlbnQgYXQ6DQo+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC1pZXRmLXNpZHJvcHMtcnBraS1oYXMtbm8taWRlbnRpdHktMDINCj4+PiAN Cj4+PiBhbmQgcHJvdmlkZSB5b3UgY29uc2lkZXJlZCBvcGluaW9uIG9uIHdoZXRoZXIgb3Igbm90 IHRoaXMgZG9jdW1lbnQgaXMgcHJlcGFyZWQNCj4+PiBmb3IgZXZhbHVhdGlvbiBieSB0aGUgZ3Jl YXQgYW5kIHBvd2VyZnVsIE9aIChJRVNHKS4gRGVhZGxpbmUgZm9yIHJlcGx5IGlzDQo+Pj4gc29m dGx5IHNldCBhdCAxMi8xNi8yMDIxIC0gRGVjIDE2LCAyMDIxLg0KPj4+IA0KPj4+IFRoYW5rcyEN Cj4+PiAtY2hyaXMNCj4+PiBjby1jaGFpci1wZXJzb25hDQo+Pj4gDQo+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBTaWRyb3BzIG1haWxpbmcg bGlzdA0KPj4+IFNpZHJvcHNAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpZHJvcHMNCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+IFNpZHJvcHMgbWFpbGluZyBsaXN0DQo+PiBTaWRyb3Bz QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpZHJv cHMNCj4gDQoNCg== From nobody Thu Dec 2 17:36:03 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E5C3A0D7B for ; Thu, 2 Dec 2021 17:36:01 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=student.utwente.nl 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 uzCEGD7D8lCY for ; Thu, 2 Dec 2021 17:35:56 -0800 (PST) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 E8B823A0D81 for ; Thu, 2 Dec 2021 17:35:55 -0800 (PST) Received: by mail-ed1-x52e.google.com with SMTP id x6so5188913edr.5 for ; Thu, 02 Dec 2021 17:35:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=student.utwente.nl; s=google; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=uqJ1lRgb7dXGxwcT/ZvmYZZmUPm3MyqBwlrTEMsGfws=; b=GNAroslpaI7ReQhdAwEkb/tm4bILECXkcyUFrLprbIzRrYVpvzf4RI6BmEQJ6rtZjS l0S7zEFqin8gTe1aJOX2/p7/zcTt3uiadSeT3kEmDku50H7BH6HaF/Wacom2eDsZC1o/ qL87hBjWex6IXJxQgCOOiiF/J7OoDHaUn5cWhXLYQN+IAJJgmwuD52cGapHvGrFDWVWw bO3i2+jK352HMHby5raotkuLxcwZnBFmxF19oDaDpnIhRiLX9kdD0P/CY6vXT64H7Ms4 z8yptGNcuTq8A0HB4AmJYljl4XKCPELvdBv/8Ju83h6Ld49wUA6gehlzzW3p9OtHlarn 8vbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=uqJ1lRgb7dXGxwcT/ZvmYZZmUPm3MyqBwlrTEMsGfws=; b=C4HjZarjxIQ8zxXDaDc/0a5oDKP4tQC26zOVEVes7t39KlN4enqJaJqALZnscxkdie sSkWQC9ywbvYEQwA8Dd+dA+UhNQ0xkiEEU0vusOPge4N9b/9Tbi7ABh2HNIiy9s1hSq1 rbcd3TJD7wKE3iN5u/y5yiyFO+w2q2sZ8GoO8bL0bL1AqPJYzGoEqhlw578BhJfrAe5R AmzIPg3xxBUTc8EF9Ryhzo1R3M4yhCdEOKXRV+1Hi6hGbCCd01LWN85FOWnSSD19/Jyx B12T2cLxOecK4cTE3Tu262gEQ6nd88Y2bFUj72u3fII8HqQGw0w1WLoy61Ci1BYuYSNh 2VpA== X-Gm-Message-State: AOAM533TeaVbg6/+qUjtdqqgU5CaNjxIz3ZmF4xYYS3BolP2+zTAp3Bp 1tZ9RXXEvU182eVUxuk9mPAAgBbPXh2/1g== X-Google-Smtp-Source: ABdhPJxJyLbPUUwd4+mWPxRFoKlmEDSPGpOZ9GotsLgI8mio5KmHM7hNwksRuJVahU3Jf8yiAZ0EMA== X-Received: by 2002:a05:6402:35d2:: with SMTP id z18mr22505779edc.188.1638495351916; Thu, 02 Dec 2021 17:35:51 -0800 (PST) Received: from DELTA (219-190-177-143.ftth.glasoperator.nl. [143.177.190.219]) by smtp.gmail.com with ESMTPSA id yd20sm830004ejb.47.2021.12.02.17.35.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Dec 2021 17:35:51 -0800 (PST) From: "Koen van Hove" To: "'Jeroen Massar'" Cc: "'SIDR Operations WG'" References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <001b01d7e638$0f34baf0$2d9e30d0$@student.utwente.nl> In-Reply-To: Date: Fri, 3 Dec 2021 02:35:51 +0100 Message-ID: <004c01d7e7e6$1b509840$51f1c8c0$@student.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG5KyS5O66QVqbINo4wVlHfa5ecZwF0ktdAAnjcc4gBoN6mM6wuuNpg Content-Language: nl Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 01:36:02 -0000 Dear Jeroen, all, I am not sure I fully follow you - could you clarify your point? This is not about DDoS - this is about a single ordinary machine exhausting all connections of multiple rsync servers that should be "highly available" according to the RFC. If it were unclear before: the actual problem is, as Ties already pointed out, that rsyncd cannot handle many simultaneous connections - high link speeds are not necessary (unlike most DDoS attacks). I am pretty sure that attack would not work against most HTTP servers, let alone large CDN providers. > As such, any infrastructure that does not want to be (D)DoSsed should be redundant, likely anycasted, and appropriately scaled as per the RFC. It is also why many people opt for Hosted RPKI at the RIRs and why that setup will cost them a dear cent. I agree. Could you explain how you would do that, and how anycast would protect against the DoS attack I described? What I described would already take down all rsyncd for all RIRs. > Every piece of code in the world will have problems somewhere: please report and people will fix. (Though as rpki.exposed shows, some of the problems (J+K) you have reported are still not resolved in some clients, things take time). Reporting issues is in part what the CVD was for. Regarding J+K: they are indeed unsolved, and to my knowledge all implementations fundamentally suffer from this problem - the Tree Hints draft was written to address that. I am not sure who maintains the spreadsheet from rpki.exposed, but I severely question the validity of some of the "not vulnerable" statements. For example, K seems to still be possible over rsync for rpki-client 7.5. > I don't know about you, but filesystem quotas are things that have existed for well over 4 decades by now. Thus that is really a non-issue. Could you explain why it is a non-issue? It likely breaks all RPs currently - that strikes me as an issue. RRDP can directly be written to object storage to avoid this issue, and implementing a maximum total size/file number limits is easier as well. > Btw, for RRDP, you do not want to know how much fun I can have with HTTP/1.0... let alone with HTTP/2 or QUIC... so many evil server possibilities... the RFCs have comments on many of these techniques and the clients and servers address many too; can't stop them all though, at one point "that server is malicious" and you need to disconnect. Actually, I do - please share. Koen van Hove -----Oorspronkelijk bericht----- Van: Jeroen Massar Verzonden: woensdag 1 december 2021 10:59 Aan: Koen van Hove CC: SIDR Operations WG Onderwerp: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt TLDR: Fix problems, instead of putting everything into HTTP.... the Internet is not just the Web Hi Koen, > On 20211130, at 23:17, Koen van Hove wrote: > > Dear Tim, all, > > I have looked at your motivation, particularly: >> * rsync is CPU and memory heavy on the server side, and easy to >> DoS > > I decided to test your hypothesis, as RFC 6480 says otherwise, and > created a small program that aims to DoS an rsync daemon using many > simultaneous connections from different IP addresses (but the same > machine). My conclusion is the same as yours - with the old computer > (4 cores, 16 GB of RAM, home fiber connection) underneath my desk I > can currently take down my own test rsync server (8 cores, 16 GB RAM, > 1 Gbps connection, different network). 8 cores? 16 GB? My phone has better CPU/mem and connectivity than that... that is literally puny. Heck, your university of utwente has way more connectivity than that, and they where DoSed easily off-net too: https://status.snt.utwente.io/incidents/42 (the answer is always 42) "Major outage effecting (nearly) all systems of SNT" Please realize that ANYTHING can be (D)DoSsed given enough resources. And as we have a LOT of people on the Internet and many that do not properly maintain their connected devices (IoT but also for instance Wordpress, or ManageEngine ADSelfService or soooo many problems), botnets in the order of 100.000's times 100mbit are common today and you go to any "Booter" or "Stresser" service and you get 50Gbit/s for a few dollars. But, heck for 666CHF/year I can even have 25GBit/s at home from init7.net as a single link... Of course, it would require you to sustain that DoS for a week, possibly two, to actually do any real damage. But centralisation is bad (even though one always have to go through the RIR) thus many orgs will want to host themselves (also makes some processes easier). [and the init7 example they will have complained and kick you off net by then ;) ] As such, any infrastructure that does not want to be (D)DoSsed should be redundant, likely anycasted, and appropriately scaled as per the RFC. It is also why many people opt for Hosted RPKI at the RIRs and why that setup will cost them a dear cent. Fortunately both rsync and RRDP require TCP connections. Most UDP can be filtered at the border, that helps quite a bit. But then as noted a 100k botnet can just do legit connections.... for a bit, as ISPs do band together and contact each other and try to resolve at least swaths of those botnets. Hence... the longer the DDoS, the more annoyance, more fixes (or blocks) will be applied and at least the size of the botnet and the attack reduces. I personally also advise doing the rpki-client part from disjunct networks, heck do it from random ASNs, just in case an operator wants to specifically target a specific ASN. > Discussions with operators from RIRs seem to show that this would also > work for their rsync servers. I believe this would even allow one to > take down all rsync servers currently running in the RPKI with a > handful of computers, but I have not tested that as I do not want to > disrupt actual operations. Just in case you did not know yet: Please realize that it would be illegal to do it under the Dutch law you fall under (and other countries have bilateral agreements and will find you too). I bet there is a law professor at your university that can explain to you if it is criminal or civil law that it will fall under and what the penalties would be. [..] > Rsync was not created to be used with a possibly malicious server. > Therefore, there are currently simple things everyone could do that > would disrupt a relying party over rsync, which are difficult to solve: > 1. One can set a motd file that is several gigabytes in size. Rsync > will wait until this is received (the --no-motd switch only hides it > on the > client) and the timeout set in rsync does not affect the maximum time > this may take. I can only suggest to fix the code. Every piece of code in the world will have problems somewhere: please report and people will fix. (Though as rpki.exposed shows, some of the problems (J+K) you have reported are still not resolved in some clients, things take time). Also remember the original motto of the IETF: running code and rough consensus... The running code so that one has experience in operating something, as one learns a lot from it. Easy fix: if a server sends an overlong MOTD (eg >1MiB can already be considered that) put it on a blacklist and ignore it. The only resources DDoSed that way are their own. You'll have a 'delay' once, but after that your client is happy. > 2. One can create an rsync repository with many folders (I tested it > with 27 million folders). This fills up the maximum amount of inodes > on most Linux and *BSD filesystems within minutes whilst bypassing any > size limits or --includes and --excludes, as a folder has a size of 0, > and folders are used in non-malicious repositories. I don't know about you, but filesystem quotas are things that have existed for well over 4 decades by now. Thus that is really a non-issue. Simpler version: have a filesystem specifically where you retrieve things. Cooler version: have a filesystem per CA one fetches -- could use loopback FS or LVM-alike. Heck, the latter one could even nicely have versioning on the filesystem and lots of other cool features allowing rollback etc etc with minimal overhead in storage. Note that code has already solved that specific problem too: https://manpages.debian.org/buster/rsync/rsync.1.en.html 8<----------------- --prune-empty-dirs, -m This option tells the receiving rsync to get rid of empty directories from the file-list, including nested directories that have no non-directory children. This is useful for avoiding the creation of a bunch of useless directories when the sending rsync is recursively scanning a hierarchy of files using include/exclude/filter rules. ------------------>8 Indeed, you are right, a malicious operator will be able to cause some kind of problems. Blacklisting that operator is very easy and would only affect the resources for that operator. And all other things, when discovered, report them, patch them and keep on running. It is extremely easy to be on the "red team", and so many people think they are cool playing attacker. It is a lot more fun to play the blue team and defend against things. But as it is a game, both sides will change tactics, red will find something, blue will fix it... that is the way of life on the Internet. Btw, for RRDP, you do not want to know how much fun I can have with HTTP/1.0... let alone with HTTP/2 or QUIC... so many evil server possibilities... the RFCs have comments on many of these techniques and the clients and servers address many too; can't stop them all though, at one point "that server is malicious" and you need to disconnect. Greets, Jeroen From nobody Thu Dec 2 23:48:40 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2A03A144C for ; Thu, 2 Dec 2021 23:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnRzPCNedQ70 for ; Thu, 2 Dec 2021 23:48:34 -0800 (PST) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 4A7603A0BBB for ; Thu, 2 Dec 2021 23:48:34 -0800 (PST) Received: by mail-ed1-x52b.google.com with SMTP id r25so7963937edq.7 for ; Thu, 02 Dec 2021 23:48:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=p0AYZBU7sGU2O5tw6dlAGeHAgkzRx5rnLg/VEnLajlM=; b=O9E48bY7j3V/vACpuPgENNN8X8Iz5FVJEAR7SCSfEz8ivxH1JT9dIx2lf5lJUpE9Bg NJWNJKk0emH2KsVvM1uuK0XfpXNy3uROpjXjXQh4izTlIVHXTMJ2Tja8Ulcq0EDZPuTy 2jzx4XnF9KJURInY8jlsJk3W89M21fW5Xaoyo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=p0AYZBU7sGU2O5tw6dlAGeHAgkzRx5rnLg/VEnLajlM=; b=bq09GjxC+cvM0UTbvbIVCSI8fXMO+j9wahwKdSPgDjf/nDFZZ6+88z5SPaUbk8DSum BIgjzD6d5NwXyjbFYd9b2iMszTnkEB5thVFPFCMV5Qr+JWV/9NMcmlAbpir4yWuEOA7I HDS36MfyG5REjUnXPH035f6yXXnc3HssCy2N4AOpfNLHHV/Azp5rM3AzPcqC0DBxSfvA V4mbfg+LcGYIxY79lfFj7fQrfUUkLQMWiC9IHUjtQZkh0qjhP08OeJi04LWa9zkSTA6L z3bSLugGIbNNpjk/Cgy0ESF+gn56qFxMiVHoemREj1aMOjIRXJCGkU9Rd+7LtGPB/q5i ThEg== X-Gm-Message-State: AOAM5336X+L6KOpK+0BK5gls84ULF3wLhlIYE2wFg7jciTW1ndKyN5oD k6wNVC210Juyo0kpDymNoI97Og== X-Google-Smtp-Source: ABdhPJwtI1mYCp+5M1bFlJ185VUiX9WJzpbiSoP/c+GjSdYdvBDh5ZZ0peuttR+rWF+tUuC9AMJnpQ== X-Received: by 2002:a50:ce4a:: with SMTP id k10mr24957450edj.31.1638517711369; Thu, 02 Dec 2021 23:48:31 -0800 (PST) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id g14sm1350705edq.86.2021.12.02.23.48.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Dec 2021 23:48:30 -0800 (PST) Date: Fri, 3 Dec 2021 08:48:29 +0100 From: Job Snijders To: Koen van Hove Cc: 'Jeroen Massar' , 'SIDR Operations WG' Message-ID: References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <001b01d7e638$0f34baf0$2d9e30d0$@student.utwente.nl> <004c01d7e7e6$1b509840$51f1c8c0$@student.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004c01d7e7e6$1b509840$51f1c8c0$@student.utwente.nl> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 07:48:39 -0000 > I am not sure who maintains the spreadsheet from rpki.exposed, but I > severely question the validity of some of the "not vulnerable" > statements. For example, K seems to still be possible over rsync for > rpki-client 7.5. I suspect the 'not vulnerable' fields are filled based on test results obtained using the testbed at https://rpki.koenvh.nl/ control run: 144665 lines of validated output under RIPE TA https://sobornost.net/~job/control.txt RIPE TA + J: 144671 lines of output (within error margin) https://sobornost.net/~job/j1.txt RIPE TA + K: 144665 lines of output (within error margin) https://sobornost.net/~job/k1.txt The testbed does not offer rsync access, so your claim about rsync cannot be verified. If you are creating variants of those tests, it would be helpful if you use distinct labels (K.1, K.2, etc) for each variant, and clearly document each permutation. Another consideration would be to make your testbed and source code publicly available so that others can replicate/confirm/inspect whatever claims are made. Regards, Job From nobody Fri Dec 3 00:14:35 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0D33A14F6 for ; Fri, 3 Dec 2021 00:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl 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 A9LjlOKknlrT for ; Fri, 3 Dec 2021 00:14:28 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [116.202.126.228]) (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 6D76D3A14F4 for ; Fri, 3 Dec 2021 00:14:27 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 5715466; Fri, 3 Dec 2021 08:14:23 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1638519262; bh=M37ihpMSSQAbNXuA3s3KgP8bakWym25OxbjASX5IrXA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Sb9PN1z8q0sM7Me+hsroaIzYyM9eSnqStmmX1pUHiJOjC6HYsT6j+ZWwmue2wiReH tHe+OKYVt312z6NheWmo5LJnxl5/dP7CcOe2iTq/ctDg0rksiRpQDbwJ+LABEOTbcX k6d82pCPqusI1pemJtqnYE3Pi/xyJ1j3i57phltE1QYhIrdTyv5va1FycC1VvnItRQ sMm9cxL67SzAYcF/QW4dBPT0vZysF0hqcTCZvMbprskQGzUiO+xMK9pfBIAZ6lxITR b9JoiCOf138lE2e6QIy4XpMF2CptDxyH8l/ZhKuCKPV4OOy9J69iFaPz4nhzuT+oru z/2t/1ZSIC0Zw== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Tim Bruijnzeels In-Reply-To: Date: Fri, 3 Dec 2021 09:14:20 +0100 Cc: "sidrops@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <1C0B5653-BBB7-4F61-A6C9-CD4857F260C0@nlnetlabs.nl> References: <0B2DE27E-B67F-413B-806B-7131B90F3333@arrcus.com> <14BFC0A3-0352-47C7-86CF-23223F0E660E@nlnetlabs.nl> To: Randy Bush Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 08:14:34 -0000 Morning Randy, > On 2 Dec 2021, at 17:46, Randy Bush wrote: > > tim, > > i am confused, so i keep going back to your messages on ASPA. i just > don't get it. you'll have to try a new clue bat. > > the RP cache's job is to deal with all the RPKI cruft, crypto, alg > rolls, transfers, whatever. the job of the cache is to insulate the > router from all that. > yes, agree. > in the ASPA case, the cache takes what it knows, sums it up (as in set > union), and whacks it off to the router in completely processed form. I am reading the document again, and I see that I was confused. I read: "Therefore, the cache MUST deliver the entire data of an ASPA record in a single ASPA PDU." to mean that RPs MUST make a PDU based on a single ASPA object. Only to miss that just below it you continue to say: The router should only see one ASPA for a particular Customer Autonomous System Number active at any time. This may place a burden on the cache to merge multiple ASPA records it has received from the global RPKI into one ASPA PDU. The above is exactly what I was trying to say.. > what am i missing here? Sorry for my confusion on this, and thank you for making me re-read! Tim > > randy From nobody Fri Dec 3 01:28:34 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E533A0CDC for ; Fri, 3 Dec 2021 01:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl 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 5hjouscZ1DEh for ; Fri, 3 Dec 2021 01:28:30 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [116.202.126.228]) (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 CFDDF3A0803 for ; Fri, 3 Dec 2021 01:28:29 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 45025809; Fri, 3 Dec 2021 09:28:21 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1638523700; bh=/l+iet97A0VK3qF3w9zm8vTv9iAs99xq8yNbbiY/QRg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=ZPZ8Giptx63KW6JOpL1f2M3vS1tkg3V2rM9ctZThosYlFxUb5ou7azRQJA9TkgNjA fkDMUTrNxib0IOPU/IebnjQq50uPm/lHoMWLWWHykx6OKBVLLVtO4U4aRd4MlHzari /tU02a9k00L5eINfmQf5Wzg3urnKF/wyOiourDAlJE42rDQS9inuwxhKCYk5yDa4gb wya1xH2nACQW8wzXehTHnX4PY71iDDHdp+Z+0h1X+SPY3rUpJ8VvT7SLh/6cJkp8LZ FRv7c+Ev4G9hDJWyegK3r3oUgVc6xEsykcDhZT/b8tPYK0PsyF9EvwTPnuYrh5PURS UuDX+54lk7qRg== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Tim Bruijnzeels In-Reply-To: <1C0B5653-BBB7-4F61-A6C9-CD4857F260C0@nlnetlabs.nl> Date: Fri, 3 Dec 2021 10:28:17 +0100 Cc: "sidrops@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <2ED23A27-CC42-4BED-AD5C-8CD3D741766E@nlnetlabs.nl> References: <0B2DE27E-B67F-413B-806B-7131B90F3333@arrcus.com> <14BFC0A3-0352-47C7-86CF-23223F0E660E@nlnetlabs.nl> <1C0B5653-BBB7-4F61-A6C9-CD4857F260C0@nlnetlabs.nl> To: Randy Bush Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 09:28:33 -0000 Randy, all, after some more coffee.. > On 3 Dec 2021, at 09:14, Tim Bruijnzeels wrote: > > The router should only see one ASPA for a particular Customer > Autonomous System Number active at any time. This may place a burden > on the cache to merge multiple ASPA records it has received from the > global RPKI into one ASPA PDU. > > The above is exactly what I was trying to say.. In my defence ;) I think the above could benefit from some more explicit language. Would you agree to something like the following (feel free to rephrase - but to give you something to shoot at): The router should only see one ASPA object for a particular Customer Autonomous System Number active at any time, as issuing CAs must register multiple providers for a single customer in a single object (section 3 of [I-D.ietf-sidrops-aspa-profile]). However, despite this requirement on CAs, edge conditions may result in multiple valid ASPA objects for a single customer to appear in the global RPKI. This places a burden on the cache to merge multiple records into one ASPA PDU. Tim From nobody Fri Dec 3 01:52:37 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020BC3A0D71 for ; Fri, 3 Dec 2021 01:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJXhM5j6CeXe for ; Fri, 3 Dec 2021 01:52:31 -0800 (PST) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCAAF3A155C for ; Fri, 3 Dec 2021 01:52:29 -0800 (PST) Received: (qmail 27428 invoked by uid 1000); 3 Dec 2021 09:52:26 -0000 Date: Fri, 3 Dec 2021 10:52:26 +0100 From: Claudio Jeker To: Koen van Hove Cc: 'Jeroen Massar' , 'SIDR Operations WG' Message-ID: References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <001b01d7e638$0f34baf0$2d9e30d0$@student.utwente.nl> <004c01d7e7e6$1b509840$51f1c8c0$@student.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004c01d7e7e6$1b509840$51f1c8c0$@student.utwente.nl> Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 09:52:36 -0000 On Fri, Dec 03, 2021 at 02:35:51AM +0100, Koen van Hove wrote: > Dear Jeroen, all, > > I am not sure I fully follow you - could you clarify your point? > > This is not about DDoS - this is about a single ordinary machine exhausting > all connections of multiple rsync servers that should be "highly available" > according to the RFC. If it were unclear before: the actual problem is, as > Ties already pointed out, that rsyncd cannot handle many simultaneous > connections - high link speeds are not necessary (unlike most DDoS attacks). > I am pretty sure that attack would not work against most HTTP servers, let > alone large CDN providers. > > > As such, any infrastructure that does not want to be (D)DoSsed should be > redundant, likely anycasted, and appropriately scaled as per the RFC. It is > also why many people opt for Hosted RPKI at the RIRs and why that setup will > cost them a dear cent. > > I agree. Could you explain how you would do that, and how anycast would > protect against the DoS attack I described? What I described would already > take down all rsyncd for all RIRs. > > > Every piece of code in the world will have problems somewhere: please > report and people will fix. (Though as rpki.exposed shows, some of the > problems (J+K) you have reported are still not resolved in some clients, > things take time). > > Reporting issues is in part what the CVD was for. Regarding J+K: they are > indeed unsolved, and to my knowledge all implementations fundamentally > suffer from this problem - the Tree Hints draft was written to address that. > I am not sure who maintains the spreadsheet from rpki.exposed, but I > severely question the validity of some of the "not vulnerable" statements. > For example, K seems to still be possible over rsync for rpki-client 7.5. I am not sure I fully follow you - could you clarify your point? There is no difference between rsync or RRDP. Both protocols use a filesize limit in rpki-client so if the file makes it to disk then it is below the maximum allowed file size. The .roa file in K parses just fine in rpki-client 7.5: rpki-client -nrv -t koenvh-K.tal rpki-client: ta/koenvh-K: using cache rpki-client: https://k--XXXXXX-YYYY.rpki.koenvh.nl/notification.xml: using cache rpki-client: rrdp/117fe1e3bacf74a79db3d1d015378bb38430d491dbc3c9f50df8aba0cb666cf2/k--XXXXXX-YYYY.rpki.koenvh.nl/repository/koenvh.crl: File too large rpki-client: all files parsed: generating output rpki-client: Processing time 1 seconds (0 seconds user, 0 seconds system) rpki-client: Route Origin Authorizations: 1 (0 failed parse, 0 invalid) rpki-client: BGPsec Router Certificates: 0 rpki-client: Certificates: 1 (0 invalid) rpki-client: Trust Anchor Locators: 1 (0 invalid) rpki-client: Manifests: 1 (0 failed parse, 0 stale) rpki-client: Certificate revocation lists: 1 rpki-client: Ghostbuster records: 0 rpki-client: Repositories: 2 rpki-client: Cleanup: removed 0 files, 0 directories rpki-client: VRP Entries: 262145 (262145 unique) 1.36 real 1.04 user 0.30 sys It took a total of 1.36 seconds to process this .roa file with 262145 VRP entries. So please tell me how this result is considered "vulnerable" for you? -- :wq Claudio From nobody Fri Dec 3 03:13:45 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8933A07AE for ; Fri, 3 Dec 2021 03:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSb6PE7UO7e9 for ; Fri, 3 Dec 2021 03:13:40 -0800 (PST) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 D64983A07AB for ; Fri, 3 Dec 2021 03:13:39 -0800 (PST) Received: by mail-ed1-x52f.google.com with SMTP id w1so10036844edc.6 for ; Fri, 03 Dec 2021 03:13:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=8hu4qXzlfK4iYoJWav6LvDEVoK8PEUwVIzRdZIgh6uU=; b=jOuI3wkjms7Fh9KUdUl4F2knjYPXFc1cxqcawjUnVNsR186gLIY/x/d1sMQ02+vpMV mu92g2BuPf2qheRMwUf/dLsJbnGVUGOzMll179DQhvhCx0wD0AKhMC2fd+0qa0yzSn+F gcV7LlOuaWuh4K7RFM31YzOY3kcW9xxbH88KM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=8hu4qXzlfK4iYoJWav6LvDEVoK8PEUwVIzRdZIgh6uU=; b=yxl/trX5pBHdjQGQuOhLBiTeYFdJ2aiV5h88jLKok1ipuXiMKZRkETSOVs0znZ8s2O qDD7+f1hQE/Zk5JXFHlLxFVw0Xp85DL9yOfZSrEFNtnCNSJB5OClnxSxDNdaC50RMQQx SHK3vHnZMmAsk81NuWZVYj8e7Yc9tro0rdZNSlqi7dedrbAwojCwW31bV301ChnCgcom edP7I9C30NbWQvvtPGHZfPZub9FHmpxk7FrhkTgM6fYBIJ7wjyH48QlylBkLtJ0G6JnB /mrODgyoK8FI6SooQMEgtmYiNBuk3n8yevWpK5TaoFfi0Kp6fL/ZgJe548bejiyRttBE ukoA== X-Gm-Message-State: AOAM530R0C7dagmUcTt21///sZfRl206co6ZeJ9ORPZzkpIr+YMSKT+c ivRdJLsG87nodRomFz+9WWbnDg== X-Google-Smtp-Source: ABdhPJzjIyQ6yUYL72Uyw2Y+MRifjFVjYINtXge0uBZwLaggzl1dHOjLyTJJwxV+GJnc32fJv4aRvA== X-Received: by 2002:a17:907:1c25:: with SMTP id nc37mr22669469ejc.333.1638530016586; Fri, 03 Dec 2021 03:13:36 -0800 (PST) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id qf8sm1858635ejc.8.2021.12.03.03.13.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Dec 2021 03:13:36 -0800 (PST) Date: Fri, 3 Dec 2021 12:13:34 +0100 From: Job Snijders To: Koen van Hove Cc: 'Jeroen Massar' , 'SIDR Operations WG' Message-ID: References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <001b01d7e638$0f34baf0$2d9e30d0$@student.utwente.nl> <004c01d7e7e6$1b509840$51f1c8c0$@student.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004c01d7e7e6$1b509840$51f1c8c0$@student.utwente.nl> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 11:13:44 -0000 On Fri, Dec 03, 2021 at 02:35:51AM +0100, Koen van Hove wrote: > Could you explain why it is a non-issue? It likely breaks all RPs > currently - that strikes me as an issue. Is it really that likely? I have yet to see it happen. > RRDP can directly be written to object storage to avoid this issue, > and implementing a maximum total size/file number limits is easier as > well. Earlier on I mentioned 'rsync-os': https://mailarchive.ietf.org/arch/msg/sidrops/RQTi6TbyRQtYpfaigA5OA0JJNvg/ github.com/kaiakz/rsync-os "A port of rsync written in Go, with object storage support" ^^^^^^^^^^^^^^^^^^^^^^^^^^^ The concept of 'object storage' doesn't seem RRDP-specific. Regards, Job From nobody Fri Dec 3 03:49:12 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60363A0854 for ; Fri, 3 Dec 2021 03:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net 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 6DCYPRYIcNbl for ; Fri, 3 Dec 2021 03:49:05 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 C06243A0857 for ; Fri, 3 Dec 2021 03:49:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version:Content-Type ; bh=FCYVYZkwtOXj8aAO91P6nWp4XduJeBuy01dctHeLMeM=; b=gLb0TCVNk4GYa0zt5XcsHb+m 9nHJTRA1MEBq0DIu1U6dX/lEb1GD25VwUh3Gshy0N8La0WwI8O6HZ9jvcBkO4cJ61Fws575FNJE64 PvLhm6AeGhgGc4Q/3jqK4F4PFEd1MiR42b0mcauV/xBHUjw1JbJVNg2MooRxE74fpiX8U2pUGSmZW ESaVH8YLuUdPGxX1ZMH4iIWfhLpItCaM2f752qi1kHUvfRGbhW7E/eGB0m1sZ4K4J47WhIh/U4Hf0 POe3tF6SrbGxr41ObrfBSHahYaSBKsW9Zbc29MEGMuYcwPsC+LsyqebhNbzmMfcnjt3z0JITdnSc4 66uog5ZMrg==; Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:39080) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mt73k-0004Kn-BQ for sidrops@ietf.org; Fri, 03 Dec 2021 12:49:00 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mt73k-0002tW-8b; Fri, 03 Dec 2021 12:49:00 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mikhail Puzanov In-Reply-To: <51448777-038D-4B0D-97D9-129053B5115F@ripe.net> Date: Fri, 3 Dec 2021 12:48:59 +0100 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <873EE1A3-B86A-46A3-9D96-AD4BEA21103F@ripe.net> References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <001b01d7e638$0f34baf0$2d9e30d0$@student.utwente.nl> <51448777-038D-4B0D-97D9-129053B5115F@ripe.net> To: Ties de Kock X-Mailer: Apple Mail (2.3654.120.0.1.13) X-RIPE-Signature: e2494821e8eb7112beaeaa277e8c25e0c8a6a906093dc4135ed973b25295e5f4 Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 11:49:11 -0000 >>=20 >> https://manpages.debian.org/buster/rsync/rsync.1.en.html >>=20 >> 8<----------------- >> --prune-empty-dirs, -m >>=20 >> This option tells the receiving rsync to get rid of = empty >> directories from the file-list, including nested >> directories that have no non-directory children. This = is >> useful for avoiding the creation of a bunch of useless >> directories when the sending rsync is recursively = scanning >> a hierarchy of files using include/exclude/filter rules. >> ------------------>8 >=20 > You can transfer empty files instead. You can set --min-size ;) Which for RPKI objects should be more than 100 bytes (vague = hand-waving). Actually, it would be nice to have a consensus about the minimal object=20= size, we can have a good number here contrary to the max size. So, lets say, we have timeboxed "rsync --max-size 32Mb --min-size 100 = --prune-empty-dirs=E2=80=9D. How bad it can still be? -- Misha= From nobody Fri Dec 3 06:09:21 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2E43A09F7 for ; Fri, 3 Dec 2021 06:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net 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 UopMU02Jj-da for ; Fri, 3 Dec 2021 06:09:13 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 31C613A09F2 for ; Fri, 3 Dec 2021 06:09:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version:Content-Type ; bh=+Rff2rghrBLiiavp9gCTyrryjCzCRZWJVcdop0kxkk0=; b=UcWMJzwKmfSuGPeHKU4mXQys KuLeusCYJZepT5V4FFbF1Bht5072+ZNuKo++U8JnrI5aWYlFL36hL8E/16ZfgxlYB9UyN3Ne8rl+/ 8Buvm5pqQ7+1p490Czb2Aq25rrw9thZ7cOeL9YJZUcw3bzHtJRJiNwXBf+O8GccwSP799jfvzCwVs 7ZbJMl4GIHBxtrwsW1I6Z+KhBmqVpbxiISnBehyUROX6jJs9wZlNyIHKYqdRyonDLinCktCLq6tk+ xU1RQjSSNKftww178FWelmOOhiGz3d2gAE8OTZYxtiWojB4cHJqezoT4iJ2rgS0bvkytfAjKkVybl cDws8sAYCg==; Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:39666) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mt9FK-000Al6-P4 for sidrops@ietf.org; Fri, 03 Dec 2021 15:09:06 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mt9FK-0001p4-M6; Fri, 03 Dec 2021 15:09:06 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Ties de Kock In-Reply-To: <873EE1A3-B86A-46A3-9D96-AD4BEA21103F@ripe.net> Date: Fri, 3 Dec 2021 15:09:06 +0100 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <2C2970A5-33D6-4C49-94E1-F4B87CD8DD14@ripe.net> References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <001b01d7e638$0f34baf0$2d9e30d0$@student.utwente.nl> <51448777-038D-4B0D-97D9-129053B5115F@ripe.net> <873EE1A3-B86A-46A3-9D96-AD4BEA21103F@ripe.net> To: Mikhail Puzanov X-Mailer: Apple Mail (2.3654.120.0.1.13) X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e1ada8e642962684c20b8e768102a6e9ec Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 14:09:20 -0000 > On 3 Dec 2021, at 12:48, Mikhail Puzanov wrote: >=20 >=20 >>>=20 >>> https://manpages.debian.org/buster/rsync/rsync.1.en.html >>>=20 >>> 8<----------------- >>> --prune-empty-dirs, -m >>>=20 >>> This option tells the receiving rsync to get rid of = empty >>> directories from the file-list, including nested >>> directories that have no non-directory children. This = is >>> useful for avoiding the creation of a bunch of useless >>> directories when the sending rsync is recursively = scanning >>> a hierarchy of files using include/exclude/filter rules. >>> ------------------>8 >>=20 >> You can transfer empty files instead. >=20 > You can set --min-size ;) Superficially this may look like an improvement, but in reality, it does = not not help against a realistic attacker. For any reasonable lower limit on = object size, many filesystems will have much more free space than free inodes. For example, what I see on a host with small disks: [user@host ~]$ df -i Filesystem = Inodes IUsed IFree IUse% Mounted on ... /dev/mapper/vg01-lv_root = 5242880 66960 5175920 2% / [user@host ~]$ df -h ... /dev/mapper/vg01-lv_root 10G = 7.3G 2.7G 74% / 2.7GB of data until the disk is full, but if you send 100b files the = disk is full much sooner (remember that the inodes themselves will use a non-trivial = amount of space). You can also exhaust both space and size efficiently: = transfer a collection of sparse files and rsync transfers if efficiently and = materialises it non-sparsely for the receiver. And for many RPs, the server could just transfer symlinks instead. > Which for RPKI objects should be more than 100 bytes (vague = hand-waving). > Actually, it would be nice to have a consensus about the minimal = object=20 > size, we can have a good number here contrary to the max size. Can we? Do we know what future object the RPKI will contain? > So, lets say, we have timeboxed "rsync --max-size 32Mb --min-size 100 = --prune-empty-dirs=E2=80=9D. > How bad it can still be? Just as bad. I'll reiterate my point from earlier. An rsync client that does not: * abort after a set number of objects received, or * abort after a set amount of bytes transferred by the connection, or * get killed by the parent process after a certain time It is inherently vulnerable to resource exhaustion attacks when reading = from an untrusted source. Kind regards, Ties From nobody Fri Dec 3 06:22:53 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2E33A0A2B for ; Fri, 3 Dec 2021 06:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2g3ai9o-LLk for ; Fri, 3 Dec 2021 06:22:33 -0800 (PST) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 1EFAD3A0A21 for ; Fri, 3 Dec 2021 06:22:33 -0800 (PST) Received: by mail-ed1-x52e.google.com with SMTP id o20so12142795eds.10 for ; Fri, 03 Dec 2021 06:22:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=xdpJBTE7ym1M9aIF8HhlWYgzHfnX4Y7qf2oU7BsMPQA=; b=aLP7Xn8QvsekU+PQ/2dIYs2UC0nV/krzv+fuYcPj9btLxzkixng+ucYL7uk5Cdrxiy rExIS1jAEbt/zldadY6a4RmtAbdOvcuY1YR6Vf2dr3unaOKHcgDv6hFIZuXP150xpnJo R+f+p69CF2qGBpSRdFGydky6XExrxGWK7SFv8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=xdpJBTE7ym1M9aIF8HhlWYgzHfnX4Y7qf2oU7BsMPQA=; b=OFmrtKjE0HIDXlYp7MhP5bUSKT54hssXX3fePcUcXdqHvWQVg7THTEohZHWnv2mO8q HdnbVowO8Tn6s+W7oMuXc5hFzr++LNJT4co+Od1zlpXUequoVf0DTgUblOKsCYwWRmTA ESrJDPLlNijhmlbIbzE34DLsbNojZQVIKCU1xYtMuz6bR1KcctWF3HrOr9wVpNa0xXZL a5sQ8RmJUVwmb83Labo5A/Yo5rktTklYR74WJRSXAyN6tedvZyCkXKD3NiRxe1vscgh0 vezP0K68CnXunsMvPArPrIk1PW1ZrpeEsZthPaYcU3Cj5VYatKAQpb2rTJBqw2RoPYYY gfpQ== X-Gm-Message-State: AOAM530vJFJClH5bbJCYDdA9GD2SFtAO2BcAx9cIPCHcUDgTrzSPkuqO qDarPy2tqfmOQNoSmyQuYlvzSw== X-Google-Smtp-Source: ABdhPJyotK2nsMPlA36bxAxgTKPU0RYcFt1UFol6xz5i0BEQnzKPVjoOyvnjFcBD+fwFBQ71MqbexQ== X-Received: by 2002:a17:907:1626:: with SMTP id hb38mr24191384ejc.481.1638541332064; Fri, 03 Dec 2021 06:22:12 -0800 (PST) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id jg32sm2394612ejc.43.2021.12.03.06.22.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Dec 2021 06:22:11 -0800 (PST) Date: Fri, 3 Dec 2021 15:22:09 +0100 From: Job Snijders To: Ties de Kock Cc: Mikhail Puzanov , SIDR Operations WG Message-ID: References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <001b01d7e638$0f34baf0$2d9e30d0$@student.utwente.nl> <51448777-038D-4B0D-97D9-129053B5115F@ripe.net> <873EE1A3-B86A-46A3-9D96-AD4BEA21103F@ripe.net> <2C2970A5-33D6-4C49-94E1-F4B87CD8DD14@ripe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2C2970A5-33D6-4C49-94E1-F4B87CD8DD14@ripe.net> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 14:22:44 -0000 > On 3 Dec 2021, at 12:48, Mikhail Puzanov wrote: > > So, lets say, we have timeboxed "rsync --max-size 32Mb --min-size > > 100 --prune-empty-dirs”. On Fri, Dec 03, 2021 at 03:09:06PM +0100, Ties de Kock wrote: > I'll reiterate my point from earlier. An rsync client that does not: > * abort after a set number of objects received, or > * abort after a set amount of bytes transferred by the connection, or > * get killed by the parent process after a certain time Ties - Mikhail says "timeboxed", you say "get killed after X time". I think you are saying the same thing? OpenBSD rpki-client kills syncing after 15 minutes (or 1/4th of the timeout specified via '-s'), what do other RPs do? Please leave a note at https://trac.ietf.org/trac/sidrops/wiki/FencingLimits Kind regards, Job From nobody Fri Dec 3 08:44:52 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C903A0C20 for ; Fri, 3 Dec 2021 08:44: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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQ0lXFMq4Mhm for ; Fri, 3 Dec 2021 08:44:46 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 345D63A0C18 for ; Fri, 3 Dec 2021 08:44:46 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mtBft-0008Qu-Pe; Fri, 03 Dec 2021 16:44:42 +0000 Date: Fri, 03 Dec 2021 08:44:41 -0800 Message-ID: From: Randy Bush To: Geoff Huston Cc: SIDR Operations WG In-Reply-To: References: <87v906j2cm.wl-morrowc@ops-netman.net> <1F30B4DD-F34A-40C2-89C4-6F84D7F83291@apnic.net> <0E6ED68D-46F0-4303-8FF4-1932847E43DC@vigilsec.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-rpki-has-no-identity - ENDS 12/16/2021 (Dec 16 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 16:44:51 -0000 > My point was that the text is handwaving and imprecise. as our nlnet friends demonstrated, any text can be misconstrued. so i no longer put a lot of effort into preventing misconstruction. but i was hoping you, having so aggressively argued for the rpki not providing identity (and we did not disagree), might have some simple text to propose. randy From nobody Fri Dec 3 09:36:27 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5EAD3A0CF3 for ; Fri, 3 Dec 2021 09:36:25 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltOSkkprlxx3 for ; Fri, 3 Dec 2021 09:36:22 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 8FA913A0CEF for ; Fri, 3 Dec 2021 09:36:22 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mtCTq-00006u-P5; Fri, 03 Dec 2021 17:36:18 +0000 Date: Fri, 03 Dec 2021 09:36:18 -0800 Message-ID: From: Randy Bush To: Tim Bruijnzeels Cc: "sidrops@ietf.org" In-Reply-To: <1C0B5653-BBB7-4F61-A6C9-CD4857F260C0@nlnetlabs.nl> References: <0B2DE27E-B67F-413B-806B-7131B90F3333@arrcus.com> <14BFC0A3-0352-47C7-86CF-23223F0E660E@nlnetlabs.nl> <1C0B5653-BBB7-4F61-A6C9-CD4857F260C0@nlnetlabs.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 17:36:26 -0000 > I am reading the document again, and I see that I was confused. i must have looked at your messages a dozen times over a week trying to see what i did not understand. :) aside from removing the duplicated paragraph, The Provider AS Count is the number of Provider Autonomous System Number(s) at the end of the PDU, and MUST be one or more. is there something we could have done to be more clear? randy From nobody Fri Dec 3 09:38:40 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1713A0D06 for ; Fri, 3 Dec 2021 09:38:38 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QBWAGtnhWNT for ; Fri, 3 Dec 2021 09:38:35 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 844C63A0CFD for ; Fri, 3 Dec 2021 09:38:35 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mtCW1-00007K-4J; Fri, 03 Dec 2021 17:38:33 +0000 Date: Fri, 03 Dec 2021 09:38:32 -0800 Message-ID: From: Randy Bush To: Tim Bruijnzeels Cc: "sidrops@ietf.org" In-Reply-To: <2ED23A27-CC42-4BED-AD5C-8CD3D741766E@nlnetlabs.nl> References: <0B2DE27E-B67F-413B-806B-7131B90F3333@arrcus.com> <14BFC0A3-0352-47C7-86CF-23223F0E660E@nlnetlabs.nl> <1C0B5653-BBB7-4F61-A6C9-CD4857F260C0@nlnetlabs.nl> <2ED23A27-CC42-4BED-AD5C-8CD3D741766E@nlnetlabs.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 17:38:38 -0000 > The router should only see one ASPA object for a particular > Customer Autonomous System Number active at any time, as issuing > CAs must register multiple providers for a single customer in > a single object (section 3 of [I-D.ietf-sidrops-aspa-profile]). > However, despite this requirement on CAs, not sure i want to dive into the complications of aspa profile. but i think i will steal this if you do not mind > edge conditions may result in multiple valid ASPA objects for a > single customer to appear in the global RPKI. This places a burden > on the cache to merge multiple records into one ASPA PDU. randy From nobody Fri Dec 3 09:46:43 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555CE3A0D22 for ; Fri, 3 Dec 2021 09:46:42 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DclhS79fhk1 for ; Fri, 3 Dec 2021 09:46:41 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 2E2FE3A0D1E for ; Fri, 3 Dec 2021 09:46:41 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mtCdp-00008E-Ok; Fri, 03 Dec 2021 17:46:37 +0000 Date: Fri, 03 Dec 2021 09:46:36 -0800 Message-ID: From: Randy Bush To: Tim Bruijnzeels Cc: "sidrops@ietf.org" In-Reply-To: <2ED23A27-CC42-4BED-AD5C-8CD3D741766E@nlnetlabs.nl> References: <0B2DE27E-B67F-413B-806B-7131B90F3333@arrcus.com> <14BFC0A3-0352-47C7-86CF-23223F0E660E@nlnetlabs.nl> <1C0B5653-BBB7-4F61-A6C9-CD4857F260C0@nlnetlabs.nl> <2ED23A27-CC42-4BED-AD5C-8CD3D741766E@nlnetlabs.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 17:46:42 -0000 The router should see at most one ASPA for a particular Customer Autonomous System Number active at any time. As a number of conditions in the global RPKI may present multiple valid ASPA objects for a single customer to a particular RP cache, this places a burden on the cache to merge multiple ASPA records it has received from the global RPKI into one ASPA PDU. ok? From nobody Fri Dec 3 09:50:00 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251493A0D2C for ; Fri, 3 Dec 2021 09:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCAWph88_Jkx for ; Fri, 3 Dec 2021 09:49:53 -0800 (PST) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 3BDA73A0D2E for ; Fri, 3 Dec 2021 09:49:53 -0800 (PST) Received: by mail-ed1-x530.google.com with SMTP id g14so14298930edb.8 for ; Fri, 03 Dec 2021 09:49:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=BOZio39ZeT+FiHQxL/6ya/gTdwIOnxMlT/bdq3EjOeU=; b=fqBKNQ4BstiB2NQ/rFpObsXrZBBJf1ozzxmfKAOoVkurtvazEGHUwzuOeo8XeEqbEU KBGfWZURQ1tMJVfjBCUhebYdP4ILhrwp2racjWkFnAZSljw6bPUBaTNw259E2QaJQsRO xDSLFIIdq1vEQrddX5Q+dpmRv0h/ml9Z2aACY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=BOZio39ZeT+FiHQxL/6ya/gTdwIOnxMlT/bdq3EjOeU=; b=DHF7qpkN5+l2YPyUnzjUGnWJct5yFdQU1dXXlnrbhLdQH6V7PILQU/tTcGi93lgKBA a6LsLBE0zta7c7fDksnNu6tGs9fP62RuhHLNmZGJRpFblC7E8gjhceso1JvIu5UFL7qH MwqkxCAZzGEtDJkCbN9AP1YB/SeYVz/O9AV5dRtiyJ2/TTaqsQPDJBj/MJ53ARdMoOvS /nbTxLmgWXG0b2XEaVhsWXt0rdmYIYwl7kBJX880KAHbJHr/WL/ZOza7nLECy1EqFqOb Gljbi0IcEcwN8KSfE/zPoPlvZxt4WOQESZfjrF8r2EmMsDYhNcofatoU5VARqF/NhYIp Qyog== X-Gm-Message-State: AOAM530B/+6nGEDuVC7ZBaF3y9jP6R4PG3NXZ9qQt2S7zg/PPTfGibx2 FBt+Qs6WlCxIvOJKhf8tLl5UhA== X-Google-Smtp-Source: ABdhPJzxL/J+xuWUajI9LI6Cxe1bWCSSDrv/L/JfOSiNclS0ADNdoG8Mtr9SN+G9nHgVhSF0d5tVvg== X-Received: by 2002:aa7:d794:: with SMTP id s20mr27737972edq.305.1638553790673; Fri, 03 Dec 2021 09:49:50 -0800 (PST) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id qw27sm2392431ejc.101.2021.12.03.09.49.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Dec 2021 09:49:50 -0800 (PST) Date: Fri, 3 Dec 2021 18:49:48 +0100 From: Job Snijders To: Randy Bush Cc: Tim Bruijnzeels , "sidrops@ietf.org" Message-ID: References: <0B2DE27E-B67F-413B-806B-7131B90F3333@arrcus.com> <14BFC0A3-0352-47C7-86CF-23223F0E660E@nlnetlabs.nl> <1C0B5653-BBB7-4F61-A6C9-CD4857F260C0@nlnetlabs.nl> <2ED23A27-CC42-4BED-AD5C-8CD3D741766E@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 17:49:58 -0000 On Fri, Dec 03, 2021 at 09:46:36AM -0800, Randy Bush wrote: > The router should see at most one ASPA for a particular Customer > Autonomous System Number active at any time. As a number of > conditions in the global RPKI may present multiple valid ASPA objects > for a single customer to a particular RP cache, this places a burden > on the cache to merge multiple ASPA records it has received from the > global RPKI into one ASPA PDU. What to do when the router receives dissimilar ASPA PDUs via different RPKI-To-Router sessions? Another merge? Kind regards, Job From nobody Fri Dec 3 10:00:41 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F50A3A0D43 for ; Fri, 3 Dec 2021 10:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl 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 o7qkk9TfsM7J for ; Fri, 3 Dec 2021 10:00:34 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [116.202.126.228]) (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 3BD2C3A0D45 for ; Fri, 3 Dec 2021 10:00:33 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 6DAB0185; Fri, 3 Dec 2021 18:00:29 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1638554428; bh=XA1Ts6N33xMaTHgp5SrYjjJKAYnyGkYykmGVnOeVeic=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=QVcCKR3EWWGdEsI85E/v2AvsQtCq52EgaU+YsbmU9HPweewVcLrSLARWQRwcc7xss 4hVVs6URuENXup9wkfiXurQxZHOGNuTvd9qTtsLbheNnMIp5m5vUzstngx6+QuJhPa /N24VNjMyFSk6bGAs+uaOwBZf+RKdfz43znEjteEg3Jhlg2b9OkeIS9zKvrHNBMUMt 58hy543qBlJsZ61PpP5gGmTN67KhvgIgmOQVICz+LGSsGsAZnHFV3/LvOsfTWWVyIc 9EAN6WUedXIScrFJTYCGtctSW5s+DhSAr32A0BGKWguu1MkvH93yTqai0tAr8x9nLU egBQNSn7v/GBw== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Tim Bruijnzeels In-Reply-To: Date: Fri, 3 Dec 2021 19:00:26 +0100 Cc: "sidrops@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <10C81CF6-6F43-4AC6-B232-431460051F88@nlnetlabs.nl> References: <0B2DE27E-B67F-413B-806B-7131B90F3333@arrcus.com> <14BFC0A3-0352-47C7-86CF-23223F0E660E@nlnetlabs.nl> <1C0B5653-BBB7-4F61-A6C9-CD4857F260C0@nlnetlabs.nl> <2ED23A27-CC42-4BED-AD5C-8CD3D741766E@nlnetlabs.nl> To: Randy Bush Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 18:00:40 -0000 > On 3 Dec 2021, at 18:46, Randy Bush wrote: > > The router should see at most one ASPA for a particular Customer > Autonomous System Number active at any time. As a number of > conditions in the global RPKI may present multiple valid ASPA objects > for a single customer to a particular RP cache, this places a burden > on the cache to merge multiple ASPA records it has received from the > global RPKI into one ASPA PDU. > > ok? Works for me, thanks! > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Dec 3 10:04:08 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927CC3A0D55 for ; Fri, 3 Dec 2021 10:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LKm6jPZJ1qb for ; Fri, 3 Dec 2021 10:04:02 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) (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 AC66B3A0D52 for ; Fri, 3 Dec 2021 10:04:02 -0800 (PST) Received: from [198.180.150.2] (helo=mail.rg.net) by psg.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1mtCud-000BMm-6a; Fri, 03 Dec 2021 18:03:59 +0000 Received: from c-24-21-195-208.hsd1.or.comcast.net ([24.21.195.208] helo=[192.168.0.18]) by mail.rg.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mtCuc-0001dT-5f; Fri, 03 Dec 2021 18:03:58 +0000 From: Randy Bush To: Job Snijders Cc: Tim Bruijnzeels , sidrops@ietf.org Date: Fri, 03 Dec 2021 10:03:56 -0800 X-Mailer: MailMate (1.14r5818) Message-ID: In-Reply-To: References: <0B2DE27E-B67F-413B-806B-7131B90F3333@arrcus.com> <14BFC0A3-0352-47C7-86CF-23223F0E660E@nlnetlabs.nl> <1C0B5653-BBB7-4F61-A6C9-CD4857F260C0@nlnetlabs.nl> <2ED23A27-CC42-4BED-AD5C-8CD3D741766E@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 18:04:06 -0000 > What to do when the router receives dissimilar ASPA PDUs via different = RPKI-To-Router sessions? Another merge? i thought that a router specified a priority on each member of a set of RP caches. having a hard time finding that. i would be very hesitant to suggest the router form the union, as it then has to backtrack if one is withdrawn. yuchh randy From nobody Fri Dec 3 10:20:18 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3E13A0D77 for ; Fri, 3 Dec 2021 10:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.792 X-Spam-Level: X-Spam-Status: No, score=-2.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 fm3tlX-MoN5P for ; Fri, 3 Dec 2021 10:20:11 -0800 (PST) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on20729.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d04::729]) (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 A45EB3A0D6F for ; Fri, 3 Dec 2021 10:20:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kWm4hUxeFl9AjKcP34u0CseT5/64URqHGdOYHyf7rpCzFrDtma9kLZQBgTpz1AhKoy7rhfjUS9IAjjZQzsGg+fUO06c3EudkxA1H8fkHIqsNh4GQP44t9bY5O6QorXyDTfL6A1RiEavRwgfqRhBz9YcSHUiI3fIPaGmZxDHZR2HtVBsiMTsJQXx8B4CqasRiUiB/9kY4a9PYcHbWtArKbIG4/zf0u4JtGKDsWKtykI4cMshPEAazf5G101KO0ynfZmG9QvBLjkBZVuTcZTEU+h6Ti0s0gGJ8cB0jU4rI5WUXd0VBMH9CDtG/Yg0TUdhN93jnz1WKTuKErqnd3SaRTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OrIvL/VZBraD6FkfLBdUOBY1WVctIZ4X5Yg0TneQSRA=; b=Cbg58FGA/EvrhWpn3ZFADIekZGsZQlM/4YOzxhiqc5e8dTdfLkeLVh3s8GEfbZCFkm9WqmBV9dmqY3dSMGZeabSU+RGtCfN1lRDsCYtPxQO8oehmGB62El/Vos3x+xL/Pjm6Zc/yQ4/hT966VsrNg5PidbxJPA4cEWtSB4OBInLfHSJTouUvLNoFLa2Mi7yAHa/DNxOq8exuqrIJpKWUuFdVJa0SCRYGaF0irV4ayPCrVpXYFptFLEdwDklrS0/Mf5h5LbEis3olSwQMgiL9jp3Xc+ZAZhr6dFvMMCs5Utk3aKSEJBy+GicCNv2xRbxd9cGUu+rl/N4WkuSIhm3lRw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OrIvL/VZBraD6FkfLBdUOBY1WVctIZ4X5Yg0TneQSRA=; b=GgFzV6C0oRnHXhJer6TRON2T357j/wWhH3Hlhz2cyl3JHgP3khq0AA1pztd8I8yDjqB6MPL+XoysvMIpHxW8Lh4hQpAfrnAsTZQqYa2Mo2HR0a8kG3oPf4br6swlHbmRe87r3hx6D5z1v/wzM1FF54vavYceP2SOL7V43O6pkmg= Received: from BLAPR09MB6322.namprd09.prod.outlook.com (2603:10b6:208:2af::22) by BLAPR09MB6723.namprd09.prod.outlook.com (2603:10b6:208:2a0::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.16; Fri, 3 Dec 2021 18:20:03 +0000 Received: from BLAPR09MB6322.namprd09.prod.outlook.com ([fe80::c161:f060:c5ad:9b59]) by BLAPR09MB6322.namprd09.prod.outlook.com ([fe80::c161:f060:c5ad:9b59%6]) with mapi id 15.20.4755.019; Fri, 3 Dec 2021 18:20:03 +0000 From: "Borchert, Oliver (Fed)" To: Job Snijders , Randy Bush CC: "sidrops@ietf.org" , Tim Bruijnzeels , "Borchert, Oliver (Fed)" Thread-Topic: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021 Thread-Index: AQHX4JxjysDMm9aqUk+5kLJKlC2YP6wShquAgAzwY4CAAQNEAIAAFKqAgACLOgCAAADlAP//tKEA Date: Fri, 3 Dec 2021 18:20:03 +0000 Message-ID: <523B28BF-9CAB-4E35-AD93-39EBD0A371CF@nist.gov> References: <0B2DE27E-B67F-413B-806B-7131B90F3333@arrcus.com> <14BFC0A3-0352-47C7-86CF-23223F0E660E@nlnetlabs.nl> <1C0B5653-BBB7-4F61-A6C9-CD4857F260C0@nlnetlabs.nl> <2ED23A27-CC42-4BED-AD5C-8CD3D741766E@nlnetlabs.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.55.21111400 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nist.gov; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b3e313b1-9756-4990-19dc-08d9b689866f x-ms-traffictypediagnostic: BLAPR09MB6723: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7HCFkqcOwKA51kOd4qnJ7XizJ1OjZUCs6YO35h6xB9Psj9akMGl6DeOXgfI2BKWeNY/RkhdQKFONzPpRc1CavwrGrNoEUbKNJV8VB6o8J8T2t7eFZvAcb7VevrNu39uJ5ykARhZdDdeSApcFdw2vxVoc3Vk0On8NcqdcRJ/M7qztXchNFfcs5Skx46/elRPFfd1XQiNC/QHwzXGQIKfnqQeQkfcx/HD9yLcpBdDyrL3LiXzcLT2Ha6Nwiy1hA2iIZZOoV2FTrROTbBXkfTq75cgpjtuIn7rWKahKAsVK3v9k8XlgDOEojjEBj1ZnWRrmfKM6H/nGsm8uVA8xqiQeeC/MRwYsKLD/KY9knlT+AQYNesWyKoPx7HJcYKNcwgznR1iWlLrzOsb72CgBIslxociaLkIxnw2pbnD56qcN7uvO16eyBjabI9/MAZ4kCEKb7j1F2CffJRLMX//FgwKaKx579J17PypNfNqVzZvW7Cv4xVcgIJHGMFmRyBlYAkFawYihebLGym6vNInSYYCsu0Tui5Kj4k/sHY7YAylVe1bjh73eoRvbK7arEFt5LfFdia5gXng5CLqcSpx4G3v8458fUrM4xBW+rVyA8kOUDRxJYHOEVs8zL4GO+s93Fz+WGMBpoXxCNzaDVAyj1lQFpRPT3lIkdU3aP5oZOVPp0SEgvdS4Byw8w96cBW1JptvPlcOUmGU8P3vh1SAqzz638vIx0ysbHrgNwO5j1t9ziz1oWq+D4ug9IRJffDpPRLtmzKwisSkB13casMSVMrDMhaEoTEKRN1fPnfeNkOL0saT8tEWspdXcLtCQuTHUwGjW x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BLAPR09MB6322.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(316002)(33656002)(66476007)(5660300002)(107886003)(6512007)(122000001)(66946007)(36756003)(76116006)(86362001)(64756008)(8676002)(66556008)(66446008)(82960400001)(8936002)(4326008)(2906002)(186003)(6486002)(40140700001)(45080400002)(966005)(38100700002)(2616005)(54906003)(110136005)(71200400001)(508600001)(66574015)(38070700005)(6506007)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?RWN4Z3RBWi9LS0dteE8wKzA0dy8rOWh2d1BFSGxSbWxHd1NUcytpZjZYbWFF?= =?utf-8?B?VDgzaUViWUl3ejh6c1R4aG81dWdNQVVtMXVUUzROWGhqQk1KaDMwbkZ5ejA2?= =?utf-8?B?NXFNekJVaDJDMm5lRUZ2aXJGcXdzM2NDU0NEa2JzY0tNRzhiYUw1Tm0xZ21M?= =?utf-8?B?TGhiWnIzRmMzcDl2Uk1DRnRtbHM0Qm9BeVBmVCtjZUhENE9wTWNNVUN0ZTYr?= =?utf-8?B?VjhiRVRGSTQrdStCeWM1VW1FMzdMTzUvaDdnaFlKWmVYNlhMUHNlYVlxa01R?= =?utf-8?B?ZC9ETlFyOHJwSXJZcmlTc2ZVTmM4ODlJS0FldkIwZ1BGK09JRzRrclBGQSs4?= =?utf-8?B?RHBNTDBVOXNSL1N1a0ZGMGRBS1k1U2ZRZkppMkJXM2lvRlZSa09YaGNUSlFk?= =?utf-8?B?T3FvUHlSTGtJcU5pbUhwL2NrSkg1VkM2SWF4WVJmaEJ0dlNLeEF2eU9UVnM1?= =?utf-8?B?cWZxc1lpNUlQN05FSFdpQmVsazlsdzl4NlpUSnFyTjd6RkJTU1RtQTY0M2ZM?= =?utf-8?B?UzlpQXd6T2IySndrYkJpWVBBeXM0ZHlnN2lmSEV2UWp4ejZQcWN6YXdRUk05?= =?utf-8?B?S1RxY2ZFRHV0MFlMZER4bjFzRnoxa2VoVDlmMWtDcmU1ZzRYS09JZlBvUm05?= =?utf-8?B?UkxYWlhQa0dmWW5Ic2VLQ210dU1Ga0ZnMGdZeDNqeFkvcTltRmJNYzJBV0hB?= =?utf-8?B?RExNOXVXYm52RmZYVGJTV0l4KzNSL3k4RUoxNnBEZmVwY0dmVnlsL053eVNw?= =?utf-8?B?WnkzY0p2NDIxb2oyalJXWkV2WlpVK0djalhKUTJLUUhUNEw2TzE0OUgxc0pP?= =?utf-8?B?ZXZwbVkxZHhuRnB4YnJ6ZURBcXNtNEYybTRlMTg2RWljQWljRElmOGlJTFgw?= =?utf-8?B?QStaOUx2TytMTmljMUdqQ2dmNHhIWmhwQzlXQlprQ3FNc251M1QvbVlUcE5x?= =?utf-8?B?YmNjWGJYYnN5dGVWbG9rSFRQNDhaaENrVmlsOHJrbG5yMnI0Vys1QllHN1VE?= =?utf-8?B?eHVRR1g3THU0dDg5RFk0Umx0NjdGRHFKRUk4UnJyYmtCQmxLem95V0pXNzBr?= =?utf-8?B?RkQ0OHFpY0ZUZDJJZS94LzFIREVIeTNiMDM0aENPQzkxTklGY0VySm1mVnoz?= =?utf-8?B?d2RZQ3dPMUx4bFgvMmIvQlEwVTdEWXhNQ2EwMmVZTXZxYWo5UmpBa2wvRTJN?= =?utf-8?B?S3R4YzRkZy9hUU1odWFqU2dPRGpPQXJ3TUZZOXU4UEs4UXBvNVZ4N0kxbW55?= =?utf-8?B?ZFI2WWhpampHaVlVWnZ4Z216cmhTSmUxS29TUUFuNnVEMnZiVXZzeU4xVDhj?= =?utf-8?B?MWxQODdKY2lTUWtrV0hpZzV3OGF4NUNrY0xCc3VBZkkrRDVoNHZsam9RVjZh?= =?utf-8?B?THVWMWowNVB4NjU4ZVdYU2JkUGhwUTI1OGNQVXdMVGNXUWxadTFNUWI0NWo1?= =?utf-8?B?Sy9wR20wMEU3bFJQOVQvdTRJSDVNc2ZEQ05MbHNQQVdEb3dwOXVrdHlVdDJX?= =?utf-8?B?R2dXNkl1TlRsZldvcUdxdlZ3L280L0p0YSt4cVhpaUQzU0NJZnJKTmJkK1dL?= =?utf-8?B?ZUFtc0l3M3d0MVlLL09pSmJ5NVFUOFpLczZqTng5OHRtNUszU3gxOGtrUUNR?= =?utf-8?B?ci9ZUjFHOG9rSTlteGFzTlNzemtiK2gxUGlpeGlzTG5lZTJHa3JtZTNuS2R1?= =?utf-8?B?Y1RSTjJ5ZjEwMDA3YW5JR2pmMG5UVTNhRUZ6ZkIrZTBwcm5aK1NkdjYzVnZP?= =?utf-8?B?Q3Q1TGNCcjJPZ0t6ZnlKcXIxa0JrbUltM2NydzdYUXk3OFVwc1h4bXhNOTRF?= =?utf-8?B?cjBSNm90QmFCTmhNU25jQT09?= Content-Type: text/plain; charset="utf-8" Content-ID: <39E9954594D9F94BB2D2D0654E739D85@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BLAPR09MB6322.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b3e313b1-9756-4990-19dc-08d9b689866f X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2021 18:20:03.0225 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB6723 Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 18:20:17 -0000 UmFuZHksDQoNCkNhbiB5b3UgZXhwbGFpbiB0byBtZSB3aHkgd2UgdHJlYXQgQVNQQSBQRFUgZGlm ZmVyZW50IHRoYW4gZm9yIGluc3RhbmNlIFJPQSBQRFUncyB3aXRoIGEgc2luZ2xlIEFTLXByZWZp eCB0dXBsZT8NCldoYXQgaXMgdGhlIGRvd25zaWRlIG9mIGVuY29kaW5nIHRoZSBBU1BBIFBEVSBh cyBhIHNpbmdsZSBjdXN0b21lci1wcm92aWRlciB0dXBsZT8NCg0KVGhlIHJvdXRlciB3b3VsZCBy ZWNlaXZlIG9uZSBQRFUgZm9yIGVhY2ggZGVmaW5lZCBDdXN0b21lci1Qcm92aWRlciB0dXBsZSwg c2FtZSBhcyBmb3IgUk9BUyB3aGVyZSB0aGUgcm91dGVyIHJlY2VpdmVzIGEgb25lIFBEVSBmb3Ig ZWFjaCBBUy1wcmVmaXggdHVwbGUuDQoNCldoYXQgaXMgdGhlIGJlbmVmaXQgZm9yIHRoZSByb3V0 ZXIgdG8gYWRkIHRoZSBjb21wbGV4aXR5IG9mIHRoZSAiaW1wbGljaXQiIHdpdGhkcmF3YWwgdGhh dCBJIHBvaW50ZWQgb3V0IGluIG9uZSBvZiBteSBlYXJsaWVyIGVtYWlscz8NCg0KSSBwZXJzb25h bGx5IGJlbGlldmUgaXQgbWFrZXMgbW9yZSBzZW5zZSB0byBoYXZlIGFsbCBkYXRhIFBEVSdzIHBy b2Nlc3NlZCBpbiBhIHVuaWZpZWQgZm9ybS4gUk9BIGFuZCBLZXkgUERVJ3MgZG8gdGhhdCwgQVNQ QSBpcyBjb21wbGV0ZWx5IGRpZmZlcmVudC4NCg0KT2xpdmVyDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpPbGl2ZXIgQm9yY2hlcnQsIENvbXB1dGVy IFNjaWVudGlzdA0KTmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVjaG5vbG9n eQ0KKE9mZmljZSkgKzEuMzAxLjk3NS40ODU2DQooR1ZvaWNlKSArMS4yNDAuNjY4LjQxMTcNCiAN Cg0K77u/T24gMTIvMy8yMSwgMTI6NTAgUE0sICJTaWRyb3BzIG9uIGJlaGFsZiBvZiBKb2IgU25p amRlcnMiIDxzaWRyb3BzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGpvYj00MGZhc3Rs eS5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgT24gRnJpLCBEZWMgMDMsIDIwMjEg YXQgMDk6NDY6MzZBTSAtMDgwMCwgUmFuZHkgQnVzaCB3cm90ZToNCiAgICA+ICAgIFRoZSByb3V0 ZXIgc2hvdWxkIHNlZSBhdCBtb3N0IG9uZSBBU1BBIGZvciBhIHBhcnRpY3VsYXIgQ3VzdG9tZXIN CiAgICA+ICAgIEF1dG9ub21vdXMgU3lzdGVtIE51bWJlciBhY3RpdmUgYXQgYW55IHRpbWUuICBB cyBhIG51bWJlciBvZg0KICAgID4gICAgY29uZGl0aW9ucyBpbiB0aGUgZ2xvYmFsIFJQS0kgbWF5 IHByZXNlbnQgbXVsdGlwbGUgdmFsaWQgQVNQQSBvYmplY3RzDQogICAgPiAgICBmb3IgYSBzaW5n bGUgY3VzdG9tZXIgdG8gYSBwYXJ0aWN1bGFyIFJQIGNhY2hlLCB0aGlzIHBsYWNlcyBhIGJ1cmRl bg0KICAgID4gICAgb24gdGhlIGNhY2hlIHRvIG1lcmdlIG11bHRpcGxlIEFTUEEgcmVjb3JkcyBp dCBoYXMgcmVjZWl2ZWQgZnJvbSB0aGUNCiAgICA+ICAgIGdsb2JhbCBSUEtJIGludG8gb25lIEFT UEEgUERVLg0KDQogICAgV2hhdCB0byBkbyB3aGVuIHRoZSByb3V0ZXIgcmVjZWl2ZXMgZGlzc2lt aWxhciBBU1BBIFBEVXMgdmlhIGRpZmZlcmVudA0KICAgIFJQS0ktVG8tUm91dGVyIHNlc3Npb25z PyBBbm90aGVyIG1lcmdlPw0KDQogICAgS2luZCByZWdhcmRzLA0KDQogICAgSm9iDQoNCiAgICBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIFNpZHJv cHMgbWFpbGluZyBsaXN0DQogICAgU2lkcm9wc0BpZXRmLm9yZw0KICAgIGh0dHBzOi8vZ2NjMDIu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5p ZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNpZHJvcHMmYW1wO2RhdGE9MDQlN0MwMSU3 Q29saXZlci5ib3JjaGVydCU0MG5pc3QuZ292JTdDZjZjNzhjN2ExMTBkNDRiOGQyNmEwOGQ5YjY4 NTViYzklN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MwJTdDNjM3NzQx NTA2MjAzMTM5NDQ0JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFp TENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmYW1w O3NkYXRhPW5oYkoyanBxR3lnN3hKaFdUJTJGMzJhR1Q1MiUyRjRjQk0zVlJDbndKNSUyRnJodGMl M0QmYW1wO3Jlc2VydmVkPTANCg0K From nobody Fri Dec 3 10:20:54 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5EE83A0D76 for ; Fri, 3 Dec 2021 10:20:52 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijL-EPFzQILd for ; Fri, 3 Dec 2021 10:20:50 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 DE5953A0D6F for ; Fri, 3 Dec 2021 10:20:50 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mtDAu-0000FU-Vj; Fri, 03 Dec 2021 18:20:49 +0000 Date: Fri, 03 Dec 2021 10:20:48 -0800 Message-ID: From: Randy Bush To: Oliver Borchert Cc: SIDR Operations WG In-Reply-To: <4ECF3177-C682-480F-81EF-9155498F081F@nist.gov> References: <0B2DE27E-B67F-413B-806B-7131B90F3333@arrcus.com> <14BFC0A3-0352-47C7-86CF-23223F0E660E@nlnetlabs.nl> <0520521A-DF0E-4209-8FF2-745094D742C8@nlnetlabs.nl> <4ECF3177-C682-480F-81EF-9155498F081F@nist.gov> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 18:20:53 -0000 oliver, i have been confused here too > The current version of the draft mentions a router only contains one > single APSA object per customer. This assumes a specific form of > implementation. I don't believe a protocol specification should do > that. One can imagine an implementation that stores the data as link > relations hence multiple internal objects per customer. Take 10 > implementers and you might end up with 10 solutions. and those implementation variations are an internal matter for the RP, and should not affect the router. the job of the RP is to make life simple for the router by presenting one and only one current ASPA PDU. of course, ten router vendors could have ten ways of handling their internal data structures. but the ASPA PDU is the narrow waist. > I always read to keep things simple - Great I like simple. Though, as > I outlined in my email from last week, the current specification > introduces implicit withdrawals while announcing an ASPA object. That > contradicts simplicity - it adds additional complexity to the router. the alternative is requiring the withdraw to be explicit which places analogous burdens on the router to handle the error condition if it receives more than one announcement with no intervening withdraw. win some, lose some. > As I mentioned in my email as well as was mentioned in prior IETF's a > router should never perform any validation on incomplete data. The > moment the router starts updating the data, it most likely will > encounter a break before make situation - at least when it comes to > ROA's. Therefore the router should always wait until a complete update > is processed prior acting upon it. > > Therefore, "Keep it simple" should result in a PDU as I proposed with > only a single Customer Provider. An ASPA object that contains 10 > providers should result in 10 PDU's each with the customer and a > single provider. Duplicates are treated as established, withdrawals > are treated as established. No special handling required on the > router's side. i hear you; and would seriously consider it if we were doing this de novo. but, as you say, router vendors undoubtedly have varied internal data structures. as we did not place a receive-all-before-processing requirement on them in v0 and v1, doing so now would seem to be a major pola violation. hence we used SHOULD instead of MUST in 11. ROA PDU Race Minimization When a cache is sending ROA PDUs to the router, especially during an initial full load, two undesirable race conditions are possible: Break Before Make: For some prefix P, an AS may announce two (or more) ROAs because they are in the process of changing what provider AS is announcing P. This is is a case of "make before break." If a cache is feeding a router and sends the one not yet in service a significant time before sending the one currently in service, then BGP data could be marked invalid during the interval. To minimize that interval, the cache SHOULD announce all ROAs for the same prefix as close to sequentially as possible. Shorter Prefix First: If an AS has issued a ROA for P0, and another AS (likely their customer) has issued a ROA for P1 which is a sub- prefix of P0, a router which receives the ROA for P0 before that for P1 is likely to mark a BGP prefix P1 invalid. Therefore, the cache SHOULD announce the sub-prefix P1 before the covering prefix P0. how much data would a router have to buffer and for how long and with what end-of-session timeout? if we now tried to place a receive-all-before-processing requirement on routers, would there be effects on other PDUs and requirements? randy From nobody Fri Dec 3 10:51:34 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECF93A003D; Fri, 3 Dec 2021 10:51:33 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyAnbBaixklh; Fri, 3 Dec 2021 10:51:31 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 A2DCD3A003C; Fri, 3 Dec 2021 10:51:31 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mtDea-0000Jj-OW; Fri, 03 Dec 2021 18:51:28 +0000 Date: Fri, 03 Dec 2021 10:51:27 -0800 Message-ID: From: Randy Bush To: "Borchert, Oliver (Fed)" Cc: Job Snijders , "sidrops@ietf.org" , Tim Bruijnzeels In-Reply-To: <523B28BF-9CAB-4E35-AD93-39EBD0A371CF@nist.gov> References: <0B2DE27E-B67F-413B-806B-7131B90F3333@arrcus.com> <14BFC0A3-0352-47C7-86CF-23223F0E660E@nlnetlabs.nl> <1C0B5653-BBB7-4F61-A6C9-CD4857F260C0@nlnetlabs.nl> <2ED23A27-CC42-4BED-AD5C-8CD3D741766E@nlnetlabs.nl> <523B28BF-9CAB-4E35-AD93-39EBD0A371CF@nist.gov> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 18:51:33 -0000 oliver > Can you explain to me why we treat ASPA PDU different than for > instance ROA PDU's with a single AS-prefix tuple? What is the > downside of encoding the ASPA PDU as a single customer-provider tuple? same reason as last time we followed the woozle tracks around this tree. does a router have to add and substract from a set of valid providers, or does it simply receive the current set? does the cache have to remember what it told the router so it can withdraw appropriately[0]? does the cache need to accumulate all updates for a customer so it can send sequentially to reduce race condition exposure with incoming bgp? randy [0] - fyi, my routers log symptoms of inappropriate roa withdrawals for various RPs From nobody Fri Dec 3 10:51:47 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7004A3A0047 for ; Fri, 3 Dec 2021 10:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 HCbVktvnTduH for ; Fri, 3 Dec 2021 10:51:41 -0800 (PST) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl0gcc02on20702.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d05::702]) (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 D61A63A02BD for ; Fri, 3 Dec 2021 10:51:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TVtpBDVI58O2LGIVKKqHReEmNvCFt9any/q1eaje2MrwaOQrbL9ztaKsotWbd1ApitM3eHNQA0zOjrw/qQc87V228mOIKNmTMCLBxv+1l5sq5SO5Gh8223O0eafpVQIDB/gnntuCJeBeYjD/F3hhLv3X1LYeZ7ANfsaSsNbFGr2iDraS1swuzx3+JOjLnZ9lyudhntNmTMZASNleQ6iHnHZLbtagdzN33111rBFtCULd4ph/nEVo7FzSlaX+EYu20Cv4rlHTW4eSgfLfWnQSfn9NsPWgNJ6jWWQaLBaAk0lclZee4VYIXuRQh7PM5WeqCsnj1pywSYE3KsOEW3kzSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IT/KgP+bzHyobXL7D8fsOx+WmfNa2gzuKaNTsDU2UXA=; b=i/SCf05VUeFAoYiyb6yMnTIE+lVVr2gcXFSpvraQNZh87b68VygHaCa4iFLI4qGUs+9jL2dJsLXkHUsB9Bsp6jiEgwOpAKGHZ+x1FTMwva66rCpCWp/QEISJ22YK+TQwZAuYMs3gJyrijDJ/figa2KUNotzkF2HNr4+3k4D6SqS1hmkQdxE7Jhr7KjMNwP+ozoF7nWWumFd1KYR5OZOFTiVcbAMjIq+3qATw1FUGOQFtES2df4RZ8/gqWs1e76coZOhZ8g/09G+gidyqWNELTC1O/KhGdZziaa0aIbUtNflY5aCT8fG8Afjx7xrybkBEv7NzNjbWtSTlTrjM8CQtrg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IT/KgP+bzHyobXL7D8fsOx+WmfNa2gzuKaNTsDU2UXA=; b=ocUaY7O6zOTYPK0dpJd/0B+/MW9YLgOW/JE0t1QaIp/zMNlbujCdD5iYEgpG+h8ymPsDU9KX5XqQIN10YX6dseIQrk0GLi+flTYe8Pc1jG1OaHJw7xdenyMINYteo5mNzVAxttkw9b03Vm3cSF9ciLLaNPkBbayYyS+fi49o5Ok= Received: from BLAPR09MB6322.namprd09.prod.outlook.com (2603:10b6:208:2af::22) by BLAPR09MB6387.namprd09.prod.outlook.com (2603:10b6:208:2a0::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4734.23; Fri, 3 Dec 2021 18:51:34 +0000 Received: from BLAPR09MB6322.namprd09.prod.outlook.com ([fe80::c161:f060:c5ad:9b59]) by BLAPR09MB6322.namprd09.prod.outlook.com ([fe80::c161:f060:c5ad:9b59%6]) with mapi id 15.20.4755.019; Fri, 3 Dec 2021 18:51:34 +0000 From: "Borchert, Oliver (Fed)" To: Randy Bush CC: SIDR Operations WG , "Borchert, Oliver (Fed)" Thread-Topic: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021 Thread-Index: AQHX4JxjysDMm9aqUk+5kLJKlC2YP6wShquAgAW5UQCAAiQTAP//3P4AgAbitwD//7THAA== Date: Fri, 3 Dec 2021 18:51:34 +0000 Message-ID: <9B526B35-FC61-48A3-897B-BF3E84B305FB@nist.gov> References: <0B2DE27E-B67F-413B-806B-7131B90F3333@arrcus.com> <14BFC0A3-0352-47C7-86CF-23223F0E660E@nlnetlabs.nl> <0520521A-DF0E-4209-8FF2-745094D742C8@nlnetlabs.nl> <4ECF3177-C682-480F-81EF-9155498F081F@nist.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.55.21111400 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nist.gov; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bdbb80d0-6c33-4f37-4c81-08d9b68dedf1 x-ms-traffictypediagnostic: BLAPR09MB6387: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9u55L9ZMSZ8Bm733vYUelD6asB7Szag2lGt/FtCOzdchueE8BvWSBXveLwd+yc5sYbRYbalbpdt9OGxTWHSuMnhlXLELs7JPi74OjUN4/E4G3WYogLm1V8KlQp/JBo5P/6OY5W0WOWS6Lcrtg4wjWnk5T0TyXyThxTZQZGRnBpB274yT+/xuv2/ab7QmiMJIzyOVulOxm6L60T1iYfBlRIZlZ96YYga82GEd+4xWTJhhFexgouLPY/wobuAkBScNzGAOXvoecET4KaFx80x9Vey1PBBqjWkwmUXonxoYKosVyZNWsyBKW37dvBOwzQ7FFDJWXLDQm/WQCDpZ9MjCF0vOkB0ZUFnVIh2jfv45NwZAvDF3sti2rZ8Zf6tu3PGslv2VSzaOetJ21TdpkWCIWsXnxgSnp30YlNFITVRIDYP6/WSoEj/Bndz6ikMUOM449u3sf3rsJmNrcAsFhs9RA9LzNuzMspjPI+xJwxLMsOtlKpiX6hTTuYL6XXT+WfI4C0/LrsUYEi9tKnIGy0ObHshrdvmQQwozeQXvlA+tFj0YJVC2PQMT6ZtIRd7hlJv63DGt96K7zILsAnbzwmkB5n8TWVbWzi8ID7zCiqFAgHiKXONBhhmYPvlaTPaGZQom6hJkTMHaRGdZyky7Yo2Nai1zruRp0x6x1s1GYpR/i6Qs/6JZ51nXjLqSlYnp/QkBNFKhi4wPSkOgO0LV75E7Bu9aNzG7i2ZOAfwZf7eDa2h1U9din+05rm2ZU417+7pE x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BLAPR09MB6322.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(76116006)(66476007)(38070700005)(4326008)(66946007)(66446008)(64756008)(66556008)(122000001)(8676002)(33656002)(107886003)(8936002)(6506007)(2906002)(66574015)(316002)(83380400001)(82960400001)(6486002)(86362001)(38100700002)(40140700001)(5660300002)(2616005)(54906003)(186003)(6916009)(508600001)(6512007)(71200400001)(36756003)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dzNseUdtUzhlZUtLYnYyb3gzdWxJaWZ5dkxFeERDL1FJV3RkdGJLZy9sMHlC?= =?utf-8?B?QmEyb0JSTVByM0NWaUoySnF0SmxWSW5ZaXFWMFNGSXRTc3RXM0ZGRUhFUjhQ?= =?utf-8?B?QVBDa0VRdnJaNDhhUDRiMENTbjRoSnFlOXBUdURwZzRUUVozMlV5dG5lc2pU?= =?utf-8?B?dy9aZW85SEprME9PU3J6MUM4N25pNGNqSUhUSzVRWFp1V0U4ZDkrSVMwSDZ4?= =?utf-8?B?RHJ5a2VpT0Mxd09US1NjaW1aMmhDL3UyZkhmUWlHVXZwVVU1TXlMYmhiNFFG?= =?utf-8?B?V2pqaFlDTUNKbzB1ZkFqbGJUaXF6WE5sR0lVWlQwcEx1TW9UZVVWOW1mWm1w?= =?utf-8?B?OTJqSElUTnZJc0dRM3NFTEJReHdwU3l4KzRMZGV4ZG1FdXNnMWh3V1JOMWdP?= =?utf-8?B?RVg4UXF3UlJWR3hpenpQSi9oQURkOE1uakFTYkJvdzBPRkF2bE9jSG10L2Mw?= =?utf-8?B?ekhsY2dKOHprM1VLenVkbnpoK002WkN1eWRQMnM0WUl2cVE0YmZPa1ROSnQ0?= =?utf-8?B?U0dUUWV2K3YzbERuVGhISklzNEUya2FodTArN1lPbkZQT1BJbWFsNjRMWFFs?= =?utf-8?B?TFlFQjJ5aFRUQmJ5MTBaTnJXdzJhbnMxeGlGYVJVaHpqNFBNOHpIbFY2T0d2?= =?utf-8?B?WXdZWXlEU2tmNWxXOXVHOWZsNkV6OGl2RmlCNlIrQTJKNjFHdnhHdXoxVFFu?= =?utf-8?B?MlVqSVNiRE9nRGF5RjN1NUw0U2Rvam5aelBFZUc1bldMbzRDN0UvTzNrSXp5?= =?utf-8?B?bGFHZmFpdGhIR25kaVJZeHlWR1J2UzZPdk12MmlBWGlSNnlPazAxU0pRbmYw?= =?utf-8?B?dDhVd3ptK1NET3dUVTJhWEtOam51aEtaV1UvOERxZDdGSGVmbnRIOHlWNTA1?= =?utf-8?B?SHRtaVAya3NUTjV6UVJDK3YzTkE1a25HNjRwanI4emcvWEVxTHBGVXRyRGlC?= =?utf-8?B?TWI5bThBNDFzdEp1NXh4NUc1VDFXdVBxb05Sc21uY1NrSTNOOXphbjgrTmkz?= =?utf-8?B?SzZEcThRM3ZuWEtOR1VDRzVxNFVHOGRndmg3ZDJPVmxYOXdJQkkwU0FLRXk5?= =?utf-8?B?bEs0K3lhSEZjd2Y0NUJJUmdhemZacWdvZGF1Y2xGYnpIZ3BabFpjTkQzVVJm?= =?utf-8?B?RksrbHpTZFdnYmxtbVZjLzNVanhBOWtZaUd5djQrKzFCcHpCYUZRNG9PRlpl?= =?utf-8?B?UU84MXh3NWZHMnN2Vm0vVU1mSVhMMkdnUzhLQWkrV005TEE4dzBIVTBZdys0?= =?utf-8?B?VVY5TWRqOTZIU2Q5YWZFRUVhNUZRekthVHFXWHZISUV6a0VCZDRkbkFkQmxj?= =?utf-8?B?bkhMQndBTDF6QmJkaFJadU9YZHJyYW5tb1NTNnFhMU9SNmd2SHJETU02aUpV?= =?utf-8?B?dXhkN0o3Z3poRFRKayt5UDNWNm9DSG5tUUFWYlVnZkNZdzNvUkp5bmtJNU9p?= =?utf-8?B?ODgvRVlZRDlOblBIWVhnbnJDMi83dE5pRmU3QnhrT1lyOVRUQWdxbFVXKzZ3?= =?utf-8?B?UmQ2K2FNcmFZWEJGSEdZd0IvclJTcFZRR1F6dDcwMEN4VjJYVkcvd05jRERQ?= =?utf-8?B?cW9oWUVXN2t5R29Ram9jd1FzcVRBV0xCY0Y1bW9hMm50eFMvSUhXa054MWw0?= =?utf-8?B?K0YrVWpFN3A5VmtnNUE0SDdDUzM4dTAvdDNma2NPUk1RNXpWOFJkQXFxY1Vr?= =?utf-8?B?Tkw2eU1RRHZwU1RhTE1COVYzV0ZpMzZQNnNIcmJoZ3hNalgyVlJZa1J0dHN0?= =?utf-8?B?ZVlRTkVwdXJzMjhjZXROZWQwOFREV0FUZ3VHOEdUMjBWcU5mdGdtQmJXY3cr?= =?utf-8?B?YVNQeTcwVkN5NVJCWTZQdz09?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BLAPR09MB6322.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bdbb80d0-6c33-4f37-4c81-08d9b68dedf1 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2021 18:51:34.6392 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB6387 Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 18:51:46 -0000 SSB1bmRlcnN0YW5kIHRoZSBtYWtlIGJlZm9yZSBicmVhayBmZWFyIGluIEFTUEEgYnV0IGl0IGlz IGFscmVhZHkgYSBiaWcgaXNzdWUgd2l0aCBST0Ency4NCk1heWJlIGV2ZW4gYSBiaWdnZXIgaXNz dWUgaWYgeW91IGRyb3AgaW52YWxpZHMuDQoNCkkgYWxzbyBkbyBub3Qgc2VlIHRoYXQgdGhlIHNl bmQgc2hvcnRlciBwcmVmaXggZmlyc3Qgc29sdmVkIHRoZSBwcm9ibGVtIGZvciBST0Ency4gVGhp cyBkb2VzIG5vdCBzb2x2ZSB0aGUgaXNzdWUgb2YgdHdvIEFTZXMgdGhhdCBhcmUgYWxsb3dlZCB0 byBhbm5vdW5jZSB0aGUgc2FtZSBwcmVmaXguIEhlcmUgQVMtYSBhbmQgQVMtYiBjb3VsZCBhbm5v dW5jZSBQcmVmaXgtcCBhbmQgaWYgdGhlIFBEVSBmb3IgW0FTLWEsIFByZWZpeC1wXSBhcnJpdmVz IGFuZCBnZXRzIHByb2Nlc3NlZCBhaGVhZCBvZiBbQVMtYm0gUHJlZml4LXBdIHdpdGggdGhlIHNl Y29uZCByb3V0ZSBiZWluZyB0aGUgc2VsZWN0ZWQgb25lLCB0aGUgc2Vjb25kIG9uZSAoc2VsZWN0 ZWQpIHdvdWxkIGJlIGltbWVkaWF0ZWx5IGJlY29tZSBpbnZhbGlkIGluIGNhc2UgdGhlIHJvdXRl ciBhY3RzIHVwb24gZWFjaCBQRFUgaW1tZWRpYXRlbHkuIFRoYXQgd291bGQgcmVzdWx0IGluIGEg d2l0aGRyYXdhbCBvciBzd2l0Y2ggZm9sbG93ZWQgYnkgYSBzd2l0Y2ggYmFjayBvbmNlIHRoZSBz ZWNvbmQgUk9BIFBEVSBpcyByZWNlaXZlZC4gVGhlcmVmb3JlIHRoaXMgdG9vIGNhbiBjYXVzZSBh IHJvdXRlIGZsaXAgb3IgY29tcGxldGUgd2l0aGRyYXdhbC4NCg0KSGVuY2UsIHRoZSBvbmx5IHBy b3BlciBzb2x1dGlvbiBpcyB0byB3YWl0IHVudGlsIGFsbCBkYXRhIGlzIHVwZGF0ZWQuIEFuZCBp ZiBub3QgdGhlbiB0aGUgUk9BIFBEVSB0b28gc2hvdWxkIHVzZSB0aGUgZm9ybWF0IG9mIA0KcHJl Zml4LUFTLUFTLUFTLUFTIGNvbWJpbmVkIHdpdGggc21hbGxlciBmaXJzdC4gDQoNClRoZSBtYWlu IGlzc3VlIEkgaGF2ZSBpcyB0aGF0IGZvciB0aGUgc2FtZSBwcm9ibGVtIHNwYWNlIChyYWNpbmcg Y29uZGl0aW9uKSBST0EgYW5kIEFTUEEgUERVJ3MgYXJlIGVuY29kZWQgZGlmZmVyZW50bHkgYXMg aXQgaXMgcmlnaHQgbm93LiBDdXJyZW50bHksIHdpdGggUk9BJ3MgdGhlIHJvdXRlciBjYW4gYmUg ZHVtYiwgYWRkIG9yIHJlbW92ZSwgb3Igc2VuZCBhbiBlcnJvciBmb3IgZHVwbGljYXRlcy4gRm9y IEFTUEEgbm90IHNvIG11Y2gsIGl0IG1pZ2h0IG5lZWQgdG8gZXhhbWluZSB0aGUgZGVsdGEuIEFu ZCB0aGVuIHdoYXQgYWJvdXQgZHVwbGljYXRlcyBoZXJlLCB0aGV5IGFyZSBhbGxvd2VkLiBEaWZm ZXJlbnQgYmVoYXZpb3IgZm9yIHRoZSBzYW1lIHNpdHVhdGlvbiB3aGljaCBJIHRoaW5rIGlzIG5v dCBnb29kLiANCg0KVGhlIGFyZ3VtZW50IGZvciB0aW1lb3V0IGV0Yy4gaXMgdGhlIHNhbWUgd2hl biBvbmUgbmVlZHMgdG8gcmVsb2FkIGEgY29tcGxldGUgY2FjaGVzIHdvcnRoIG9mIGRhdGEuIFdo YXQgSSBvYnNlcnZlZCB3aGVuIGV4cGVyaW1lbnRpbmcgd2l0aCBjb21tZXJjaWFsIHJvdXRlciBp bXBsZW1lbnRhdGlvbnMgaXMgdGhhdCBJIGNhbm5vdCByZWNhbGwgdG8gaGF2ZSBzZWVuIGEgInNl cmlhbC1xdWVyeSIuIEkgYmVsaWV2ZSB0byByZW1lbWJlciBvbmx5IHRvIGhhdmUgc2VlbiAicmVz ZXQtcXVlcnkiIHJlc3BvbnNlcyB0byAic2VyaWFsLW5vdGlmaWVzIiB3aXRoIGEgdGFibGUgc3dp dGNoIG9uY2UgdGhlIHRyYW5zbWlzc2lvbiB3YXMgZG9uZSwgYnV0IEkgbWlnaHQgYmUgbWlzdGFr ZW4uDQoNCkl0IHdvdWxkIGJlIG5pY2UgdG8gaGVhciB3aGF0IHRoZSB2ZW5kb3JzIG9uIHRoZSBs aXN0IGhhdmUgdG8gc2F5LCB0aGV5IGhhdmUgdG8gaW1wbGVtZW50IGl0IGF0IHRoZSBlbmQsDQoN Ck9saXZlcg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KT2xpdmVyIEJvcmNoZXJ0LCBDb21wdXRlciBTY2llbnRpc3QNCk5hdGlvbmFsIEluc3RpdHV0 ZSBvZiBTdGFuZGFyZHMgYW5kIFRlY2hub2xvZ3kNCihPZmZpY2UpICsxLjMwMS45NzUuNDg1Ng0K KEdWb2ljZSkgKzEuMjQwLjY2OC40MTE3DQogDQoNCu+7v09uIDEyLzMvMjEsIDE6MjAgUE0sICJS YW5keSBCdXNoIiA8cmFuZHlAcHNnLmNvbT4gd3JvdGU6DQoNCiAgICBvbGl2ZXIsDQoNCiAgICBp IGhhdmUgYmVlbiBjb25mdXNlZCBoZXJlIHRvbw0KDQogICAgPiBUaGUgY3VycmVudCB2ZXJzaW9u IG9mIHRoZSBkcmFmdCBtZW50aW9ucyBhIHJvdXRlciBvbmx5IGNvbnRhaW5zIG9uZQ0KICAgID4g c2luZ2xlIEFQU0Egb2JqZWN0IHBlciBjdXN0b21lci4gVGhpcyBhc3N1bWVzIGEgc3BlY2lmaWMg Zm9ybSBvZg0KICAgID4gaW1wbGVtZW50YXRpb24uIEkgZG9uJ3QgYmVsaWV2ZSBhIHByb3RvY29s IHNwZWNpZmljYXRpb24gc2hvdWxkIGRvDQogICAgPiB0aGF0LiBPbmUgY2FuIGltYWdpbmUgYW4g aW1wbGVtZW50YXRpb24gdGhhdCBzdG9yZXMgdGhlIGRhdGEgYXMgbGluaw0KICAgID4gcmVsYXRp b25zIGhlbmNlIG11bHRpcGxlIGludGVybmFsIG9iamVjdHMgcGVyIGN1c3RvbWVyLiBUYWtlIDEw DQogICAgPiBpbXBsZW1lbnRlcnMgYW5kIHlvdSBtaWdodCBlbmQgdXAgd2l0aCAxMCBzb2x1dGlv bnMuDQoNCiAgICBhbmQgdGhvc2UgaW1wbGVtZW50YXRpb24gdmFyaWF0aW9ucyBhcmUgYW4gaW50 ZXJuYWwgbWF0dGVyIGZvciB0aGUgUlAsDQogICAgYW5kIHNob3VsZCBub3QgYWZmZWN0IHRoZSBy b3V0ZXIuICB0aGUgam9iIG9mIHRoZSBSUCBpcyB0byBtYWtlIGxpZmUNCiAgICBzaW1wbGUgZm9y IHRoZSByb3V0ZXIgYnkgcHJlc2VudGluZyBvbmUgYW5kIG9ubHkgb25lIGN1cnJlbnQgQVNQQSBQ RFUuDQoNCiAgICBvZiBjb3Vyc2UsIHRlbiByb3V0ZXIgdmVuZG9ycyBjb3VsZCBoYXZlIHRlbiB3 YXlzIG9mIGhhbmRsaW5nIHRoZWlyDQogICAgaW50ZXJuYWwgZGF0YSBzdHJ1Y3R1cmVzLiAgYnV0 IHRoZSBBU1BBIFBEVSBpcyB0aGUgbmFycm93IHdhaXN0Lg0KDQogICAgPiBJIGFsd2F5cyByZWFk IHRvIGtlZXAgdGhpbmdzIHNpbXBsZSAtIEdyZWF0IEkgbGlrZSBzaW1wbGUuIFRob3VnaCwgYXMN CiAgICA+IEkgb3V0bGluZWQgaW4gbXkgZW1haWwgZnJvbSBsYXN0IHdlZWssIHRoZSBjdXJyZW50 IHNwZWNpZmljYXRpb24NCiAgICA+IGludHJvZHVjZXMgaW1wbGljaXQgd2l0aGRyYXdhbHMgd2hp bGUgYW5ub3VuY2luZyBhbiBBU1BBIG9iamVjdC4gVGhhdA0KICAgID4gY29udHJhZGljdHMgc2lt cGxpY2l0eSAtIGl0IGFkZHMgYWRkaXRpb25hbCBjb21wbGV4aXR5IHRvIHRoZSByb3V0ZXIuDQoN CiAgICB0aGUgYWx0ZXJuYXRpdmUgaXMgcmVxdWlyaW5nIHRoZSB3aXRoZHJhdyB0byBiZSBleHBs aWNpdCB3aGljaCBwbGFjZXMNCiAgICBhbmFsb2dvdXMgYnVyZGVucyBvbiB0aGUgcm91dGVyIHRv IGhhbmRsZSB0aGUgZXJyb3IgY29uZGl0aW9uIGlmIGl0DQogICAgcmVjZWl2ZXMgbW9yZSB0aGFu IG9uZSBhbm5vdW5jZW1lbnQgd2l0aCBubyBpbnRlcnZlbmluZyB3aXRoZHJhdy4gIHdpbg0KICAg IHNvbWUsIGxvc2Ugc29tZS4NCg0KICAgID4gQXMgSSBtZW50aW9uZWQgaW4gbXkgZW1haWwgYXMg d2VsbCBhcyB3YXMgbWVudGlvbmVkIGluIHByaW9yIElFVEYncyBhDQogICAgPiByb3V0ZXIgc2hv dWxkIG5ldmVyIHBlcmZvcm0gYW55IHZhbGlkYXRpb24gb24gaW5jb21wbGV0ZSBkYXRhLiBUaGUN CiAgICA+IG1vbWVudCB0aGUgcm91dGVyIHN0YXJ0cyB1cGRhdGluZyB0aGUgZGF0YSwgaXQgbW9z dCBsaWtlbHkgd2lsbA0KICAgID4gZW5jb3VudGVyIGEgYnJlYWsgYmVmb3JlIG1ha2Ugc2l0dWF0 aW9uIC0gYXQgbGVhc3Qgd2hlbiBpdCBjb21lcyB0bw0KICAgID4gUk9BJ3MuIFRoZXJlZm9yZSB0 aGUgcm91dGVyIHNob3VsZCBhbHdheXMgd2FpdCB1bnRpbCBhIGNvbXBsZXRlIHVwZGF0ZQ0KICAg ID4gaXMgcHJvY2Vzc2VkIHByaW9yIGFjdGluZyB1cG9uIGl0Lg0KICAgID4gDQogICAgPiBUaGVy ZWZvcmUsICJLZWVwIGl0IHNpbXBsZSIgc2hvdWxkIHJlc3VsdCBpbiBhIFBEVSBhcyBJIHByb3Bv c2VkIHdpdGgNCiAgICA+IG9ubHkgYSBzaW5nbGUgQ3VzdG9tZXIgUHJvdmlkZXIuIEFuIEFTUEEg b2JqZWN0IHRoYXQgY29udGFpbnMgMTANCiAgICA+IHByb3ZpZGVycyBzaG91bGQgcmVzdWx0IGlu IDEwIFBEVSdzIGVhY2ggd2l0aCB0aGUgY3VzdG9tZXIgYW5kIGENCiAgICA+IHNpbmdsZSBwcm92 aWRlci4gRHVwbGljYXRlcyBhcmUgdHJlYXRlZCBhcyBlc3RhYmxpc2hlZCwgd2l0aGRyYXdhbHMN CiAgICA+IGFyZSB0cmVhdGVkIGFzIGVzdGFibGlzaGVkLiBObyBzcGVjaWFsIGhhbmRsaW5nIHJl cXVpcmVkIG9uIHRoZQ0KICAgID4gcm91dGVyJ3Mgc2lkZS4NCg0KICAgIGkgaGVhciB5b3U7IGFu ZCB3b3VsZCBzZXJpb3VzbHkgY29uc2lkZXIgaXQgaWYgd2Ugd2VyZSBkb2luZyB0aGlzIGRlDQog ICAgbm92by4gIGJ1dCwgYXMgeW91IHNheSwgcm91dGVyIHZlbmRvcnMgdW5kb3VidGVkbHkgaGF2 ZSB2YXJpZWQgaW50ZXJuYWwNCiAgICBkYXRhIHN0cnVjdHVyZXMuICBhcyB3ZSBkaWQgbm90IHBs YWNlIGEgcmVjZWl2ZS1hbGwtYmVmb3JlLXByb2Nlc3NpbmcNCiAgICByZXF1aXJlbWVudCBvbiB0 aGVtIGluIHYwIGFuZCB2MSwgZG9pbmcgc28gbm93IHdvdWxkIHNlZW0gdG8gYmUgYSBtYWpvcg0K ICAgIHBvbGEgdmlvbGF0aW9uLg0KDQogICAgaGVuY2Ugd2UgdXNlZCBTSE9VTEQgaW5zdGVhZCBv ZiBNVVNUIGluDQoNCiAgICAgICAxMS4gIFJPQSBQRFUgUmFjZSBNaW5pbWl6YXRpb24NCg0KICAg ICAgIFdoZW4gYSBjYWNoZSBpcyBzZW5kaW5nIFJPQSBQRFVzIHRvIHRoZSByb3V0ZXIsIGVzcGVj aWFsbHkgZHVyaW5nIGFuDQogICAgICAgaW5pdGlhbCBmdWxsIGxvYWQsIHR3byB1bmRlc2lyYWJs ZSByYWNlIGNvbmRpdGlvbnMgYXJlIHBvc3NpYmxlOg0KDQogICAgICAgQnJlYWsgQmVmb3JlIE1h a2U6ICBGb3Igc29tZSBwcmVmaXggUCwgYW4gQVMgbWF5IGFubm91bmNlIHR3byAob3INCiAgICAg ICAgICBtb3JlKSBST0FzIGJlY2F1c2UgdGhleSBhcmUgaW4gdGhlIHByb2Nlc3Mgb2YgY2hhbmdp bmcgd2hhdA0KICAgICAgICAgIHByb3ZpZGVyIEFTIGlzIGFubm91bmNpbmcgUC4gIFRoaXMgaXMg aXMgYSBjYXNlIG9mICJtYWtlIGJlZm9yZQ0KICAgICAgICAgIGJyZWFrLiIgIElmIGEgY2FjaGUg aXMgZmVlZGluZyBhIHJvdXRlciBhbmQgc2VuZHMgdGhlIG9uZSBub3QgeWV0DQogICAgICAgICAg aW4gc2VydmljZSBhIHNpZ25pZmljYW50IHRpbWUgYmVmb3JlIHNlbmRpbmcgdGhlIG9uZSBjdXJy ZW50bHkgaW4NCiAgICAgICAgICBzZXJ2aWNlLCB0aGVuIEJHUCBkYXRhIGNvdWxkIGJlIG1hcmtl ZCBpbnZhbGlkIGR1cmluZyB0aGUNCiAgICAgICAgICBpbnRlcnZhbC4gIFRvIG1pbmltaXplIHRo YXQgaW50ZXJ2YWwsIHRoZSBjYWNoZSBTSE9VTEQgYW5ub3VuY2UNCiAgICAgICAgICBhbGwgUk9B cyBmb3IgdGhlIHNhbWUgcHJlZml4IGFzIGNsb3NlIHRvIHNlcXVlbnRpYWxseSBhcyBwb3NzaWJs ZS4NCg0KICAgICAgIFNob3J0ZXIgUHJlZml4IEZpcnN0OiAgSWYgYW4gQVMgaGFzIGlzc3VlZCBh IFJPQSBmb3IgUDAsIGFuZCBhbm90aGVyDQogICAgICAgICAgQVMgKGxpa2VseSB0aGVpciBjdXN0 b21lcikgaGFzIGlzc3VlZCBhIFJPQSBmb3IgUDEgd2hpY2ggaXMgYSBzdWItDQogICAgICAgICAg cHJlZml4IG9mIFAwLCBhIHJvdXRlciB3aGljaCByZWNlaXZlcyB0aGUgUk9BIGZvciBQMCBiZWZv cmUgdGhhdA0KICAgICAgICAgIGZvciBQMSBpcyBsaWtlbHkgdG8gbWFyayBhIEJHUCBwcmVmaXgg UDEgaW52YWxpZC4gIFRoZXJlZm9yZSwgdGhlDQogICAgICAgICAgY2FjaGUgU0hPVUxEIGFubm91 bmNlIHRoZSBzdWItcHJlZml4IFAxIGJlZm9yZSB0aGUgY292ZXJpbmcgcHJlZml4DQogICAgICAg ICAgUDAuDQoNCiAgICBob3cgbXVjaCBkYXRhIHdvdWxkIGEgcm91dGVyIGhhdmUgdG8gYnVmZmVy IGFuZCBmb3IgaG93IGxvbmcgYW5kIHdpdGgNCiAgICB3aGF0IGVuZC1vZi1zZXNzaW9uIHRpbWVv dXQ/DQoNCiAgICBpZiB3ZSBub3cgdHJpZWQgdG8gcGxhY2UgYSByZWNlaXZlLWFsbC1iZWZvcmUt cHJvY2Vzc2luZyByZXF1aXJlbWVudCBvbg0KICAgIHJvdXRlcnMsIHdvdWxkIHRoZXJlIGJlIGVm ZmVjdHMgb24gb3RoZXIgUERVcyBhbmQgcmVxdWlyZW1lbnRzPw0KDQogICAgcmFuZHkNCg0K From nobody Fri Dec 3 11:09:16 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971D03A046A for ; Fri, 3 Dec 2021 11:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net 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 ELrV0GqSpwqk for ; Fri, 3 Dec 2021 11:09:11 -0800 (PST) Received: from sonic301-32.consmr.mail.ne1.yahoo.com (sonic301-32.consmr.mail.ne1.yahoo.com [66.163.184.201]) (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 A10DF3A045E for ; Fri, 3 Dec 2021 11:09:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1638558550; bh=A6Pwaz0SRNJqMMC5OAucRfdl8qqBlIBCqO8oQtabICs=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=XQbvMNELWlCxi2duYEGXqZdPste2FWlqCfmnVwDeiOXNOEiIBXJt9CYTGKa23N3p9yhE0rGTK9pIU+P8pRkOU7bsQLFhFccJ+Zs+R7LzY6H3Zgf01ywYp3sRmq+c3rOBp2Eo6f7bihAcOjLh6QLE4vI5vl3DVEPcptQCUuHls5kffY5gTnc+3xnH4CySdAnxwlMk3W7WmcEU2Fg0N2KmdwvO6zIawQtxoPROIxQ82goTxlAUgbFjQsBf5bbEQwEiz8lris35R5V0b+N0oMOt4MQn3DfOMp7PMoI8vaNSJwcYsRBMKXsAGcEsFNh332jHvnolH9bPqqYF5l809XkSUA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638558550; bh=LBm41yNtFWrK3KJef3VhF8qCZvCY/3daYwT2XHLRMYq=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=ryMR6ZLdF5WZW4RczQIjJvZfh5uMEU28oA65JpUK7H7wnITIsaMWq3BSi/zAOnRCQGrqCFC1kMyGNw9lQp0fAUjkgbwX2TvJf11adbrTXct3sAjG3BnlE2JVoZfiof16vPxlTD9mR5r2gF5YScXqS1RsNfc528Dfka/9FbHkS+ykTEYHRBYA2WwczXcYrn1sVuYyIHNmawYYALy4LrCDZsTMN8xkgFim0fwXvmUTxhLlybPpZvLcjqB3+XCDfQbp2Cn8kC5BDcmZSJqACWULhXEpIhU9UqSziq2lqX7Bdi6GufGN1qLANI8NdRh4V2d7PE8dkOoro7Elie7EEOnzUg== X-YMail-OSG: U_9e0p8VM1nLwtCKuVL59PIefdTt944_znoPiURlKtBOJpTFsd3miVxEqxPeC9x B_qr0xay0n6xyuxhclQhiB.QK18AX5KXxcrSDzY5ow_CWwlTqjINqu7R5kG5Ja_yVmsg_4Ydm3dO uCKmH49KjO0iGtb9wTzM1HCLODyjImJiQisTQ4UcC.ByHdorl2lUE34YyzxDVO1XI4NhNelQuJWk HY_RMlbM6asasU5Or8R.XydJSeTGiHDnrzt3XQSw0q7fs4eaDxGc.PWZO44OdvuFRHzNq2wajChC 17xqraIn4o_LKtgyHOkOv8BR.6I9erWbq4_YvXV0654c_atw_esNadiVfwVFMB_PmgYnkBY_dUox q7Zr1WFzlDC4Wv7DAnT6iGDTOUV40kxskeUlXGIVxFIyPxoA97wObg9hgMIyOTMv0kCGLMFJnoVx 6ZEkTByII.jgp.fPleOh5iw6mgAnoix9NBsdKUR_tyT7JanfblvuPligqcwjtlF9NaOqLUcS5e.x 04C_7XEM0hoihfMSIz2.zqcBOi_J6..4yPvnqlB76uXYW00VCtz3I3vM8zuf5TjQjAXsqH1JdyP3 mf0eYLCZ6CyzWTyk01bCuFbHqsQqgs0r17dk1F4d_E.6fRlEUBFy0YPeom6mOnrC.VC9ICAevK1Q R8.dT9JFlSw973TbAA8aLZoJ.7s.YRhbd_qkbXJW2p9uDVnOb76aYLx_xWXoS6VkhfHSzJZOnQG2 _8XNMMiY7.BZ2snRq_a8NlwA66mHJeM9sgx.AHNQzlS6Gr3_z7Oi8kC2BguCDNpLg4eDa8rdQSeY hO5xBfNccNLoQYlYyybyLr07YOJoFCi40S5V.xIHLkMtYPIZsaLMbTEfWfdsrUznGx6Ruv1Qyb5u TXX.t9BmI8STeUu8JyMVi7e2o0QN5gkT2AnWjelUcQLs3beaAoWtL9C6FQHRCYKTXADTNxdou4pG ..sbJlpNBd3w8AryuWteYtnpgrOa5WmgM9_s_r9MKyyNuxCyk3eCxAmQns2PExpoZyPHkLHPEZxW r44bichuY.NdDPHfgoY_Luf6qG3KBOKi2uFL_7svUw2C3e3rcFX_jRxa_XhEmHG9r1MvjSnaJbqA FYX.KfiWzNzpE5Re1d5hcK9.EOAB412c9O3a1L71OPjUHBhZsIeZ8VGzCp452nca4ZJntBJCj1Lc JOYRHZfHXkS0Yu6ImvpX1NB5SpYZq0AdKZ9e3iQ75wniU4Qf0sFODmlvfNXpMCMhpZ6GOfZDg9WU zeaGmaoyiJ.y5.BMS4_m6m5.N9fnksNwlr7YpUKWYdfWHMDT_36swplruULQMDPtC6RkIz_dZ6N4 OSxwrD799BzCKuI0J.WPEDyj9.WiSId4IBpHZT5KiNqzcn2pltpBxR8Klb.TGJIsJgVCugo5Awam t4u3O5GRJ0JLbzHqkjUTmI.axMpjOe4.xtU8lpjvQK6APUFBnL8N2nx7icW2SsfgdZSIGpY96b_8 Xo0DnteRB9kuHgQQ2vyp9NqArnWv2uJIzPFULfdUg5ngkJ8UMQJuF6cAEFhyRABGQO7CmAkmoai8 ygjUp7s8juD7aqtO5KAgZHLvtPukvbKXdOIWPQDa4qjZZbNBv_GZBGfHJwlEP6_deZ83nHL6s5AE oJMy7b6AmuH9SsqqPVP.w8ABVv0vc_YhknEijYyG0EZXhVJ44Y.zitOCkP2IBbt5wxqn2ctg49p7 6PezrQQUbOZvy8sZ2SCNXysBsp45Pwv2Pn5RLA8.y1n8ep0969n7YKA8a7NUPj16_ThLJy9ylnR4 NCqEariiAq2KzF8TmxkrrFlEra97DNztl5wj6k9B44vA4U.JyI37axV25dxk7tbJWvpVTyCmK7ow XUkacomB6GM5.gbESqUZXrpeQd1Xgi0jmhTciqBQrThm2Hy.u55LIMmkIO4VTyoV.CItTEi9g0D4 _dMi.u9QvrmZ43.SJXwoBpE867E_fMLLLqRmUIf_U3Ptd9rkrSUJ9XHWr65NA4RK4qUGQUiZBsIg p5XPfeCWvTr2oRd7ZEpno93DCsqWvNXz0EQWBrDyP1QqAj30RKU9uFMIA5k48xNtlxcihGNsuvx4 g4cWK.wuD7yE8hpI47lNENSFRDu5x4o7lHuB0etT8WB05XI7Fv1OXoAKtt7KCMoiaeumNCEnHUIY j.xuQr7hnZv4sQsbi41iSPAiHZ0GEIEmPc62nBBRQI7NZsT.xP.JJxJOxIxX79yOWL2se8lkOkex ruYJk X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Fri, 3 Dec 2021 19:09:10 +0000 Received: by kubenode527.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b00a38f6542a659d3ac7cf15ca338367; Fri, 03 Dec 2021 19:09:07 +0000 (UTC) Message-ID: <38644b23-a0ff-d444-d937-ec6444c2f6ea@verizon.net> Date: Fri, 3 Dec 2021 14:09:06 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Geoff Huston Cc: "sidrops@ietf.org" References: <87v906j2cm.wl-morrowc@ops-netman.net> <1F30B4DD-F34A-40C2-89C4-6F84D7F83291@apnic.net> <6EBB2980-1315-4C14-8FBC-68368B91BBC9@apnic.net> From: Stephen Kent In-Reply-To: <6EBB2980-1315-4C14-8FBC-68368B91BBC9@apnic.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.19306 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-rpki-has-no-identity - ENDS 12/16/2021 (Dec 16 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 19:09:15 -0000 Geoff, > ... >> In the historical context, an RPKI cert would be viewed as a "capability" conferring authorization to the holder of the private key associated with the public key in the cert, irrespective of the identity of that private key holder. In the RPKI, an RP makes decisions about the validity of assertions about INR holdings based on this characteristic of the RPKI cert. >> >> This is in stark contrast to the Web PKI, where CAs assert that the name embedded in a cert is the identity of the private key holder. > Opinions differ as to the precise intent of a domain name certificate, but that is perhaps a horse (?) of a different colour in the context of this discussion. CABF requirements make it very clear that accurate identification of the Subject Name, or Subject Alt Name in a cert is the primary focus of Web PKI certs. > >> RPs in that context make value judgements about "trusting" a specified web site, based in large part on the asserted identity. >> >> because of this very significant difference, I think it';s appropriate to document the difference for users of the RPKI, who will, in general, be tempted to think about certs in the context of the Web PKI, with which they are more familiar. > I don't think we differ here Steve, aside from my discomfort about the draft leaving a bunch of things that are unsaid, and my previously tated desire to see a document be way more explicit and well defined. I am not an author of the ID in question, and I am not interested in editing that document; I just wanted to note that identification is NOT a "feature" of the RPKI, which is consistent with the name of the ID. Steve From nobody Fri Dec 3 11:13:28 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7513A058F for ; Fri, 3 Dec 2021 11:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net 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 Y_8spRp0zpyh for ; Fri, 3 Dec 2021 11:13:24 -0800 (PST) Received: from sonic304-22.consmr.mail.ne1.yahoo.com (sonic304-22.consmr.mail.ne1.yahoo.com [66.163.191.148]) (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 740F23A0542 for ; Fri, 3 Dec 2021 11:13:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1638558801; bh=BwOUdf/rINQI/m0pjCoPIZ9C8Tk4BegVarD4UqcipLc=; h=Date:Subject:To:References:From:In-Reply-To:From:Subject:Reply-To; b=Po12u+HuGMBVtPS+tB6FjZGKEVecb9sSR13WzVekI6QUnCevU0SUGGAc/H1ajdSqnuyIiop2+1uMJqqJZ43jqu1zeYcS/HHLqodgVTTcoMdJb4aq8trr8kA/fGPsAEjLbcVfYwQFuvh3CQGPc2YzZSwksdr4Y+9g5B/9kituMTbeMYlPQZzfUbfImHaYciyL5HHGEJInGENi2m8auP7gff8+RmoH+8o3wxryH91fKW4aQGZKR4J2ydi1Th3HTbpeFNHVhegfUalPqVzoEZ9YbMQf9ufO6bqV4OuqA/CGcr7HYchk7r9ASMNtTEeeFxrKD1P3aJXR9emXveYE8j+bKg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638558801; bh=9DK4LSTtG55QTJ3RHL4ANIis5SltmfQMYMiO2j5K0am=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=eDOKsYwce3Pbh+zzBgkE9FEPNMFB0KOjNpAndFx/kCV2Uaq1Ks0A0YX0Q7zGIhypV7RNnM/dFJKAdPq9GimO/QnNcbzYE6eRMiq/AANK6Uo4qao+7/TXDMXpu2X+8Xy1YmdKVy1y2g5u8FBj6CxGzGi+WzaML7Q37nRQjp4oM6iUlJi0ZKOvjv9KsPrTdJOHgub6V3plQZREaV1yV5w5lOdchHx9Dk2ESMClphKMYXy9usHx69gnZjxR2i2OpN3zivICj/CQ0oVE31UPrIVfVFyQtmO8cdGVi/k8UGB7WTdErOCSB4rDohc9agsYb7X/2u5zou2TD7amQ5IyWj7VcA== X-YMail-OSG: IN0rLvoVM1njqzqws33oMAENG2udDxPB.EB.MMQMFp2UZjNKgCgF0Sai3W8qd2d _Y43DboH.L9dZCKP_xwocREXTFfWFZpgE5g4I5DhrJ1ZKk9eWx_uyouqYCXUj5K8zI0WbxpVodFU nL3mWwpVieeoJZeUEnJyon8BV51ZTqYPjIJPsD12ySVklszCOXMTV6GsxX6XPrNldvcLenEPNn1c mTeo5c_okpHPKTbXPPYBbPHWQuE9OvucgTYjQtgK8HCGFatikke4tmmnmoGaN3qtkJO69uuQU2n_ tn9XQmgbDJJGsrnP4hEmcw8zmKQvk2PuxgwZXGIC0zI_N6ptnNZuSDl0YSQe7.Nj6KDNZvFJVsHF V1.9CifnyPp3N5s2y4QfclL0UEwAdfTd4vtExCDu1iNEmar8m9mfywDa.PIt7jM9YQFg8pma7cB7 Cx9MQIaMvo7i5dlNYDZnMcH2xB9wEb7V6QKVhw8tmD2ZZPWEOyEn3mXaLbQMlRTNlPINfGDat7p0 Dz0DIfzEzszdC6hfrZcqUn9Y6zRkzRN6L3u_fsHKHkXCgFUvuzNQPSLNbTwVFIZFldfbQBQoAr5C ucYTBq8atPGuCGgw4nrueO858J57kza0Oz2d0GRogAVJyi5ZSb93JZWdEwiHIKJlkO8RNglRTOLA YvEGx_QgcPri5GPoIXYC9ecs5ZEw0UN7G9RBHRftpD42JxTWlxwFh_D9wdQxSXGxnYtI.lSksjl9 yCJfOlichncyp3maKunBTYNt70YpUp17iIsRKaBsV_4idN0ju4ZrTKG3oeYnFWnxc6ld68dkaDRx 0o_xvGsEGUtOyY4ca4oD.HOQpoVW_R3S9svbV.b8uEbMqIb7y0xumSlj5Gv20KSwiGZySOySe0v1 zro.jB94jomJq5MMiK.HbJ5kJ60QA52iL6l5Iwqn9PU68lJB2mrxLAAKbYx6HvO0KY5hHh2N3hGA cZPtW1.yx27CT75VT7IJxdoPBvf1E39SMh8n5dBMUzhHFoZMneLXUcoPt9KS7xzWSsQG2lJYN26t OIwj0Vueh6Ppvheain7nyoSacGxsrXVME4u972mIY48l1TzaEwQ.MY6BmD6DsTt_LXUkAGwT.LEo TQo23uDHIqlf2mNDai8epaVojmun1fG5SNJY4C4nhmdjoN0dkr9qix_c0zBWlo9XYjVqcAQyhBy7 gR031fZtgR_.r8V2IDPBWZc_Tlco5yoPj4bH7Q_jrm4qcp2TLe46W8Y1V44cXVvXHpp4zYkgdQVK Dd5yl5AHux.OUJ4lcb6fMm1hibguwFyGtOpPW8LExGB.dnjUHETAZIxkUJjCgPf4vV96VcNyV7Lk aQpOhHPklKEmbbqxtafOBv4.FRC4m1TQx7c7bjpf7_SEpBIEsFFBkzPCteuviVhBX_42ATCX6GIV GZBuYimwwKWgd24YZz9.JTHxgD_u8zCLbXyXqZhjtaA67xMWqg8wY6MZcUGO.G3DhZ63bJgNDNtd CEhTL2beb0TdXoXmLVEwZawpNX8baN6i4kSWpVndmrGDgOYzenjbho1UoRuJZJ9YDfkUWbskAcGe xpnWcFg90eqwo8nCA.npBEcJyuPSRAgr6lqnwhSLlPE6mOTqn7PlpUnBSGZmQt3q2YsrTVfknuFg Ge2CLl7reuGU65Ex3ex38Ry1zQmOIvjftHmA4TUxjZdL05bdd_xsl6BVEueRstF6kbtEpAvXI7_E 9KwjFpHmHVxegFrFZAoWSv0Pk3Pz_UX4J3R4Gen47CYpjR.L3ZLCWKqdcBo2pmxdnNiSnx3eeWWW 44WOcGAhAm.aTThJgKjVqIiWNEyte9t3MIU1h7JH_OjXIi69Iw6NjD_0KjMFT4mUbvPRLK9vEu.0 EoE0fpe3wV.Cv.rep6LLki2vMMjbvzImN.n0gKRpDw3_VVZ.rvjURJ8CAO8B40.vLoP5zm.Shvhi tnkLzVTyaH_EuVipmeKkEq.ZDpoyEXrGD3qZwJcAwVW.L_K_gONFMA06jHFEtBzLO6GwNA26R9bH PIi9YlPywf796QF0CKiCGJ4ja1H7ccwwCmM9E8IdM2i_W8joRyxpOUd6iurqBW6sBjPlRvJ8fOQu 3ivv6g7sbJKGRWShZCMSiUwSH1CnhKaR56MloTEma2wA4haUyPGir2a5t8ldOW5KIKTgLRm_2chI _TzhfgeiImaqavbJ_rvbkbfgWda53DYmFXJXctG1goJ7SKsh4JWVryqkBb4faWfiMeA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ne1.yahoo.com with HTTP; Fri, 3 Dec 2021 19:13:21 +0000 Received: by kubenode542.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d793896fd69f838b5456a5c77b5dc00a; Fri, 03 Dec 2021 19:13:20 +0000 (UTC) Message-ID: Date: Fri, 3 Dec 2021 14:13:18 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: sidrops@ietf.org References: <87v906j2cm.wl-morrowc@ops-netman.net> <1F30B4DD-F34A-40C2-89C4-6F84D7F83291@apnic.net> <0E6ED68D-46F0-4303-8FF4-1932847E43DC@vigilsec.com> From: Stephen Kent In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: WebService/1.1.19306 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-rpki-has-no-identity - ENDS 12/16/2021 (Dec 16 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 19:13:27 -0000 Geoff, > Hi Russ, > > My point was that the text is handwaving and imprecise. > > Even your text that says that I don't intend to say that "it is appropriate for the private key associated with an RPKI certificate to sign a legal document or an email message” seems to me to be lacking in precision. Yes I can use te same private key for a whole bunch of different uses, Using the same private key in conjunction for different purposes, e.g., with different certs is a bad idea, just like reusing a password for different accounts. It also might violate the CPs under which the certs were issued. > but I think what you mean is that the PKI that is being used to validate a particular use of the key provides a context of valid use. It's not the key per se you are referring to, but the terms and conditions where a CA was willing to issue a certificate for this key that defines its scope of use. If I used the same private key to generate a CSR from my government for some identity certificate as I had used to certify some resources under the RPKI. as noted above, re-use of a key pair for different contexts would, in most cases, be a bad idea. Steve From nobody Fri Dec 3 11:13:39 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA813A0657 for ; Fri, 3 Dec 2021 11:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.net 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 vp6pJLR0pmjF for ; Fri, 3 Dec 2021 11:13:29 -0800 (PST) Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01on20603.outbound.protection.outlook.com [IPv6:2a01:111:f403:7004::603]) (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 7557B3A05F0 for ; Fri, 3 Dec 2021 11:13:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YU3iXxf+VrfGdvRrDEXuG1jZy5QmSETKiIbj4I1iuTlNmdJvZSAvbSsLJP9KzVGvHDI8Noc4eiqOqFvrEv1bniugA/Hol6F0Cv17HU0NuvH/VE3+kCl18TgYFQzETfjq6mUgEKrVvnBLQXyw6g/VHOb3XKDGhwSI7aYg/UlNGbLEsuX8NzHgp9kusrvU16vYpRfY4PgmUS8ndi3liLogVGoc+NSfK+m+sPPZP3tJlF0rV8TuPoLilPjjoPhAKEZWHUV0FaIjjG46GrH5dAlBxJkj4+hDeSEWQK5KPPSoXQoO32brWSJ0d72q5I/VkP95OboEvMOJGBXBj7oJBA9IGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3u5trKGYcvZKe1yGeDnhMaDhoUjIxh4cQUlUQsH2+1g=; b=dLqT3pqQrzw2qMoYEkmw+iLvLK6g8Bdi6qBkzBF2knIE9V08W+MMf43OCfcHdzZy8MD6vjrtFiyFUX8tVTpjWg8VbgDwCs/3qKt0NWxK3wqqJh+49MMtjuWkyyx2es3FmRDCG+O/xk5J0Dk0S+iQ1Z0fdlzuKnMMcw+HKt5XwpGUPEWswsLV6pMhYSBoVWatoo5DjUfrZRdo0g5iaPfpSa8z+7AwoRfqZPHNoCwkMp/q/rhkU2nAR3bvSrFW8v1IafoVvPUYhwTMBaBku4XwwJjyeIUR7t7vJxXIdveZ+MkO0r8GslHV/VpDDEtWksqIvmVd0bL6w5MuMCOgbwREhg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=apnic.net; dmarc=pass action=none header.from=apnic.net; dkim=pass header.d=apnic.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3u5trKGYcvZKe1yGeDnhMaDhoUjIxh4cQUlUQsH2+1g=; b=F6PVXMx+y/QivpMeRyzUEZ/Aw6QzzjWZLo4AzAP2LNBVx2M+mph6vUW+k/y9TmtI1biPMnaiEq0TnlTLP9XXuotkH7qL/GRCTWrx7zIb2XW3ouAkSQ3nW+RdPhzWYPRsFGzq20jrakEJFs4LPaZOalbWpTATTracISqB1nRnxtY= Received: from SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:176::18) by SY4P282MB2951.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:15e::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.22; Fri, 3 Dec 2021 19:13:23 +0000 Received: from SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM ([fe80::c834:8e45:135b:15d6]) by SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM ([fe80::c834:8e45:135b:15d6%6]) with mapi id 15.20.4713.031; Fri, 3 Dec 2021 19:13:23 +0000 From: Geoff Huston To: Randy Bush CC: SIDR Operations WG Thread-Topic: [Sidrops] WGLC - draft-ietf-sidrops-rpki-has-no-identity - ENDS 12/16/2021 (Dec 16 2021) Thread-Index: AQHX56lIek54tNT0FU60UhtchksHS6wfoFmAgAAK+4CAAERnAIABCxWAgAApigA= Date: Fri, 3 Dec 2021 19:13:23 +0000 Message-ID: <4C8C61D1-DDB0-4CDE-814F-3DB79CEFE3A6@apnic.net> References: <87v906j2cm.wl-morrowc@ops-netman.net> <1F30B4DD-F34A-40C2-89C4-6F84D7F83291@apnic.net> <0E6ED68D-46F0-4303-8FF4-1932847E43DC@vigilsec.com> In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3693.20.0.1.32) authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=apnic.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 127c3111-cdd3-4d65-e80e-08d9b690f9ec x-ms-traffictypediagnostic: SY4P282MB2951: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sjVBmamzEITPtTBBfRtAS6A5yDgbKgISGvhpbjvDiz28OtBCUHtXVxJB2rLsnrSTth3pqCVVo9HneLONIWVSbL6zoyoRd9zY5s0ob68DS1/DTAi1dlvXz0NRq1clVd5tPCHMxYv30bbgyZmIwhvQhSz2TZexhMOEYPl8nZm7YCnkgLBV8dlnRLlHg/aI2W38DiKFxjvvDrtsru7qaXWj7zgyMb5zypHvBgdAagD9jJwzx9Fzu8fdnouhAaYKE+JE+90BrcDx10hgXFButiUgzj5AlmBzBzb2fVSpV1nE9SMgW1FB5ZOYmMTBgkdr3S20lwhgoCVhDbAu1xtKUmfpWmYu4bHKO9OVSRTbnKxv8p212Qwj+nPwZWbaCbkLxcVfk8VeirkfBqvFPqxrGgJI2fj1GkKYy1lwgGrax6GD1J+dUjyUkU4ARR0N+WAcOplmTk1W656amgP/P8A3yVjsLV4gDmh7ikQYY/hzFPJ4WptXBd8WdQtJ2EItU5m+7GMh57rN91O71wiJlKJ3B+VOVFoRi5qOomtBwiBT7kPlWMjlKIl3Yac+mxrZMW2YXiGGQzoMdqNQpnnSDwL67HqXGlYqQbh2S/hpurWW9r4IBWttfUjpF30CIFzMvK+Fio/M+4ewPvVlbx4vvQAa1UDeatT36L7tznoAnIFJVbWsU+QNpgAplSb1wVPpPYnZOfE34Ezai828DklMMn01yC+4dSwa+oOOi9YTKwT4lx0pLSR9+PckGyzlluEx1tznW5aD x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(39840400004)(366004)(396003)(376002)(2616005)(36756003)(66556008)(33656002)(6506007)(83380400001)(186003)(6486002)(53546011)(316002)(5660300002)(66476007)(122000001)(2906002)(71200400001)(4744005)(66446008)(508600001)(64756008)(66946007)(6916009)(8936002)(8676002)(38070700005)(76116006)(4326008)(6512007)(38100700002)(86362001)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NGZOMURoQ1JsbUpRbXU1dU84bTdvZk91MUJmMm92R1JtTEtLL1huYmQwWndl?= =?utf-8?B?L2RDZnFCRktSUmxLNGhNaXdMc3VGYVJnRUNlTzlzbjVEUCtBYUpsSkRUTUpK?= =?utf-8?B?UFNiYVdqK3JUdUNWTW5wZmVLOFhtWnBuT2hEc0YxTG1MNTVRYnBGc3lxNDBk?= =?utf-8?B?ODVEVjNWeGhLZ3JzQVZ3QTNZcXJVSnNkNExBaHM3Mnk2dzlRQiszclg2OWF2?= =?utf-8?B?RWFuMTFKeEQzWFVNaFBMZ3k0QjdWQnByRUhYNEZMb0JlSDhyN1h6NDhiM3Rp?= =?utf-8?B?OVA3TWZHcnZCdXIvaExqb3hITHBKSVBIM2pKZkVHZnZYKzV0R0Q2TXRIQTVY?= =?utf-8?B?ekpDc3MxZHBWK0loay8xbC9QWjFuWTZpZ043WnVndGhZSHl0TlgxSWc2UGMz?= =?utf-8?B?QWRmTENwYjZnRkdZWkQzMDBMY1RXM3RLUTFwaFRHR0tDc1JJZEFrM0toMHgv?= =?utf-8?B?Vm5wMVp1Q3F2UWE4RUJ2ejE0ZDRZVkZtUWFoTlBqYm53dnpZRXJWQmNQN3o4?= =?utf-8?B?cXh6Ri9teFpMQkVhZzNZbXQwMEh0Y21pajg0dlMxSFlBdVp5VzlJaUFpdGNj?= =?utf-8?B?UFBFZk55VklPV1JoT1dTN1IxMTZoMFJkbjFEL1BuZlB0eWN6ZGZIdEpZSXli?= =?utf-8?B?K3VzZHlXQTdjSHhpRnUzN2E5SW5uODQrY1liTHNkZ2xCZW0wVmhyOTFjMnRi?= =?utf-8?B?VHdTQmpZa1RYMmM4T0VlSXg4V1B1cTRCUXYwREI3K01ybW9KSU5aL3FObzcx?= =?utf-8?B?b1pwRUZiZEVVbjdjeDlDSlQ2Mjk2QTNYWmphR0VteS8yWUVtUXYyK0thaGVD?= =?utf-8?B?UnBXcE9UN0VwK2E2dUxmSW14dFNWbzNoYXQxVENMZjZSZ2NpR0g1M1JnYkRJ?= =?utf-8?B?V2xDLytUOFBvNCtXbGthQTJteUgvM0ZhT01sSnZRZVFKdXpiUGIxZlVadFFs?= =?utf-8?B?M29JejdiaG5OTXM3VXpvbEhGNXpFS0tKWTh3U0dvV2VXeStkT3p2TG9jSkFZ?= =?utf-8?B?aUtPSm8rOXFvdzMwMXJEM2l1a040M2JoejJseGcyckxWdmhYT08rcXZYdHhL?= =?utf-8?B?U09VVG5CZGc3UTJaODQ2SXNVWjYvc1pHM1RhR2U0N2Q4eGVNcktEcG1WMXJy?= =?utf-8?B?N255Nm1LaWdrUy84WlU1bndHc1JiVncvbngrdVZmY21yWXlsVlNxd1R2WFNU?= =?utf-8?B?R04xVDhVRmxFTWtFcFg1Y0NuTTF5RlJZSWYrSndoVnZTaWpGOGFwNmZjWjVJ?= =?utf-8?B?aHZqS2M2b0FudGQ3eGdiS2NhRWRFR283VWxrZHFkOTJPRVlZcGZvczM1YzVM?= =?utf-8?B?eWlGdDIrSmxwZHFERXhtVm43V0dEY1FLQSs3RjZlVVdoaFREMG84MVJSY3Nx?= =?utf-8?B?NTdVdjUxUFFaeVFVSjBaYm1aay8xNDBjY0JMR1FDL0p3UmVlWHp1L1Rnd1c3?= =?utf-8?B?QjFNbjkzYnY2aGd4RVo2SmdpV1dkMmZNNCtnc0svT09PTnJRRUpleGhzMGow?= =?utf-8?B?dlB6ZzBUbVFZQmY1aThnenlkNE53emxZV1ZmR2dZZVQ2ai92VUNUOVpSdStW?= =?utf-8?B?akR0Vm85Vy9TeEovT082c0YyTjNrU3dCN3pab0c5cEgydWVtd3ZrUlU3N0U0?= =?utf-8?B?M1pvVDB0Wm5DeGpsdElGVGYvWU94VkpQWTltR0lJSG9UdEdSNHFWWmRhNzVj?= =?utf-8?B?cFg0bUxCOVNZQnYySk5xa3RVMDI4aFNic09VRkFXZW1Rekx4dzZ2SVB3U1Nt?= =?utf-8?B?bDFtbEFrQ2M3SkRjbThHeHJ5VmdjRW8vWVdZOVpHNnd4RUZTNkI4czU3TXJ5?= =?utf-8?B?RWZNNFpmZi9kdWNMdUg5WEF3eFpvdklwTVJzVWEvM3U1d0NUSk1hM2RjT1NS?= =?utf-8?B?Y2tvTitTR2xpdHdEU0pNL1BuTFJvOGgwYTVIRGNvSzV2K0VqTTF5MmF6L2dP?= =?utf-8?B?ZVY4WHBtTS9VK3FzS1ZGUzkyd1R0Uzl6bm5ob0RPZWh6ZTNDQ01KbGdQNnJY?= =?utf-8?B?SmFzemxjRVhhdHBmRHIxNEFUQ0djVnRkZmczYkY0QTRyallwdWg3YVU0SGpD?= =?utf-8?B?Q21MeDBTbEN1QWs3bmkxRnk4MFhlZXZIbTlNaUpnTDN5YnhQY2tla1QrZzk4?= =?utf-8?B?NWNEaXpGVUFuR2dONnRrMVZ2dUY1YWtrVmYrWGRyZ0NmSWlmMXQzOG00OXZT?= =?utf-8?Q?r5/CUTcuLZfRnfwxMQ9outMRx+X927JxFF6sFIPxGIFS?= Content-Type: text/plain; charset="utf-8" Content-ID: <1E6DD6CF1102374E98A3A1CC41EF0BD8@AUSP282.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 127c3111-cdd3-4d65-e80e-08d9b690f9ec X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2021 19:13:23.3059 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: AWT/7+c5tcg6ZS5E0OCZ/tgGn8jSDoBhQ2TgqIkrMK1nl1mxyuQZJH0657EPbfFD X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY4P282MB2951 Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-rpki-has-no-identity - ENDS 12/16/2021 (Dec 16 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 19:13:38 -0000 DQoNCj4gT24gNCBEZWMgMjAyMSwgYXQgMzo0NCBhbSwgUmFuZHkgQnVzaCA8cmFuZHlAcHNnLmNv bT4gd3JvdGU6DQo+IA0KPj4gTXkgcG9pbnQgd2FzIHRoYXQgdGhlIHRleHQgaXMgaGFuZHdhdmlu ZyBhbmQgaW1wcmVjaXNlLg0KPiANCj4gYXMgb3VyIG5sbmV0IGZyaWVuZHMgZGVtb25zdHJhdGVk LCBhbnkgdGV4dCBjYW4gYmUgbWlzY29uc3RydWVkLiAgc28gaQ0KPiBubyBsb25nZXIgcHV0IGEg bG90IG9mIGVmZm9ydCBpbnRvIHByZXZlbnRpbmcgbWlzY29uc3RydWN0aW9uLg0KPiANCj4gYnV0 IGkgd2FzIGhvcGluZyB5b3UsIGhhdmluZyBzbyBhZ2dyZXNzaXZlbHkgYXJndWVkIGZvciB0aGUg cnBraSBub3QNCj4gcHJvdmlkaW5nIGlkZW50aXR5IChhbmQgd2UgZGlkIG5vdCBkaXNhZ3JlZSks IG1pZ2h0IGhhdmUgc29tZSBzaW1wbGUNCj4gdGV4dCB0byBwcm9wb3NlLg0KPiANCg0KYWggeWVz LCB0aGF04oCZcyBwYXJ0IHR3byBvZiB0aGUgcHJvY2Vzcy4gRmlyc3QgcHV0IHVwIGEgaGFuZCB0 byBvZmZlciB0aGUgb3BpbmlvbiB0aGF0IGl0IGlzIG5vdCByZWFkeSBhbmQgd2h5IGFuZCB0aGVu IHNlY29uZGx5IHN1Z2dlc3QgdGV4dCB0byByZXNvbHZlIHRoZSBwb2ludHMuIFlvdSBoYXZlIGNh dWdodCBtZSBiZXR3ZWVuIHRoZXNlIHR3byBzdGVwcyENCg0KR2VvZmYNCg0KDQo= From nobody Fri Dec 3 11:20:31 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A833A0659 for ; Fri, 3 Dec 2021 11:20:29 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4x0e8FETGhyK for ; Fri, 3 Dec 2021 11:20:28 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 CDAD23A0658 for ; Fri, 3 Dec 2021 11:20:28 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mtE6b-0000Pd-Cj; Fri, 03 Dec 2021 19:20:25 +0000 Date: Fri, 03 Dec 2021 11:20:24 -0800 Message-ID: From: Randy Bush To: Geoff Huston Cc: SIDR Operations WG In-Reply-To: <4C8C61D1-DDB0-4CDE-814F-3DB79CEFE3A6@apnic.net> References: <87v906j2cm.wl-morrowc@ops-netman.net> <1F30B4DD-F34A-40C2-89C4-6F84D7F83291@apnic.net> <0E6ED68D-46F0-4303-8FF4-1932847E43DC@vigilsec.com> <4C8C61D1-DDB0-4CDE-814F-3DB79CEFE3A6@apnic.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-rpki-has-no-identity - ENDS 12/16/2021 (Dec 16 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 19:20:30 -0000 > ah yes, that=A2s part two of the process. First put up a hand to offer > the opinion that it is not ready and why and then secondly suggest > text to resolve the points. You have caught me between these two > steps! :) glad to work with you on text. maybe out of band, as folk may not be interested in our usual tussle about over terseness vs verbosity :) randy From nobody Fri Dec 3 11:23:17 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F29B3A0687; Fri, 3 Dec 2021 11:23:16 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umFaLGfimgIj; Fri, 3 Dec 2021 11:23:14 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 D9A2E3A0688; Fri, 3 Dec 2021 11:23:14 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mtE9H-0000QI-Fk; Fri, 03 Dec 2021 19:23:11 +0000 Date: Fri, 03 Dec 2021 11:23:10 -0800 Message-ID: From: Randy Bush To: Stephen Kent Cc: sidrops@ietf.org In-Reply-To: References: <87v906j2cm.wl-morrowc@ops-netman.net> <1F30B4DD-F34A-40C2-89C4-6F84D7F83291@apnic.net> <0E6ED68D-46F0-4303-8FF4-1932847E43DC@vigilsec.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-2022-JP Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-rpki-has-no-identity - ENDS 12/16/2021 (Dec 16 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 19:23:16 -0000 >> Even your text that says that I don't intend to say that "it is >> appropriate for the private key associated with an RPKI certificate >> to sign a legal document or an email message$B!I(B seems to me to be >> lacking in precision. Yes I can use te same private key for a whole >> bunch of different uses, > > Using the same private key in conjunction for different purposes, > e.g., with different certs is a bad idea, just like reusing a password > for different accounts. It also might violate the CPs under which the > certs were issued. giving geoff the benefit of doubt, i assume he will generate per-purpose signing certs randy From nobody Fri Dec 3 11:23:41 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70553A073D for ; Fri, 3 Dec 2021 11:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net 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 nV4oEfuGTQ58 for ; Fri, 3 Dec 2021 11:23:36 -0800 (PST) Received: from sonic301-32.consmr.mail.ne1.yahoo.com (sonic301-32.consmr.mail.ne1.yahoo.com [66.163.184.201]) (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 68E9D3A0687 for ; Fri, 3 Dec 2021 11:23:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1638559415; bh=sQAChyoFYLBXG1yqbweLVATj2uNGekZKftmYxYFm7Cc=; h=Date:Subject:To:References:From:In-Reply-To:From:Subject:Reply-To; b=P+MTsQpCyYwJnazShIp1Vg0cATUf+zlgnN3LwFkdogWnW9AzIrb9mY/EB8fMa1bxSAuJkE/RDGMPmJmYWOj5uGOqhFbi3gKUag17OarWx1Jrl2cPTnb2K2Sz7kfQZ6H9PvbMa00D3uylLfgp9Nt6Hc9OdXWvQsPnfzTLo0KSTCgdeZCPKh33tslHEa75aB3Gn+6Z1WUkpEsqF+L2qjiSvk4tP54MEbOPSYrqq+ag+Dj1PeM21au9esMk+Ml8/F5SNfsGm8SesPB4a9qk/nUuLdXlMu3peEBcCxe3gZI371hwFT2ob9ItXIk0rMSUO4VUPaOjinCIWVyYAw2jp9fj5A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638559415; bh=3RhmUU1pXZLIGESf0VJBo7yofXlQgGvqIk4Utd6k0gY=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=KQ7H8q+FDQT3NipufPfiBLSodADX3PWgZxayhOLQu66tKkavXXW/KNzj7QHFKUzU3QNlKj/cPi2/LUE9YXTDmzNLKNL1Kj6rbsjBu6jwQ3ruhVJ2CJqHyY+IsCpAWxRvnRf4NroyyGDmcp6/N7pA2UvdkoxZJZnKglNg6odWF9Ep5k9AI8S88lQ3MRGwdnjCzeTTnP5fXux25PCVySyxF2yDgvA8oqyWFU/Fkit8gYeuUGl2+5H8oHXmiLX9stQqJNvs5HtsnfTMsohyabnT5mn1qsohczhRKu3p4oDquQ5Uc7gZLQ4PZtly7mwz4W7w+MYmE2y1RUt/XceJJZxKVg== X-YMail-OSG: kzjl0DsVM1nkl5Mj_o34DThQBjF5vMCthmKgG9sT5WjzyuJ5P6XKFQi65gm1UaN Z6k0zw9lISqgnQE5AIZaBuxTL7jmrCkkbZNn8s4.B3KRibrNOlT8_B7m8B2YSTXhj_QPYVhf0ceX Li6shGOWzvokg3pIQ1TcqqNQWy73Tqk4t_Hl9WU49csYBb8NvLEHCVA5aDSaZjEgTXL8sfW4HEXX QItzgTJuFxb6qtGoF85kzBIDHMZZDyO9K.0SRO6LrcblEWmTcTfM6e5V1zk63Y90zKHH8nKgSdNe XBvIKvtxuWgvlac9SJIc8qsWc3UA.SWZPMlor4hlXQgOcKO_rTOCSuwvpnQSoOYDZNYC7BjUJB_Y fNMd.g9kw.hyaEWvKtRwmVssd5D4TCZtF0Yiovn6cc0Ahwk0w8cpkjKsdlq2D_NOmJzrMlTzn89O OMZwyOdEeliwwdsPIOkAOwOmVRU_1Lk6ljNuVd0FDMJdpJlejD4jYrjnm9BtFZsW7tWjRHK1ElWo l2vh9TOUo3tKBbMO6pkx1d3nrdgbv7UQNWGWoXAYd3UGbH2ra8RRPzs4aUa2kD5kwE.bXbbixKWi qGgRknq2JwXJIvdIV_gd_nYDJ09ptofuOQEblK49Xa0sAWB_sehb6L92HFkYCuo2unbzgkvIuKDK gqTq74f_sYrRNW1fJL5xHC_ONxMWIcOOy2uGBpkVSa7HIx3jZVjCeGbN2PnbgekHW0F8Toj8TmdP HLih1GSp9p2IoTEPKgeI611l9JZizi3LU_yi8pcQ9Zwmg2hoa.roszL.VCLMZGPSETYBRRDkzx37 hxwnEZ4MecX3ZsA.c1K.1U6azs3mj0xBYk0NkkrCqsH0xVIZsGVKutVhgQOq5PSWPN4VkSQmCp35 3aP6dKGjZ5jbGmCvmul9fiVd7bfagq8SCux9xyM2M4DLm9Kni.OiCn7BEB8fFE.e1qXifDA5Q7oJ p8OZhQ_aXeo4ACz2DFuk276VVApQYfY1VpECfXx8_ZgyGRyCWRTJrlMj8QJ.kAKXM6B_gAFlK81N GkmSl_gMlQJQAy83O.V61XdP15jQ5lbIgcUJ43votnBRvDk9zg7EQDbA2VOcr4l123w3FwpmbBp8 RpRlPAH_A8oxkq2D4Ec5DDiXpUmjE7IHUuNBcGfUe8CNJGqnuWDVFBd6nHCAj6Dtsbutf.xNKryU aZ4.9CvMBAg19DfCf_xc.NDV1Ql..SRNKoMvgbWJGan5sgn5vkke4zeuhW7w0gPDuYrUg9rCZTVG 4tRC2pyMwY7qTfjOc.Av27gGpxyngAgBb9cThmadBFXk1Vym5xpPwditEH8vMTkQFVelNuIPSea0 n3KXnNkOLBXNtwOUJEied_n0ou32YN8QJPMSzS0WtOdFy_fhJAKPnOgRH7bqIV_zcBY6O9njxcm5 bmdBpbuHtuO8r5OjxRA6MzKjyiky71I6wBRKWxhEqbFZ2XrK1IAO2sMgR23HmhMmxEXglZQS_Yak q6niTVt0uhvIJE.qmb3ZTFBTLdTAPcX92KV3LqcHVf9gWEap3oYjrqASrArFbaHIxXp4lJGpL7rB FCyL_sfOgrqH7XymJo.BaipSvfOiD4NOO_.lsnXDnoYCMwqhvv6mOlvWrcBGLWr8ZIRKNspCuTTV 6OhsS_Yzw7MamXV0R._zP9vFaKuQvBZyltKegdWyaLrpc8vG9oAYNQMzGAPlJZxHs2SgRcy1iGpC dkFDtcKLf.2l_E4TPP4gANA6SiLmpLH47y18iAhVBUZgziACV7m0lxLqabUoCylVHS0Dm7FxKar5 Ilb7GPUYTtTitiYVGSH5cpKGJdpSWFanp.sO486eLa.QQwJYLSV_PB2Bbh3ppxUBQ4WajRxx9w2P zEDABDW39cCPwsbk01h4mNCf.fQvqB.Cn5CblMopT7qoajxFzN2erzWe2XFwjzI0g0ya8GRK4sWm GYYfXr.nfEu71B2epHaR20OUryq8RYuvliiSJZvAs49xEMRZspEKRFgMeR5yduEPfqQrRCO6aHA1 nUawDPiiRj0m4IY4i3yaYsoqgenSsaWRvsCvOuOB_MTGdKcfXXX5VSR4m_1aVYdC.tKJvrBTK0tL 3vIXRb314Z2oadL_gPjHg.iLNCwbJkKfHL_DhHh6IM39bHZ6Q85YCIBXdInXphjzGAKU2mlIivNs wF.PyoDxUzs4UU73P9JkYzpvqh3Zpdwe23zji6WwFgP_rvtByRTIpAjx7MXyayOuNd7U- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Fri, 3 Dec 2021 19:23:35 +0000 Received: by kubenode512.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9e2984ac4de77664f95368c33a5b4668; Fri, 03 Dec 2021 19:23:30 +0000 (UTC) Message-ID: <8d9b693c-137d-4a76-9fef-65968bb5062e@verizon.net> Date: Fri, 3 Dec 2021 14:23:29 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: sidrops@ietf.org References: <813d1599-fc9d-18b6-a76c-b550855b1186@verizon.net> <20211130193034.344F62EA0102@minas-ithil.hactrn.net> From: Stephen Kent In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.19306 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Archived-At: Subject: Re: [Sidrops] AD Review of: draft-ietf-sidrops-6486bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 19:23:40 -0000 Tim, > ... > So, section 6.3 says: > "If the current time is earlier than thisUpdate, the CA has made an error" > > It is also RECOMMENDED earlier that the EE certificate notBefore matches > thisUpdate. > > As a CA I have every intention not to be sloppy and manage my own NTP, > but I feel vulnerable to RPs with sloppy NTP. I do not see what the > big deal is with back-dating five minutes. The object did not exist five > minutes ago, but if an RP lives 2 minutes in the past - why should they > reject me? What if my parent issued a covering ROA and I try to publish > a more specific, and it is rejected for this reason? If an RP is sloppy re their time maintenance, they will have to retry the fetch, and eventually the problem will be resolved. We have no way to ensure that all RPs process newly posted info in a timely fashion, so this is just another factor that influences the speed with which PP data is acquired, validated, and used internally by RPs. > NOTE: For manifest and other RPKI Signed Objects there is also the option > of using the Signing-Time Attribute (section 2.1.6.4.3 of RFC 6488). In > my mind this is where the CA tells the truth about the time of signing. > > Also note that there are different components involved in the chain. > When a CA signs a new manifest and uses *now* for notBefore, then there > will still be some delay before it is actually published by its > Publication Server (seconds to minutes). And then there is a further > delay before an individual RP picks it up. So, assuming that the CA and > RP NTP are in sync, the latter will always find things after the fact. > > Speaking for my own implementation publication happens within seconds > after signing and that is when the first RPs will pick it up. For others > it may take minutes between signing and publications and therefore they > may be less afraid of RPs living in the very recent past. As you observed, different CAs may have different timing concerns. Still, if we don't direct RPs to pay attention to this field, it undermines confidence in the system. Experience from a number of PKI contexts shows that if RPs fail to enforce constraints on cert processing, bad behavior by CAs will go unnoticed and uncorrected for some time. Steve From nobody Fri Dec 3 11:42:12 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAD33A07CC for ; Fri, 3 Dec 2021 11:42:11 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r938jyJSJprF for ; Fri, 3 Dec 2021 11:42:09 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 6B7613A07C3 for ; Fri, 3 Dec 2021 11:42:09 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mtERa-0000UU-93 for sidrops@ietf.org; Fri, 03 Dec 2021 19:42:06 +0000 Date: Fri, 03 Dec 2021 11:42:05 -0800 Message-ID: From: Randy Bush To: sidrops@ietf.org In-Reply-To: References: <0B2DE27E-B67F-413B-806B-7131B90F3333@arrcus.com> <14BFC0A3-0352-47C7-86CF-23223F0E660E@nlnetlabs.nl> <1C0B5653-BBB7-4F61-A6C9-CD4857F260C0@nlnetlabs.nl> <2ED23A27-CC42-4BED-AD5C-8CD3D741766E@nlnetlabs.nl> <523B28BF-9CAB-4E35-AD93-39EBD0A371CF@nist.gov> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 19:42:11 -0000 > [0] - fyi, my routers log symptoms of inappropriate roa withdrawals > for various RPs disclosure: i have two hats i work for a vendor, arrcus. i am also work as a research fellow at iij, a large isp. in that role, i am part of a research commune which has a few research racks in space kindly donated by folk such as equinix and google. these racks have routers from various vendor friends. the research racks do not have an arrcus box running rov. think cobbler's children. so the note above is not with my arrcus vendor hat, but with my researcher hat and on well known reputable hardware from other vendors. randy From nobody Fri Dec 3 12:04:57 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83AE3A081F for ; Fri, 3 Dec 2021 12:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.net 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 VAQy6jM1GHe1 for ; Fri, 3 Dec 2021 12:04:47 -0800 (PST) Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01on2064.outbound.protection.outlook.com [40.107.107.64]) (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 678483A081E for ; Fri, 3 Dec 2021 12:04:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b0CUY52KZImkXoNlfsMs/axLYWH2+DWlFY/Xa5k3TAk0q0Q9gmQ5WRfoG/zQki4+9NPUoeA43J74qPMD0AzJpZCjBRerYhEU8/5jW4seDmKc0g6WgmMLlbZSzMfMCbVHASO6sAh9htv7ZKjwU5mnpGR2euaKQmLDDsXLBDWeLwZyv3c9Gc5Ss8ffRlTaRbBaAc0tT/Mk6HOiXpPxYOuq3kiJcfYZTq9HQVUvGXxf0S+No9Hk5w0t+Z47knAcRt2GfnELDOkUT3YVrdsCDjv1zv22HF2zO9tdI1mK4AWdCkMKJOdNVNepkTPK5owa1loQBiH8VkDDGqLUWa8Twy848g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pAGBWuj/1G53W0X3H/O+Jcrn4Wta0JpIc8dzoCNvxE4=; b=GbNtiFeqxatkUNQjpLebZuDin2wwYXdVDzzzt2K0XmfNdPQjt/8jjY2kFOwRIUk8uR3Nz2jMdufwSVN9/Fntc8GhqRPh2pH3ZMdN2mpRxr8HxbK63lKJ+Zl2cQ6OuISZXxXpl0CoI82uMRF2BeXA8zvsc8b1Yv5vNr2uO7u0Qh/P9AG0+cdHPiZrEap+I7np2H0rwGnDVD1PpS/npNCgXmILKA96z7SSCeIma8Y42V5k5ewtSAM7z7Fv6ZFhlyPzfKwcq6enXFl/ap/yGqjOabgE+6XbmDlnAEKUs8kerO9fC0YpuV6KkmWjMb2x/pGV4l2j/Qs18b5LpMXJLF30Yw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=apnic.net; dmarc=pass action=none header.from=apnic.net; dkim=pass header.d=apnic.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pAGBWuj/1G53W0X3H/O+Jcrn4Wta0JpIc8dzoCNvxE4=; b=iHQ6hb1pQlTYLwAvZ0//djD/TlRjKTBfX1P3xZjJ4TB6l/MXyiOHleGD9J7/ANicZAcdMFqx3Oh28Cab+CW4ZbKzdkSeHMA8ogsSpdcUPdJgQFUwOt6ehUZrNpkYXXSxPEpQKpQGz5hALqweKpKaVHk3WNAQAAAZlrP+wy7aN0M= Received: from SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:176::18) by SY4P282MB3613.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:17c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.21; Fri, 3 Dec 2021 20:04:41 +0000 Received: from SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM ([fe80::c834:8e45:135b:15d6]) by SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM ([fe80::c834:8e45:135b:15d6%6]) with mapi id 15.20.4713.031; Fri, 3 Dec 2021 20:04:41 +0000 From: Geoff Huston To: Randy Bush CC: Stephen Kent , "sidrops@ietf.org" Thread-Topic: [Sidrops] WGLC - draft-ietf-sidrops-rpki-has-no-identity - ENDS 12/16/2021 (Dec 16 2021) Thread-Index: AQHX56lIek54tNT0FU60UhtchksHS6wfoFmAgAAK+4CAAERnAIABNJoAgAACwgCAAAuYAA== Date: Fri, 3 Dec 2021 20:04:41 +0000 Message-ID: <505D4823-4CCF-44B2-980F-8984328B105B@apnic.net> References: <87v906j2cm.wl-morrowc@ops-netman.net> <1F30B4DD-F34A-40C2-89C4-6F84D7F83291@apnic.net> <0E6ED68D-46F0-4303-8FF4-1932847E43DC@vigilsec.com> In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3693.20.0.1.32) authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=apnic.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3d6f6fef-f879-4f30-d80b-08d9b698249c x-ms-traffictypediagnostic: SY4P282MB3613: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2qsDjDnRk71k+DA3+zb0dld4oFA4MbHLDwBTLvhHhuJm1xTsQHByUi++yQ9JcmcyepItrsTqDdhx094cQVjRO6UCrSb8XAVyuSqpQNLqR62xNvRSEoYlEPK9kIMJsV47Dsw9KXFO9vCQnzebmLIUfkOM0Mfu2xWIwcXnKNvnHkKCsh/N9+UErpBwLbzKRzuPk2MD9/qHoDvVr6Xp4U4Y1zgczI8FaMK2hyeIZkzG36/ilXZiVjfzZXx2reLZhveT8kd2zwI0L3r51Lj9bIRYl18zIDGhTWwchtghhBH+BuF0gDT1c3V+q/2SVIAAPEPse11cRoUrknovZ+OHvpVRzDJWB7DLjWXpTrYldhicUmCCi4djnrXozOGB65arInTU71ngK5GWEcLw9KtzXKb3jjtbEaIUxiY0t6fskYwtuuJlGthAwtQ6RPt1IodEqHNQlbQ6qw+19kkhDR5BMmkiDOaDuFXH8WMB8GjtOBbpv6Dd1cEEQjsr+xroHWy6m4TWy+ZtRVZ1k1xbaT2RJqUVXJ0DWsplY0SSOURjWz/BF93RD0XbMYih0oWspF+WfxujDp30WUiVuykDPKLuaJQiHUurpGu8gEtof8EbPRWfNdNjshlY3YIdYXEJgSoTGl5BUZdif94bkggy7fCVBcXralpO7G4K57mXK3Stu7k2xPW7EVuxxZECLmbNrZHcIUQEl3TxjI7tIWWBd+zecEIS4rLtT0q/I7BkawaPw/ruDM429yd9PPrOii6HDINBvwTG x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(136003)(39830400003)(346002)(376002)(316002)(38100700002)(33656002)(71200400001)(4326008)(66556008)(54906003)(122000001)(6486002)(5660300002)(186003)(8936002)(8676002)(64756008)(2616005)(6512007)(66946007)(66476007)(76116006)(66446008)(36756003)(86362001)(508600001)(6916009)(53546011)(38070700005)(6506007)(83380400001)(2906002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?WjdjZHNtSU1IdzEzM2UzSjZwQjUxYjhxMm5xc0ZlMU1uYmNYOEpRT081NVFq?= =?utf-8?B?MGJ3VUI5YjU1Ri81MW4wZXAvWktQRXlVSUtuUHJMSHQ2MlZwTHd6Z1R6SXoz?= =?utf-8?B?bGdRcGVvcVRaQW9OMFZYNFJsUFZacXBIaGNVODNPMzlDMGQ1a0JOM1lLQnlV?= =?utf-8?B?dEpJa0JlV1NPLzJBL0haNzBnbEJpUjhtaXg1eVpnalJib1BMUUZldVVlYjFi?= =?utf-8?B?UmkxS3pjc3U5VmlyRFpGZUhiNTZ4TWptYnRqRFBpZmJGNG90QThsVnZtWk1q?= =?utf-8?B?MU9BTTlQQ2RGSmdaaFN3SkxhQjF3Q3U3dC9zYWVuVzFaWWI4K0ZEY2FIOFM3?= =?utf-8?B?OTAyemVUMTJPbHRLdUNSRUZkOHFoR0tjZGt5aDJJcGxLUURXSUxramtTaGd2?= =?utf-8?B?alhwbDVsNGNqN3pWcTQvL0xFZXN0bVM2WEEwRVg1T2FJQlM1K0hwcjA5ODdW?= =?utf-8?B?bU9hRE5wWkUrcWFZQkdUTmdha0hoLzdPSVJKZENKS3kyQTUyazh0eTdyQlRX?= =?utf-8?B?S3o2U1ErblowRng5ZTloZ1RobXE2UXZFdjVCcys5My9GSzJkT05RNTU0Vmht?= =?utf-8?B?Q01NaEJSL1N1aEthZDY1VkszZy8wQjhJd2czRTFsL0dWY0p3RTRHNU9HYXdq?= =?utf-8?B?VW8rem9TVWhqNitjSDRTVTh1dXE4cjRXaXk2QTNqOU5GVEdrSDlTMHI4N28x?= =?utf-8?B?RFpTWEY5cHp2U1BXMkRVMXM4eVY0aTVQU0QzaUdhSVArUDdXalVEUGtaYlFQ?= =?utf-8?B?Q1ZTN0NXanc1REQrbWJneTVoL0ZqSzFkMGQ1MlViaDFwSHF6RklGMnZCM3VQ?= =?utf-8?B?Z1Y4dnc4T1dCalhDUjVHYkNrMzR4UVBoRFZEQkFra09oYjRhZGtScEVhRTZF?= =?utf-8?B?SDlva0twZXQzVFAvU1FtNWVtMi9NcExyaVNHUE1oa3JSaTEwY0V1eGc2bzZN?= =?utf-8?B?NEQrME02dHpoYzNjcnlJWVNpSGd1eS9LWFVBdkVSSzhwRVY1V2FXZXc5UDZh?= =?utf-8?B?UzFkN29sTUZyR0xJc1QzOEtYc0lZWERPZ294dUNTWlZleGhNVUYvT3lkQnFu?= =?utf-8?B?SE40U2tHUWl5eFJsNkd3YldaekgvejQ1SzlZQWhYdjRsb1VUQ2YwN0FEUElp?= =?utf-8?B?cnd4MmhIWkl5VTY2aXVuMVhuU0FBd3IyR3N2SjZ5NjZoR1BYOFl0aDFXOXVi?= =?utf-8?B?NjB5Z0RwcmwrZXpzRHNkcHREZ3hPcnhKNlMwbzNaSXJneS9DM0lGT2xETm9Z?= =?utf-8?B?SlNmZVpvc2F0V1ltTFpJMXdCVERSMUZpR3h5TWFUa1FFQkhNOHcySlRyUHB3?= =?utf-8?B?UUFyZSt3Zm15MUQzOHFUdzVtb2g3d0pJMHNlaVVCYW1jQ0pxVzdOWC9sSnhP?= =?utf-8?B?RVJrZnIwbXg3UUxBSlRSTEZnN3VGSThOSG85WFhRNVBNOFlvVUdKTUkzQVlG?= =?utf-8?B?MTRRUi9RS2RVbkM4MzhGaXFKeXdnZ2s2S1ZnSHh0UldOTzRRV3d4L1VYbkds?= =?utf-8?B?ZVFXelJIVERZcDk2cEtuYVEyNjlyNS9CdTJySVFGblN5TXFtRGx3RUVoV0lC?= =?utf-8?B?aFRjQnJZc3ZjN1dySTllS3lLVUpmV0tnV0ZoNUdiOGQzcVlnSGRRL1pob29V?= =?utf-8?B?N2lkN01TZFZ4REdNa0wzbzBiQUxXYWNFdlhOalRTb1libEtKNXFmM3YzTlNW?= =?utf-8?B?M0c4WWNOcFIyRDkrc1R5OVRUa1FTN25xaUlkQnBKemJpdkZNTFkzU1lZR2lZ?= =?utf-8?B?cHRDVDd6b3d3REFBczFPSGpXdE1Fa0dvcFloMURJNHRocTEzTU90RlpnaG02?= =?utf-8?B?VnN1N2lUL1RVNUdlSGpoQzRrUDByN2RPSU9Lek9ERld6OEgzYndYQVdqbk9X?= =?utf-8?B?WU9TakZTQzBhWDJ0OWJhMGdJaktpMDRhR3FZM3pUVU1tbzZWMHl0Sm1rb0d5?= =?utf-8?B?VFBjNGIyK3EralFmbmlPeGpVYmZLWUJia25qbHRSSDl4VHJCSjZHN1pmNFVm?= =?utf-8?B?Mmk3b0w5NUlEaSs5aERNRjBORzFDM21uVDJjU3plN2R1RVdrbXBDTCtVb2xZ?= =?utf-8?B?L2VMRy94N21BWE1UeU1CbEJtMi84b2lxdnRJS1BLL05uYTBkRVpVM1VoSEpr?= =?utf-8?B?aWRJMmc5VjdIUytXU3BOTWpIcnljNTFCaHJxc290V3l1OTcwenFkTXRCSFBt?= =?utf-8?Q?Rm/DZjt95+nPbWrdrEnG1gwd5iNwgSsucK+ObePpsOR4?= Content-Type: text/plain; charset="utf-8" Content-ID: <6433E780EE38304EA7570F1262DBAA3B@AUSP282.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 3d6f6fef-f879-4f30-d80b-08d9b698249c X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2021 20:04:41.4013 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /gIU9iN4ua0spjKZrF3vI5xBu8KCRlPJrkVzQJuWDccL9e5nk+3aJ3+S6wdkdlRF X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY4P282MB3613 Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-rpki-has-no-identity - ENDS 12/16/2021 (Dec 16 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 20:04:55 -0000 DQoNCj4gT24gNCBEZWMgMjAyMSwgYXQgNjoyMyBhbSwgUmFuZHkgQnVzaCA8cmFuZHlAcHNnLmNv bT4gd3JvdGU6DQo+IA0KPj4+IEV2ZW4geW91ciB0ZXh0IHRoYXQgc2F5cyB0aGF0IEkgZG9uJ3Qg aW50ZW5kIHRvIHNheSB0aGF0ICJpdCBpcw0KPj4+IGFwcHJvcHJpYXRlIGZvciB0aGUgcHJpdmF0 ZSBrZXkgYXNzb2NpYXRlZCB3aXRoIGFuIFJQS0kgY2VydGlmaWNhdGUNCj4+PiB0byBzaWduIGEg bGVnYWwgZG9jdW1lbnQgb3IgYW4gZW1haWwgbWVzc2FnZeKAnSBzZWVtcyB0byBtZSB0byBiZQ0K Pj4+IGxhY2tpbmcgaW4gcHJlY2lzaW9uLiBZZXMgSSBjYW4gdXNlIHRlIHNhbWUgcHJpdmF0ZSBr ZXkgZm9yIGEgd2hvbGUNCj4+PiBidW5jaCBvZiBkaWZmZXJlbnQgdXNlcywNCj4+IA0KPj4gVXNp bmcgdGhlIHNhbWUgcHJpdmF0ZSBrZXkgaW4gY29uanVuY3Rpb24gZm9yIGRpZmZlcmVudCBwdXJw b3NlcywNCj4+IGUuZy4sIHdpdGggZGlmZmVyZW50IGNlcnRzIGlzIGEgYmFkIGlkZWEsIGp1c3Qg bGlrZSByZXVzaW5nIGEgcGFzc3dvcmQNCj4+IGZvciBkaWZmZXJlbnQgYWNjb3VudHMuIEl0IGFs c28gbWlnaHQgdmlvbGF0ZSB0aGUgQ1BzIHVuZGVyIHdoaWNoIHRoZQ0KPj4gY2VydHMgd2VyZSBp c3N1ZWQuDQo+IA0KPiBnaXZpbmcgZ2VvZmYgdGhlIGJlbmVmaXQgb2YgZG91YnQsIGkgYXNzdW1l IGhlIHdpbGwgZ2VuZXJhdGUgcGVyLXB1cnBvc2UNCj4gc2lnbmluZyBjZXJ0cw0KPiANCg0KVGhh bmtzIGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgZG91YnQgUmFuZC4gWWVzLCBteSBoeXBvdGhldGlj YWwgc2VsZiB3b3VsZCBkbyB0aGF0LiBNeSBwb2ludCB3YXMgdGhhdCBpdHMgdGhlIGNlcnQgbm90 IHRoZSBrZXkgdGhhdCBpcyB0aGUgYmFzZSByZWFzb24gZm9yIHRoaXMsIGFuZCBJIHdhcyBzaW1w bHkgb2JzZXJ2aW5nIHRoYXQgdGhpcyBsYWNrIG9mIHByZWNpc2lvbiBpbiB0aGUgbGFuZ3VhZ2Ug d2FzIHRoZSBjYXVzZSBvZiBteSBtb2FuaW5nLiBJIG5vdCBjbGFpbWluZyBhbnkgYmV0dGVyIHRy YWNrIHJlY29yZCBoZXJlIChmYXIsIGZhciBmcm9tIGl0ISksIGJ1dCBJIHdhcyBzYXlpbmcgdGhh dCBpbiBSRkNzIHRoZXJlIGlzIGEgZ29vZCByZWFzb24gdG8gYmUgc3VwZXItY2FyZWZ1bCBhYm91 dCBwcmVjaXNpb24gYW5kIGFjY3VyYWN5IGluIHRoZSBsYW5ndWFnZSB1c2VkLg0KDQpHZW9mZg0K DQoNCg== From nobody Fri Dec 3 18:25:44 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE083A1030 for ; Fri, 3 Dec 2021 18:25:42 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=student.utwente.nl 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 GEwfrizJ2hU6 for ; Fri, 3 Dec 2021 18:25:37 -0800 (PST) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 482A73A102E for ; Fri, 3 Dec 2021 18:25:36 -0800 (PST) Received: by mail-ed1-x530.google.com with SMTP id o20so18786846eds.10 for ; Fri, 03 Dec 2021 18:25:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=student.utwente.nl; s=google; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=V6ElM7+7RmExbTr/niMUqLNLPaOAiNdxbfTtgwIEQBk=; b=A410EjyS1Cs6Hx5pb5CNHVIoIoILFOWoC1308MkBSOQQHIqYQOiOUK8GVGvKfGv0QU mTtnLb7Y6xkOSlcT0iYL3ww26fTnXYeMHPkl+c56+v3egqj0PqXdtZ49GlX/1YmUHi7X U0hYq3zUXW8Mi3wcrDV2WNOj/j5ugVc8Tuoad1wbFF5j+4c5PH7ZeKcpXkCh5kn4PvFK mCbCGQs1TcKUjMmqdxPEELVYjAEmJAa73jdPV8czBBK0fn3DCGZcx6keGvheWlEVK/LO vGVyuAtA8m79sGYIeynALy7FYaMLMB6i+9ZclbW8FoebBbCvIH3s6PsEfAnRHrBF4YE5 TEgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=V6ElM7+7RmExbTr/niMUqLNLPaOAiNdxbfTtgwIEQBk=; b=iGGHhY5OH1wpEo6qZ/XYptUR8JLjownVJE3Ev5AJSf+k4DtfH5lOlR5kXsvjXSY3+D ni7hJ1SFL9wyeTBjHUabv9qfkr0azKDBhgY6QEMJzEIsbgY5RB3FWHa+Or2Q8brj/ik1 YG2SMWAt/muNQ94lu/omqNlfwpvU3HFgscJtR2vDr8z2BXwYrjpwJ937b8smLAU8Ulrv iozhuUO8lQ2Ev8p1yu0kKYgeMyCVWe2UV2yseZrmg3tjhQOGJng91CgqXFDEbn6E6n0i qRokqZTKGR/Sc4XJmoKNbOw4riTV5etelKwRxhSf8e/7t5lEjX20uoE9iizM9e9ozMww ZFBw== X-Gm-Message-State: AOAM531CTM28eyUiYja2u2C7ePW0UmMb81ZOm0f+1v+TIc/G8Hq4IDEk gugEKSyhgFVSFFNi4AmXDVfm/zhPA+Ztmg== X-Google-Smtp-Source: ABdhPJytvwfrr/wAiWbjHgE0fjmh3Rg7dDX6nofa8uMG6c2omvweaGr9qt0PO4kwZWCeVgCJzRBazw== X-Received: by 2002:a05:6402:4382:: with SMTP id o2mr30868021edc.143.1638584732936; Fri, 03 Dec 2021 18:25:32 -0800 (PST) Received: from Epsilon (219-190-177-143.ftth.glasoperator.nl. [143.177.190.219]) by smtp.gmail.com with ESMTPSA id nc24sm3093591ejc.94.2021.12.03.18.25.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Dec 2021 18:25:32 -0800 (PST) From: "Koen van Hove" To: "'Job Snijders'" Cc: "'Jeroen Massar'" , "'SIDR Operations WG'" References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <001b01d7e638$0f34baf0$2d9e30d0$@student.utwente.nl> <004c01d7e7e6$1b509840$51f1c8c0$@student.utwente.nl> In-Reply-To: Date: Sat, 4 Dec 2021 03:25:31 +0100 Message-ID: <007901d7e8b6$3667e770$a337b650$@student.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG5KyS5O66QVqbINo4wVlHfa5ecZwF0ktdAAnjcc4gBoN6mMwFi/GrlAoSEKpKsE0KLAA== Content-Language: nl Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2021 02:25:43 -0000 Dear Job, all, The idea of K is that one can create a lot of entries in the ROV table by splitting, for example, a /48 into 2^80 /128s (or for an actual attack, a random subset), and subsequently overload it. To my knowledge, the only hindrances so far posed by implementations are a maximum file size, a maximum size of an RRDP repository, a maximum number of entries on a manifest, a maximum number of repositories, and a maximum number of prefixes per file. K hit, if I recall correctly, the maximum file size limits and the maximum repository size limits. The first is simply solved by splitting a ROA into multiple ROAs, the latter is easily solved by using rsync does not have a maximum repository size limitation, and a maximum files per MFT is easily bypassed by using multiple CAs in the same repository. I just tried this out by decreasing the number of prefixes in one ROA to 2^17, but creating 2^8 different ROAs. This works, and I do not believe I was nearing any limits yet. For context, this is roughly two orders of magnitudes larger than all current ROV entries from the five RIRs combined. The testbed does support rsync for the tests that do not require RRDP to function (i.e., tests that do not rely on XML vulnerabilities and the likes). Just like for RRDP, the rsync repositories are generated on-demand at the first request, thus your initial rsync request may take some time. (This is, by the way, the entire reason the testbed requires IPv6 to use, as rsync does not support SNI.) However, my point is not so much whether this specific test succeeds or fails. The question I asked myself was: "Can an attacker disrupt RPKI RP software by introducing a malicious CA/repository into the tree?". The answer to that question currently is: yes. This threat of many entries is made easier by rsync, hence I support moving away from rsync towards RRDP. Koen van Hove PS: Making it open source is something that is under consideration, but it is not a decision I can make on my own. -----Oorspronkelijk bericht----- Van: Job Snijders Verzonden: vrijdag 3 december 2021 08:48 Aan: Koen van Hove CC: 'Jeroen Massar' ; 'SIDR Operations WG' Onderwerp: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt > I am not sure who maintains the spreadsheet from rpki.exposed, but I > severely question the validity of some of the "not vulnerable" > statements. For example, K seems to still be possible over rsync for > rpki-client 7.5. I suspect the 'not vulnerable' fields are filled based on test results obtained using the testbed at https://rpki.koenvh.nl/ control run: 144665 lines of validated output under RIPE TA https://sobornost.net/~job/control.txt RIPE TA + J: 144671 lines of output (within error margin) https://sobornost.net/~job/j1.txt RIPE TA + K: 144665 lines of output (within error margin) https://sobornost.net/~job/k1.txt The testbed does not offer rsync access, so your claim about rsync cannot be verified. If you are creating variants of those tests, it would be helpful if you use distinct labels (K.1, K.2, etc) for each variant, and clearly document each permutation. Another consideration would be to make your testbed and source code publicly available so that others can replicate/confirm/inspect whatever claims are made. Regards, Job From nobody Fri Dec 3 18:32:16 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AF03A103E for ; Fri, 3 Dec 2021 18:32:14 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=student.utwente.nl 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 zx2f5YgOT_Eb for ; Fri, 3 Dec 2021 18:32:09 -0800 (PST) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 874723A103C for ; Fri, 3 Dec 2021 18:32:09 -0800 (PST) Received: by mail-ed1-x52c.google.com with SMTP id l25so18759064eda.11 for ; Fri, 03 Dec 2021 18:32:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=student.utwente.nl; s=google; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=gPs+jQp6E0BanRgVkHnPI16hUEDZ8hg58G6zEChkTm0=; b=wJv3di1bVaSMAbj9b1sutgAyFI+O90uE15x1zYQnqV/Qkj0knrh5zyRRRRULvTdrID pmMnVoPGl86bH3+DCqhYv18vsWsZljaWqpd2dzMk/THQA0/eFdoEDEsAztKdU0joPQee jz/KyOm7ihzEOV5L5hl6GU4q4Fpz8hDpc3+y/JyLi/VOpvYEYmwG3IXYvTKaVi7cgnRw ADX17aqznNW9P4vBtaOvhzZYAUOrXOvy3AyQOPkYJzU/N8Waf3sCqxjZrz+aS7azwV/v oWtQeeqhw0TDUu/5zMZ4k05pFhjWKXR7dKww9nz2nneTLHo+j41lDp4XfsZiKXD3Jd/d yoCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=gPs+jQp6E0BanRgVkHnPI16hUEDZ8hg58G6zEChkTm0=; b=wZ6ePhpqf5AihEjLpL3dr13Llgq7qMwE9bZvULkyVH1/KhzzHcQQDbZ9h+AZ/PYcpN Dp05An4MO4x6e6bFZD5+V9zcJ6E28dIa27qODZpV2ZiAPp3SuGZB2oTrJNhjuyQvemDE hrLK6Gcat0J2BQuVPudKIAnjtypVgApovJ7Z46ZnD2IpillcypsDS8ofRkuXXbYuZ31Y 3yTv2JaqE8pG7M7MxwUAKjycgPw6Veoqi5NrNjfE/Or5YwluNyGPtKEr3aT0fB+ic+P5 MTxEtgetetw44FCJTGEaO4x0+g/2apO9HBktpxRgxfhhh9xX1q8F6B/X4L2heMfn/Xr7 Hw1Q== X-Gm-Message-State: AOAM530GrhbzKGylIlqYDBxIp0oBX4n9aapurzzeP1wlJENvF9q1VEmx 4oGMA84lxkPUQW52/BKnp3RB4A== X-Google-Smtp-Source: ABdhPJz2zYxmsayvUtIHGpXmVb9N1Odak6LK8yd+930neSmgsQyif5PFjg1957ogmOpzZ2dAP5EQFA== X-Received: by 2002:a17:907:94c6:: with SMTP id dn6mr28151182ejc.490.1638585126882; Fri, 03 Dec 2021 18:32:06 -0800 (PST) Received: from Epsilon (219-190-177-143.ftth.glasoperator.nl. [143.177.190.219]) by smtp.gmail.com with ESMTPSA id c11sm3101752ede.32.2021.12.03.18.32.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Dec 2021 18:32:06 -0800 (PST) From: "Koen van Hove" To: "'Job Snijders'" Cc: "'Jeroen Massar'" , "'SIDR Operations WG'" References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <001b01d7e638$0f34baf0$2d9e30d0$@student.utwente.nl> <004c01d7e7e6$1b509840$51f1c8c0$@student.utwente.nl> In-Reply-To: Date: Sat, 4 Dec 2021 03:32:06 +0100 Message-ID: <007c01d7e8b7$213cc950$63b65bf0$@student.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG5KyS5O66QVqbINo4wVlHfa5ecZwF0ktdAAnjcc4gBoN6mMwFi/GrlAWtspx2sHDCggA== Content-Language: nl Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2021 02:32:15 -0000 Dear Job, all, BGP hijacks were once not likely - until the first one happened. Similarly, attempts to sabotage the RPKI are not likely. We can wait until it happens, or proactively resolve the issue to prevent it from happening in the first place. The latter has my preference. Koen van Hove -----Oorspronkelijk bericht----- Van: Job Snijders Verzonden: vrijdag 3 december 2021 12:14 Aan: Koen van Hove CC: 'Jeroen Massar' ; 'SIDR Operations WG' Onderwerp: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt On Fri, Dec 03, 2021 at 02:35:51AM +0100, Koen van Hove wrote: > Could you explain why it is a non-issue? It likely breaks all RPs > currently - that strikes me as an issue. Is it really that likely? I have yet to see it happen. > RRDP can directly be written to object storage to avoid this issue, > and implementing a maximum total size/file number limits is easier as > well. Earlier on I mentioned 'rsync-os': https://mailarchive.ietf.org/arch/msg/sidrops/RQTi6TbyRQtYpfaigA5OA0JJNvg/ github.com/kaiakz/rsync-os "A port of rsync written in Go, with object storage support" ^^^^^^^^^^^^^^^^^^^^^^^^^^^ The concept of 'object storage' doesn't seem RRDP-specific. Regards, Job From nobody Mon Dec 6 11:01:06 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7438B3A0D6A for ; Mon, 6 Dec 2021 11:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net 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 JafaDfVROovv for ; Mon, 6 Dec 2021 11:00:49 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 83B813A0D69 for ; Mon, 6 Dec 2021 11:00:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version:Content-Type ; bh=7luBSQwEKbvQ2CqHto8Ab+u7B57qgqWW1np3ykySr8A=; b=HAy5qLmwRPyCVqau/Q0A6cwZ GXtugPB4FFOlD2mJA2cYyZFB9l/A5BJJ8yIh0umf3BYIkghTPMDXtYiO+U+vASF/5rke0jnXGTmLA Vd3d8skexBAg0tW6rWt7ftB/sIwLjIFxyU7RcJBnaFPnl9nxzPT4da0MwYHgdCu/dMxsxMbSrNU0x UwiE4Bw1Fc20uAQUd9IQr/tvNvMxuC/Wr+bMtLPsS+TSM8oko6chI7mBd3YVREGKuL3f7j2yzG4Aw bqsPxbYHM+OfO/CQED+Fo9+kIzVdXySZONMg/hyOMNYFkYFU3SqLAQR8JctMq4HQICgqNW6j52tgY 60lkrOfkcA==; Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:59780) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1muJE9-0006rE-Oe for sidrops@ietf.org; Mon, 06 Dec 2021 20:00:41 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1muJE9-0001Ql-LM; Mon, 06 Dec 2021 20:00:41 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mikhail Puzanov In-Reply-To: <2C2970A5-33D6-4C49-94E1-F4B87CD8DD14@ripe.net> Date: Mon, 6 Dec 2021 20:00:41 +0100 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <001b01d7e638$0f34baf0$2d9e30d0$@student.utwente.nl> <51448777-038D-4B0D-97D9-129053B5115F@ripe.net> <873EE1A3-B86A-46A3-9D96-AD4BEA21103F@ripe.net> <2C2970A5-33D6-4C49-94E1-F4B87CD8DD14@ripe.net> To: Ties de Kock X-Mailer: Apple Mail (2.3654.120.0.1.13) X-RIPE-Signature: e2494821e8eb7112beaeaa277e8c25e01b1691a919e080175daa0fcead5c10d0 Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2021 19:01:04 -0000 >>=20 >> You can set --min-size ;) >=20 > Superficially this may look like an improvement, but in reality, it = does not not > help against a realistic attacker. For any reasonable lower limit on = object size, > many filesystems will have much more free space than free inodes. >=20 > For example, what I see on a host with small disks: > [user@host ~]$ df -i > Filesystem = Inodes IUsed IFree IUse% Mounted on > ... > /dev/mapper/vg01-lv_root = 5242880 66960 5175920 2% / > [user@host ~]$ df -h > ... > /dev/mapper/vg01-lv_root 10G = 7.3G 2.7G 74% / >=20 > 2.7GB of data until the disk is full, but if you send 100b files the = disk is full > much sooner (remember that the inodes themselves will use a = non-trivial amount > of space). You can also exhaust both space and size efficiently: = transfer a > collection of sparse files and rsync transfers if efficiently and = materialises > it non-sparsely for the receiver. >=20 > And for many RPs, the server could just transfer symlinks instead. True. And apparently there=E2=80=99s no flag to avoid it.=20 >=20 >> Which for RPKI objects should be more than 100 bytes (vague = hand-waving). >> Actually, it would be nice to have a consensus about the minimal = object=20 >> size, we can have a good number here contrary to the max size. >=20 > Can we? Do we know what future object the RPKI will contain? I think we can and probably should since there is an effort to define = all sort of common=20 limits for RPs. As a quick estimate example -- every certificate has, at = least, one RSA key=20 of 256 bytes, a couple of dates - 24 bytes, SKI + AKI - 46(I guess?) = bytes, serial, other=20 3 extensions, distribution points and ASN.1 machinery, which at the very = least is 350 bytes=20 or so. The same calculation can be done for signed objects, all of them = have an EE and=20 a SHA256 somewhere, so probably these 350 byte would also be ok. All in all, I would suggest `--min-size 300` for RPs to use = consistently. >=20 >> So, lets say, we have timeboxed "rsync --max-size 32Mb --min-size 100 = --prune-empty-dirs=E2=80=9D. >> How bad it can still be? >=20 > Just as bad. >=20 > I'll reiterate my point from earlier. An rsync client that does not: > * abort after a set number of objects received, or > * abort after a set amount of bytes transferred by the connection, or > * get killed by the parent process after a certain time I have a hunch that =E2=80=9Cget killed by the parent process after a = certain time=E2=80=9D may=20 cover most of the cases. Or it may not but it's pretty hard to say = without a=20 realistic test. We also need to keep in mind that almost any rsync-based attack on RPs = would require proportional amount of resources on the attacker's side -- feeding every = single RP in the world with zillions of tiny files is quite a drag, so it may = happen that an=20 attacker would DDoS themselves before causing any serious damage to = anyone. Koen did a very convincing job on RRDP-related vulnerabilities, so = probably it would=20 make sense to have something the same systematic for rsync, similar to = the test=20 with directories. Having said that, I entirely support the initial direction of the draft = and would=20 want rsync to become optional/deprecated, but first and foremost because = rsync is=20 a headache for repository operators (RIPE NCC, specifically), rather = less so (from=20 what I can see now) for RP users. It is way too easy to bring = practically any rsync=20 repository to its knees, the only reason it has not happen yet is that = nobody tried. -- Misha From nobody Mon Dec 6 18:27:09 2021 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 313C23A0476; Mon, 6 Dec 2021 18:27:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <163884402813.13927.12989211497444684779@ietfa.amsl.com> Date: Mon, 06 Dec 2021 18:27:08 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-8210bis-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2021 02:27:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2 Authors : Randy Bush Rob Austein Filename : draft-ietf-sidrops-8210bis-04.txt Pages : 38 Date : 2021-12-06 Abstract: In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 2 of the RPKI-Router protocol. RFC 6810 describes version 0, and RFC 8210 describes version 1. This document updates RFC 8210. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-8210bis/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-8210bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-8210bis-04 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Mon Dec 6 18:30:43 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775873A0ECD for ; Mon, 6 Dec 2021 18:30:41 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 410_R12chiuk for ; Mon, 6 Dec 2021 18:30:40 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 1A21A3A0EC9 for ; Mon, 6 Dec 2021 18:30:40 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1muQFY-0003wV-HN for sidrops@ietf.org; Tue, 07 Dec 2021 02:30:37 +0000 Date: Mon, 06 Dec 2021 18:30:35 -0800 Message-ID: From: Randy Bush , Oliver Borchert To: SIDR Operations WG User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] three 8210bis issues X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2021 02:30:42 -0000 we had a chat about the ASPA PDU in draft-ietf-sidrops-8210bis. this is not a vote or opinion poll. but we would deeply appreciate new and different insights, simply stated. three issues, two minor or cosmetic, one substantial. saving the substantial for last. 0 - currently the AFI is a bit in the Flags field. in ROA PDUs, IPv4 and IPv6 are two different PDU Types. one suggestion is to do the same, an IPv4 ASPA PDU and an IPv6 PDU. another is to move the AFI bit out of the Flags field into the currently MBZ field following it. a separate idea is to have two bits in Flags or the following MBZ. but what to do when both are zero, yucchhh? pending further insight, -04 does not change this for the moment. 1 - currently, an ASPA Withdraw PDU is mandated to have at least one Provider AS. but, as the purpose of the Withdraw is to completely remove the ASPA for that Customer from the router, why insist that the RP cache be able to exactly reproduce the Announce PDU in order to withdraw it? if 2, below, does not result in a change, one alternative is to mandate that the Withdraw ASPA PDU have zero Provider ASs, and that it removes all Providers for that single Customer. another approach, still assuming 2 below does not change, is to simply not flag Announce/Withdraw, and an ASPA PDU with no Providers is an implicit withdraw of all Providers for that Customer. pending further insight, -04 has the last alternative for the moment. 2 - the ROA PDUs are sent one Prefix/AS tuple at a time. currently, the ASPA PDU groups all Providers into one tuple for the single Customer. the intuition was that ASPA is a one to many mapping while ROAs are one to one mappings. but the result is different program flows on both ends of the protocol. for an ASPA PDU, currently the cache and router need not worry what the other thinks; a new ASPA is an implicit withdraw of the previous ASPA data in the router. this is in contrast to ROAs and Router Key PDUs, where the cache and router must be aware of the other's state, and if discovered to be out of sync, a reset MUST be performed. -04 does not change this for the moment. more insight is needed. it would be especially good to hear from more router side folk. thanks. From nobody Tue Dec 7 00:18:47 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101D73A13F1 for ; Tue, 7 Dec 2021 00:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NQqwtFGDSqF for ; Tue, 7 Dec 2021 00:18:41 -0800 (PST) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F9D33A13EF for ; Tue, 7 Dec 2021 00:18:39 -0800 (PST) Received: (qmail 67376 invoked by uid 1000); 7 Dec 2021 08:18:36 -0000 Date: Tue, 7 Dec 2021 09:18:36 +0100 From: Claudio Jeker To: Mikhail Puzanov Cc: Ties de Kock , SIDR Operations WG Message-ID: References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <001b01d7e638$0f34baf0$2d9e30d0$@student.utwente.nl> <51448777-038D-4B0D-97D9-129053B5115F@ripe.net> <873EE1A3-B86A-46A3-9D96-AD4BEA21103F@ripe.net> <2C2970A5-33D6-4C49-94E1-F4B87CD8DD14@ripe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2021 08:18:45 -0000 On Mon, Dec 06, 2021 at 08:00:41PM +0100, Mikhail Puzanov wrote: > > > >> > >> You can set --min-size ;) > > > > Superficially this may look like an improvement, but in reality, it does not not > > help against a realistic attacker. For any reasonable lower limit on object size, > > many filesystems will have much more free space than free inodes. > > > > For example, what I see on a host with small disks: > > [user@host ~]$ df -i > > Filesystem Inodes IUsed IFree IUse% Mounted on > > ... > > /dev/mapper/vg01-lv_root 5242880 66960 5175920 2% / > > [user@host ~]$ df -h > > ... > > /dev/mapper/vg01-lv_root 10G 7.3G 2.7G 74% / > > > > 2.7GB of data until the disk is full, but if you send 100b files the disk is full > > much sooner (remember that the inodes themselves will use a non-trivial amount > > of space). You can also exhaust both space and size efficiently: transfer a > > collection of sparse files and rsync transfers if efficiently and materialises > > it non-sparsely for the receiver. > > > > And for many RPs, the server could just transfer symlinks instead. > > True. And apparently there’s no flag to avoid it. Just don't add -l or -a to your rsync command. Symlinks are skipped by default. > > > >> Which for RPKI objects should be more than 100 bytes (vague hand-waving). > >> Actually, it would be nice to have a consensus about the minimal object > >> size, we can have a good number here contrary to the max size. > > > > Can we? Do we know what future object the RPKI will contain? > > I think we can and probably should since there is an effort to define all sort of common > limits for RPs. As a quick estimate example -- every certificate has, at least, one RSA key > of 256 bytes, a couple of dates - 24 bytes, SKI + AKI - 46(I guess?) bytes, serial, other > 3 extensions, distribution points and ASN.1 machinery, which at the very least is 350 bytes > or so. The same calculation can be done for signed objects, all of them have an EE and > a SHA256 somewhere, so probably these 350 byte would also be ok. > > All in all, I would suggest `--min-size 300` for RPs to use consistently. I doubt that --min-size will result in RPs not being vulnerable. 300 bytes is smaller than most disk block sizes and with that you can actually run a FS out of space as well. > > > >> So, lets say, we have timeboxed "rsync --max-size 32Mb --min-size 100 --prune-empty-dirs”. > >> How bad it can still be? > > > > Just as bad. > > > > I'll reiterate my point from earlier. An rsync client that does not: > > * abort after a set number of objects received, or > > * abort after a set amount of bytes transferred by the connection, or > > * get killed by the parent process after a certain time > > I have a hunch that “get killed by the parent process after a certain time” may > cover most of the cases. Or it may not but it's pretty hard to say without a > realistic test. > > We also need to keep in mind that almost any rsync-based attack on RPs would require > proportional amount of resources on the attacker's side -- feeding every single RP > in the world with zillions of tiny files is quite a drag, so it may happen that an > attacker would DDoS themselves before causing any serious damage to anyone. > > Koen did a very convincing job on RRDP-related vulnerabilities, so probably it would > make sense to have something the same systematic for rsync, similar to the test > with directories. > > Having said that, I entirely support the initial direction of the draft and would > want rsync to become optional/deprecated, but first and foremost because rsync is > a headache for repository operators (RIPE NCC, specifically), rather less so (from > what I can see now) for RP users. It is way too easy to bring practically any rsync > repository to its knees, the only reason it has not happen yet is that nobody tried. There are some much larger rsync repositories out there then the one from RIPE NCC. I think the main issue with rsync is that there is only one real implementation of the server and there is no official specification of the protocol. rsync has a few benefits over RRDP so I would be very careful about removing rsync support without fixing or adding an RRDP replacement. -- :wq Claudio From nobody Tue Dec 7 00:29:55 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D3A3A141A for ; Tue, 7 Dec 2021 00:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20210112.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsuK7mNx5ypw for ; Tue, 7 Dec 2021 00:29:48 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::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 28BE23A1418 for ; Tue, 7 Dec 2021 00:29:47 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id 207so25925726ljf.10 for ; Tue, 07 Dec 2021 00:29:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=MahjcNQSiPsYvXgaSuDwm30Xtw5UmFApC5+jv4FGKF4=; b=5PMzyrcGzxJYqZUV1vB0YmMyp9HXOWfIJ1lYcyGPc8gKNgaDnhubGodDf84Rc3H4r3 rnfboPPHa7De/aojeFJIjANYpTyo7p0wyJOl0gsscT+dHVVhWaNn2thxIfu/CDSTG0kn F/N1+qEwSZQGxgSODt84HiH9s14T3uj961uP/IkBuu++xMFmid9w/pT0xPLVJu9p4Fex Y3dGgLgQR2qU+DumMrLKjb9Ag+wJHNjfUnBTrqwDmTlpj4+6p7gaAP4To8I4sfpqfbTa 9vNSQOb0cKGHZJp/GWH9hpBe9fsWDgvweZBoxOqrJ8kgz9PbuVj6sKwNb3+VQCnp87wT E6rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=MahjcNQSiPsYvXgaSuDwm30Xtw5UmFApC5+jv4FGKF4=; b=Gx62uYgVtTvUvpnql32ys3ZoYdrXOh+/dsGsRvtff3bOevRnareDKXwn4yXkBQZrrV CMHc/jTKnoY7LuGr/RT5dg72LRgsww+itaGMau4WJqaRUUlfbCLQrXkNsDQNZ4lNPCXu H0znrF5RHy7aMJUdE/DvESqzK7ZxvSvg6AL1tyw7zI5agNXq8Z6xCbO1zmld0fKZ0B0a KFIkwqVS+gC5bw5aygWOnrX4dStP5+BOTwRaC9TcnsR/vjcKEC2HemLitKkf0R/KGN0x 4QVM4mWl1PjNd5WLrEUUOB7evHYn28bAjmoDAT1y5ZeDHU00tOIc66QFUFet3QGL0mOb a5xA== X-Gm-Message-State: AOAM530JQIG9d3C/OXGs+oVE2fM+klFwt6SuePebHgdwg8eRwNZf6wEA yf4WllCuBsTb9Bhfv2U3NLetZa72ZBZcjgIXiDA543TgoO0fdQ== X-Google-Smtp-Source: ABdhPJwxL7M2F/divtXDdCwLu27iNvBRSI55M1yY3fcZJv0+E/aBQcIa0QLsi938HRwbQ/T9+zf77oDFrB8aTs9R7nI= X-Received: by 2002:a2e:a596:: with SMTP id m22mr41336758ljp.342.1638865784559; Tue, 07 Dec 2021 00:29:44 -0800 (PST) MIME-Version: 1.0 References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <001b01d7e638$0f34baf0$2d9e30d0$@student.utwente.nl> <51448777-038D-4B0D-97D9-129053B5115F@ripe.net> <873EE1A3-B86A-46A3-9D96-AD4BEA21103F@ripe.net> <2C2970A5-33D6-4C49-94E1-F4B87CD8DD14@ripe.net> In-Reply-To: From: George Michaelson Date: Tue, 7 Dec 2021 18:29:33 +1000 Message-ID: To: SIDR Operations WG Content-Type: multipart/alternative; boundary="000000000000ec6c2005d28a2cf9" Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2021 08:29:53 -0000 --000000000000ec6c2005d28a2cf9 Content-Type: text/plain; charset="UTF-8" On Tue, 7 Dec 2021, 6:18 pm Claudio Jeker, wrote: > > There are some much larger rsync repositories out there then the one from > RIPE NCC. I think the main issue with rsync is that there is only one real > implementation of the server and there is no official specification of the > protocol. > Aside from the 5 RIR who do not directly produce roa, although they do publish roa for hosted services in distinct paths what are these much larger repositories? Do you mean APNIC or another RIR? Large to object size or large to count or ... ? > rsync has a few benefits over RRDP so I would be very careful about > removing rsync support without fixing or adding an RRDP replacement. It pays to be explicit. What are these benefits? The only one I have seen discussed is the cost shifting to compute the object tree from deltas (shifted cost to client side in RRDP) vs the complete structure in rsync at a cost of per fetch difference calculation, server side. There are also disadvantages. Rsync is inherently serialised. Http has at least implicit parallelism in its transport protocol (HTTPS). And is CDN friendly. Rsync CDN support is tcp anycast and that's about it. And the ones you stated (lack of implementations, lack of ietf standard) Cheers G > --000000000000ec6c2005d28a2cf9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, 7 Dec 2021, 6:18 pm Claudio Jeker, <cjeker@diehard.n-r-g.com> wrote= :

There are some much larger rsync repositories out there then the one from R= IPE NCC. I think the main issue with rsync is that there is only one real i= mplementation of the server and there is no official specification of the p= rotocol.

Aside from the 5 RIR who do not directly produce roa, although th= ey do publish roa for hosted services in distinct paths what are these much= larger repositories? Do you mean APNIC or another RIR? Large to object siz= e or large to count or ... ?


rsync has a few benefits over RRDP so I would be very careful about
removing rsync support without fixing or adding an RRDP replacement.

It pays to = be explicit. What are these benefits? The only one I have seen discussed is= the cost shifting to compute the object tree from deltas (shifted cost to = client side in RRDP) vs the complete structure in rsync at a cost of per fe= tch difference calculation, server side.

<= div dir=3D"auto">There are also disadvantages. Rsync is inherently serialis= ed. Http has at least implicit parallelism in its transport protocol (HTTPS= ). And is CDN friendly. Rsync CDN support is tcp anycast and that's abo= ut it. And the ones you stated (lack of implementations, lack of ietf stand= ard)

Cheers

G
--000000000000ec6c2005d28a2cf9-- From nobody Tue Dec 7 01:14:26 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2733A3A1451 for ; Tue, 7 Dec 2021 01:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl 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 SerzVlcJ0gfw for ; Tue, 7 Dec 2021 01:14:18 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [116.202.126.228]) (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 518123A144F for ; Tue, 7 Dec 2021 01:14:17 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 3728F83E; Tue, 7 Dec 2021 09:14:13 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1638868452; bh=uMuaEokf4i9T92Zz/1Y/krlxDMKTy/MCz826+8j2+h0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=uTZWUfTgDF0uLY4XGiIj0V0gw/FJIgGV1U7Ove05NQZmVnUgv4/RzWOzxcRlJnSsE Au4WLpPzksYeRJsnBZfhNk8ym+voc8cgjrPKKjjJjN8FEzX98P70UKaiu31mGDxVpc E63nNr+Ho2rRTSrV2s8Y7tFJiG28zg/DDmMpxyyDZu6ac4YhWmxl1WVYxvmUfT9w67 r/hIZoYqOzbZu55dAAkgSnmDo8ouU9xjOAwZoz5L4rHznS+Pf2qcsMSxbIc+Cw3CwI QNM+1kp0kgorcAJ95zEo3L/o5lvJUJOM5QSM4Cs32yXSxValLcAan7BUWE4f0WTPRJ +pFdYnDhoj7kw== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Tim Bruijnzeels In-Reply-To: Date: Tue, 7 Dec 2021 10:14:10 +0100 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <3413E245-55FF-4C8E-BB93-BFD48C3F1A1F@nlnetlabs.nl> References: To: Randy Bush Archived-At: Subject: Re: [Sidrops] three 8210bis issues X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2021 09:14:24 -0000 Hi Randy, all, in-line.. Generally speaking though, I think we need closure on the ASPA profile changes as proposed and discussed. Ben Maddison raised questions on November 11 (Re: [Sidrops] Experimental ASPA object published in = testbed). > On 7 Dec 2021, at 03:30, Randy Bush wrote: >=20 > we had a chat about the ASPA PDU in draft-ietf-sidrops-8210bis. this = is > not a vote or opinion poll. but we would deeply appreciate new and > different insights, simply stated. >=20 > three issues, two minor or cosmetic, one substantial. saving the > substantial for last. >=20 > 0 - currently the AFI is a bit in the Flags field. in ROA PDUs, IPv4 > and IPv6 are two different PDU Types. >=20 > one suggestion is to do the same, an IPv4 ASPA PDU and an IPv6 PDU. >=20 > another is to move the AFI bit out of the Flags field into the > currently MBZ field following it. >=20 > a separate idea is to have two bits in Flags or the following MBZ. > but what to do when both are zero, yucchhh? >=20 > pending further insight, -04 does not change this for the moment. Note that there is also a proposal to have both v4 and v6 providers on a single ASPA object. I think the cache can handle splitting this into separate PDUs, but it may benefit from some text. An alternative that I can think of is that there would be three length fields. One for v4+v6, one for v4 only, one for v6. Any of which can have length 0. =10Then a single PDU can contain the same data as a = single ASPA object, with a total combined length of 0 implying a withdraw (see below). I don't have any very strong preference in the matter, except to point out that we need to be sure that the ASPA profile and this -bis are in agreement. >=20 > 1 - currently, an ASPA Withdraw PDU is mandated to have at least one > Provider AS. but, as the purpose of the Withdraw is to completely > remove the ASPA for that Customer from the router, why insist that > the RP cache be able to exactly reproduce the Announce PDU in order > to withdraw it? >=20 > if 2, below, does not result in a change, one alternative is to > mandate that the Withdraw ASPA PDU have zero Provider ASs, and that > it removes all Providers for that single Customer. >=20 > another approach, still assuming 2 below does not change, is to > simply not flag Announce/Withdraw, and an ASPA PDU with no = Providers > is an implicit withdraw of all Providers for that Customer. >=20 > pending further insight, -04 has the last alternative for the > moment. This alternative works for me as long as we stick to the full providers approach. But... There was a proposal to have an explicitly signed empty list of = providers, rather than overloading AS0 to mean no (valid) providers.=20 I think we need closure on this in the ASPA profile because it may have a bearing on this -bis. If the ASPA profile -07 were to go for empty provider list rather than AS0, then an explicit empty list PDU would be needed and it would not be a withdraw. I.e. we would need to flag 'no ASPA for customer ASN' vs 'no providers for customer ASN'. Because I did not wish to complicate the validation and rtr (this -bis), I therefore came back on my earlier viewpoint on this, and suggested = that we do stick to AS0. Can we conclude that the ASPA profile will keep AS0 and a minimal length of 1 provider? > 2 - the ROA PDUs are sent one Prefix/AS tuple at a time. currently, = the > ASPA PDU groups all Providers into one tuple for the single > Customer. >=20 > the intuition was that ASPA is a one to many mapping while ROAs are > one to one mappings. but the result is different program flows on > both ends of the protocol. >=20 > for an ASPA PDU, currently the cache and router need not worry what > the other thinks; a new ASPA is an implicit withdraw of the = previous > ASPA data in the router. this is in contrast to ROAs and Router = Key > PDUs, where the cache and router must be aware of the other's = state, > and if discovered to be out of sync, a reset MUST be performed. >=20 > -04 does not change this for the moment. more insight is needed. > it would be especially good to hear from more router side folk. I somewhat dislike it being inconsistent with how ROA VRPs are treated. I also dislike that it could result in long PDUs being resent - the current limit is 64k providers.. in practice I don't expect to see that much, but the protocol allows it. I don't think this would impact the RTR server much, but it could impact routers. All that said, to me the most important point is that this gets input as you are asking as well. I can have peace with either as long as that has happened. Thanks for raising this Randy, Tim >=20 > thanks. >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Dec 7 01:30:49 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DED93A1475 for ; Tue, 7 Dec 2021 01:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciEuogIyhRfx for ; Tue, 7 Dec 2021 01:30:44 -0800 (PST) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 B72893A1471 for ; Tue, 7 Dec 2021 01:30:43 -0800 (PST) Received: by mail-ed1-x52f.google.com with SMTP id z5so54850899edd.3 for ; Tue, 07 Dec 2021 01:30:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=HUssp3Wr5e+kuoXH6iQifcdoynHq2VwGo+mKElIWxOo=; b=B7F7HVT+w+7iOVv7O5YLE6rz6gC1C0HUnnpAViFRqhJjGc+/3F0Yl/f5GMtW5P1Qg6 x13s7G47kwPVPPM1Uj42eOYX+EtHTd1q4SpM7vTo/jicug19pzujuj81O6H9DYWlOBMH kdUfQq/Et7mpqrtdXnoHH7I8GSl+Sue8p/tvw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=HUssp3Wr5e+kuoXH6iQifcdoynHq2VwGo+mKElIWxOo=; b=HvF3bTJmA/zyjGNCob6wzk/e4y4QRzL1l82Cp0Nu7v1XelC0aa884X/E5iOWe32CKg jiIERcx4Xrq3W5PFqnq0q6mNzn3pmmcCJOvxRHrS/s4o4Fnjm2PJJMh0vkpUTjPYaSQq oBCBSAnIr/bnWVySoGJUMKPAgX6bz1qbKVSs6yq6Y2dr3WbIW6X7WGyOLAQ33oKHHx+0 Q1rEqcuNH5FT2jFkoYenaT8Q3XjdwLh/OM1ZXT7o5dXTIvtwhj/rU3IAurJM+gVDBJ6w fccK41xPQai0hjlf1N63OY1w8L6CBR5njpZrbcd0d6IMbY6Zt6yVnZF8DUz7FeAFS+Py JjLA== X-Gm-Message-State: AOAM5306q6SZXS40ZVKPqULx4NJ/ZQT6VVwCmBOt1WXtKAR4o48iSW3k bOsKLRFLFeosVLNJzMyFpfBWDw== X-Google-Smtp-Source: ABdhPJwukC6alIlPTyJW45MI2hWW7kqV6xxnGQrYJcjNPX2GFx8iGn+p6MuZe7wPnN/Zw7xVYuz8Jg== X-Received: by 2002:a17:907:961a:: with SMTP id gb26mr51077544ejc.71.1638869441187; Tue, 07 Dec 2021 01:30:41 -0800 (PST) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id ga26sm8189438ejc.11.2021.12.07.01.30.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Dec 2021 01:30:40 -0800 (PST) Date: Tue, 7 Dec 2021 10:30:39 +0100 From: Job Snijders To: George Michaelson Cc: SIDR Operations WG Message-ID: References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <001b01d7e638$0f34baf0$2d9e30d0$@student.utwente.nl> <51448777-038D-4B0D-97D9-129053B5115F@ripe.net> <873EE1A3-B86A-46A3-9D96-AD4BEA21103F@ripe.net> <2C2970A5-33D6-4C49-94E1-F4B87CD8DD14@ripe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2021 09:30:48 -0000 On Tue, Dec 07, 2021 at 06:29:33PM +1000, George Michaelson wrote: > Aside from the 5 RIR who do not directly produce roa, although they do > publish roa for hosted services in distinct paths what are these much > larger repositories? Do you mean APNIC or another RIR? Large to object > size or large to count or ... ? One example that comes to mind is: rsync://mirror.leaseweb.com/ (25T, millions of files, anycasted) When an RSYNC repository is DoSsed, perhaps it is unreachable from some parts of the world for a brief period of time; but when the RSYNC operator decides to no longer do their job (by permanently turning off the RSYNC server); the rsync service goes offline, completing the DoS. > > rsync has a few benefits over RRDP so I would be very careful about > > removing rsync support without fixing or adding an RRDP replacement. > > It pays to be explicit. What are these benefits? The only one I have > seen discussed is the cost shifting to compute the object tree from > deltas (shifted cost to client side in RRDP) vs the complete structure > in rsync at a cost of per fetch difference calculation, server side. 0/ Via rsync all Signed Objects (and all other x509v3 extension references to related objects) are available as distinct downloadable resources. This is a wealth of data for debuggers: 'CA Issuers', 'Signed Object', CRLDP, etc. 1/ An RP has to replay the enitre RRDP session to figure out if they are desynchronized. RRDP doesn't offer an index table (other than downloading the entire snapshot). 2/ The RRDP element is unauthenticated and unsigned. 3/ RRDP clearly was a hackjob: all URIs in the XML are rsync:// URIs. 4/ The RRDP spec is awfully light on how rsync/rrdp should co-exist. 5/ RRDP did not need XML as wrapper, should've/could've been DER. 6/ The B in base64 stands for Bloat. 7/ RRDP has a hard dependency on HTTP Keep-Alive: without Keep-Alive you might fetch a Notification file from server A, and attempt to fetch the delta or snapshot from B. Rsync is a single TCP stream, less sensitive to repository operator mistakes in this regard. > There are also disadvantages. Rsync is inherently serialised. Http has at > least implicit parallelism in its transport protocol (HTTPS). And is CDN > friendly. Rsync CDN support is tcp anycast and that's about it. And the > ones you stated (lack of implementations, lack of ietf standard) I find it interesting how CDNs are SIDROPS' deus ex-machina :-) Why is the 'lack of implementations' meme being repeated, even though by now (anno 2021) more rsync implementations seem to exist than RRDP implementations? Times have changed. Kind regards, Job From nobody Tue Dec 7 01:45:41 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E716D3A148B for ; Tue, 7 Dec 2021 01:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20210112.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6OvPtlDZ58U for ; Tue, 7 Dec 2021 01:45:35 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 E4F263A1489 for ; Tue, 7 Dec 2021 01:45:34 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id d10so12234352lfg.6 for ; Tue, 07 Dec 2021 01:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nyb19Bv/ezbhKuSGDKV4QQ2oN7H1nSzksMfTJQUOb+s=; b=H+c5cAZS+rV8FQDJx4hgelmX1qvlfKW6wozTkSh+Nb5vsvKtp5UYYw/Rz4ouQwHgeU NZcCxMFmjMCBgslxe8+Qw6gLKmc0DX2VToq6t/A/wQYmZePAV4k9Q2hRlDMywJugtYqw 1hufAdj3G9jpMrCmFkYbBs2Z0BTJgx8N+zLTq9fuPfaK52lVVSoZEij3H5jue60aWcxd ZtyLsUAhW5hpGoyP92m8T7XXCqKMWSwsicTpbPOLWs7Bo1gilx1UckE4YvkoaPV92pEW GUakuE94GEczGtM4aTG8D8pNteDt2kuQB15K5x7cUSUDCBpGl5mMujGjgTd6csSmvr0Q qSIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nyb19Bv/ezbhKuSGDKV4QQ2oN7H1nSzksMfTJQUOb+s=; b=3eRzWcgH98Md78dqv+gXmfTGPMauV0MMnvyUV5pL/R1sRSCoM0rd+hUEbqlyX2AlSi Ws1f6uODqJPhWK+ajapWWC3MphwnjyIETxyqt/6ZmS77zPhyJYpIccUnE7+xdIzX5Lyh t6ZCdfT7bQhWv5RF+QYP1cwdhR/HqNX+TAPMV2pZUi5QZezB1M2Tml0s4wn5DC59rMwm qIi9pNxGxjT6mzMRkATMyVkVoNPHoYMrxAVZKxSvofV0jh4LYg4DADXsGr2O0F/ejPaZ uUX+2W06aJ1uetFFsWi1P04vopiacqKhK5t27SQbIN2uXZiUIbtzXlGophYXDd0cPvTS MYkQ== X-Gm-Message-State: AOAM5337JXXV7wAMde2W+zE4sQc4UOiDLMAqfepRQXT7E2hFry4xjijh 9xpDAfnFaG7lhnFibEF82Ga4YK0aDYJz9S4kIWkLcw== X-Google-Smtp-Source: ABdhPJwk7IpL02ycvvSjUJFsyKGF4Nyhg6qSDE6QoJbfr+XMXeNOjMx8c2oR0dxgu6Rj7pd7LQo3EA5+hiDg0728t00= X-Received: by 2002:ac2:5927:: with SMTP id v7mr39089215lfi.416.1638870327450; Tue, 07 Dec 2021 01:45:27 -0800 (PST) MIME-Version: 1.0 References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <001b01d7e638$0f34baf0$2d9e30d0$@student.utwente.nl> <51448777-038D-4B0D-97D9-129053B5115F@ripe.net> <873EE1A3-B86A-46A3-9D96-AD4BEA21103F@ripe.net> <2C2970A5-33D6-4C49-94E1-F4B87CD8DD14@ripe.net> In-Reply-To: From: George Michaelson Date: Tue, 7 Dec 2021 19:45:15 +1000 Message-ID: To: Job Snijders Cc: SIDR Operations WG Content-Type: multipart/alternative; boundary="000000000000b3707a05d28b3b73" Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2021 09:45:40 -0000 --000000000000b3707a05d28b3b73 Content-Type: text/plain; charset="UTF-8" On Tue, 7 Dec 2021, 7:30 pm Job Snijders, wrote: > On Tue, Dec 07, 2021 at 06:29:33PM +1000, George Michaelson wrote: > > Aside from the 5 RIR who do not directly produce roa, although they do > > publish roa for hosted services in distinct paths what are these much > > larger repositories? Do you mean APNIC or another RIR? Large to object > > size or large to count or ... ? > > One example that comes to mind is: rsync://mirror.leaseweb.com/ (25T, > millions of files, anycasted) > So not an RPKI repository. Context is everything. > When an RSYNC repository is DoSsed, perhaps it is unreachable from some > parts of the world for a brief period of time; but when the RSYNC > operator decides to no longer do their job (by permanently turning off > the RSYNC server); the rsync service goes offline, completing the DoS. > I don't understand the moral force of this sentence in the context of RPKI. > > > rsync has a few benefits over RRDP so I would be very careful about > > > removing rsync support without fixing or adding an RRDP replacement. > > > > It pays to be explicit. What are these benefits? The only one I have > > seen discussed is the cost shifting to compute the object tree from > > deltas (shifted cost to client side in RRDP) vs the complete structure > > in rsync at a cost of per fetch difference calculation, server side. > > 0/ Via rsync all Signed Objects (and all other x509v3 extension > references to related objects) are available as distinct downloadable > resources. This is a wealth of data for debuggers: 'CA Issuers', > 'Signed Object', CRLDP, etc. > OK. A good point. RRDP could do with stable pointers to objects, noting the D has meaning, but the point stands. I think in an http only world the URI below would stand, no? > 1/ An RP has to replay the enitre RRDP session to figure out if they are > desynchronized. RRDP doesn't offer an index table (other than > downloading the entire snapshot). > Seems to me it's fixable. Rsync also does not offer an index that zsync would (IIRC) and incurs index and size and checksum passes server side. Byron and I explored this in our "attack on rsync" presentation to ietf. A hand rolled server can do a lot with in memory state and also walk over the per file checks and just send the stream. There's a lot of optimisation potential in rsync even though I dislike it. > 2/ The RRDP element is unauthenticated and unsigned. > Likewise. > 3/ RRDP clearly was a hackjob: all URIs in the XML are rsync:// URIs. > This is a point of contention. Personally I would have preferred to remove this obligation which dates from prior dependency on the URI. I think this needs to change but I was taken as a co author to "not now" I really don't think hackjob is helpful Job. 4/ The RRDP spec is awfully light on how rsync/rrdp should co-exist. > What relevance does this have to relative merits? Not that it's untrue but it's a non sequester. > 5/ RRDP did not need XML as wrapper, should've/could've been DER. > You want to do raw DER over https? Is there any precedent for that? I agree in principle because.. > 6/ The B in base64 stands for Bloat. > This is of course true. The encoding is a cost. But it's also well understood. > 7/ RRDP has a hard dependency on HTTP Keep-Alive: without Keep-Alive you > might fetch a Notification file from server A, and attempt to fetch > the delta or snapshot from B. Rsync is a single TCP stream, less > sensitive to repository operator mistakes in this regard. > Cache coherency in the local node. Hmm. This is something I hadn't thought about. Thank you. That's informative. > > > There are also disadvantages. Rsync is inherently serialised. Http has > atDE/ > > least implicit parallelism in its transport protocol (HTTPS). And is CDN > > friendly. Rsync CDN support is tcp anycast and that's about it. And the > > ones you stated (lack of implementations, lack of ietf standard) > > I find it interesting how CDNs are SIDROPS' deus ex-machina :-) > > Why is the 'lack of implementations' meme being repeated, even though by > now (anno 2021) more rsync implementations seem to exist than RRDP > implementations? Times have changed. > I repeated a mem the OP responded to. Ask of the OP. > Kind regards, > Kind, Hackjob aside :-) the keep alive thing is well worth noting. Cheers George --000000000000b3707a05d28b3b73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, 7 Dec 2021, 7:30 pm Job Snijders, <job@fastly.com> wrote:
On Tue, Dec 07, 2021 at 06:29:33PM +1000, George Mich= aelson wrote:
> Aside from the 5 RIR who do not directly produce roa, although they do=
> publish roa for hosted services in distinct paths what are these much<= br> > larger repositories? Do you mean APNIC or another RIR? Large to object=
> size or large to count or ... ?

One example that comes to mind is: rsync://mirror.leaseweb.com= / (25T,
millions of files, anycasted)

So not an RPKI repository. Context is everythi= ng.=C2=A0


When an RSYNC repository is DoSsed, perhaps it is unreachable from some
parts of the world for a brief period of time; but when the RSYNC
operator decides to no longer do their job (by permanently turning off
the RSYNC server); the rsync service goes offline, completing the DoS.
<= /blockquote>

I don= 't understand the moral force of this sentence in the context of RPKI.<= /div>


> > rsync has a few benefits over RRDP so I would be very careful abo= ut
> > removing rsync support without fixing or adding an RRDP replaceme= nt.
>
> It pays to be explicit. What are these benefits? The only one I have > seen discussed is the cost shifting to compute the object tree from > deltas (shifted cost to client side in RRDP) vs the complete structure=
> in rsync at a cost of per fetch difference calculation, server side.
0/ Via rsync all Signed Objects (and all other x509v3 extension
=C2=A0 =C2=A0references to related objects) are available as distinct downl= oadable
=C2=A0 =C2=A0resources. This is a wealth of data for debuggers: 'CA Iss= uers',
=C2=A0 =C2=A0'Signed Object', CRLDP, etc.

OK. A good point. RRDP cou= ld do with stable pointers to objects, noting the D has meaning, but the po= int stands. I think in an http only world the URI below would stand, no?


1/ An RP has to replay the enitre RRDP session to figure out if they are =C2=A0 =C2=A0desynchronized. RRDP doesn't offer an index table (other t= han
=C2=A0 =C2=A0downloading the entire snapshot).
=

Seems to me it's fixable.= Rsync also does not offer an index that zsync would (IIRC) and incurs inde= x and size and checksum passes server side. Byron and I explored this in ou= r "attack on rsync" presentation to ietf. A hand rolled server ca= n do a lot with in memory state and also walk over the per file checks and = just send the stream. There's a lot of optimisation potential in rsync = even though I dislike it.


2/ The RRDP <withdraw/> element is unauthenticated and unsigned.
<= /blockquote>

Likew= ise.


3/ RRDP clearly was a hackjob: all URIs in the XML are rsync:// URIs.

This i= s a point of contention. Personally I would have preferred to remove this o= bligation which dates from prior dependency on the URI. I think this needs = to change but I was taken as a co author to "not now"

I really don't think hackjob is= helpful Job.

4/ The RRDP spec is awfully light on how rsync/rrdp should co-exist.

What re= levance does this have to relative merits? Not that it's untrue but it&= #39;s a non sequester.

<= div class=3D"gmail_quote">

5/ RRDP did not need XML as wrapper, should've/could've been DER.

Yo= u want to do raw DER over https? Is there any precedent for that? I agree i= n principle because..


6/ The B in base64 stands for Bloat.

This is of course true. The encoding = is a cost. But it's also well understood.


7/ RRDP has a hard dependency on HTTP Keep-Alive: without Keep-Alive you =C2=A0 =C2=A0might fetch a Notification file from server A, and attempt to = fetch
=C2=A0 =C2=A0the delta or snapshot from B. Rsync is a single TCP stream, le= ss
=C2=A0 =C2=A0sensitive to repository operator mistakes in this regard.
<= /blockquote>

Cache= coherency in the local node. Hmm. This is something I hadn't thought a= bout. Thank you.=C2=A0 That's informative.

> There are also disadvantages. Rsync is inherently serialised. Http has= atDE/=C2=A0
> least implicit parallelism in its transport protocol (HTTPS). And is C= DN
> friendly. Rsync CDN support is tcp anycast and that's about it. An= d the
> ones you stated (lack of implementations, lack of ietf standard)

I find it interesting how CDNs are SIDROPS' deus ex-machina :-)

Why is the 'lack of implementations' meme being repeated, even thou= gh by
now (anno 2021) more rsync implementations seem to exist than RRDP
implementations? Times have changed.

I repeated a mem the OP responded to.= Ask of the OP.


Kind regards,

Kind, Hackjob aside :-) the keep alive thing is well worth not= ing.

Cheers

George=C2=A0
--000000000000b3707a05d28b3b73-- From nobody Tue Dec 7 01:51:38 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8CE3A1494 for ; Tue, 7 Dec 2021 01:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl 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 vehFY48pJINI for ; Tue, 7 Dec 2021 01:51:30 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:65::8:228]) (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 329A93A1483 for ; Tue, 7 Dec 2021 01:51:30 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id BF96685E; Tue, 7 Dec 2021 09:51:25 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1638870684; bh=a2ce/bbf6hVLuoCf0kcnU8Jdp+GCJK880fF/O7uJYks=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=fjrm6XHRztuay82UkZEEdRpiZ0+uWzGD3b6jzMRCXQozMK8U7WpMPQz4FZo9Fb4eq iPdwoT6Qkz/+tpAl5ArzFouZ+8fQhYr6TD+8SVLsTWRPNXmt01GSv6LuMa/F4dQmUx wx6Fh69V5svWOdIK+E8gPFEkExq22Qa5ozObzn9UzacAsZdqP7+RCUT3lJ7SZx64qt h7zgLdwRBYCuZdYz/aF087EFBe09w/Mx6qIogRjXlv06TZl/km8GADob21PZ7jzzMb fLJ12IY7JN4ljpOfH3jNXT1RPxKRkexwBPVuW4tjq1HVBy5W21y7+gSqb12XSNvJ0x fKEA7SFyyOlXA== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Tim Bruijnzeels In-Reply-To: Date: Tue, 7 Dec 2021 10:51:22 +0100 Cc: George Michaelson , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <583F37F7-E55E-4C7C-842C-6FEB65BAF95C@nlnetlabs.nl> References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <001b01d7e638$0f34baf0$2d9e30d0$@student.utwente.nl> <51448777-038D-4B0D-97D9-129053B5115F@ripe.net> <873EE1A3-B86A-46A3-9D96-AD4BEA21103F@ripe.net> <2C2970A5-33D6-4C49-94E1-F4B87CD8DD14@ripe.net> To: Job Snijders Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2021 09:51:36 -0000 > On 7 Dec 2021, at 10:30, Job Snijders = wrote: >=20 >>> rsync has a few benefits over RRDP so I would be very careful about >>> removing rsync support without fixing or adding an RRDP replacement. >>=20 >> It pays to be explicit. What are these benefits? The only one I have >> seen discussed is the cost shifting to compute the object tree from >> deltas (shifted cost to client side in RRDP) vs the complete = structure >> in rsync at a cost of per fetch difference calculation, server side. >=20 > 0/ Via rsync all Signed Objects (and all other x509v3 extension > references to related objects) are available as distinct = downloadable > resources. This is a wealth of data for debuggers: 'CA Issuers', > 'Signed Object', CRLDP, etc. Let me remind you that the proposal is to prefer RRDP, but leave rsync in place as a secondary option. So you can still download files for debugging. Of course all files are also b64 encoded in the snapshot. I understand that is more work - but it's not impossible to get. Also RPs can save the decoded files and many do. > 1/ An RP has to replay the enitre RRDP session to figure out if they = are > desynchronized. RRDP doesn't offer an index table (other than > downloading the entire snapshot). This is why there is a session and serial. If you have reason to believe you are out of sync then get a new snapshot. You are free to disagree with the choice, but the objective was to shift the load onto RPs where it can scale in paralel, rather than leaving it to the server. > 2/ The RRDP element is unauthenticated and unsigned. Indeed, so is rsync's --delete. > 3/ RRDP clearly was a hackjob: all URIs in the XML are rsync:// URIs. >=20 > 4/ The RRDP spec is awfully light on how rsync/rrdp should co-exist. The idea at the time was, and in prefer-rrdp is, that the protocols can co-exist and the rsync URIs are used as identifiers. >=20 > 5/ RRDP did not need XML as wrapper, should've/could've been DER. >=20 > 6/ The B in base64 stands for Bloat. You are welcome to disagree now, but at the time it was decided that rather than inventing a new encoding RRDP would leverage existing code and definitions from the publication protocol (RFC8181). > 7/ RRDP has a hard dependency on HTTP Keep-Alive: without Keep-Alive = you > might fetch a Notification file from server A, and attempt to fetch > the delta or snapshot from B. Rsync is a single TCP stream, less > sensitive to repository operator mistakes in this regard. Server implementation dependent.. Many CDNs will fetch from source on cache misses. In a simple setup with multiple local http proxies one can implement the same. If local copies are used then one can sync the snapshot and deltas first in synchrony, and add a small delay before making notification files available. From nobody Tue Dec 7 02:36:21 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259433A14E2 for ; Tue, 7 Dec 2021 02:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNM18N-82prZ for ; Tue, 7 Dec 2021 02:36:14 -0800 (PST) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0E343A09F2 for ; Tue, 7 Dec 2021 02:36:13 -0800 (PST) Received: (qmail 40167 invoked by uid 1000); 7 Dec 2021 10:36:05 -0000 Date: Tue, 7 Dec 2021 11:36:05 +0100 From: Claudio Jeker To: George Michaelson Cc: SIDR Operations WG Message-ID: References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <001b01d7e638$0f34baf0$2d9e30d0$@student.utwente.nl> <51448777-038D-4B0D-97D9-129053B5115F@ripe.net> <873EE1A3-B86A-46A3-9D96-AD4BEA21103F@ripe.net> <2C2970A5-33D6-4C49-94E1-F4B87CD8DD14@ripe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2021 10:36:19 -0000 On Tue, Dec 07, 2021 at 06:29:33PM +1000, George Michaelson wrote: > On Tue, 7 Dec 2021, 6:18 pm Claudio Jeker, wrote: > > > > > There are some much larger rsync repositories out there then the one from > > RIPE NCC. I think the main issue with rsync is that there is only one real > > implementation of the server and there is no official specification of the > > protocol. > > > > Aside from the 5 RIR who do not directly produce roa, although they do > publish roa for hosted services in distinct paths what are these much > larger repositories? Do you mean APNIC or another RIR? Large to object size > or large to count or ... ? rsync is still used by various software distributions to sync large repositories. For example the OpenBSD CVS repository is made available via multiple rsync servers and at 7.7GB and 500'000 files it is a fair amount larger than any RIR repo. I noticed that many RIR repos like to add unnecessary load on their servers by changing file timestamps in their repositories. This breaks rsync fast path. > > rsync has a few benefits over RRDP so I would be very careful about > > removing rsync support without fixing or adding an RRDP replacement. > > > It pays to be explicit. What are these benefits? The only one I have seen > discussed is the cost shifting to compute the object tree from deltas > (shifted cost to client side in RRDP) vs the complete structure in rsync at > a cost of per fetch difference calculation, server side. RRDP lacks integrity checks. If a file is for whatever resason missing on the RP then it will not be refetched for a very long time. Rsync has the benefit that missing files are refetched automatically. After a rsync run your repository is the same as the on the remote side and any local modification is detected and fixed. RRDP has nothing like that. It only carries a hash for delete and update operations but there is nothing that ensures that other files are actually what their supposed to be. So every file served via RRDP needs to be kept on the RP system even if it has nothing todo with the RPKI. > There are also disadvantages. Rsync is inherently serialised. Http has at > least implicit parallelism in its transport protocol (HTTPS). And is CDN > friendly. Rsync CDN support is tcp anycast and that's about it. And the > ones you stated (lack of implementations, lack of ietf standard) RRDP is inherently serialised. You can not parallel process it. You can run many rsync servers on different IPs. There is no need for tcp anycast. I could run rsync as a CDN but there is probably not that much interest in doing that from the big CDN players. -- :wq Claudio From nobody Tue Dec 7 02:58:26 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E9E3A150E for ; Tue, 7 Dec 2021 02:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20210112.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eowF0hmuRaaC for ; Tue, 7 Dec 2021 02:58:19 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::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 913F53A150F for ; Tue, 7 Dec 2021 02:58:17 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id m12so26657359ljj.6 for ; Tue, 07 Dec 2021 02:58:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Hq+VUhvz29WPVoyUg4uS1TpvhdCPNdcTffMQy/lrUrQ=; b=Hf3KTZYD/fo+f8Mzp1zr+a4bGn3ZAWZXBiKixyTAp7Nf1YYoWHM5YhR3rzNOWPr4Fr aHOtzF3ZHMzDURRf8PYWDg/87d4RW2she0IgWnopgpNIZO8gZ6LsXg0HfXLYlT1KX9/A gIZ+rdGywVqySixqPVW40FXioJQOJ1foLKmN43QVZTPVCrMVgtJzbRO4O8dSg7b1gfbl j7UuxWRb9JoIQqnLcYGuOMUq37YJndpF2BovphIvIj3ZREQtAS7rHVx1kGmOQruoXieU tl/kLiPyrAtT6CEG7UYvy4FCpSrKcXqtAfIx1RRJwaqTP7JLwQvZf1LK1cEk8BY1HM6/ SyNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Hq+VUhvz29WPVoyUg4uS1TpvhdCPNdcTffMQy/lrUrQ=; b=yMWHJNtiityvYzGUZo5fhmPDcqdyqPD2+hOH3m5f5Xpthc5mTBcbMGI5hjw3FlT8U6 QNhhPSKT4ic/nR4OSUrLrzCUOHYGUyA1sX5QNi74J0RALfjHInmYReqtRnlCEunu5mMz e174awb6wPRA1GjlzbJsmONG2ySpgv8HnuQS3kWRGPH54lbZDMjXKD1VoHSfZU7yVtfC k8shOA4faJjXvPmP1i3U+EQW6lkZPr5DTB/Ikva4XT5Q0/9/aSFvjmB0j++PaH3nXlRx dUTuddS7nV4awxliVdx8TLHlTrC9+34Zqf/V+4srvHVfopNrJY05DB9kGol+zjT93qUr tUWQ== X-Gm-Message-State: AOAM533lEzt5wUfxnF0pchFkPs2fUvK0T7PTkvFmbBF3jc3H0yo+yGyG OkVogIQhaU0frfJyqrenWDp8F9f0MLaXSlQp0r8BH3ND18T2Ww== X-Google-Smtp-Source: ABdhPJw57MZkCiPyrO3gakVEF0bf1jrBdb80fMIUIt40uWlxQyYWBxFqZpfzosaP0wxcscXvQcq739tlq/txGfALc6k= X-Received: by 2002:a2e:86da:: with SMTP id n26mr40333795ljj.522.1638874695092; Tue, 07 Dec 2021 02:58:15 -0800 (PST) MIME-Version: 1.0 References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <001b01d7e638$0f34baf0$2d9e30d0$@student.utwente.nl> <51448777-038D-4B0D-97D9-129053B5115F@ripe.net> <873EE1A3-B86A-46A3-9D96-AD4BEA21103F@ripe.net> <2C2970A5-33D6-4C49-94E1-F4B87CD8DD14@ripe.net> In-Reply-To: From: George Michaelson Date: Tue, 7 Dec 2021 20:58:03 +1000 Message-ID: To: Claudio Jeker Cc: SIDR Operations WG Content-Type: multipart/alternative; boundary="000000000000085ec405d28c4027" Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2021 10:58:24 -0000 --000000000000085ec405d28c4027 Content-Type: text/plain; charset="UTF-8" On Tue, 7 Dec 2021, 8:36 pm Claudio Jeker, wrote: > On Tue, Dec 07, 2021 at 06:29:33PM +1000, George Michaelson wrote: > > On Tue, 7 Dec 2021, 6:18 pm Claudio Jeker, > wrote: > > > > > > > > There are some much larger rsync repositories out there then the one > from > > > RIPE NCC. I think the main issue with rsync is that there is only one > real > > > implementation of the server and there is no official specification of > the > > > protocol. > > > > > > > Aside from the 5 RIR who do not directly produce roa, although they do > > publish roa for hosted services in distinct paths what are these much > > larger repositories? Do you mean APNIC or another RIR? Large to object > size > > or large to count or ... ? > > rsync is still used by various software distributions to sync large > repositories. For example the OpenBSD CVS repository is made available via > multiple rsync servers and at 7.7GB and 500'000 files it is a fair amount > larger than any RIR repo. > So as job pointed out this is a generality about the applicability of rsync to massive filestore synchronisation which is what Tridge designed it for. servers by changing file timestamps in their repositories. This breaks > rsync fast path. > To be clear, you must mean when there's been no change to filestate because reissuance of files demands that be resigned and retimestamped. Because of partial update problems a lot of people server side are now doing republication by the near-atomic operation on the root dir of the repository so that its an integral collection. Because of validation failure states for partially updated state. It's possible the mechanistic cheap ways of doing this accidentally change file and dir timestamps, worth noting. We could try harder to avoid this. > > > rsync has a few benefits over RRDP so I would be very careful about > > > removing rsync support without fixing or adding an RRDP replacement. > > > > > > It pays to be explicit. What are these benefits? The only one I have seen > > discussed is the cost shifting to compute the object tree from deltas > > (shifted cost to client side in RRDP) vs the complete structure in rsync > at > > a cost of per fetch difference calculation, server side. > > RRDP lacks integrity checks. If a file is for whatever resason missing on > the RP then it will not be refetched for a very long time. Rsync has the > benefit that missing files are refetched automatically. After a rsync run > your repository is the same as the on the remote side and any local > modification is detected and fixed. RRDP has nothing like that. It only > carries a hash for delete and update operations but there is nothing that > ensures that other files are actually what their supposed to be. > So every file served via RRDP needs to be kept on the RP system even if it > has nothing todo with the RPKI. > I think you're conflating issues here. RRDP is a delta protocol but includes pointers, URI to every object. All rpki objects being signed I don't understand the point about files not being what they are supposed to be. If you mean and adversarial attack, remember the crypto is there. But it is probably fair that neither rsync nor rrdp were designed for bad actor risks. I think people are driving hard to attack RRDP but remember we're here because of the trivially low bar to attacking rsync. > There are also disadvantages. Rsync is inherently serialised. Http has at > > least implicit parallelism in its transport protocol (HTTPS). And is CDN > > friendly. Rsync CDN support is tcp anycast and that's about it. And the > > ones you stated (lack of implementations, lack of ietf standard) > > RRDP is inherently serialised. You can not parallel process it. You can > run many rsync servers on different IPs. There is no need for tcp anycast. > I think we're talking at cross purposes. Per rsync connection there is no internal threading it's a single linear sequence of fetches. If you run two rsyncs in parallel between some A and B you stomp on each others fetches. But in principle (if not in practice) you can thread and multifetch the stream of an RRDP. In any case snapshot aside you fetch less and you do not do per file checking, the delta sync is a smaller total fetch size. I don't think anyone has coded RRDP to exploit parallelism. So this is only in hypothesis. But, unless you move to zsync or other modern takes on rsync this is pretty hard to do. I could run rsync as a CDN but there is probably not that much interest in > doing that from the big CDN players. > As an RIR employee I can only agree. There is no first class support for rsync as a clouded service. We asked. You have to build your own. You can now embed rsync into services which do closest TCP provider mapping, but there's no meaningful edge cache. APNICs AS0 is in cloudflare and there is a significant RTT advantage in second fetcher because of the caching, which came along for free in http cloud services. Cheers G > --000000000000085ec405d28c4027 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, 7 Dec 2021, 8:36 pm Claudio Jeker, <cjeker@diehard.n-r-g.com> wrote= :
On Tue, Dec 07, 2021 at 06:29:33P= M +1000, George Michaelson wrote:
> On Tue, 7 Dec 2021, 6:18 pm Claudio Jeker, <cjeker@diehard.n-= r-g.com> wrote:
>
> >
> > There are some much larger rsync repositories out there then the = one from
> > RIPE NCC. I think the main issue with rsync is that there is only= one real
> > implementation of the server and there is no official specificati= on of the
> > protocol.
> >
>
> Aside from the 5 RIR who do not directly produce roa, although they do=
> publish roa for hosted services in distinct paths what are these much<= br> > larger repositories? Do you mean APNIC or another RIR? Large to object= size
> or large to count or ... ?

rsync is still used by various software distributions to sync large
repositories. For example the OpenBSD CVS repository is made available via<= br> multiple rsync servers and at 7.7GB and 500'000 files it is a fair amou= nt
larger than any RIR repo.
So as job pointed out this is a generality about t= he applicability of rsync to massive filestore synchronisation which is wha= t Tridge designed it for.

servers by chan= ging file timestamps in their repositories. This breaks
rsync fast path.

To be clear, you must mean when there's been no change = to filestate because reissuance of files demands that be resigned and retim= estamped.

Because of par= tial update problems a lot of people server side are now doing republicatio= n by the near-atomic operation on the root dir of the repository so that it= s an integral collection. Because of validation failure states for partiall= y updated state. It's possible the mechanistic cheap ways of doing this= accidentally change file and dir timestamps, worth noting. We could try ha= rder to avoid this.


> > rsync has a few benefits over RRDP so I would be very careful abo= ut
> > removing rsync support without fixing or adding an RRDP replaceme= nt.
>
>
> It pays to be explicit. What are these benefits? The only one I have s= een
> discussed is the cost shifting to compute the object tree from deltas<= br> > (shifted cost to client side in RRDP) vs the complete structure in rsy= nc at
> a cost of per fetch difference calculation, server side.

RRDP lacks integrity checks. If a file is for whatever resason missing on the RP then it will not be refetched for a very long time. Rsync has the benefit that missing files are refetched automatically. After a rsync run your repository is the same as the on the remote side and any local
modification is detected and fixed. RRDP has nothing like that. It only
carries a hash for delete and update operations but there is nothing that ensures that other files are actually what their supposed to be.
So every file served via RRDP needs to be kept on the RP system even if it<= br> has nothing todo with the RPKI.

I think you're conflating issues here. R= RDP is a delta protocol but includes pointers, URI to every object. All rpk= i objects being signed I don't understand the point about files not bei= ng what they are supposed to be. If you mean and adversarial attack, rememb= er the crypto is there.

= But it is probably fair that neither rsync nor rrdp were designed for bad a= ctor risks. I think people are driving hard to attack RRDP but remember we&= #39;re here because of the trivially low bar to attacking rsync.


> T= here are also disadvantages. Rsync is inherently serialised. Http has at
> least implicit parallelism in its transport protocol (HTTPS). And is C= DN
> friendly. Rsync CDN support is tcp anycast and that's about it. An= d the
> ones you stated (lack of implementations, lack of ietf standard)

RRDP is inherently serialised. You can not parallel process it. You can
run many rsync servers on different IPs. There is no need for tcp anycast.<= br>

I= think we're talking at cross purposes. Per rsync connection there is n= o internal threading it's a single linear sequence of fetches. If you r= un two rsyncs in parallel between some A and B you stomp on each others fet= ches.

But in principle (= if not in practice) you can thread and multifetch the stream of an RRDP. In= any case snapshot aside you fetch less and you do not do per file checking= , the delta sync is a smaller total fetch size.

=
I don't think anyone has coded RRDP to exploit = parallelism. So this is only in hypothesis. But, unless you move to zsync o= r other modern takes on rsync this is pretty hard to do.


I could run rsync as a CDN but there is probably not that much interest in<= br> doing that from the big CDN players.

As an RIR employee I can only agree. = There is no first class support for rsync as a clouded service. We asked. Y= ou have to build your own. You can now embed rsync into services which do c= losest TCP provider mapping, but there's no meaningful edge cache. APNI= Cs AS0 is in cloudflare and there is a significant RTT advantage in second = fetcher because of the caching, which came along for free in http cloud ser= vices.

Cheers

G
--000000000000085ec405d28c4027-- From nobody Tue Dec 7 03:52:05 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D100C3A1577 for ; Tue, 7 Dec 2021 03:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl 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 kRl8z-5ECdjU for ; Tue, 7 Dec 2021 03:51:58 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:65::8:228]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2B4D3A1576 for ; Tue, 7 Dec 2021 03:51:57 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 089C884E; Tue, 7 Dec 2021 11:51:54 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1638877913; bh=HKJ05npigtQDDAm6CdeF5i/f3rh3FZONGqauUoyJnqY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=QljVW+9DfJJM4yVKIe/EuYB7czDJXC9KBHSx59EK0a5Q3viJiCy/gRgVKmaF0h8b3 8PrbTuOMil0QA8NaQ+7ixYsMmMPZKo0Manw6lJqH8PtD0taL4Q02Eu0gL0dbAWBcYu gCWRT+cvaNjD8AvhC7mRMyQ+4xOwRqyrp3orS9ajpvYaYorKh66Mv3CT3gErfkLfnO 2/8XWxns13HYboPo4PFOG2OzrFl5464lZ77annkagl90/Ck7QTg7qhF6alBzcCW56s K/o/5NXGR9cHJ3/f5zVBSMSfUGCDpbhvjp4GLo/y2C0mKM1Q3/fvd09P4kDJhIxhKM AVTLUlLjC2wHQ== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) From: Alex Band In-Reply-To: Date: Tue, 7 Dec 2021 12:51:50 +0100 Cc: George Michaelson , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <7934B8F0-1052-4D71-A218-0E816B0E469D@nlnetlabs.nl> References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <001b01d7e638$0f34baf0$2d9e30d0$@student.utwente.nl> <51448777-038D-4B0D-97D9-129053B5115F@ripe.net> <873EE1A3-B86A-46A3-9D96-AD4BEA21103F@ripe.net> <2C2970A5-33D6-4C49-94E1-F4B87CD8DD14@ripe.net> To: Claudio Jeker Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2021 11:52:04 -0000 An aspect that appears to be overlooked is the operational experience a = typical ISP or cloud provider will have with running a highly available = rsync service vs an HTTP service. While it may be technically possible = to offer rsync at scale, the barrier to having an IT department commit = to operating a globally load balanced HTTP service is much lower than = doing the same for rsync, purely from an experience standpoint.=20 I know for a fact that the rsync requirement has been the reason for = several operators to abandon their plans for running Delegated RPKI.=20 Be that as it may, with the prospect of more RIRs offering RFC8181 = publication services this barrier is likely taken away. It=E2=80=99ll be = interesting to see if the ~10 Delegated RPKI instances in the ARIN = region now will start rising to the likes of the ~1000 in Brazil at the = moment. -Alex > On 7 Dec 2021, at 11:36, Claudio Jeker = wrote: >=20 > On Tue, Dec 07, 2021 at 06:29:33PM +1000, George Michaelson wrote: >> On Tue, 7 Dec 2021, 6:18 pm Claudio Jeker, = wrote: >>=20 >>>=20 >>> There are some much larger rsync repositories out there then the one = from >>> RIPE NCC. I think the main issue with rsync is that there is only = one real >>> implementation of the server and there is no official specification = of the >>> protocol. >>>=20 >>=20 >> Aside from the 5 RIR who do not directly produce roa, although they = do >> publish roa for hosted services in distinct paths what are these much >> larger repositories? Do you mean APNIC or another RIR? Large to = object size >> or large to count or ... ? >=20 > rsync is still used by various software distributions to sync large > repositories. For example the OpenBSD CVS repository is made available = via > multiple rsync servers and at 7.7GB and 500'000 files it is a fair = amount > larger than any RIR repo. >=20 > I noticed that many RIR repos like to add unnecessary load on their > servers by changing file timestamps in their repositories. This breaks > rsync fast path. >=20 >>> rsync has a few benefits over RRDP so I would be very careful about >>> removing rsync support without fixing or adding an RRDP replacement. >>=20 >>=20 >> It pays to be explicit. What are these benefits? The only one I have = seen >> discussed is the cost shifting to compute the object tree from deltas >> (shifted cost to client side in RRDP) vs the complete structure in = rsync at >> a cost of per fetch difference calculation, server side. >=20 > RRDP lacks integrity checks. If a file is for whatever resason missing = on > the RP then it will not be refetched for a very long time. Rsync has = the > benefit that missing files are refetched automatically. After a rsync = run > your repository is the same as the on the remote side and any local > modification is detected and fixed. RRDP has nothing like that. It = only > carries a hash for delete and update operations but there is nothing = that > ensures that other files are actually what their supposed to be. > So every file served via RRDP needs to be kept on the RP system even = if it > has nothing todo with the RPKI. >=20 >> There are also disadvantages. Rsync is inherently serialised. Http = has at >> least implicit parallelism in its transport protocol (HTTPS). And is = CDN >> friendly. Rsync CDN support is tcp anycast and that's about it. And = the >> ones you stated (lack of implementations, lack of ietf standard) >=20 > RRDP is inherently serialised. You can not parallel process it. You = can > run many rsync servers on different IPs. There is no need for tcp = anycast. > I could run rsync as a CDN but there is probably not that much = interest in > doing that from the big CDN players. >=20 > --=20 > :wq Claudio >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Dec 7 03:57:18 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593313A157E for ; Tue, 7 Dec 2021 03:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8d-S6m5mDnc for ; Tue, 7 Dec 2021 03:57:11 -0800 (PST) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541FF3A157D for ; Tue, 7 Dec 2021 03:57:10 -0800 (PST) Received: (qmail 51094 invoked by uid 1000); 7 Dec 2021 11:57:08 -0000 Date: Tue, 7 Dec 2021 12:57:08 +0100 From: Claudio Jeker To: George Michaelson Cc: SIDR Operations WG Message-ID: References: <001b01d7e638$0f34baf0$2d9e30d0$@student.utwente.nl> <51448777-038D-4B0D-97D9-129053B5115F@ripe.net> <873EE1A3-B86A-46A3-9D96-AD4BEA21103F@ripe.net> <2C2970A5-33D6-4C49-94E1-F4B87CD8DD14@ripe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2021 11:57:17 -0000 On Tue, Dec 07, 2021 at 08:58:03PM +1000, George Michaelson wrote: > On Tue, 7 Dec 2021, 8:36 pm Claudio Jeker, wrote: > > > On Tue, Dec 07, 2021 at 06:29:33PM +1000, George Michaelson wrote: > > > On Tue, 7 Dec 2021, 6:18 pm Claudio Jeker, > > wrote: > > > > > > > > > > > There are some much larger rsync repositories out there then the one > > from > > > > RIPE NCC. I think the main issue with rsync is that there is only one > > real > > > > implementation of the server and there is no official specification of > > the > > > > protocol. > > > > > > > > > > Aside from the 5 RIR who do not directly produce roa, although they do > > > publish roa for hosted services in distinct paths what are these much > > > larger repositories? Do you mean APNIC or another RIR? Large to object > > size > > > or large to count or ... ? > > > > rsync is still used by various software distributions to sync large > > repositories. For example the OpenBSD CVS repository is made available via > > multiple rsync servers and at 7.7GB and 500'000 files it is a fair amount > > larger than any RIR repo. > > > > So as job pointed out this is a generality about the applicability of rsync > to massive filestore synchronisation which is what Tridge designed it for. > > servers by changing file timestamps in their repositories. This breaks > > rsync fast path. > > > > To be clear, you must mean when there's been no change to filestate because > reissuance of files demands that be resigned and retimestamped. > > Because of partial update problems a lot of people server side are now > doing republication by the near-atomic operation on the root dir of the > repository so that its an integral collection. Because of validation > failure states for partially updated state. It's possible the mechanistic > cheap ways of doing this accidentally change file and dir timestamps, worth > noting. We could try harder to avoid this. I just noticed that rsync refetches the hole repository more often than it has to. This is because timestamps change but the file content is still the same. So this adds extra load to the rsync servers. > > > > rsync has a few benefits over RRDP so I would be very careful about > > > > removing rsync support without fixing or adding an RRDP replacement. > > > > > > > > > It pays to be explicit. What are these benefits? The only one I have seen > > > discussed is the cost shifting to compute the object tree from deltas > > > (shifted cost to client side in RRDP) vs the complete structure in rsync > > at > > > a cost of per fetch difference calculation, server side. > > > > RRDP lacks integrity checks. If a file is for whatever resason missing on > > the RP then it will not be refetched for a very long time. Rsync has the > > benefit that missing files are refetched automatically. After a rsync run > > your repository is the same as the on the remote side and any local > > modification is detected and fixed. RRDP has nothing like that. It only > > carries a hash for delete and update operations but there is nothing that > > ensures that other files are actually what their supposed to be. > > So every file served via RRDP needs to be kept on the RP system even if it > > has nothing todo with the RPKI. > > > > I think you're conflating issues here. RRDP is a delta protocol but > includes pointers, URI to every object. All rpki objects being signed I > don't understand the point about files not being what they are supposed to > be. If you mean and adversarial attack, remember the crypto is there. I can send you a delta that holds files that are not in the snapshot. You will store those files in your cache until you fetch a new snapshot. This way the disk on RP systems can be filled with very little effort from a publication point. RRDP is a weak delta protocol there is no way to know if all files are present because there is no index which can be compared. In this regard the consistency of the database is just presumed. > But it is probably fair that neither rsync nor rrdp were designed for bad > actor risks. I think people are driving hard to attack RRDP but remember > we're here because of the trivially low bar to attacking rsync. The problem here is that RPKI is setup in a way that makes it easy to DoS RP software. It does not matter if RRDP or rsync are used. > > There are also disadvantages. Rsync is inherently serialised. Http has at > > > > least implicit parallelism in its transport protocol (HTTPS). And is CDN > > > friendly. Rsync CDN support is tcp anycast and that's about it. And the > > > ones you stated (lack of implementations, lack of ietf standard) > > > > RRDP is inherently serialised. You can not parallel process it. You can > > run many rsync servers on different IPs. There is no need for tcp anycast. > > > > I think we're talking at cross purposes. Per rsync connection there is no > internal threading it's a single linear sequence of fetches. If you run two > rsyncs in parallel between some A and B you stomp on each others fetches. How is this different to a HTTPS connection? There is not internal threading there either. If you run two RRDP processes in parallel you also stomp on each other fetches. > But in principle (if not in practice) you can thread and multifetch the > stream of an RRDP. In any case snapshot aside you fetch less and you do not > do per file checking, the delta sync is a smaller total fetch size. > > I don't think anyone has coded RRDP to exploit parallelism. So this is only > in hypothesis. But, unless you move to zsync or other modern takes on rsync > this is pretty hard to do. You must apply all RRDP deltas in order. You can not apply them in parallel or you may end up with a corrupted repository. In this regard I think RRDP and rsync are behaving the same way. >From a security standpoint neither RRDP nor rsync are good. In RPKI all risks are on the RP side and very little on the side of publication points. This is a fundamental issue. > I could run rsync as a CDN but there is probably not that much interest in > > doing that from the big CDN players. > > > > As an RIR employee I can only agree. There is no first class support for > rsync as a clouded service. We asked. You have to build your own. You can > now embed rsync into services which do closest TCP provider mapping, but > there's no meaningful edge cache. APNICs AS0 is in cloudflare and there is > a significant RTT advantage in second fetcher because of the caching, which > came along for free in http cloud services. -- :wq Claudio From nobody Tue Dec 7 09:58:20 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A883A17D5 for ; Tue, 7 Dec 2021 09:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxxgBs5cnbQU for ; Tue, 7 Dec 2021 09:58:13 -0800 (PST) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 4C5EA3A17D4 for ; Tue, 7 Dec 2021 09:58:13 -0800 (PST) Received: by mail-pf1-x42d.google.com with SMTP id o4so27579pfp.13 for ; Tue, 07 Dec 2021 09:58:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QJHmLSQisrpMYfSuOGHPfWLJHrUYEr2k1w7M4z0BUXA=; b=JlgJKKkO2s6x4314neYzadZjr1Bf5QWOdI002H3ZM1R3xBffntItvBgDjMSn0xlpgx QH7XNiNve7cmbfhumlgdlxe4+WY7BUibTUs8HFqEFvpVqTT74aPuriosMphjP/2Ro5+t ZS9IMacUwHz4bVN8/59QnJsEY/6miPUn76TlbQdcrkAP4cl9Q9mt18NhbBEpO1FQXiaP pEq2H3IpM4f0n4BfaTY7nlVnW1U3ZydAIDAt5hsS0Qn6m1ovrscgNdEM6I5SlcJeX7yp /CFnIriO6kqi1jDNN6/MBTM/rAjAd02nQ2pN6jUUtjPunF8BBYSfGToqc8bd7fF2ZvuE ss/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QJHmLSQisrpMYfSuOGHPfWLJHrUYEr2k1w7M4z0BUXA=; b=uABYxinqCcZTC1qrE+9C375dW7nt2QfdzZB7W8s6f3qD2ZcfxJmf7qmTYP26EjgPvq +D1PawVxIoDq0O7AM/j8EGkCS4VW7IuStSJsxCiwSBvt6wN5viOYRS5Np94DrRaWg7yO +gnAWpeZZGJ/FmMnlNNX/Ff2roJtGXSvqDmYQzqr9VRd3gkpJZ8JY89yxXVOS51AmVk2 TPzt2jhCXRcjP3QVvuim+AhvdtsfqJMG/DjiKDVBdmxV21A3mGAc6uZSXww1MEhNkErp CAUzHRN3giiwsKNPchSophOBBCG6u58IW/tKfmRHqiVsP6/O5IrO6EkP62pAadl9UwBV btZw== X-Gm-Message-State: AOAM532zmtr8WwpwOBSrFIEzQGZBzD/lhuSXPXSJskBaUvNMojaIuGJe WYOCUgrAzf5PwsuUNVC5mgkwmwx0iqRWJVL078g= X-Google-Smtp-Source: ABdhPJwbRg923IyHkSqRCY8xJt+W0wbMBoBdOCst7DDweh8Oqb6O7qdXrNXF8GdzZbb0ZrK03Dy8VQ8M1zmMS0EqFE0= X-Received: by 2002:a05:6a00:24c7:b0:4a0:41b:38f9 with SMTP id d7-20020a056a0024c700b004a0041b38f9mr683223pfv.54.1638899891396; Tue, 07 Dec 2021 09:58:11 -0800 (PST) MIME-Version: 1.0 References: <00E18520-A535-4CC8-A287-56FB2F164E14@nist.gov> <5B2CD457-E376-4B8C-B901-202ACC4C465C@ripe.net> In-Reply-To: From: Alexander Azimov Date: Tue, 7 Dec 2021 20:58:00 +0300 Message-ID: To: Job Snijders Cc: Nick Hilliard , "sidrops@ietf.org" , Ties de Kock Content-Type: multipart/alternative; boundary="000000000000d962d905d2921d05" Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-rpkimaxlen-08 - ends 25/October/2021 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2021 17:58:18 -0000 --000000000000d962d905d2921d05 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear colleagues, I mixed up the 'reply all' and 'reply' buttons, and only Job was able to see my reply and keep on the discussion. I'm sending the original message to the mailing list so we can proceed from this point. =D1=81=D1=80, 24 =D0=BD=D0=BE=D1=8F=D0=B1. 2021 =D0=B3. =D0=B2 13:42, Job S= nijders : > On Tue, Nov 23, 2021 at 04:43:26PM +0300, Alexander Azimov wrote: > > In the world with high adoption rate of ROV I would have definitely > > supported this document for publication. > > Unfortunately, according to latest research by Geoff Huston - we are > > living in a very different world. > > Can you provide a reference for this 'latest research'? > Oops, forgot to add it: https://www.potaroo.net/presentations/2021-10-20-isoc-rpki.pdf > > We have steady progress in signing ROAs but far less progress in > > adopting ROV. And you can't easily distinguish is it safe enough to > > start using maximal ROA length or not. For the network that I'm > > responsible at the moment - it is not safe. > > Can you elaborate? This seems a rather subjective statement. In any > regard, you are free to configure your own ROAs as you deem fit for > purpose. :-) > Another complication may happen when ROV is done at egress (rfc8893). > > In case of fast de-aggreagation you may need to turn it off, though > > such issue is much easier to resolve. > > To sum it up: I still have a feeling that the document is ahead of its > > time, and in the imperfect world may itroduce new gaps between > > routing-security-in-theory and operations. > > I fail to see how this document introduces new gaps. It merely warns > about the potential pitfalls of using the maxlen macro functionality. > Yes, I'm free to configure whatever I like, and the authors of the document are free to do it in a different way. The difference is that authors of these documents suggest their operational practice as BCP, and I can't agree that this practice is safe at the moment= . Let's elaborate what kind of events we are facing at the moment. The majority of hijacks and route leaks are mistakes. We can assume that the difference between accidental and malicious hijacks is absence of forged as path in case of accidental events. So, ROA with ANY prefix length is good enough to limit the blast radius of accidental hijacks. Unfortunately ROV deployment isn't at the level when we are no longer affected by accidental hijacks. And the best option is instant prefix deaggregation, if it is possible. And I hope you will agree - the time is precious. Now let's discuss how the recommendations from this document may complicate things that already got nasty due to the fact that your address space was hijacked. *Scenario 1:* Being a proactive and BCP aware autonomous system holder, one may add egress ROV with strict policy to drop Invalid routes with an exception to blackhole routes. In case of a hijack this good citizen will have to relax it's routing policy/turn off ROV on egress. It is still not that bad, but in huge companies with complicated access rules to devices, it may still take time. *Scenario 2:* Previously I described this scenario as two islands of good and bad actors, where good actors perform ROV and sign minimal ROA, bad actors that perform hijacks and 'ocean' of Internet in the middle. In this scenario good actors lose opportunity for deaggregation without updating ROA records. Let's give it a more realistic and simple shape. Let we have an ASX that peers with two 'important ISPs' in selected regions. These two ISPs (ASY and ASZ) have significant intersections in their customer cones. ASX creates ROA, ASZ does perform ROV, ASY doesn't. And a customer of ASY makes an accidental more specific hijack, and due to lack of filtering it is accepted by ASY. Since it is customer's route it gets higher local preference, and prefix deaggregation toward ASY doesn't help. But deaggregation toward ASZ may be helpful, since we will have two routes with same length competing in the intersection of customer cones of ASY and ASZ. If ASX has ROA with maximum prefix length, this simple technique will reroute back to ASX at least portion of the traffic. If ASX has ROA with minimal prefix length - effective deaggregation will be possible only after ROA update. So IMO minimal prefix length will be safe if all 'important' peers of selected AS support ROV. For Yandex this statement is not true. I wonder how many networks can say that they fulfill this requirement today. =D1=81=D1=80, 24 =D0=BD=D0=BE=D1=8F=D0=B1. 2021 =D0=B3. =D0=B2 13:42, Job S= nijders : > On Tue, Nov 23, 2021 at 04:43:26PM +0300, Alexander Azimov wrote: > > In the world with high adoption rate of ROV I would have definitely > > supported this document for publication. > > Unfortunately, according to latest research by Geoff Huston - we are > > living in a very different world. > > Can you provide a reference for this 'latest research'? > > > We have steady progress in signing ROAs but far less progress in > > adopting ROV. And you can't easily distinguish is it safe enough to > > start using maximal ROA length or not. For the network that I'm > > responsible at the moment - it is not safe. > > Can you elaborate? This seems a rather subjective statement. In any > regard, you are free to configure your own ROAs as you deem fit for > purpose. :-) > > > Another complication may happen when ROV is done at egress (rfc8893). > > In case of fast de-aggreagation you may need to turn it off, though > > such issue is much easier to resolve. > > To sum it up: I still have a feeling that the document is ahead of its > > time, and in the imperfect world may itroduce new gaps between > > routing-security-in-theory and operations. > > I fail to see how this document introduces new gaps. It merely warns > about the potential pitfalls of using the maxlen macro functionality. > > Kind regards, > > Job > --=20 Best regards, Alexander Azimov --000000000000d962d905d2921d05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear colleagues,

I mixed up the 're= ply all' and 'reply' buttons, and only Job was able to see my r= eply and keep on the discussion.=C2=A0
I'm sending the origin= al message to the mailing list so we can proceed from this point.

=D1=81=D1=80, 24=C2=A0=D0=BD=D0=BE=D1=8F=D0=B1. 2021 = =D0=B3. =D0=B2 13:42, Job Snijders <job@fastly.com>:
On Tue, Nov 23, 2021 at 04:43:26PM +0300, Alexander Azimov wrote:
>= ; In the world with high adoption rate of ROV I would have definitely
&g= t; supported this document for publication.
> Unfortunately, accordin= g to latest research by Geoff Huston - we are
> living in a very diff= erent world.

Can you provide a reference for this 'latest resear= ch'?
=C2=A0<= /div>
> We have steady = progress in signing ROAs but far less progress in
> adopting ROV.=C2= =A0 And you can't easily distinguish is it safe enough to
> start= using maximal ROA length or not. For the network that I'm
> resp= onsible at the moment - it is not safe.

Can you elaborate? This seem= s a rather subjective statement. In any
regard, you are free to configur= e your own ROAs as you deem fit for
purpose. :-)
> Another comp= lication may happen when ROV is done at egress (rfc8893).
> In case o= f fast de-aggreagation you may need to turn it off, though
> such iss= ue is much easier to resolve.
> To sum it up: I still have a feeling = that the document is ahead of its
> time, and in the imperfect world = may itroduce new gaps between
> routing-security-in-theory and operat= ions.

I fail to see how this document introduces new gaps. It merely= warns
about the potential pitfalls of using the maxlen macro functional= ity.
Yes, I'= ;m free to configure whatever I like, and the authors of the document are f= ree to do it in a different=C2=A0way.=C2=A0
The difference is tha= t authors of these documents suggest their operational practice as BCP, and= I can't agree that=C2=A0this practice is safe=C2=A0at the moment.

Let's elaborate what kind of events we are facing at th= e moment.=C2=A0
The majority of hijacks and= route leaks are mistakes. We can assume that the difference between accide= ntal and malicious hijacks is absence of forged=C2=A0as=C2=A0path=C2=A0in c= ase of accidental events.=C2=A0
So, ROA wit= h ANY prefix length=C2=A0is good enough to limit the blast radius of accide= ntal hijacks.

Unfortunately ROV deployment isn't at the level when we are no = longer affected by accidental hijacks. And the=C2=A0best option is instant = prefix deaggregation, if it is possible.
An= d I hope you will agree - the time is precious.=C2=A0

Now let's discuss how t= he recommendations from this document may complicate things that already go= t nasty due to the fact that your address space was hijacked.

Scenario 1= :
Being a proactive and BCP aware auton= omous system holder, one may add egress ROV with strict policy to drop Inva= lid routes with an exception to blackhole routes.=C2=A0
In case of a hijack this good citizen will have to relax it= 9;s routing policy/turn off ROV on egress. It is still not that bad, but in= huge companies with complicated access rules to devices, it may still take= time.

Scenario 2:
Previously I described = this scenario as two islands of good and bad actors, where good actors perf= orm ROV and sign minimal=C2=A0ROA, bad actors that perform hijacks and '= ;ocean' of Internet in the middle. In this scenario good actors lose=C2= =A0opportunity for deaggregation without updating ROA records. Let's gi= ve it a more realistic and simple shape.=C2=A0

Let we have an ASX that peers with= two 'important ISPs' in selected regions. These two ISPs (ASY and = ASZ) have significant intersections in their customer cones.
ASX creates ROA, ASZ does perform ROV, ASY doesn't. A= nd a customer of ASY makes an accidental more specific hijack, and due to l= ack of filtering it is accepted by ASY.=C2=A0
Since it is customer's route it gets higher local preference, and pr= efix deaggregation=C2=A0toward ASY doesn't help.
But deaggregation toward ASZ may be helpful, since we will have t= wo routes with same length competing in the intersection of customer cones = of ASY and ASZ.=C2=A0

If ASX has ROA with maximum prefix length, this simple tec= hnique will reroute back to ASX at least portion of the traffic.=C2=A0
If ASX has ROA with minimal prefix length - eff= ective deaggregation will be possible only=C2=A0after ROA update.

So IMO minimal = prefix length will be safe if all 'important' peers of selected AS = support ROV. For Yandex this statement is not true.=C2=A0
I= wonder how many networks can say that they fulfill this requirement today.= =C2=A0

=D1=81=D1=80, 24 =D0=BD=D0=BE=D1=8F=D0=B1. 2021 =D0=B3. =D0=B2 = 13:42, Job Snijders <job@fastly.com>:
On Tue, N= ov 23, 2021 at 04:43:26PM +0300, Alexander Azimov wrote:
> In the world with high adoption rate of ROV I would have definitely > supported this document for publication.
> Unfortunately, according to latest research by Geoff Huston - we are > living in a very different world.

Can you provide a reference for this 'latest research'?

> We have steady progress in signing ROAs but far less progress in
> adopting ROV.=C2=A0 And you can't easily distinguish is it safe en= ough to
> start using maximal ROA length or not. For the network that I'm > responsible at the moment - it is not safe.

Can you elaborate? This seems a rather subjective statement. In any
regard, you are free to configure your own ROAs as you deem fit for
purpose. :-)

> Another complication may happen when ROV is done at egress (rfc8893).<= br> > In case of fast de-aggreagation you may need to turn it off, though > such issue is much easier to resolve.
> To sum it up: I still have a feeling that the document is ahead of its=
> time, and in the imperfect world may itroduce new gaps between
> routing-security-in-theory and operations.

I fail to see how this document introduces new gaps. It merely warns
about the potential pitfalls of using the maxlen macro functionality.

Kind regards,

Job


--
Best regards,
Alexander Azi= mov
--000000000000d962d905d2921d05-- From nobody Tue Dec 7 10:08:14 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFB93A17DF for ; Tue, 7 Dec 2021 10:08:12 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdIOiJDDQSlM for ; Tue, 7 Dec 2021 10:08:11 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 538363A17DE for ; Tue, 7 Dec 2021 10:08:11 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1muesp-00063G-DX; Tue, 07 Dec 2021 18:08:07 +0000 Date: Tue, 07 Dec 2021 10:08:06 -0800 Message-ID: From: Randy Bush To: Tim Bruijnzeels Cc: SIDR Operations WG In-Reply-To: <3413E245-55FF-4C8E-BB93-BFD48C3F1A1F@nlnetlabs.nl> References: <3413E245-55FF-4C8E-BB93-BFD48C3F1A1F@nlnetlabs.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] three 8210bis issues X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2021 18:08:13 -0000 tim, [ excuse my loss of humor. but some of this is getting old ] > Generally speaking though, I think we need closure on the ASPA profile > changes as proposed and discussed. only if they affect the wire between cache and router > Note that there is also a proposal to have both v4 and v6 providers on > a single ASPA object. as the two AFIs have very different topologies, i assume this is just noise and people will get over it. > An alternative that I can think of is that there would be three length > fields. One for v4+v6, one for v4 only, one for v6. Any of which can > have length 0. Then a single PDU can contain the same data as a single > ASPA object, with a total combined length of 0 implying a withdraw > (see below). welcome to the ietf, where we take something simple and make it much more complex. why don't we merge the ROA AFIs too? sheesh! > There was a proposal to have an explicitly signed empty list of > providers, rather than overloading AS0 to mean no (valid) providers. which is what -04 says. overloading magic values has a long unhappy history in software engineering. if folk really want to do this, i propose AS17, or maybe AS666. > If the ASPA profile -07 were to go for empty provider list rather than > AS0, then an explicit empty list PDU would be needed and it would not > be a withdraw. I.e. we would need to flag 'no ASPA for customer ASN' vs > 'no providers for customer ASN'. you may want to actually look at -04 and, btw, as in previous discussion, what the RP receives from the global rpki need not be what the RP sends to the router. so it can receive some kinky signal such as AS17 and send a null list to the router. > Can we conclude that the ASPA profile will keep AS0 and a minimal length > of 1 provider? while i do not think that is useful or wise, this draft is not the place to discuss it, see my previous paragraph. >> 2 - the ROA PDUs are sent one Prefix/AS tuple at a time. currently, the >> ASPA PDU groups all Providers into one tuple for the single >> Customer. >> >> the intuition was that ASPA is a one to many mapping while ROAs are >> one to one mappings. but the result is different program flows on >> both ends of the protocol. >> >> for an ASPA PDU, currently the cache and router need not worry what >> the other thinks; a new ASPA is an implicit withdraw of the previous >> ASPA data in the router. this is in contrast to ROAs and Router Key >> PDUs, where the cache and router must be aware of the other's state, >> and if discovered to be out of sync, a reset MUST be performed. >> >> -04 does not change this for the moment. more insight is needed. >> it would be especially good to hear from more router side folk. > > I somewhat dislike it being inconsistent with how ROA VRPs are treated. > I also dislike that it could result in long PDUs being resent - the > current limit is 64k providers.. in practice I don't expect to see that > much, but the protocol allows it. I don't think this would impact the > RTR server much, but it could impact routers. ok, i will put on my vendor hat. part of the discussion oliver and i had is the unfortunate reality that there are ops with deployed routers which do not have the resources to buffer an entire rpki-rtr session and then process only once the End of Data PDU is received. and the size of a full fresh rpki-rtr data set is growing. so it would be extremely anti-pola to retroactively require this. if the cache sends cust/provider tuples for cust AS42 one at a time to the router, as each one arrives, does the router need to sweep all paths to revalidate? how does it know it has the full provider set? ... as i tried to hint, i would really like to hear from [other] router vendors on this. randy From nobody Wed Dec 8 02:42:30 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B7D3A0D2D for ; Wed, 8 Dec 2021 02:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl 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 H65zFazvYQle for ; Wed, 8 Dec 2021 02:42:24 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [116.202.126.228]) (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 B9FFF3A0D33 for ; Wed, 8 Dec 2021 02:42:23 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id D62DB66; Wed, 8 Dec 2021 10:42:16 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1638960136; bh=jq0Mre/y5PpXCX4nX6ES63y4qyKUsLvW41kDXXrik4Q=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=UoD7e9YNFBEA2wz/IGTTa0zBo3evkhxLwWswGxHcZEj6UVdH/JXHqPuv3p1qed9Ch L56ljkbhDsg7K97LjzJUd2dW11cokfsTPw0YZzKcdpUU1c+i8giLDq22ZQUldMx8Fp eUjy7398YoqNJEjYWcmFYkTVtthLr9/Uf2ZT1W4Dq9Ay7w1iwYTfEjjHDUnveq48Bd FwLxo76sjGSzFHdDR1zpPBgdmYP3eQ/8CYQYhaU1uB0oyQZ8UHoK0ILDeWfs1vQ5s1 RTOz2AxTk2GgM7APf8B+IDQv6AmtXbtQc6ADRo52udjpVzdyUQw7HWGKqkP8Ev+zi7 H3PLk3xiGp/Kg== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Tim Bruijnzeels In-Reply-To: Date: Wed, 8 Dec 2021 11:42:14 +0100 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <3413E245-55FF-4C8E-BB93-BFD48C3F1A1F@nlnetlabs.nl> To: Randy Bush Archived-At: Subject: Re: [Sidrops] three 8210bis issues X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2021 10:42:29 -0000 randy > On 7 Dec 2021, at 19:08, Randy Bush wrote: >=20 > tim, >=20 > [ excuse my loss of humor. but some of this is getting old ] Funny you should say that. It's my sense of humor that allows me to continue to participate in this working group despite the loss of humor in responses I get. I know that many have already given up. >=20 >> Generally speaking though, I think we need closure on the ASPA = profile >> changes as proposed and discussed. >=20 > only if they affect the wire between cache and router That is indeed what I meant as well, so we are in agreement here. >=20 >> Note that there is also a proposal to have both v4 and v6 providers = on >> a single ASPA object. >=20 > as the two AFIs have very different topologies, i assume this is just > noise and people will get over it. It would be helpful to make comments on that matter then when and where it is discussed. I would be hesitant to make assumptions in a last call. >=20 >> An alternative that I can think of is that there would be three = length >> fields. One for v4+v6, one for v4 only, one for v6. Any of which can >> have length 0. =10Then a single PDU can contain the same data as a = single >> ASPA object, with a total combined length of 0 implying a withdraw >> (see below). >=20 > welcome to the ietf, where we take something simple and make it much > more complex. why don't we merge the ROA AFIs too? sheesh! Indeed welcome to the IETF: https://en.wikipedia.org/wiki/Reductio_ad_absurdum >=20 >> There was a proposal to have an explicitly signed empty list of >> providers, rather than overloading AS0 to mean no (valid) providers. >=20 > which is what -04 says. overloading magic values has a long unhappy > history in software engineering. if folk really want to do this, i > propose AS17, or maybe AS666. Which -04? draft-ietf-sidrops-8210bis-04? The current relevant counterparts to this document are: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-profile-06 = https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification= -08 The verification document which relies on the information communicated through RTR from this -bis says in section 6: Specifically, AS 0 is reserved to identify provider-free networks Furthermore, the downstream paths section (5.2) relies on the presence of an INVALID pair to decide where to switch from upstream to = downstream: The first unequal of AS_SEQUENCE segments that has an "Invalid" = outcome of the customer-provider verification procedure indicates the end of = the Upstream fragment. If an 'empty set' is to be used instead then this would need to be = flagged explicitly. Normally the empty set would result in "Unknown", so = switching the path verification direction on the first "Unknown" would not work. >> If the ASPA profile -07 were to go for empty provider list rather = than >> AS0, then an explicit empty list PDU would be needed and it would not >> be a withdraw. I.e. we would need to flag 'no ASPA for customer ASN' = vs >> 'no providers for customer ASN'. >=20 > you may want to actually look at -04 >=20 > and, btw, as in previous discussion, what the RP receives from the > global rpki need not be what the RP sends to the router. so it can > receive some kinky signal such as AS17 and send a null list to the > router. Assuming that things are changed and an explicit empty set is used instead of AS0.. then we will need support to flag the difference between a 'null' list (as you seem to say now) and no list. Section 5.12 of draft-ietf-sidrops-8210bis-04 ends with: Receipt of an ASPA PDU with zero providers is an implicit withdraw of the entire ASPA data for that customer AS from that cache. In other words this is indistinguishable from the case where no ASPA object exists for that customer AS. Perhaps this is not what you meant to say. Perhaps you meant to say that this explicitly indicates "no providers exist for this customer AS" - i.e. it's a null list, and that one should use a withdraw PDU instead to say "no ASPA information exists for this customer AS" - i.e. it's the absence of a list. If this is the case, then I think that last sentence of 5.12 should be changed to clarify this. That could work.. but then the aspa-verification section 5.2 would have to be modified. Where it now says: The first unequal pair of AS_SEQUENCE segments that has an "Invalid" outcome of the customer-provider verification procedure indicates the end of the Upstream fragment. It should then get something like: The first unequal pair of AS_SEQUENCE segments that has a null list of providers for the customer in the outcome of the customer-provider verification procedure indicates the end of the Upstream fragment. And then the 'null list' customer-provider outcome would need to be defined in section 4. I think that this may also be more clear than overloading 'invalid'. I am not opposed to this direction, but that text does not exist yet, and I think it's unsafe to assume that it does - until it does.. >> Can we conclude that the ASPA profile will keep AS0 and a minimal = length >> of 1 provider? >=20 > while i do not think that is useful or wise, this draft is not the = place > to discuss it, see my previous paragraph. The reason it's relevant is that this RTR protocol needs to be capable = of communicating the information encoded in aspa-profile and used by aspa-verification. If you don't want to discuss it here, then sure.. but it needs to be resolved before last call of this -bis can be concluded. Otherwise you make assumptions about the final outcome of those = documents, which may not be true - and the 8210-bis RFC may then not be suitable = for use with those documents.. >=20 >>> 2 - the ROA PDUs are sent one Prefix/AS tuple at a time. currently, = the >>> ASPA PDU groups all Providers into one tuple for the single >>> Customer. >>>=20 >>> the intuition was that ASPA is a one to many mapping while ROAs = are >>> one to one mappings. but the result is different program flows on >>> both ends of the protocol. >>>=20 >>> for an ASPA PDU, currently the cache and router need not worry = what >>> the other thinks; a new ASPA is an implicit withdraw of the = previous >>> ASPA data in the router. this is in contrast to ROAs and Router = Key >>> PDUs, where the cache and router must be aware of the other's = state, >>> and if discovered to be out of sync, a reset MUST be performed. >>>=20 >>> -04 does not change this for the moment. more insight is needed. >>> it would be especially good to hear from more router side folk. >>=20 >> I somewhat dislike it being inconsistent with how ROA VRPs are = treated. >> I also dislike that it could result in long PDUs being resent - the >> current limit is 64k providers.. in practice I don't expect to see = that >> much, but the protocol allows it. I don't think this would impact the >> RTR server much, but it could impact routers. >=20 > ok, i will put on my vendor hat. >=20 > part of the discussion oliver and i had is the unfortunate reality > that there are ops with deployed routers which do not have the > resources to buffer an entire rpki-rtr session and then process = only > once the End of Data PDU is received. and the size of a full fresh > rpki-rtr data set is growing. so it would be extremely anti-pola = to > retroactively require this. >=20 > if the cache sends cust/provider tuples for cust AS42 one at a time > to the router, as each one arrives, does the router need to sweep > all paths to revalidate? how does it know it has the full provider > set? ... >=20 > as i tried to hint, i would really like to hear from [other] router > vendors on this. >=20 > randy >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Dec 8 02:46:30 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C023A0D38 for ; Wed, 8 Dec 2021 02:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQhodyTNBwtj for ; Wed, 8 Dec 2021 02:46:24 -0800 (PST) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 7A4B63A0D34 for ; Wed, 8 Dec 2021 02:46:24 -0800 (PST) Received: by mail-ed1-x534.google.com with SMTP id v1so6988428edx.2 for ; Wed, 08 Dec 2021 02:46:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=114pumgQc5/CZjyoK43wcKPQG95mMJZdbF4k8nIALV0=; b=fIV2mjluAjAyusdC32twZqZfC4x2SrZ64Gb1iBlKDEJMLnLf60Kl2gfNWS/2oWR3/y EWWSq0Dp00MygUMqiA1YN8khnG8boNkvmYT4t6fXFkM2trDlKDOTGRJFXlV/UICaSWlM QhnuVjJm2OoOb9rlIfsEQZ40Tr8PJmvJXZwjs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=114pumgQc5/CZjyoK43wcKPQG95mMJZdbF4k8nIALV0=; b=fEtcq3M6gg8n1Wcp55U2m56w2uf/prTC1yxuhZ8X2I4j6QQL/nJj4lIOn0fXmPj9Qr j20TWVYUFtBXoAd19CLnVFhV9tu+kZ/GNckrmasCCGFHPgD+um/iz0+AIvoV3pb+peyI OxWcBb18Kys8SPQR2xeY91YCvqPO9Dfo9C4oeEKjl82c+tXP+gkyP8b5aOdmKSz+RcRj bJvFqtBMknZFsC57vTK/lU9fq35OJufAutEeUqlbzBtK4YVc7BWSVWY4m0dU2w68lBcR u1nKQhxUZRxxLFRj/FNx4YL1VVCaBKMueuNXFXkO6DJqCgcfDh82PBSgUDkQ0cxLMIH9 250A== X-Gm-Message-State: AOAM532xyitfJjz4MepovGaHVZ8PCNLVS8fbPRN1YhJQRt8KyksHLiNW S9G29TO1h9eoTOpbUI5bmPZRBNzuLk9UvdvUsAo68BjaYhBRW1yAVGSoonjruYKK8OsMdKieN98 naCavMn1MSj9AmOayU9AzU4aWWhTurNlR/E4dhmj03mDTnrNvYf+fnzo= X-Google-Smtp-Source: ABdhPJwzVrekOcpwXFB2S9sMXkbcpOvizgWFAwg8pIQbukR6VnAXyEnVGn36rd9rO5WEZQvZMiHgmQ== X-Received: by 2002:a17:907:6e91:: with SMTP id sh17mr6771808ejc.86.1638960380626; Wed, 08 Dec 2021 02:46:20 -0800 (PST) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id x7sm1882299edd.28.2021.12.08.02.46.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Dec 2021 02:46:20 -0800 (PST) Date: Wed, 8 Dec 2021 11:46:18 +0100 From: Job Snijders To: sidrops@ietf.org Message-ID: References: <00E18520-A535-4CC8-A287-56FB2F164E14@nist.gov> <5B2CD457-E376-4B8C-B901-202ACC4C465C@ripe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-rpkimaxlen-08 - ends 25/October/2021 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2021 10:46:29 -0000 Hi Alexander, group, What puzzles me is why the state of global RPKI ROV deployment bears any relevance to the proposed BCP at hand. For networks which do NOT deploy RPKI ROV 'invalid == reject' policies, it doesn't matter what the maxlength macro value is set to; it doesn't even matter whether the ROA exists at all! For those networks RPKI doesn't exist :-) On the other hand, for networks which DO honor RPKI ROAs by having deployed RPKI ROV, a minimal maxlength value is advantageous (because of the reasons outlined in the draft). Resource holders wishing to deaggregate at a moment's notice (like Alexander's employer?) - apparently their best course of action is to either create most-specific ROAs, or set maxlength to /24. Why? Because of the widespread RPKI ROV deployment :-) On the topic of egress ROV: this is what SLURM can be used for, or a clause in your routing policy similar to what you mentioned about blackholes. If instant deaggregation is a requirement, I think it is safe to assume operators will ahead-of-time prepare for such eventualities. Indeed, counter-hijacking is complicated. Minimal ROAs does not preclude one from makin a best effort to counter-hijack. I checked this morning, for only 51,858 out of 297,901 VRPs maxlength is set, so it seems to me a majority of the industry already adheres to using minimal ROAs. Kind regards, Job From nobody Wed Dec 8 04:10:04 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33C93A05A9 for ; Wed, 8 Dec 2021 04:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=workonline.africa 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 qANCu614t5xF for ; Wed, 8 Dec 2021 04:09:56 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70085.outbound.protection.outlook.com [40.107.7.85]) (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 85E3F3A05A7 for ; Wed, 8 Dec 2021 04:09:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lfaEA11cazBhPD/JRc3AcIGB6xLVpymivdnKE26dEtbTBagDl+H1IRnPfZiqoVmvnEuxueu0aiCveAftyIRmEwkThRiG7y2+aTNT+PcJdVzrSg65P606g5nEtFPRWFvojVcLktHsEuoYE4betX1j6lK7RH50k2xmh8rqB8yjV/YbX0g8NcXbMNOgFQ3k9k6oM7MpLf5ZU1qR4H3JgzMXwAvkWNj3O5z3uG+JAVz3huUpg/ChXR94kdlptkaiRnlH9CNJX86u6AiXngte8Y898kzxtnW3dcV8CchqHoK/4Tc3ycdxCxHWN2vDOmmydVvnsDUGUYSiQCJ/hyCdPr9ThA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2mRTez/iJTK6noUgoQYJJAIgOl8uEOMOhRkqISNoNTI=; b=Ylx8KLe9ohT/7z5gsLenviaJnLfjweMwAi4IG8/0kKnb1Kfc/gHcbiFkG/wDPziC4cEIDOgHYe07Fm+x+ptV64y0Arrt7zZn5Sun5LKBTdCkRMQPEPj+JpMO2b1NZ3vZGDJmPuKHDoFeRlOa5oliAr7ubcl1YsO9Vnu0AD4dGZHLFQcJqOQqJqt40rv/MmsXPrDk/RYoP4OC5XihejD76TC/cEntrHHxYTDQgYfXrelCq7MPp7zx5NTefZlwOI1d/OEF/uFetOkuML1K9z7rvGwyZs8vM/be5Z4Q9kGIjBjrenKUKdIAf7SJNAjF5msLyZyf1DqI3nOjMV53LVYE7w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=workonline.africa; dmarc=pass action=none header.from=workonline.africa; dkim=pass header.d=workonline.africa; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=workonline.africa; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2mRTez/iJTK6noUgoQYJJAIgOl8uEOMOhRkqISNoNTI=; b=ZXCNcR0zxXust+RP/6JwnIcZdt+CFFGmL8H2Y/mHOAgJT2uHaUYAYCh8n8yQf7PMK6Ch5VekZoxZqyhedtN10Q36Nnt372dQL+/o+vpH8WG9E2bbAzRd/TPcQxfD2a8YaqcziFWyPqXzwmqvZQiVPh7He1gyHdfHCIHFnRXiTig= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=workonline.africa; Received: from AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13) by AS8P190MB1270.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2ed::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.21; Wed, 8 Dec 2021 12:09:51 +0000 Received: from AS8P190MB1078.EURP190.PROD.OUTLOOK.COM ([fe80::a079:73c5:8443:3068]) by AS8P190MB1078.EURP190.PROD.OUTLOOK.COM ([fe80::a079:73c5:8443:3068%5]) with mapi id 15.20.4755.021; Wed, 8 Dec 2021 12:09:51 +0000 Date: Wed, 8 Dec 2021 14:09:44 +0200 From: Ben Maddison To: Alexander Azimov Cc: Job Snijders , "sidrops@ietf.org" , Ties de Kock , Nick Hilliard Message-ID: <20211208120944.5oq6o2sr6m6xzq42@benm-laptop> References: <00E18520-A535-4CC8-A287-56FB2F164E14@nist.gov> <5B2CD457-E376-4B8C-B901-202ACC4C465C@ripe.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wt24wpsajasm2qd4" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: CT2P275CA0019.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:b::31) To AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13) MIME-Version: 1.0 Received: from localhost (105.233.97.54) by CT2P275CA0019.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:b::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.20 via Frontend Transport; Wed, 8 Dec 2021 12:09:50 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1f2ce1da-7829-4127-a3df-08d9ba43a2f0 X-MS-TrafficTypeDiagnostic: AS8P190MB1270:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: c1SoPFhlb91qjs+0zZxXGrSIj3J+vbW1RqcXG0ILuiyao0LoXn/+1aDlkxOwb+7et5/rFUtDy3GEFX6VA3ZRI4Qf0oOhpnLkZu0q8cHLlDpNc5wR/q4brhxnw7qJVADcF7wDzPtpF4YAoAz3a3enwFE5SM1vMpLvFQUCYSeq3iDoji+LLOz+GAGpFUx5bFD+1ktGF2FSZkTsu+Gp+z7vcDC/kTDphEwS3RnxKVqNHOVhKtMtJSTRmqshDtZMtwG5gwAA3cBE4fT0Gi1mW6dMZmg0ofLxjpmHSmaZg6gHp3PMwDCowXiiQv6Js5p4qps1HVgDAxlNkLoJKBAVX+WlctvCiPV1N56o1gdaJTAganlewrDe8m9N8Pwx6F8n43FAI8cyedxrIlndHmxVjBWr7gp2Any2/I1rwhGh/7PPsXbIiur9Hg9ne2D204OakFqwu7mnLrGm0PqRVDUpO7AaJW85PVBsUB/r297qDbA2sfGd2pLi5XFbBsyeZd0IsAOGmVbB1qDvinASzyr+DqPNwuOFKjCCaW35aLgNoY4UCqgBvKaEcnBtFOg45jhi2Xk9LZAsl1OSlWQFTmGYmo9AQE+RGn50VQ/m+VJo2wbXhT0hxrA+bSjhlmFhKhYWtOgbqVLFDf63fApIdZjUQFj9uk38SELxenC/Nn6IEP/c692c8ApYTSpGEYEbHuXdq0lZXPNYkxG+5cf08P5woO0nrIlNdEvbss9O2PPf9Dl+pW119qIGXhKzaD8620v6XuG2 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8P190MB1078.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(7916004)(136003)(366004)(376002)(346002)(39830400003)(396003)(8676002)(8936002)(4326008)(83380400001)(66574015)(52116002)(9686003)(86362001)(2906002)(44144004)(33716001)(6496006)(956004)(21480400003)(6486002)(186003)(1076003)(26005)(54906003)(5660300002)(66946007)(66476007)(6666004)(6916009)(66556008)(316002)(38350700002)(508600001)(38100700002)(46492014)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?hwQEI5eVVYmenOVCMMTlnxJN6Tnb45gBTNIxE2r6ksTQ2tR/rRNeMzTmsivT?= =?us-ascii?Q?Ip2GW54iHNik8P1Cuqp0eZfM7MGccIgXKBf7hz6tbXMUBuZJWa6Nhx+9Zu1e?= =?us-ascii?Q?cP5//ZfLRt6G5QZ+L/7FG2BUORc/si1zHk0uxqfpU0bC7oQH5KPcA6VkOuVV?= =?us-ascii?Q?Wye/Hi28t30sImV/uRJLhzVQbUjCvlrSIl98RdrXi5v7/SYgGuE5yUyKq/rX?= =?us-ascii?Q?8Q+BaWc0SEauKOiPoPHF/WvJHXWwltJBZ2TGV+CxrKP4YaicXKbdKJei1XfD?= =?us-ascii?Q?Yx5Rhmywq6TeF9RIza8qEAnCqoProKcuDWvyF6b2hxZmoFeAyyK6EV5remUg?= =?us-ascii?Q?9561q5Lh0+wdA3Mqp68ved8bTEGU+UyZknJmtS5iGg+Ycw9MIyqqYhOCmhLc?= =?us-ascii?Q?JWuFREexlw/qsaKDfbsOp8kKsIx6kJgcFRz9e46vmRy68wGR/bAsvI/S0UVQ?= =?us-ascii?Q?2OasVdBoAy7WFhdWjumQptv0kLwRPKL0pJU7n8NA5bh458ci4CfoonNUwrO/?= =?us-ascii?Q?SOERQkyBdKN2n7SMNSsVYD9S5wtVBH1K7OZ5WGcwBjLbRCsYuK7F32Yb+6sF?= =?us-ascii?Q?O+XjblRdxKhv0Py2j25vulTAc8GGGUuY5USUGVzam4bPsV5BcVzDlS+XwwrE?= =?us-ascii?Q?Kx5xso8fMNFS2tblm/oyB0Up7RN8v+Pn8pIa/YrHgBNrhNmdVeWXM9z5yO/q?= =?us-ascii?Q?fsJW3H1hZAq//mUu5fZY0JmkQn0Qs9oZ1PoiryvDpo279S7kMG8T5mDx13GY?= =?us-ascii?Q?lOeiagpnHGZqOe2kNFRk/Kx/mYOs5vJlfTAwOGv/hMPrjkhZm9bJ8tmW/IfE?= =?us-ascii?Q?7nOa21hXA0nT6uDwMN1rOU5tsAqQvuaTsQEbbuP+DngMQDOFAFHWdFmLkHbd?= =?us-ascii?Q?7wcjUC+BrxN18AbQgr/n/8khAxnZsfbHIjk+alyhGZaIV7D7ND7F1hu5TAGE?= =?us-ascii?Q?rZcXuoa7aWxfNndRZEl0Armxoq+HuzjvYNY1gKCraGZQltiAgKnbIUIxY0Lp?= =?us-ascii?Q?cIOQ0jgr1F/LcVoRUF9NW0Yu29dxCpyy4q5VdBNjM0EPxH8vTtEXMgne+HxY?= =?us-ascii?Q?kY6V3NIF31+VenzSLnNr/uzPda6XG/BpUb+cmH2NFjj8odKO8OOjUfjbg+JM?= =?us-ascii?Q?q64yvv4U5rPRN9yfTGJgjTBx4XzQ7sQJgsB1BILWq3j/SCcsKHDDA7/36jsV?= =?us-ascii?Q?vduGwL/rzpmia64Yj3KJaRHZB+L2zhC3HPPqevQ02z+b44oS9pudUzQDg5bg?= =?us-ascii?Q?YLTqwKVO8CaLxrHqst3xtsT08/67W829KqX5aMplZCHUvD4VYjA2lmLy2cVs?= =?us-ascii?Q?LJOrWxriO6lmJ48NOVCSmoCx2abyo/k7pI86hfqagprF1gRuTjt40HwhmN2c?= =?us-ascii?Q?Ksm2im1z5RBU8VdywVPg+uyJKzHZoqSB7uNVQb0iWRn+jFCm+cBUsaX95dgn?= =?us-ascii?Q?wH2JLqAlFsWJXXhqIPVob6QqdnKY3BIKe6H1RP+GWkj4JOVKWT726Jmln0dh?= =?us-ascii?Q?hRIyvOlGLUJs5kiBLWAJvX8PLWNN2hUjbR7uFXQoKT3rYwGkHUrMYeK8jjGB?= =?us-ascii?Q?kD6aIzNong5iVxH5ykK9pWAx6m0l0XGLCbQOPWqB9vS1Wk74q+Et6PwnTGff?= =?us-ascii?Q?IhA4ZVcZ4oY8LhxzBmk5kz8=3D?= X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: 1f2ce1da-7829-4127-a3df-08d9ba43a2f0 X-MS-Exchange-CrossTenant-AuthSource: AS8P190MB1078.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Dec 2021 12:09:51.1390 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 1Ce1S3Ik8h8FWU3Pa0Qnd1jEk0rAcxWSMWBg69XeDRNt6CJuqfA9EYNrW5j1MSOakYpMchiel2ntz3sszU5WRQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8P190MB1270 Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-rpkimaxlen-08 - ends 25/October/2021 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2021 12:10:03 -0000 --wt24wpsajasm2qd4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Alexander, On 12/07, Alexander Azimov wrote: > Dear colleagues, >=20 > I mixed up the 'reply all' and 'reply' buttons, and only Job was able to > see my reply and keep on the discussion. > I'm sending the original message to the mailing list so we can proceed fr= om > this point. >=20 Thanks! >=20 > [...] >=20 > > > We have steady progress in signing ROAs but far less progress in > > > adopting ROV. And you can't easily distinguish is it safe enough to > > > start using maximal ROA length or not. For the network that I'm > > > responsible at the moment - it is not safe. > > > > Can you elaborate? This seems a rather subjective statement. In any > > regard, you are free to configure your own ROAs as you deem fit for > > purpose. :-) >=20 > > Another complication may happen when ROV is done at egress (rfc8893). > > > In case of fast de-aggreagation you may need to turn it off, though > > > such issue is much easier to resolve. > > > To sum it up: I still have a feeling that the document is ahead of its > > > time, and in the imperfect world may itroduce new gaps between > > > routing-security-in-theory and operations. The draft contains substantial discussion of the tension that exists between minimising attack surface and retaining the ability to make ad-hoc route origination changes. The whole of sections 5.1 and 5.2 are dedicated to the topic, and essentially say "some operators may choose to publish non-minimal ROAs in order to retain flexibility, but should think carefully about the trade-offs before doing so". > > > > I fail to see how this document introduces new gaps. It merely warns > > about the potential pitfalls of using the maxlen macro functionality. > > > Yes, I'm free to configure whatever I like, and the authors of the docume= nt > are free to do it in a different way. > The difference is that authors of these documents suggest their operation= al > practice as BCP, and I can't agree that this practice is safe at the mome= nt. >=20 > Let's elaborate what kind of events we are facing at the moment. > The majority of hijacks and route leaks are mistakes. We can assume that > the difference between accidental and malicious hijacks is absence of > forged as path in case of accidental events. > So, ROA with ANY prefix length is good enough to limit the blast radius of > accidental hijacks. Only if the origin AS of the hijack route is that of the hijacker. That is not the case for all mistakes (Noction-leaks, for example). Minimal ROAs are the best current initial line of defense to such incidents. >=20 > Unfortunately ROV deployment isn't at the level when we are no longer > affected by accidental hijacks. And the best option is instant prefix > deaggregation, if it is possible. > And I hope you will agree - the time is precious. >=20 > Now let's discuss how the recommendations from this document may complica= te > things that already got nasty due to the fact that your address space was > hijacked. >=20 > *Scenario 1:* > Being a proactive and BCP aware autonomous system holder, one may add > egress ROV with strict policy to drop Invalid routes with an exception to > blackhole routes. > In case of a hijack this good citizen will have to relax it's routing > policy/turn off ROV on egress. It is still not that bad, but in huge > companies with complicated access rules to devices, it may still take tim= e. >=20 If your neighbors drop invalids, turning off egress ROV doesn't make any difference: the update gets dropped on the other end of the wire. If your neighbors don't drop invalids then this can be done in local policy using SLURM, in close to real time. In either case, this is a red-herring. > *Scenario 2:* > Previously I described this scenario as two islands of good and bad actor= s, > where good actors perform ROV and sign minimal ROA, bad actors that perfo= rm > hijacks and 'ocean' of Internet in the middle. In this scenario good acto= rs > lose opportunity for deaggregation without updating ROA records. Let's gi= ve > it a more realistic and simple shape. >=20 > Let we have an ASX that peers with two 'important ISPs' in selected > regions. These two ISPs (ASY and ASZ) have significant intersections in > their customer cones. > ASX creates ROA, ASZ does perform ROV, ASY doesn't. And a customer of ASY > makes an accidental more specific hijack, and due to lack of filtering it > is accepted by ASY. > Since it is customer's route it gets higher local preference, and prefix > deaggregation toward ASY doesn't help. > But deaggregation toward ASZ may be helpful, since we will have two routes > with same length competing in the intersection of customer cones of ASY a= nd > ASZ. >=20 > If ASX has ROA with maximum prefix length, this simple technique will > reroute back to ASX at least portion of the traffic. > If ASX has ROA with minimal prefix length - effective deaggregation will = be > possible only after ROA update. >=20 I think this analysis is flawed. If the customer of ASY (call them ASW) doesn't forge the origin, then ASZ will filter the path. ROV works, and no de-aggreagation is necessary. If ASW does forge the origin, but the leaked route has length greater than maxLength in the published ROA, then again ASZ will filter the path, and no de-aggreagation is necessary. De-aggreagation is only necessary to influence ASZ's bestpath selection if the ROA is non-minimal to start with. In general, with minimal ROAs, de-aggreagation is only a useful response to influence bestpath selection in third-party networks that: a) do not filter ROV-invalids; b) are at least as topologically close to you as your attacker; c) assign at least as high a local-pref to routes from you as your attacker; and d) you actually care about exchanging traffic with. For many (most?) operators, a-d define a small and shrinking list of ASs. Because of a), the existence of a ROA is irrelevant, other than in the corner case that you previously set out, and which is discussed in section 5.2. > So IMO minimal prefix length will be safe if all 'important' peers of > selected AS support ROV. For Yandex this statement is not true. I disagree that this is the correct test, for the reasons above. The contents of a ROA are (by definition) not relevant when discussing path selection in a network that doesn't drop ROV-invalids[*]. Cheers, Ben [*]: Some operators might (foolishly) de-pref invalids. They appear simply not to perform ROV at all for the purposes of this discussion. --wt24wpsajasm2qd4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEadkaB2uV5dm5UllaOkYk/rSLaGAFAmGwoIgACgkQOkYk/rSL aGARFA/+Jax0uniJQWMs7w0wa3vhjiQe5pJNTN812lSrpzT9qHrRH2Uyd2Njzcx/ Sf7lEaUZqzhRScHUu5kZzefgB0wnXlBqDetbYQqLpOAcfL1VdEXuXBrQUbZFTrCS enci3EbHVqD5pg7gjG2XCgLFU6Dhxl3WgV+aW79e4tR3e0gm0RAScAu04h+L9Txb PPa5/SEp8OyRi0JBRHfKV05J0PhZKaKG389ERNGjGkuQi6TWm91FuYydybBdm8zx 0kDuoAGrDwxUXURR5o4Sn0CeFcXPevfRfgjmYwFLoXAMWtciWZU1+Pjv9+cPgROc SCVEN7o9j3WVWJhJlF9KFoHbkYsl+5uRM5/049i5P+dknyReCaxjdb3qawBG7uQv /TShHOI4Qu+8EUdaGmITa5MmpkSzXcoLnfQjvHalrvgWZ9JATcLRmDEZaZ7vdATe c7MYzpAm/yaN/m9E4Ry0TQAFGYEOlqtYvbATduiMRenaxIFn2U3Eb7GMezdmDHug 5eTQ1+Dr9cO6D0VnDk/ZukIrec9gbzVXxNRXhowOzsFFq16ujb6qrbIsdRjretPW fGKORjW3kRq1LjVpReKdxeZIpIgQjAJTZV93lNXXWbywXU8o75FIlWg3DoJMcOPf 2EwPnNvmD0hViJU733D/EZLmMHUlkqWiU7c+5+Hi3HHLdwmVPyE= =3ile -----END PGP SIGNATURE----- --wt24wpsajasm2qd4-- From nobody Wed Dec 8 06:30:59 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26EFD3A096B for ; Wed, 8 Dec 2021 06:30: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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ezAT7hE1O-N for ; Wed, 8 Dec 2021 06:30:50 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 230C03A099E for ; Wed, 8 Dec 2021 06:30:50 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1muxy1-00011Y-Pl; Wed, 08 Dec 2021 14:30:45 +0000 Date: Wed, 08 Dec 2021 06:30:45 -0800 Message-ID: From: Randy Bush To: Tim Bruijnzeels Cc: SIDR Operations WG In-Reply-To: References: <3413E245-55FF-4C8E-BB93-BFD48C3F1A1F@nlnetlabs.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] three 8210bis issues X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2021 14:30:57 -0000 sidrops chairs, tim's right on at least two counts i need to keep my sense of humor; but you can't do much about that 8210bis really can not advance with an ASPA PDU while ASPA itself is still wobbly i request pulling 8210bis out of wglc randy From nobody Wed Dec 8 09:36:41 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF523A0825 for ; Wed, 8 Dec 2021 09:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLyKwEiyh_ab for ; Wed, 8 Dec 2021 09:36:35 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 E0C983A0822 for ; Wed, 8 Dec 2021 09:36:34 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id g28so2614386qkk.9 for ; Wed, 08 Dec 2021 09:36:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=99KCOoM87UY6aRH0pUFCSjjg9oSQ3NSsDVSp7RC8MHM=; b=G5n+60UTUdCZOuVN1iUxguYVgBVSpfiPPfGSIMDMrhVWYQSj9Ez3lCcT4c1crkty5y Xcf7byTwp9LUgfUt0Bk4rV4nUwWuDyeG2YzC9GPSMsaZWgNFBbFnW64fUJit0FSMmIBR Fz89guDone+HJqY7mttdoofeWVt4mj7/x2pSMy3QT9fRGpO8R+Uo1DqU1XWkQHTX9tjY +T40MO1jlAF34QkZFroLwlkZmaGpEzh5EO8G9JoPTt1r9ZmvzUigr3kZetUvvtRX1dfO BeiderksSpd8JRYHJlB2mPbfbdmvpCJxcxE275dLAHTKnXHvZdbYohnSkyMYTdni7LZ0 F1Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=99KCOoM87UY6aRH0pUFCSjjg9oSQ3NSsDVSp7RC8MHM=; b=lpyAduTpE2x1nBeU7caH34RJMqZ8FPXiBospVNVkFjMjHEIA/2efPmTSSLh75bHqjA +0Y1tCx0SrfJ9QZM7YFJXbJDy2evh2A0Lj+OkCbuWsCTSmWPecoomW7WCMX1ZfEtCQiz 29+CP4/3qvE3419LxYMmlL1FJLxwr8i9eZJ34jkRQS16STT/QNApyXINlewR4eybM/KJ LZ3Cuco+NKd7Q1sagpeRqTXtQ4hUlijRZADU66rslhAK5yrOV3NJfQK2AOQDznuXxDHN I64WUtuq2d1EKlnIKr+DjB+IL+h6V1pcbi6vPR6ZxEmo46NKtzD/2e9JJs6j4iKjGZhy lxPw== X-Gm-Message-State: AOAM531gq8nqHjeLF0BZ+uaBNCM8kveUfybrubWk6Bc3uEZUEJw7NZwJ kFNHlzFVxxZo0nFOWzVqO5Ua//5ZWMAoS2pFjOY= X-Google-Smtp-Source: ABdhPJwbhoyz+LcFotQSRFYvS3zu9LqIaD/Rph9znpHF/k0Z+8WzCYffw5OzKde+EF5DWuud/ck2SM84ZNBGlFU28Sg= X-Received: by 2002:a37:b705:: with SMTP id h5mr8366779qkf.742.1638984990745; Wed, 08 Dec 2021 09:36:30 -0800 (PST) MIME-Version: 1.0 References: <3413E245-55FF-4C8E-BB93-BFD48C3F1A1F@nlnetlabs.nl> In-Reply-To: From: Christopher Morrow Date: Wed, 8 Dec 2021 12:36:20 -0500 Message-ID: To: Randy Bush Cc: Tim Bruijnzeels , SIDR Operations WG Content-Type: multipart/alternative; boundary="0000000000002a66fb05d2a5ee9d" Archived-At: Subject: Re: [Sidrops] three 8210bis issues X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2021 17:36:40 -0000 --0000000000002a66fb05d2a5ee9d Content-Type: text/plain; charset="UTF-8" On Wed, Dec 8, 2021 at 9:31 AM Randy Bush wrote: > sidrops chairs, > > tim's right on at least two counts > > i need to keep my sense of humor; but you can't do much about that > > A reminder to everyone: (I didn't want to say this N times in the thread) "please remember we (all of us) are here trying to make the internet safer/better. people aren't actually trying to torpedo you/your-ideas/etc, we (all of us) are trying to work through possible problems/solutions in an effort to 'make the internet safer/better'" So, with that in mind, please remember that before hitting 'send' we (all of us) need to verify that we are talking about the problems/solutions in the proposal and not upset about how our coffee is not hot right now :( (I need better coffee) > 8210bis really can not advance with an ASPA PDU while ASPA itself > is still wobbly > > i request pulling 8210bis out of wglc > > This makes sense to me, sadly for the document, but happily for the discussion and the process/end-result which I hope will be better once we finish sorting out ASPA docs. pending other WG-Chair comments, we can do this in the next short while. -chris > randy > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --0000000000002a66fb05d2a5ee9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 8, 2021 at 9:31 AM Randy = Bush <randy@psg.com> wrote:
<= /div>
sidrops chairs,

tim's right on at least two counts

=C2=A0 i need to keep my sense of humor; but you can't do much about th= at


A reminder to everyone: (I didn't = want to say this N times in the thread)
=C2=A0 "please remember=C2= =A0we (all of us) are here trying to make the internet safer/better.
<= div>=C2=A0 =C2=A0people aren't actually trying to torpedo you/your-idea= s/etc, we (all of us) are trying
=C2=A0 =C2=A0to work through pos= sible problems/solutions in an effort to 'make the internet safer/bette= r'"

So, with that in mind, please remember that before hitt= ing 'send' we (all of us) need to
verify that we are = talking about the problems/solutions in the proposal and not upset about
how our coffee is not hot right now :( (I need better coffee)
=
=C2=A0
=C2=A0 8210bis really can not advance with an ASPA PDU while ASPA itself =C2=A0 is still wobbly

i request pulling 8210bis out of wglc


This makes sense to me, sadly for the = document, but happily for the discussion and the process/end-result
which I hope will be better once we finish sorting out ASPA docs.
<= div>
pending other WG-Chair comments, we can do this in the n= ext short while.

-chris
=C2=A0
randy

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops
--0000000000002a66fb05d2a5ee9d-- From nobody Wed Dec 8 09:50:53 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070073A089B for ; Wed, 8 Dec 2021 09:50:52 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foYClVMJSZeH for ; Wed, 8 Dec 2021 09:50:46 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 DD66E3A0899 for ; Wed, 8 Dec 2021 09:50:46 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mv15W-0001TI-2J; Wed, 08 Dec 2021 17:50:42 +0000 Date: Wed, 08 Dec 2021 09:50:41 -0800 Message-ID: From: Randy Bush To: Christopher Morrow Cc: Tim Bruijnzeels , SIDR Operations WG In-Reply-To: References: <3413E245-55FF-4C8E-BB93-BFD48C3F1A1F@nlnetlabs.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] three 8210bis issues X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2021 17:50:52 -0000 >> 8210bis really can not advance with an ASPA PDU while ASPA itself >> is still wobbly >> i request pulling 8210bis out of wglc > > This makes sense to me, sadly for the document, but happily for the > discussion and the process/end-result which I hope will be better once > we finish sorting out ASPA docs. as there are other somewhat imortant changes to the protocol in the document, i considered just pulling out the ASPA bit. but maybe we give the ASPA docs another bit of time before giving up. thanks. randy From nobody Wed Dec 8 09:56:39 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D574E3A089B for ; Wed, 8 Dec 2021 09:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8N2iIwVYEBP for ; Wed, 8 Dec 2021 09:56:33 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 41C9A3A0899 for ; Wed, 8 Dec 2021 09:56:33 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id 8so2941395qtx.5 for ; Wed, 08 Dec 2021 09:56:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rqOTwD9FXocktRPLI8v/lOI7/da4wiG3qmVTtOicKd4=; b=Sa0wZqc+wQ4dys2U6YZkn0rsmtBhjgbKo1Jj99vy9kuj49hBOR6BJP9ZKch5TCcfod 7I1IFFyrChsNrAEx4NTo2UdAv2s4AED8iHZLVDn/DJjtB9d1jxrztz03BQtAAk1lhAlD 4vorZNmJM4LTnlzd0k29IJtt3UNjW4Gd2eZXvW+fGPHxemEalSPbImFWU5eYL2IFqGxE VKq3hJc1eV1nawgDwmsJb+g06aYY/YFhqhea2+zHitx5nrclsyask5REd1g0Wn4Hw9or I/yJ2Dt7NDzPumW0tmshkB4MknZ0Bgzelw/VN550HUI0IFy+0chSTx/d+HOBT0gSUW+S 3l0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rqOTwD9FXocktRPLI8v/lOI7/da4wiG3qmVTtOicKd4=; b=teFZ43ajoMl7hP6XfE+o3EGX6ditgDbrceda3CVjCyCRo/fpxi6Pr3v64jgJJwhDI7 qKI5MlWcW2aaEBuKvkgg2r3ZPlwnXIBvr87/MSGoOPMidrMMg+DVMQPaFFLg5Yhk3sD8 eJc0pXyRBKp6+ZdjcdiE0VxUhxCSw5IIwv/glg8jgyUwoXJxGfCsMLfstxVryMaM6JFg EAcvr8Aq2sTPus+w571DlXRTo0HROWs+H67j2zMtPMNletOaHedR7sQd3t2SK5XXG7jG MV9t6kNhWIvWk2If7OLy34oeh5h7jIKhNDKYUcHEhAtd3mWaAnfvOVPf8v3NXjidaEUp tIUg== X-Gm-Message-State: AOAM53151YBp0LALmUlc1AZw6JERDmHKjmE1Td00KHNVNo/x3/QoWoKV aSGWqH/iXS2b6ZLmrayA5NSeQFrSHgsvQOSxj4Adt6i/aV8= X-Google-Smtp-Source: ABdhPJxmsgo4eYSQSOTfhBDZmw9My0oabOfnsWTnP2OW+5fGMlQgRVRnBGjohNd83Cve1ZictZxK5tFm433mhvZsWrU= X-Received: by 2002:ac8:5acf:: with SMTP id d15mr9759568qtd.5.1638986191434; Wed, 08 Dec 2021 09:56:31 -0800 (PST) MIME-Version: 1.0 References: <3413E245-55FF-4C8E-BB93-BFD48C3F1A1F@nlnetlabs.nl> In-Reply-To: From: Christopher Morrow Date: Wed, 8 Dec 2021 12:56:20 -0500 Message-ID: To: Randy Bush Cc: Tim Bruijnzeels , SIDR Operations WG Content-Type: multipart/alternative; boundary="000000000000bb771605d2a63513" Archived-At: Subject: Re: [Sidrops] three 8210bis issues X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2021 17:56:38 -0000 --000000000000bb771605d2a63513 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 8, 2021 at 12:50 PM Randy Bush wrote: > >> 8210bis really can not advance with an ASPA PDU while ASPA itself > >> is still wobbly > >> i request pulling 8210bis out of wglc > > > > This makes sense to me, sadly for the document, but happily for the > > discussion and the process/end-result which I hope will be better once > > we finish sorting out ASPA docs. > > as there are other somewhat imortant changes to the protocol in the > document, i considered just pulling out the ASPA bit. but maybe we > give the ASPA docs another bit of time before giving up. > > that seems reasonable to me, yes. --000000000000bb771605d2a63513 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 8, 2021 at 12:50 PM Randy= Bush <randy@psg.com> wrote:
=
>>=C2=A0 =C2= =A08210bis really can not advance with an ASPA PDU while ASPA itself
>>=C2=A0 =C2=A0is still wobbly
>> i request pulling 8210bis out of wglc
>
> This makes sense to me, sadly for the document, but happily for the > discussion and the process/end-result which I hope will be better once=
> we finish sorting out ASPA docs.

as there are other somewhat imortant changes to the protocol in the
document, i considered just pulling out the ASPA bit.=C2=A0 but maybe we give the ASPA docs another bit of time before giving up.


that seems reasonable to me, yes.=C2= =A0
--000000000000bb771605d2a63513-- From nobody Wed Dec 8 14:58:23 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6CC3A07E6 for ; Wed, 8 Dec 2021 14:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari.net 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 BngmGJuxqD2X for ; Wed, 8 Dec 2021 14:58:17 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 8E91E3A07E5 for ; Wed, 8 Dec 2021 14:58:17 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id q72so4557209iod.12 for ; Wed, 08 Dec 2021 14:58:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aY7RXjl0FBYx8h6T+486ZEe+zqsZSjVVP1HWpuHuoVI=; b=WPXVY3yQXRhFHEKeXX2GZ12iZqThR8QuwrlcSCyOUog7Mm5hBAvZn9ICLawKRu76xX Cnr0aeC0HN+v2Ip9ynpZ0THeLy9eGLWfkzwf+TCCnelZXvLK1ST5kH5Zy+1HkScPho9R 6nKWd6+QdkvXSMHMihCbb5xHR9B+hOwjz8Vqcm22FK+NYqVUCqMWT5qTAcZLACq7EKJ6 OiN4obdZcBlwifNxYXAolY6ZHcsfVQd6I52G97+2IsfP2/Lf2Q/CgsfXVFy+D2myZAM7 cnzR1zVPlQXaZX52M/k+ipuC8iBWbeaOBHwNbv4o8duY/Zf01Fi9xXMDF51TSCp/3auc aoaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aY7RXjl0FBYx8h6T+486ZEe+zqsZSjVVP1HWpuHuoVI=; b=ZIkbmYNArnQTou7Q0/gWRYB5RboCRH157kNriS15DtVLT8qcsjY5cJ/udfNfnMdZTk 85P3pDvse3Z1uxXWFAdBrK7LH/EYc8Bpu4IGGJ098mtMzC+WK8rrF4QW7+Hwat1cDnGz GSMuNIQJQfODTtuEvZj0mMKfbyOVAkAwoSeI9djyWGyCoW3q2bBe6oVTcx/7CXrLSeP/ 8qd1kXYKpXQ/4+3pb+bTDUOX+rMK0zAqCDQwE+Q1Psn19Vbq1M/DB0zHfktWsGZe1xb1 FeIsoTmX7nyJeHaY35brOqKR7LG5WJbxgxoC9f3/PVHq7k3WIGVB4TZcZe3Q7D1HhIG8 F9pg== X-Gm-Message-State: AOAM531Akx9fPESJERnUIfGzcJ+VHGOcLK1kApgzWmLvuGvzZ/BQhGhf grW6XtIhWj74KOGRSKBQuCOU4T+WO3dMlkkuxCa3ulvvyMU= X-Google-Smtp-Source: ABdhPJzxxmjfFLIDu0CdLl0bmtqILfKUbym4+Pipr1q/oTBQHmH1eocVIoWLE6Q7fza9kAS9A1W0JrDUBJ2RdCHIm7M= X-Received: by 2002:a05:6602:1484:: with SMTP id a4mr10207606iow.35.1639004295645; Wed, 08 Dec 2021 14:58:15 -0800 (PST) MIME-Version: 1.0 References: <813d1599-fc9d-18b6-a76c-b550855b1186@verizon.net> <20211130193034.344F62EA0102@minas-ithil.hactrn.net> <8d9b693c-137d-4a76-9fef-65968bb5062e@verizon.net> In-Reply-To: <8d9b693c-137d-4a76-9fef-65968bb5062e@verizon.net> From: Warren Kumari Date: Wed, 8 Dec 2021 17:57:39 -0500 Message-ID: To: stephen.kent=40verizon.net@dmarc.ietf.org Cc: sidrops@ietf.org Content-Type: multipart/alternative; boundary="000000000000d3e64705d2aa6c8c" Archived-At: Subject: Re: [Sidrops] AD Review of: draft-ietf-sidrops-6486bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2021 22:58:21 -0000 --000000000000d3e64705d2aa6c8c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, I'm in the process of digging out from my mail backlog, getting all of my ducks in a row before the new year starts, etc. Just a reminder to post a new version when you have a chance, and then SHOUT LOUDLY so I don't accidentally miss it! Thanks, W On Fri, Dec 3, 2021 at 2:23 PM Stephen Kent wrote: > Tim, > > ... > > So, section 6.3 says: > > "If the current time is earlier than thisUpdate, the CA has made an > error" > > > > It is also RECOMMENDED earlier that the EE certificate notBefore matche= s > > thisUpdate. > > > > As a CA I have every intention not to be sloppy and manage my own NTP, > > but I feel vulnerable to RPs with sloppy NTP. I do not see what the > > big deal is with back-dating five minutes. The object did not exist fiv= e > > minutes ago, but if an RP lives 2 minutes in the past - why should they > > reject me? What if my parent issued a covering ROA and I try to publish > > a more specific, and it is rejected for this reason? > If an RP is sloppy re their time maintenance, they will have to retry > the fetch, and eventually the problem will be resolved. We have no way > to ensure that all RPs process newly posted info in a timely fashion, so > this is just another factor that influences the speed with which PP data > is acquired, validated, and used internally by RPs. > > NOTE: For manifest and other RPKI Signed Objects there is also the opti= on > > of using the Signing-Time Attribute (section 2.1.6.4.3 of RFC 6488). In > > my mind this is where the CA tells the truth about the time of signing. > > > > Also note that there are different components involved in the chain. > > When a CA signs a new manifest and uses *now* for notBefore, then there > > will still be some delay before it is actually published by its > > Publication Server (seconds to minutes). And then there is a further > > delay before an individual RP picks it up. So, assuming that the CA and > > RP NTP are in sync, the latter will always find things after the fact. > > > > Speaking for my own implementation publication happens within seconds > > after signing and that is when the first RPs will pick it up. For other= s > > it may take minutes between signing and publications and therefore they > > may be less afraid of RPs living in the very recent past. > > As you observed, different CAs may have different timing concerns. > Still, if we don't direct RPs to pay attention to this field, it > undermines confidence in the system. Experience from a number of PKI > contexts shows that if RPs fail to enforce constraints on cert > processing, bad behavior by CAs will go unnoticed and uncorrected for > some time. > > Steve > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --=20 The computing scientist=E2=80=99s main challenge is not to get confused by = the complexities of his own making. -- E. W. Dijkstra --000000000000d3e64705d2aa6c8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I'm in the process of diggi= ng out from my mail backlog, getting all of my ducks in a row before the ne= w year starts, etc.

Just a reminder to post a new = version when you have a chance, and then SHOUT LOUDLY so I don't accide= ntally=C2=A0miss it!=C2=A0

Thanks,=C2=A0
W

On Fri, Dec 3, 2021 at 2:23 PM Stephen Kent <stephen.kent=3D40verizon.net@dmarc.ietf.org> wrote:
Tim= ,
> ...
> So, section 6.3 says:
> "If the current time is earlier than thisUpdate, the CA has made = an error"
>
> It is also RECOMMENDED earlier that the EE certificate notBefore match= es
> thisUpdate.
>
> As a CA I have every intention not to be sloppy and manage my own NTP,=
> but I feel vulnerable to RPs with sloppy NTP. I do not see what the > big deal is with back-dating five minutes. The object did not exist fi= ve
> minutes ago, but if an RP lives 2 minutes in the past - why should the= y
> reject me? What if my parent issued a covering ROA and I try to publis= h
> a more specific, and it is rejected for this reason?
If an RP is sloppy re their time maintenance, they will have to retry
the fetch, and eventually the problem will be resolved. We have no way
to ensure that all RPs process newly posted info in a timely fashion, so this is just another factor that influences the speed with which PP data is acquired, validated, and used internally by RPs.
> NOTE: For manifest and other RPKI Signed Objects there is also the opt= ion
> of using the Signing-Time Attribute (section 2.1.6.4.3 of RFC 6488). I= n
> my mind this is where the CA tells the truth about the time of signing= .
>
> Also note that there are different components involved in the chain. > When a CA signs a new manifest and uses *now* for notBefore, then ther= e
> will still be some delay before it is actually published by its
> Publication Server (seconds to minutes). And then there is a further > delay before an individual RP picks it up. So, assuming that the CA an= d
> RP NTP are in sync, the latter will always find things after the fact.=
>
> Speaking for my own implementation publication happens within seconds<= br> > after signing and that is when the first RPs will pick it up. For othe= rs
> it may take minutes between signing and publications and therefore the= y
> may be less afraid of RPs living in the very recent past.

As you observed, different CAs may have different timing concerns.
Still, if we don't direct RPs to pay attention to this field, it
undermines confidence in the system. Experience from a number of PKI
contexts shows that if RPs fail to enforce constraints on cert
processing, bad behavior by CAs will go unnoticed and uncorrected for
some time.

Steve

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops


--
The computing scientist=E2=80= =99s main challenge is not to get confused by the
complexities of his ow= n making.
=C2=A0 -- E. W. Dijkstra
--000000000000d3e64705d2aa6c8c-- From nobody Wed Dec 8 15:20:33 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45E13A0827 for ; Wed, 8 Dec 2021 15:20:31 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4MePT7s-QZN for ; Wed, 8 Dec 2021 15:20:27 -0800 (PST) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2064.outbound.protection.outlook.com [40.107.93.64]) (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 4234C3A0822 for ; Wed, 8 Dec 2021 15:20:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=evr7eq4CX9moIYncIirCgdkCO6TzAwGD78EX9zjpqfqgYWOkdreK5axsaK4loJ1TRehuFoK1PFX/05D8wvPwRDYKG9E/TaJ0RifFhv86noGkk+q5mAqdBQptX1l7a6A39I4RaQ0lww2e9oIsuoyeCVamu9Y9F7RE3YYjHIjTux5KtnEesJTbtxcLd5hKNLeoCGnshMZUenraZ3qosPYcYcfKXxnIXbwBeS5eQkYflDRSgUh078Zdlv5IIGrPMPXyDpbZsVHEWOZsIOYrnk2sGJVRiTWSs9bSXQk9UX7gvPPmsjhYYjcyMy/59ewZCRkQr9TTMt/+n04T6s39WrAcig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Orq+hYNLeHJGpVwG3g0vIfhIKEeQXuZHuIYlDS2r9fQ=; b=Kw1UWgpB/ieRV+sBczyijJMYJlZm5u7Exkeza7MHDFiwxpyTimV/ci171/9QegjjjhJkvnzqpM1U2+UNaLsTAeKzzZEwFJ3CFsQKN/uaJHnoCZam74X7SL3OL+NTli7U6iRLlB2v8izeSV9mpQyiHP2PCPiC+3bAFdpKC0ZxThCaq37SunBquYqeTr7aLum7xqDqhlnvpCNk60eL6xuIGfDTBeJ2Nseh1PoyqiTHzQ6pBvUSc+1igoWKnz24dYOLcSjCJVaiOq2a9C4vlZwVVLOJehgXkUVSdI3EnaEtxLat5uraDOc9qVYkQYRv3BwRx9jQtpRb9fDvfs3Pw361Fw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Orq+hYNLeHJGpVwG3g0vIfhIKEeQXuZHuIYlDS2r9fQ=; b=OosXwmIYX3KYhkeAG894QYv87xJqEfJjWI+9lFLaTwzZkUCHJn2GPZjP1xjqsfWXT2ayABTDw85WDEf1QsVPRBHLm2pm7OybRwfAf8lNcA+yg9XzMXM84vYsitrNy7rNhPyLAQ1Rt1actGeakHuGPUITlsLzqdAyNCJUN1GNz/Q= Received: from BYAPR18MB2696.namprd18.prod.outlook.com (2603:10b6:a03:10b::26) by BY5PR18MB3235.namprd18.prod.outlook.com (2603:10b6:a03:1a4::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.11; Wed, 8 Dec 2021 23:20:21 +0000 Received: from BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::c8e2:4bf6:dd43:f10c]) by BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::c8e2:4bf6:dd43:f10c%5]) with mapi id 15.20.4778.012; Wed, 8 Dec 2021 23:20:21 +0000 From: Keyur Patel To: "sidrops@ietf.org" Thread-Topic: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Closed 7/December/2021 Thread-Index: AQHX7IorfjN1flBxxUOyY9gZpvY5bQ== Date: Wed, 8 Dec 2021 23:20:21 +0000 Message-ID: <1EDB669E-5E4C-455E-A109-7A69ED085D1F@arrcus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.54.21101001 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arrcus.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 51287eaf-f3ce-4139-0254-08d9baa14e5a x-ms-traffictypediagnostic: BY5PR18MB3235:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NPeAcyVuEjMOIgnfsWkUtSZs3Tg+3DnfLbYMOZUm4bUaNNw0MMeIVrm9/ruM4wDZovQYAN3kjvD2QHxiHEoTRdibDlBuBWhLUwJC4wuFAkyw/4GCiaaOYIUQldm5pEn1YzX28VFTACmLIr2JyiGfQJVxql9IvpX+qekq3HXuhSMsvU47BO2yv5nH8OpTHQJG+hiwUiH/z3viVp52olj1hrBHyjMM3w7SXDdnwXfekd99SnJ/MgzSm7JzxvEhqghTWp9ewX5iCp98MurU+TuVkMoLFL46CKLfzjoIRw61fip1n5bSuICRltuVrdlw7G7xif71676A9+54/4gJbSGjIN70lUoclpLrctoPI0jOr/XuXc+ou98mbfIa+uQ/4oJz1kURxl1vlKrmyBw1RM12m8poEtwLFIeoakjzJw7/Fr6FTgv0yY1fjvcqOP1BNZW80ekxkxjgS48yEoumPD0O/zs4zQoK/ezqDRm04Q89pyxVqPv7sRsBtfdUhN0cve8kwkZbv8E4MyCTBR2fuljKSw2Bb76l73sbWiEcFWoJ9nFr5+EkdIblnsn1BOktWiiL8V4Vo+kzqZ57k8Ldfqe8bUUyn1YtErIawya0B0rEDLQyNFjRGT1PLShmIWbhBTyy7yMe9DR6ky46SPVBJyzy0J8/8sF8rbE0ylZaMK1GWRqw/aMXun1SoYeQICM1TUZsbiMlEDXmEfZQ40CNxCWDPd9BX1n0d7gbhmLgBjbGhxMOTBcvNDAQJybbGsAhkaZdaKU/xAtbDsYgzhBxl6MTPeNYWBtqe2tQr+Xcuol1Zn+U0RclYMrWxMaOMDBBCu3B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR18MB2696.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(346002)(39840400004)(396003)(376002)(366004)(36756003)(8936002)(508600001)(64756008)(26005)(8676002)(66446008)(66476007)(2906002)(966005)(9326002)(6916009)(6486002)(186003)(66556008)(86362001)(166002)(316002)(53546011)(66574015)(122000001)(2616005)(5660300002)(76116006)(38100700002)(6512007)(71200400001)(83380400001)(33656002)(38070700005)(66946007)(6506007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?UlVFWEE2Z2RwRDhqRWVvQnRscXNnZlNCeGREcDFJV1kwZFBkOERZZVNxT1dm?= =?utf-8?B?aXYrS0UxbWMyWEs5ZUhjbDdTY0s4enY2UFhsR1hESDVPM1Q4UDh4bWJnSnNv?= =?utf-8?B?UHdrTDFHYW5GNnpneHIrTTA2MmtORWFzczlqUjQzVEZNdG1MUDhDckRVTzhr?= =?utf-8?B?SGdOYkhIeXgvRUw5S21yNnQ3SFg2Zmlodm5uK09ZcmpUdFBCOGV4bDFMbWhL?= =?utf-8?B?OEd5eTllVS9oV3g4UE5KZVNmQmNrTkJhNU9kWXV2dDR5S2VLb0lJR3Q4eGFl?= =?utf-8?B?cSs3RlFxN204Vi9HMTUvZWJxQzhPYkYxMkJzbE1HOVYyVFpGYmUrZ21qUUlN?= =?utf-8?B?Mnc1QUxZcjJldG10aWI4SDlId25ZZnFFclY5WElxcGs0akN4UDNlNGZ3UzZD?= =?utf-8?B?dE9KOGVaeVdZYXV6Qy9DRjExdnBDTUpwQmgzR3cycFZCOVR6TjRnMiszWjZV?= =?utf-8?B?ZlhzRndWbGZtK1NzWVdrblBmZUdjZ3cvWVhSMFQvYXVKbThja0RnNHVkZkVs?= =?utf-8?B?aUJrVlg3bGVTdDEvVXAxWjVicXFLTHpFSzFWd2N2MW94akEvYWhkc1J3ZURa?= =?utf-8?B?a0JSYXQ3Wk1iQUQrVjg1TkZWai8xaTFkSDhBeVRYaFNjcW55YlhFbWZGcGZx?= =?utf-8?B?Qm8zZlNNYWR3TmtyRnF3WDlaRzFUMnVFSVNnV0UxSW9MbTRqVmFxM3hPR2pY?= =?utf-8?B?WFhIcFp6ak1wZTh2WDRhb3VGTi9BeG5KSHJzUkJYL2NmOHVDM3VocnVSb2VK?= =?utf-8?B?UkNiSlJsQTZCc21GT3hHcEhPWnZHRjVMdm5KcEJidnVDdEo3MGQ1M3UxNTJU?= =?utf-8?B?eTF1Sm5SZ0lFeG05RHJsZDJiRVppbkRzbTZ4RzBPWEYzVTVVUjBhNzhZeWZU?= =?utf-8?B?OVU1RGJQNWc2ZWQrbHFHdW4xVld1VExRVE9jSHVGeXdldmR6MlFTZFpjN2xP?= =?utf-8?B?T0F5M2ZPTUxSWU1XcmI2QUc5aWFjTUxHeHFJNHUyTlZyYXJIc2hJK0Zvb21u?= =?utf-8?B?UFB2L081OXE0Vy9waldKUGtiVDh4K2ZMSzdnZ3hlTGc0UmNWaysyZzE2QnVk?= =?utf-8?B?eFYxNFZLTTR0VXI2MGVXWmRXNXlSdEUwWUkzN3BIeWFxWFp5QzlROTdXc2hn?= =?utf-8?B?c1VEK1hNMW5uUUVxd3Q2SzBaTHBBSTRrTTRNYkxMa0xKWVJqVXo4bnk0RlNs?= =?utf-8?B?Sm1zZ0t3V2N1aG9ZcHl3a0V1NU9Va29yeThVMUR2dWVNV2dJM1ZlWGllUFlS?= =?utf-8?B?VVhlN1c4ZjJYdkxmTG5rWkl1cysxS2Ztc1o3cURqdjVnVW1ZYjRQeVBKWjNV?= =?utf-8?B?N1pxRjRlblNnMEJQeG5xSFppL3ZaS3RabkdDSGh0QW5XOUZVV2E0bnNkRlBs?= =?utf-8?B?NEZFVkZIQS9PTFgvT2dsWnd5bHhOSW9WNEJTYy9CTGw0bCtyNktuTTNtQlRQ?= =?utf-8?B?YVRKOUtRUVJPeUt0WDJTRUxqZDJtV3R2UUJPUVJJZzRuSHdvWEozNWQwSW5x?= =?utf-8?B?TVhiWmFzRUhBa3Q0MXRpdGdtakF0dDR6RkFHbVJtYTZGa2w1ZXNDdU1jeHBt?= =?utf-8?B?MFRaalc5SjJ0NWRMWUltaUs0TjlodUorZDJyZFhLbUhyVEFsNXlBNlpHdk1X?= =?utf-8?B?OWt0a1NCcmJJdlpVeDBzSFJrNnBka3hvVWZJZy9DcmtlSmhxMGVBdU94cU5o?= =?utf-8?B?OEx6bk9vUFg5NHVOQVJ6TDJneFhvdmlPOEZsNWJiN3IzeVdTNzg1MVVWTDRT?= =?utf-8?B?clkzd0NoTk1xZmlNcWtwM3RxMjVTYWs5VWRwK1dnKzFpWWUrL1hoaE1WZVRS?= =?utf-8?B?Q1BBTGtCOEYyRlBnM21CZDY0N21uYnpWdGJEbEdnN3dPK1JFdzhUZkF2L2VX?= =?utf-8?B?WUN1cUFXajVEejRCY01sR3pMMmFiZE9lSld1bDR5SnFMVWJ6aERjc2JUVGty?= =?utf-8?B?bmJmcDVCcUtEZnppQ0FjWkdBYU4yRDdxd3JiaEVhc2tWd2NyenNJS1lHd1hZ?= =?utf-8?B?Y2xJaElvRktYNExXUFpOZmN3OCtIQ0RENVVlM0JGVEZSZ0ZzZi90UnRRVHRB?= =?utf-8?B?d3dBTm42cnhmYWk4c0p1cW4wK3NIa1FtTHdaaGlWekZrTTN2VmNRVHEwVzBy?= =?utf-8?B?YUd6Wm5vOW5qd1pSUUU4eWVKdmltT3lNQnlKdldQVk41bjNJQXZQU0txN1Jl?= =?utf-8?Q?SDrhm86buqhsbtZJv+2d4/g=3D?= Content-Type: multipart/alternative; boundary="_000_1EDB669E5E4C455EA1097A69ED085D1Farrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR18MB2696.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 51287eaf-f3ce-4139-0254-08d9baa14e5a X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2021 23:20:21.4939 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7+giL7ZHyva2iafl8NT4CgB2wurj4UN31S2qNw2EuEl9g4fi7o5u8xCNK4lybh0crJfbgqeAacergVsxUSm/hw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR18MB3235 Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Closed 7/December/2021 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2021 23:20:32 -0000 --_000_1EDB669E5E4C455EA1097A69ED085D1Farrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRm9sa3MsDQoNClRoaXMgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaXMgY2xvc2VkLiBBdCB0 aGlzIHRpbWUgdGhlIGRyYWZ0IG5lZWRzIGEgYml0IG1vcmUgd29yayBhbmQgaXMgbm90IHJlYWR5 IHRvIGFkdmFuY2UuIFdlIHdpbGwgcmUtaXNzdWUgdGhlIGxhc3QgY2FsbCBvbmNlIHRoZSBuZWNl c3NhcnkgY2hhbmdlcyBhcmUgY29tcGxldGVkLg0KDQpCZXN0IFJlZ2FyZHMsDQpOYXRoYWxpZSwg Q2hyaXMgYW5kIEtleXVyDQoNCkZyb206IFNpZHJvcHMgPHNpZHJvcHMtYm91bmNlc0BpZXRmLm9y Zz4gb24gYmVoYWxmIG9mIEtleXVyIFBhdGVsIDxrZXl1ckBhcnJjdXMuY29tPg0KRGF0ZTogVHVl c2RheSwgTm92ZW1iZXIgMjMsIDIwMjEgYXQgMTE6MDAgQU0NClRvOiAic2lkcm9wc0BpZXRmLm9y ZyIgPHNpZHJvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbU2lkcm9wc10gW1dHTENdIGRyYWZ0LWll dGYtc2lkcm9wcy04MjEwYmlzLTAzIC0gRW5kcyA3L0RlY2VtYmVyLzIwMjENCg0KKioqKlNlbmRl ciBpcyBub3QgZnJvbSBBcnJjdXMqKioNCkhpIEZvbGtzOg0KDQpBIHdvcmtpbmcgZ3JvdXAgbGFz dCBjYWxsIGhhcyBiZWVuIHJlcXVlc3RlZCBmb3IgZHJhZnQtaWV0Zi1zaWRyb3BzLTgyMTBiaXMt MDMsIOKAnFRoZSBSZXNvdXJjZSBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlIChSUEtJKSB0byBS b3V0ZXIgUHJvdG9jb2wsIFZlcnNpb24gMuKAnS4gUGxlYXNlIHJlcGx5IHRvIHRoZSBsaXN0IHdp dGggeW91ciBjb21tZW50cy4gVGhlIFdHTEMgd2lsbCBlbmQgb24gRGVjZW1iZXIgN3RoLCAyMDIx Lg0KDQpUaGUgZHJhZnQgY2FuIGJlIGZvdW5kIGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1zaWRyb3BzLTgyMTBiaXMuIEF1dGhvcnMsIHBsZWFzZSBy ZXBseSBpbmRpY2F0aW5nIHdoZXRoZXIgeW91J3JlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIg dGhhdCBoYXNuJ3QgYmVlbiBkaXNjbG9zZWQuDQoNClJlZ2FyZHMsDQpOYXRoYWxpZSwgQ2hyaXMg JiBLZXl1cg0KDQo= --_000_1EDB669E5E4C455EA1097A69ED085D1Farrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <3213F1C26F5D7B409FE5149DB25DADF4@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjND MTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNw YWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWls U3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIg dmxpbms9IiM5NTRGNzIiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPkhpIEZvbGtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+VGhpcyB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBpcyBjbG9zZWQuIEF0IHRoaXMg dGltZSB0aGUgZHJhZnQgbmVlZHMgYSBiaXQgbW9yZSB3b3JrIGFuZCBpcyBub3QgcmVhZHkgdG8g YWR2YW5jZS4gV2Ugd2lsbCByZS1pc3N1ZSB0aGUgbGFzdCBjYWxsIG9uY2UgdGhlIG5lY2Vzc2Fy eSBjaGFuZ2VzIGFyZSBjb21wbGV0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5CZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk5hdGhhbGllLCBDaHJp cyBhbmQgS2V5dXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+U2lkcm9wcyAmbHQ7c2lkcm9wcy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhh bGYgb2YgS2V5dXIgUGF0ZWwgJmx0O2tleXVyQGFycmN1cy5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTog PC9iPlR1ZXNkYXksIE5vdmVtYmVyIDIzLCAyMDIxIGF0IDExOjAwIEFNPGJyPg0KPGI+VG86IDwv Yj4mcXVvdDtzaWRyb3BzQGlldGYub3JnJnF1b3Q7ICZsdDtzaWRyb3BzQGlldGYub3JnJmd0Ozxi cj4NCjxiPlN1YmplY3Q6IDwvYj5bU2lkcm9wc10gW1dHTENdIGRyYWZ0LWlldGYtc2lkcm9wcy04 MjEwYmlzLTAzIC0gRW5kcyA3L0RlY2VtYmVyLzIwMjE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+KioqKlNlbmRlciBpcyBu b3QgZnJvbSBBcnJjdXMqKioNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkhpIEZvbGtzOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87 LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDtjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBh dXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVz dDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Y2FyZXQtY29sb3I6IHJnYigw LCAwLCAwKTt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QSB3 b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRyYWZ0LWlldGYt c2lkcm9wcy04MjEwYmlzLTAzLCDigJxUaGUgUmVzb3VyY2UgUHVibGljIEtleSBJbmZyYXN0cnVj dHVyZSAoUlBLSSkgdG8gUm91dGVyIFByb3RvY29sLCBWZXJzaW9uIDLigJ0uIFBsZWFzZSByZXBs eSB0byB0aGUgbGlzdCB3aXRoIHlvdXIgY29tbWVudHMuIFRoZTxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5XR0xDPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPndpbGwNCiBlbmQgb24gRGVjZW1iZXIgNzxzdXA+dGg8 L3N1cD4sIDIwMjEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBo YW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXpl LWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Y2FyZXQtY29sb3I6 IHJnYigwLCAwLCAwKTt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+VGhlIGRyYWZ0IGNhbiBiZSBmb3VuZCBhdDwvc3Bhbj4gPHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJh ZnQtaWV0Zi1zaWRyb3BzLTgyMTBiaXMiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtaWV0Zi1zaWRyb3BzLTgyMTBiaXM8L2E+LiBBdXRob3JzLCBwbGVhc2UgcmVw bHkgaW5kaWNhdGluZyB3aGV0aGVyIHlvdSdyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSIHRo YXQgaGFzbid0IGJlZW4gZGlzY2xvc2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Vi a2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 O2NhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0 bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6 IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O2NhcmV0LWNvbG9yOiByZ2IoMCwg MCwgMCk7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk5hdGhh bGllLCBDaHJpcyAmYW1wOyBLZXl1cjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1EDB669E5E4C455EA1097A69ED085D1Farrcuscom_-- From nobody Thu Dec 9 07:25:06 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21CA3A0D63 for ; Thu, 9 Dec 2021 07:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net 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 wRPoHGlUdXd8 for ; Thu, 9 Dec 2021 07:25:01 -0800 (PST) Received: from sonic311-24.consmr.mail.ne1.yahoo.com (sonic311-24.consmr.mail.ne1.yahoo.com [66.163.188.205]) (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 6DEFC3A0D50 for ; Thu, 9 Dec 2021 07:25:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1639063500; bh=5b6mgMT1EFjC/NGEkYVr58nJMT5qAKJJUkBWG/0FLFw=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=DCw5LH4TUGdiLVOFrmGKA48wRuMVJ0wzbOqWmtQwF1T6zxK8jG/qkDOBmcJmgrUYlEuLdK01TKfObC3vKB2wcKnZddort/QvteTsyanv94NyVFLbIQoTFf6tdQ9yZakIuCp3YbNTFMpP9nZp8MDgdHO28Tq41G1UXAV3WwCa8x+LWbOVpSKsOAcr6NGSspBLc4vVIg6N92aotnaLSWohiNhUsuz6EJee3YN1LRRmsvnvSXzoTdU7pLzinbzq8XoU6gLttbAjMwQ+4pR+ql0NB7Ei43xzkQ3Z/vWPn2Bcj40nAeWyn/HoV96DmCVxXhziWUASyeLRexs03CTIO1QodQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639063500; bh=e5CKwhakkohKkD9et0HVItcfS+Y5VJlKRHGnn1joj20=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=AQZkRmXkdNUVzrpYYJPBYJCTQQ3ksfyw6uenGUNUOuG5zizZKeaMWlMRxMqXMJrFrKQabut15+Xa6dFTUySWNbce4DB4zL/0iF0ktMDkLsBDy4KoUoax4sq1r6oeTouh8CaB1j3Paz19I/BWWyReO5I66ybYrDnoCaxJz/g5GMx+2hLRdYhTzv3SLaA95k0bUtOkec+RxIq0Cx9u8eHBwKi4e+mEnG+Li75+TF2/ygUibv8hGIKaMRQUXD1+jmRVgIYedQ9geVGhudCemv4u1mFzB2/UCnx/0qFhxa7opRdDRtucJ3fSD0k2sZ99RRYoo/zOEapl1ywkxWwzPjcHJg== X-YMail-OSG: VNpHA9MVM1lTIPYJtr_q1dDaGofCSTktaL3_cUkSE_cW1Qgc5mQHeTTFyclrnYe 1kXCRe6KwcPX1PPhAU.gAyy7MvR8GdY7qsyU1GYNH3mwOOAxunzVLNReKpn8aSqKKRMDAkE6fi_Q lvAGzMqFUVYDoYf654Vs1DXnK1kQEI7bJ0o3mownC88kViek2OjTTcw2WogeDD22N4XdIM8TmNeP 9fRwJWISjAEVCvZycXurAY.CFoTuhFiO_5l9xvrkpRgxYWnssnejS_hDgsHgHEO7qJYtcqxZGWi1 3POl.dmp4gR2cKytz2988.KShkBwrvxl7bsuG2Z5w5vq7VfF5np_zbWeOx52I.rY5rjmPE6acugc cjrxno21T88vC96CUp_iFB1FP5YUy8cHx44ekoLtKSD02I.P2929KyBSC_okg8A0ewadWWSw9klk ZZ7SQZgA25zqzj9BKhE8UJdjROSXRQLV9snFty6hfftZ9EWfHUE2Im.VphDWsL9o1s2M.DIxMuYC d1lMYPbycJ2tsd5JrMMDbUNKJ3LY3obhStkrDm5PoFv5.5l5y4jnoDkwkhXWFkR2X9cldvae6rIg R3V6mvWgtchNWHepzzJE.u9U1uVVS97Iparnb6HeWvvowag7FZF8RXw4KY4h.Lm9fUKStJH0XuE7 Bn_bg5gW.LDC2RpXFkG7juCZEeAo09Z6W9.R_m38JnlCd3AD7izOI..NHE9CIqjFk55cY1W475O1 Vn5KnljG1K2toeHHUxqft00EG8Z8rr5A7qrnu3Iyzjc6hNX_DTKjeyWL1eXSZDlrrJSJzEXaqURT 7EkfCLkIA.WOVxu4Sqr6eGlgfzpug8lpgWdHhcTVwpu4VF.0TdoyOUDDUXoOACc6fVjN6pvhDf_w Cz8J_JYRkIDnaB3paHfG6RYKQ9nppMESp3C1nb5.k65Sn7B2HzpQEMeOsNq0E7TT86EsqtShlMC_ jY99KoyPKfo5TQZvEY2zvzkW3_a69ZHDOtEihyosVX9jYvHUzAglEkr.gr5G.Tw95Ikr.Di9JjsR Irv_Jto5WZY0ySvR07iIElyMGVFCLq.WpPihfDBfR.o40OA3yDeGr9.J0BUXA_h87jwUa_6Tpm6_ Xp2zxkYP3ZERjY38_AMOXcatuuTDosiM1F7BCilA1MS4_twIrQny0e_HYD1NxET1aBx4sM3OWdUX Qbsmdcpnyo2O6KgAjjZa.GOlQuSrN8SINmy.GH44T6H_mMNBbcxKaJC2L4Tf8FtP5UZBiLUysyKo AwzeakOsIfx6X7mLI_Mt8v7TftR51TwR7INAJm6TcM4hPK1.umYjada4YU53BNl98vewYu0B1kLP Pjc4wswoSElymDPKGp5CjOk0QrDC7ATz1M9ZW7jhfcDMXZx5QuA6LKa22PtVdp8rXn7IzOmwr.DW grxRR8Cf0hg75M.ulugOdpyU3ThENSxA1fSQ0jWpiIp07q6knl.ndWSqUOxpoyVBG9dJaLdkHCQK ji.DmSYV_Oq.PBl0kZpzjaAvl31FARWs5pnnPxeUMv3reGinjsoRvsnFBSwBifRUQHiM5Jx_jqdm ztXamRT41izGUJkr9SgOc9dqZJxlB9KmXZGVEEEX3VUeXCnjVTmZ5_IaQ0NbEqjhcNlcfnXWIXYr apb5gpLxB11eied.wRdoKPWY6Bwhw17R_.SzmQdb01Svf5PbIMha6H1kmi4kf8vI0mg6VO6Q6iuN i.z3Lq63X3NFyasYuEkKsv97kvCk5WfLCMG.Kv9knoc0u86qgTAirRQwWksWC97_qCBbPEdhfqWQ nebnel9eOXi0zu6O9Hqu7fQam9bek2dDpac0UwTuJC2OsEh.rcvm80bt7rFX4GMaSAEKIxNafSH6 kpmaU1KDOkz.SekdMEbn5YmbeFeghGr7VyU57b2lXz_PgUQie3XSJBzHTqltHN3M6bnyTlxCALHd 9HMo9bV_LiuwznexHDM1ys2ycc4prMP5zuVUBJgHSYDsIJSRXSdiwGOx09B_qcm6fb1Q3fjcpdWm 0ZVEaMP7YCI5XngGa4hsxYc1Ft2aWW2.v7IGhFMjWTKVxea.HXOqY8kl4.j4MiLc_H5wgbzBlehV Y8TDMPvbFaNSeeFqjnAr3zuE9UjVfRSzIOjquWBYoI2gbNSpzRr3jDVRAlVQmk6JR5B6nOZ1GyUb n_h59n0.7jsyhEYx7llvVkecAWywyGGjV.n2UdwkZqytwZKNzsq07HeJW05D0lcM4fIkuBDM0Y2F ECjP3fRkrGw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ne1.yahoo.com with HTTP; Thu, 9 Dec 2021 15:25:00 +0000 Received: by kubenode550.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1e916f718c657702efcdc15557650677; Thu, 09 Dec 2021 15:24:55 +0000 (UTC) Content-Type: multipart/alternative; boundary="------------hnLqBWo3lzEAas0fVHLFaR4g" Message-ID: Date: Thu, 9 Dec 2021 10:24:54 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Warren Kumari Cc: sidrops@ietf.org References: <813d1599-fc9d-18b6-a76c-b550855b1186@verizon.net> <20211130193034.344F62EA0102@minas-ithil.hactrn.net> <8d9b693c-137d-4a76-9fef-65968bb5062e@verizon.net> From: Stephen Kent In-Reply-To: X-Mailer: WebService/1.1.19415 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Archived-At: Subject: Re: [Sidrops] AD Review of: draft-ietf-sidrops-6486bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2021 15:25:04 -0000 This is a multi-part message in MIME format. --------------hnLqBWo3lzEAas0fVHLFaR4g Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Warren, I will have a new version generated and posted by next week. To address the two outstanding issues I have made the following changes: No one has provided a cite for a filename guideline, So, I have inserted the following text in 4.2.2: The example above contains a mix of uppercase and lowercase characters in the filename. Some filesystems are case agnostic, while others are case sensitive. It is RECOMMENDED that CA employ only lowercase characters in filenames, but RPs MUST be able to process filenames that contain uppercase characters. In section 6.3 I have revised the text to take into account Tim's observations: If the current time isearlier than thisUpdate, the CA may have made an error or the RP’s local notion of time may be in error; the RP MAY choose to treat this as a failed fetch and proceed to Section 6.6. Steve --------------hnLqBWo3lzEAas0fVHLFaR4g Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Warren,

I will have a new version generated and posted by next week.

To address the two outstanding issues I have made the following changes:

No one has provided a cite for a filename guideline, So, I have inserted the following text in 4.2.2:
 

 The example above contains a mix of uppercase and lowercase characters in the filename. Some filesystems are case agnostic, while others are case sensitive. It is RECOMMENDED that CA employ only lowercase characters in filenames, but RPs MUST be able to process filenames that contain uppercase characters.


In section 6.3 I have revised the text to take into account Tim's observations:


If the current time isearlier than thisUpdate, the CA may have made an error or the RP’s local notion of time may be in error; the RP MAY choose to treat this as a failed fetch and proceed to Section 6.6. 


Steve

--------------hnLqBWo3lzEAas0fVHLFaR4g-- From nobody Thu Dec 9 07:51:42 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8EA3A0D9A for ; Thu, 9 Dec 2021 07:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-WOumwQcokm for ; Thu, 9 Dec 2021 07:51:36 -0800 (PST) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 177DF3A0D8D for ; Thu, 9 Dec 2021 07:51:36 -0800 (PST) Received: by mail-ed1-x533.google.com with SMTP id x15so21311993edv.1 for ; Thu, 09 Dec 2021 07:51:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=7wfKDSO9J+yDjRtyL1HGALEzfbM66qrxGbQFoEohsJw=; b=UsuRcBmq5dyHTJMenYTCFlBXlCTJUwCN0oCC1Y4wz9tGWzV5vjOM+pdUpHLuEFbgVs wIFBSV7xkDQMMfPjXMTw9vjxE3O1AC3CGlsQlRbJL9uDIe9pODaATwaD8jZhKjQueTuE 5/2cJxjuUcZjF+Lcse88AUXl+NRwSkGUILRy4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=7wfKDSO9J+yDjRtyL1HGALEzfbM66qrxGbQFoEohsJw=; b=PX7cd46VPycmRGIlBr6cCOlI0O57qQIikeao0glCKr8Tg8fiTRobFfKRXgOA2qEaf/ LBE6GpIqv/+LIIWobOaU8st/KTA6gnyYGG2sDprx/efICpKG5Vg4Vz5Ys8eYWQxGtl6h iIw9RKaJGJmm6yx2Ureo7p0vq43p2RTHW0zcxH60PFMGfF/PpPThCp3JSVDZ5rWGSAsa kn+nLwBnKtFWqjBDTcsVFWiwIyZxmNDXNW9rG+HU5Ehfl72Q8ynyeI3JMGbpENV0nscy UQLzFs113ma/YD4AFh66ifyHDCOZRaBleyVgaNxZwrSlzFp1x8ic6HrQUH1QyCcTD9hJ 5nkg== X-Gm-Message-State: AOAM530QZ0/HZpvWHsWFpRkVyXLlNgLMwbunMMBSYbdHDlfF7+UpmQmM Uav93uXMcY2V7m+/s6TlpxP+MQ== X-Google-Smtp-Source: ABdhPJwoA7D5N4ikbZ/P6bNmXKck6iLZmiRH3rxbYalJpUwBLSyFYNHTqdCIkZb8ULn9jF631bjR4A== X-Received: by 2002:a05:6402:1d48:: with SMTP id dz8mr30051512edb.100.1639064984077; Thu, 09 Dec 2021 07:49:44 -0800 (PST) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id gs15sm132665ejc.42.2021.12.09.07.49.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Dec 2021 07:49:43 -0800 (PST) Date: Thu, 9 Dec 2021 16:49:42 +0100 From: Job Snijders To: Stephen Kent Cc: Warren Kumari , sidrops@ietf.org Message-ID: References: <813d1599-fc9d-18b6-a76c-b550855b1186@verizon.net> <20211130193034.344F62EA0102@minas-ithil.hactrn.net> <8d9b693c-137d-4a76-9fef-65968bb5062e@verizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] AD Review of: draft-ietf-sidrops-6486bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2021 15:51:41 -0000 Dear Stephen, Warren, group, On Thu, Dec 09, 2021 at 10:24:54AM -0500, Stephen Kent wrote: > No one has provided a cite for a filename guideline, So, I have inserted the > following text in 4.2.2: > > > The example above contains a mix of uppercase and lowercase characters in > > the filename. Some filesystems are case agnostic, while others are case > > sensitive. It is RECOMMENDED that CA employ only lowercase characters in > > filenames, but RPs MUST be able to process filenames that contain uppercase > > characters. I am not sure the above paragraph aligns well with current operations. Virtually all RIRs and CAs use a mixture of upper-case and lower-case in their filenames. I believe virtually all RPs expect to run on case-sensitive, case-preserving filesystems. The newly suggested recommendation is somewhat at odds with what's currently deployed in the wild, and I see no need to introduce friction or change in this regard. POSIX.1 considers case-insensitive filesystems to be 'non-conforming' filesystems. https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html#tag_02_01_01 However, a POSIX reference is not ideal as draft-ietf-sidrops-6486bis specifies the use of a subset of the POSIX portable file name character set. If I may suggest some text: """ The example above contains a mix of uppercase and lowercase characters in the filename. CAs and RPs MUST be able to perform filesystem operations in a case-sensitive, case-preserving manner. """ Kind regards, Job [1]: https://jakewharton.com/case-insensitive-filesystems-considered-harmful-to-me/ From nobody Thu Dec 9 08:58:37 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABA73A0FC3 for ; Thu, 9 Dec 2021 08:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net 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 H0Sc9qdQR_1F for ; Thu, 9 Dec 2021 08:58:34 -0800 (PST) Received: from sonic314-20.consmr.mail.ne1.yahoo.com (sonic314-20.consmr.mail.ne1.yahoo.com [66.163.189.146]) (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 68DB03A0FC2 for ; Thu, 9 Dec 2021 08:58:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1639069113; bh=Sr4u2xW/VIE1163scv9oQRXui39axUuBhGSPp05TRrI=; h=Date:Subject:To:References:From:In-Reply-To:From:Subject:Reply-To; b=EDf1q6ES/R2nnNJ46DOeQwIUkctRVmJ4x0JWhxX48cg2v3CcrHRvjZrhr5ISmGR3wzXjVeRfJRXmflw0P1FoqAUg+Ya1PcwG2ExqyIF4nWgDVOI62oLOKjT1eVjHtFdvqTxdtOepPU9hXlczDJMGQHyZbOfiZgbvrMWV2AmwsbMkVuC9nLcTapi2ydM282GfkYKpunRI+aQGdIOpcVb7WmSiNRffREmTq8lj1lA4fxTgWfZ812mSWKgtVPjAjrHfmd63g0zLsTQtyXlptV5r0KTHeYeghQIOuBQYQ5oyWD3yo1D3/Zvhtebfyv79QXfXqqTvJeP/yNkrfGNdlTNvtw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639069113; bh=nJqu83OSNKD9Aoj1SzoAqYfZShjmfPB0Ei3aYzJ0lN/=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=dFxmAKQ7x0hNH35XH5JymVLDIiOXd+tKSfB0lmOipRMaIrsyVREu+VjLUh0Jqpt1n/ZnuhbZ17M7JNMcpU1lr0h0qvLNquckFo8WGiG1zi+J9LuLoJvesPUkqrojNSRGye03Lryvj5ZaXEV+svV9wbQycNjlcXnPWOBXFKEa9FzU24QPouF1X/OuhNuHQCw7zTVYNqGMAy2Q26uhQhIttb4AQUvVJ7v1Ixsy+grvs5+7C4gyf+mI5easE0ydsi8HM9Nxu6XGTBy4x1xvytYUdgF6yqLRNqYzQ0dcV/RcuohanlzJZdEYHbjyre2fRsyBpJuGmia7EzJ+k1KdanIbkA== X-YMail-OSG: BjGcUWQVM1k2.gdie9uEPRucXDN9GZhtTTT7dqMQhOXnu0uzkwzXS0UBie6vPU6 Gh6YEBDzH3zytbFnYwbiK5TX1EcTkcsZB.DwsN7Ae3jnDvWh8EvK0Jvekc55JqDtCBCxSL9elBf5 pUmrCvx0OP_a5NMWEhT3qKkOEuORAuppmyLxKan0q7UaWfTi9xRhDnd_JzOT5sDw_lHicidOHASc aTE9qnJOioaTxgErJqv7XStNfSSPLppNLg.o8VRfO804JZTji_QkL9op13KzSrzWf4OS8F99XQlz PD001CbiCMhzp37Faup8lYntr4fuUzlcryhTfYrIgD.hvWxgY611a9DgiGVeVNq4pN33z9TqbqD0 KaGnz7birSuL7U8H46nAdn4lkCsFqQQ9ySZ.45sDKIa2EMNPRFPYsnZRDDM8xRa2CIeQUuln6Ngn ub1aTRiYr9xYGrTyKtxT943aPr5Ri1z8IaehO54lu0YrGN.AMkkWBskSqfaDBGdtXVNBwsPOjCMw QPtyJ0g4rBgVeIfUor_vi18rm6zHOqDP3qrUvDODzAAgDlUoQXLRq86wnBo5BuF1URG8DpB695Ue kmYt8ZOnRX7zQNQOWndPhNa0ds8WtorXOmeygLdaBFbJujjIpOx6WfyHrCnQ9b862TglamGWi6_U PfDNCWfe73UIXsdyRUaOiNuSkpXdY9zipE9Czv02Y.1gbyNituUuVkNgSOutYHoP7uzFGQIEAx0B BwXpEcBOct.fIjk3zayn8KvAgAHNVujkFOIs8w3tPV2f8X3ANxH9yCjV0KItFLWK7XJCeu7qnKvE 3dmWKPPSJUEgIMuDLKWW1BijescQ4QPRLWlOWcdMhq7houqDths4mRvNO3Rk8o5GT7tEG8XLctam tfRFhPaMm._OSjJ603fi39WiDwGhozYvSdt2xqE5ARIptRLxQBVoy2I95mZcTxV1jF_wy0Hc6CMX UlW_xic.WOs4wlhW1CsjV8vJD5c2XjpcFzKpf_6v120TPRvHSDneKf8vU2MTYCh2Fq7_hyL1aH5v 2TA4_itneDGGzF3JTOaGhc9wwMcAFhz0ZmOawoEBxHPxULmGsqZDf36TCv62dlzvpn5WKFTxTwGG OukQYWZ3A4nXOrDlHGr8NyC_8orzDOytaZw.bHuwvcGQ79Yhy7WWtxpVllM0pmCGP7MjQGKpGSpG KTvqo9BZ3mvTGVs7ZSgh3EGB_U3BxsRupLFIajIBlWOSJ1SM10ZmqdAlV3SdC20V85eoFzh5TcJO zBegpU.jN0dF9AFCKjOF2I16EiLvMeDtGnR_U6fZgDoDyqWQYiHHgMWThqhhhscJzPn9XCnKeKNh QdcHdW5rL69z85GHrhI_dTdsD87JPrvfqNoGkV.Jsxk0nzrw16H05a0TGnzA8R5cOGxbIrBvoxgI fk3fKbBQaxBouLSEef_7rOvyjTh9E3nC0q.FskW_HUShq5lP7UzQt5lyCmIV0zG7nHfAbqqpSBLv nOMtjnrJTJwJ9KNHcUeq0tzqkydIwcsHudPiYymUUW9NWK9P8VusXxUXZq0A2fpHkwRUmBDSulhG SX92bflhvrRk02CSxnAxUAsxPfQtvqzvaXg2vgjwuyQCTOc__1gXAtb5v0EQkyQxP0vVSXC0iqDQ Ji_ECf_Yfum1t6nUznoeE.7og3YwD95F4tNSa5.SIM7KPFSLhfX4ggf7wghGo6l0M0U7AKJKHYEi _XKGFpCabEo1vLzuc64U4sFkqwFt0h2G56aiioCzzitz1hR16MZkjTR4vFhR6nV.JLWNm9Qb6fDr jOe_aGmo6EjDtp04Ydvz4aIQ9arWYGEFsFN3oR3FiJnGR7ZbwVh9wS52UoES3PhbWdyNDPJhCujN 3ME1zd_NeEBeQ799Tvbq3dQxlSlIYG7lMhocU9R3e2mqgDIaAFdxEhowouVEJr0SPMJikiggui0Z HZUx.IdeXy_iilME0FHAX5xd3EaVQTutCw3.D9qPuIqiXxz0YsPyVgLNhPcI1bmFeHJYrx63P9pB bNo2IK3E7HNP6C6VVwNkONfGFj8b7TINAaGeG_BDfX2x.ZJwOJH2RjgTUfssWno_t5HhMOUUKJWX O4AaQsDJGYLFP4W7Q9jH540suUXuXxncC1EEGHrHGe8UNCQQjAoPUMgPs9vU8dqWQvboA93IB5Xy i4NEB2f9hCPpM85w6e.ZzXuDpDSUdGTPl1E0m8oHyar0rAcSPotG0oqaOVmsLIZwQig-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Thu, 9 Dec 2021 16:58:33 +0000 Received: by kubenode549.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f377e43f24aa82f73fa6f8390a2e2a83; Thu, 09 Dec 2021 16:58:32 +0000 (UTC) Message-ID: <8b388845-3b51-34e5-e8d0-38f2618b0d71@verizon.net> Date: Thu, 9 Dec 2021 11:58:31 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: sidrops@ietf.org References: <813d1599-fc9d-18b6-a76c-b550855b1186@verizon.net> <20211130193034.344F62EA0102@minas-ithil.hactrn.net> <8d9b693c-137d-4a76-9fef-65968bb5062e@verizon.net> From: Stephen Kent In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.19415 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Archived-At: Subject: Re: [Sidrops] AD Review of: draft-ietf-sidrops-6486bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2021 16:58:36 -0000 Job, I'm happy to adopt your text - it would have been nice to receive this input sooner. > If I may suggest some text: > > """ > The example above contains a mix of uppercase and lowercase > characters in the filename. CAs and RPs MUST be able to perform > filesystem operations in a case-sensitive, case-preserving manner. > """ From nobody Thu Dec 9 09:06:42 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786803A011F for ; Thu, 9 Dec 2021 09:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJ9NacnJbuTR for ; Thu, 9 Dec 2021 09:06:36 -0800 (PST) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 1567B3A1001 for ; Thu, 9 Dec 2021 09:06:36 -0800 (PST) Received: by mail-ed1-x52a.google.com with SMTP id x10so4435620edd.5 for ; Thu, 09 Dec 2021 09:06:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=NlTi3RA/pk3szjPmX4smHL5A9gcYLoCOK4lmBfUEwpQ=; b=Vw6yPICksDRtXrk95lsujTo4TP4AFTSkAq6CYz/PVTztR9IXUq5f9qJqtn0UC41Wf2 S9q46jMRp47id5CTTylZs8U1QFTo+EBPf5018pAQGiJhXzDkmuASjsUMcwXfM/8/vTw1 AecYVXic7gq7+RS7nBMVULYOOwG5MEwqzAjDY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=NlTi3RA/pk3szjPmX4smHL5A9gcYLoCOK4lmBfUEwpQ=; b=udrg7N7EnYA/ilkSIamo9bSDYFEheQO1OSfi0TmAbJIrK2OMvvnms91kQUd/ltYjdz 1t1Al4D2gbdPAVOxx/gZxkTQaQrEb6ueC/h0BPUhBv5YOj707sOHcuhl7PCsdws9eyVY Ja8Jf1Gprjmm5cQu6WMl49/Y3PDyw9a5dFm3f75n64MiUNOz0dmlhbJIAsiA+KRSycA2 nkre0efj5DNlAmhboFQqueh+PxjnSWZT9jW6uARArckHmrNUvqexGjIZDgb1ZEyrBKFy eRKDnURhY7OUCwCPjC2G7NVqk9q6xipgRU0awjoCImildnwLu2FYNvJBwiNRHjwESEmG rjww== X-Gm-Message-State: AOAM533EeRF65Oa3HezmDSH2gtKYDLtgScK8lG1LeYfGjhXrsRoyNWbK FE6oMGivOQMa1YLFpSZH0LqLhQ== X-Google-Smtp-Source: ABdhPJwYi5qY8Be1pKwOGfAoFjx/avpFCJykUb06VTD1mx4QHL6QtBcJZkkYKWtxRBq7/2MmSBLuxw== X-Received: by 2002:a17:906:9f20:: with SMTP id fy32mr17631273ejc.459.1639069387716; Thu, 09 Dec 2021 09:03:07 -0800 (PST) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id x7sm185545edd.28.2021.12.09.09.03.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Dec 2021 09:03:06 -0800 (PST) Date: Thu, 9 Dec 2021 18:03:05 +0100 From: Job Snijders To: Stephen Kent Cc: sidrops@ietf.org Message-ID: References: <813d1599-fc9d-18b6-a76c-b550855b1186@verizon.net> <20211130193034.344F62EA0102@minas-ithil.hactrn.net> <8d9b693c-137d-4a76-9fef-65968bb5062e@verizon.net> <8b388845-3b51-34e5-e8d0-38f2618b0d71@verizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8b388845-3b51-34e5-e8d0-38f2618b0d71@verizon.net> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] AD Review of: draft-ietf-sidrops-6486bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2021 17:06:41 -0000 On Thu, Dec 09, 2021 at 11:58:31AM -0500, Stephen Kent wrote: > I'm happy to adopt your text - it would have been nice to receive this > input sooner. My apologies; however it was your newly suggested draft text that prompted me to immediately write a counter-proposal. Assuming a linear sequence of events, I don't see how I could've delivered earlier :-) All the best, and thank you for your good patience shepherding this -bis document. Kind regards, Job From nobody Thu Dec 9 09:32:50 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3B03A10CA for ; Thu, 9 Dec 2021 09:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUSAnvAUQYrH for ; Thu, 9 Dec 2021 09:32:45 -0800 (PST) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 E9AD53A10C7 for ; Thu, 9 Dec 2021 09:32:44 -0800 (PST) Received: by mail-ed1-x52e.google.com with SMTP id y12so21356881eda.12 for ; Thu, 09 Dec 2021 09:32:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=oVwxO9jmTOmK5Mny+9OVDjuv9r1fcRrwY6AaQBDGJgs=; b=yRwyuNN39ZCeY64aqy7pwnaRqFk4dFQ7qygDGDIIJbihloxBfVeKFsBnRGrxg1et84 o6GjESc1khp5qTQeUGHyK7c0qQPsF/jVq6qECocYSB+elO2mSPdyc2vnVCJP8T5AGIJq FAR17U0HhkU7atqTmjOMTnz6j3b9wot/V91aQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=oVwxO9jmTOmK5Mny+9OVDjuv9r1fcRrwY6AaQBDGJgs=; b=Izw5XC2GAT1O9MdZpEsPWXJVJtleAXZ3DkakCMuN/Pr7DH7zqfVzFu6Ybo/P3oWEIh 6WWGhrYrkZi7mhVzO+AWFnrwcu9OVKnkbGUwPbCvrIFw0Sk5PPWGurvl6VKS0+WLCCNi pBObDwDFJdVxkbYodsTqqGq7pKw+NBUHtqJaFUmJy3pPJVfvj+nUalhmFJUnjR52kHPT n8Hf4d/6aD+GH7bS/u00ZIxCIpalnQMJbKmQ6cHrE1m5OThe5bR1LwpJHKoz6I697DpL TM+PHhdLKbOQTHiAxuMc5yNu7bJAL+CM1yHX7q73y2K0ZzthkAXv1xL/YdeQKh/mBIUU 8JsA== X-Gm-Message-State: AOAM530uzomFHXXtsY/nODLQflNKk/kZzz0I10P47fCPe8Iy+DSm6QWw rs20pgEPY6YrdUTzOjLS5R2TYJIP/qnaYA== X-Google-Smtp-Source: ABdhPJwQe+tz5XXIww3BQ+hM/HOEKL9gvV+hEq3aPMvaXJaUkFHCeOdC8HeBOJ/jL0pO5rA7taBcJw== X-Received: by 2002:a05:6402:1d48:: with SMTP id dz8mr30822658edb.100.1639070977430; Thu, 09 Dec 2021 09:29:37 -0800 (PST) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id k21sm185277edo.87.2021.12.09.09.29.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Dec 2021 09:29:37 -0800 (PST) Date: Thu, 9 Dec 2021 18:29:35 +0100 From: Job Snijders To: Stephen Kent Cc: Warren Kumari , sidrops@ietf.org Message-ID: References: <813d1599-fc9d-18b6-a76c-b550855b1186@verizon.net> <20211130193034.344F62EA0102@minas-ithil.hactrn.net> <8d9b693c-137d-4a76-9fef-65968bb5062e@verizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] AD Review of: draft-ietf-sidrops-6486bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2021 17:32:49 -0000 Hi all, On Thu, Dec 09, 2021 at 10:24:54AM -0500, Stephen Kent wrote: > In section 6.3 I have revised the text to take into account Tim's > observations: > > > If the current time is earlier than thisUpdate, the CA may have made > > an error or the RP’s local notion of time may be in error; the RP > > MAY choose to treat this as a failed fetch and proceed to Section > > 6.6. I do not feel comfortable with this use of 'MAY', such a directive may encourage RPs to act fast & loose with the interpretation of signed time values, potentially violating "CA Intent". The use of freely and pubicly available NTP sources on the Internet EASILY brings RPs within a -/+ range of 1 (one) second (but likely accurate in the order of tens of miliseconds). The Internet's routing and forwarding system is able to deliver with jitter globally measured in the low microseconds. Time signal is also beamed through the ether for free: GPS, Galileo, GLONASS, or long wave: MSF, DCF77, WWVB. I would leave the text as-is, or suggest to change the MAY to MUST: """ If the current time isearlier than thisUpdate, the CA may have made an error or the RP’s local notion of time may be in error; the RP MUST choose to treat this as a failed fetch and proceed to Section 6.6. """ Timing matters not just for the Manifest's eContent thisUpdate value, but likewise the Manifest's EE cert, and the CRL's thisUpdate, and the parent's validity window. Let's please not open Pandora's box and do away with the concept of globally agreed upon time. CAs should not attempt to compensate for *potentially* broken RPs, as that puts a burden on everyone; it is safer to let broken RPs be broken. Hopefully the RP administrator at some point in time takes an interest to fix the RPs notion of time. In rare cases where an RP is out-of-sync within a margin of a few minutes, things will probably work 'as expected' after the next validation run. So at worst a 10-50 minute delay takes place (because the RPs clock is broken). However, in my experience RPs that have broken time, are likely to be living in the early 70s... such RPs should not produce VRPs. Kind regards, Job From nobody Thu Dec 9 11:27:51 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF86D3A0AD1 for ; Thu, 9 Dec 2021 11:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 POGJsuKTaX_Q for ; Thu, 9 Dec 2021 11:27:44 -0800 (PST) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on20714.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d04::714]) (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 B67A03A0ACA for ; Thu, 9 Dec 2021 11:27:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aWg+QjK8By+Qirqpu5prHf9dWEUmc1IdnqFfN4zxg5vqARdhLrmSSP+XydYgo8xmbhBfxExYk19UepW85jcH0AmOa0iRlsB+iJh1rGsFdP1zvTpmSbFodJqIHe+G5fjLHjzxGqauzFEXuenP1vh5Hk+ShZSRdqvLi4Uh0urfnKpN/aelgpGohoJj0EwHDnlZGvnEOf/ah1DCoUuj1SbcXnUiFhmGnABoDWvFbnTHcyMumCxsTgyn2Pt2NDNohqBs7vT5y5yOPxCz8M3GnwT06wlYbLHCh0lZD35BL2/8EJAN6fAS8TsIoE3QACmqsdmbLC/+BD6N6Zm8FghgzVcXHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Ak04imQdH2wW6l1WpR3BhsaaFEv1cXUK5lqZEY1SI5U=; b=CGX3IQh0POWqyML7Q/kbasYWB8hAWhc3PY9ZDdejsqtsPxslJAHffXKPNxdKvGTG++/Mm7dEniyWhw4GHVzizPqYQLJ9Rzum58EMdWfy/oxlGmG8oQVG4JaPvkol0Dos+NCKhz8yDnTllWxxpegRF43W6JP0SWkG73Bh/vZt8hqguc216ZrPZOBvau0pfiGfRHGC464wKOMskxYX05EJvBGXzVpiPD4nq8z4RcF41jo6cOld0xODIg6UKiZJ0xviMob53GiTYUlwEzLuqzVNgE41K9SfAuWQOQMW386LxeJ4d7NTVjxNgiiqa+nkW5mQg6jFVJUBCslljTexNYHu1A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ak04imQdH2wW6l1WpR3BhsaaFEv1cXUK5lqZEY1SI5U=; b=xpa4M7UcD4PtMftNcElHX+b2+bc7H2PWUINNcEHKURhwCT52HqAvM+kpvVvwiUVkK3vMKP4pjFtuulJp33jj5ttq9lw3bCOD0GHLNcEU2QOaMw4tD79lrTiS9IAV2dCpMzBZjZUrTatA5xsug9DtS2femB7kjvW+R2/Ti8JsMPU= Received: from SA1PR09MB8142.namprd09.prod.outlook.com (2603:10b6:806:171::8) by SA1PR09MB8768.namprd09.prod.outlook.com (2603:10b6:806:17b::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.24; Thu, 9 Dec 2021 19:27:36 +0000 Received: from SA1PR09MB8142.namprd09.prod.outlook.com ([fe80::94f5:5f35:b0e9:7eaf]) by SA1PR09MB8142.namprd09.prod.outlook.com ([fe80::94f5:5f35:b0e9:7eaf%7]) with mapi id 15.20.4778.012; Thu, 9 Dec 2021 19:27:36 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Alexander Azimov , "sidrops@ietf.org" CC: Ben Maddison , Job Snijders Thread-Topic: Re: [Sidrops] [WGLC] draft-ietf-sidrops-rpkimaxlen-08 - ends 25/October/2021 Thread-Index: AdftI8WwQNyzQz5AS5uTyOc8Gp7x6g== Date: Thu, 9 Dec 2021 19:27:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nist.gov; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5b0cac17-ae2e-4b72-31b1-08d9bb49f4e7 x-ms-traffictypediagnostic: SA1PR09MB8768:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: j/ELwXL6ljZoMlu1gJEOdtiztT/9alJHqdGjKZbkcMByQAYsvhsYchxdz8NCiiCWra3L93ED41D+B64A+2zjIHVHg2jEhqWgE8689QNoFEyE5u34zdainoixoc5775Y0YVYC0JAcxg2DWt8y+g7arU6xFgJNm/cMwbYSahNSgVLBnqr95izo/hu5XMbBWgYhX9m+dQ6+UbrokjOriNXby23S8DCX2ql0wtocPYKkZ7YNBoNkLXB5Uu8+aR4d3ifln1ShiMdP6JqFidc90Sy/jSqkc485tdp4hbgXoepOgq1n68t1Vyg9RRGGLdoNOiXkd+im3NTRibt2Ko1xBkUyUS+nFYarl9nZ29Yn0luvI+3q9/TOz4t4KENctiemqoFFRXEShB6oZhxZqoUhu2hudVu9DQexfc83xnz8W0xoIinkr870kgZhAMcUqMYTV/4GDt8ZdFVINI7puYdeK9XJdDoJmy4eaN+kuVd7EJzfr2CyBEsMclk5nSVagaTv1E5QK0gkBG2klpAVWIjqNagyXc1frm8ROksEfIjSfklSbjwiZKgR9MJZPjUhPHpmKxcFhABGh3aaSTSghHbGKTJbPec24gPrdUDJ3I7Avm1xi/tvMGeyGVTzjDeUlCyvzHDs+4RC5Dg2VcFa+6IH1wwdmotnBTRJ6jcOSLBeYPBlVfU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA1PR09MB8142.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(54906003)(508600001)(110136005)(33656002)(8676002)(122000001)(38100700002)(9686003)(8936002)(2906002)(316002)(5660300002)(6506007)(4744005)(83380400001)(66946007)(4326008)(76116006)(64756008)(66476007)(66446008)(66556008)(99936003)(186003)(71200400001)(52536014)(82960400001)(86362001)(26005)(7696005)(55016003)(38070700005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?iTE6NoXFyzkTXEObF6kjY8EXiLt9nMmxONbxrPsMQIbMNtEi+JmlcWyCXcVU?= =?us-ascii?Q?1EDo761OwWgfGyoRW7jdzK8/SLknw7C2+4vjedrmKxVIB8f2Con9drfKcrI4?= =?us-ascii?Q?j4tFu8fnQuvjUUz9SPV6uwByzvl5K0p7Zf/CRURkCREHShZUvYb/UVVfILLw?= =?us-ascii?Q?Bey3SNEBG2WdkXTjgHQ9yI73UT82uvdmAjRPzfeA82EzWvAW//BbWRJ5wsgs?= =?us-ascii?Q?SoBLiw6f9auxwOgd1Y3Mw6DVcfzif0/6q9jonEd56pnyFJytGDL2Nn/j3E+L?= =?us-ascii?Q?bzmQXYYUcBMy5ePLMl/A7soWNL6AVSoBcFSHB2r4hX/K8/Z9c31jtZJowzQ2?= =?us-ascii?Q?P5FN52aCNZoBGboOGl2bxOiTia+6U+dSVQ91FunvAr4EwQBiRSNp2r1aKHol?= =?us-ascii?Q?BmxIPvoRu7TEkLRxeR65KVpTuBPGmaqHBk2KlqZxkVUxl8zrbAtHueMvMZLW?= =?us-ascii?Q?qNh0tJaIcXU98TB0csUTKh/QAi9XfQQJ48vWMF7O//6ldO/IboFZFdMKS0Ik?= =?us-ascii?Q?ZwVHeNgu2T/YwL0PmVHBjj6U5uN+O2N5m2uUOkmx373ukDBnQ7yzJhGRC/S9?= =?us-ascii?Q?DUplWvpx5hE/NnOT/xUYlisY9TRI8PvTOCC0+nKzOkr9sWv+IYbNo5oBI6+J?= =?us-ascii?Q?Iuw/9ymMYu05MYe9YwUs3UEGRpl9PVUBgPBgfomEp4hrjZaD/iHnq6XtnZdw?= =?us-ascii?Q?Gj3s7BztACeSpfj6eOMvKR8IAFpw8RD4subPRHoPKpBt7bBFP/il4no1C2kx?= =?us-ascii?Q?0/5qnt4xPoGHDw2uKJ3Ly/QbEQhHcs2vZzad3q3PlIbjlFbnjgtCV2i7zJhJ?= =?us-ascii?Q?OyLaUYYOk1w1TolJs4zFRKG1oBtOGiYg/qImCnfzflNwpXKUuIr6NNuTVemP?= =?us-ascii?Q?kJ4eGuD8AcN7mp9gs/Ge316eUfiIhAhxcweUIDUex5eC1NW7as7PHe3DpCnU?= =?us-ascii?Q?jq80nz1PUbQRqmYHp8rlEwdzey1NKarZsiJ3OSZA3/kmDZV91tAcQC3SXO0x?= =?us-ascii?Q?afNwGk1NYY/WRzB4t9qV/bByRod5xHHRdOmSSwvikPZ3b4Hq8olPJWJWbK8i?= =?us-ascii?Q?HkBsXuR/9EAo47NSaDUO7EkF13s0FjGrFlwKXc++heRp8E+Vj8A2qPBPqjSm?= =?us-ascii?Q?12vXV1Jz1a/12Ybg7SrepoE8iytshAiIkzG5vfEUirNZ3+7wZOoOqTb/wJsR?= =?us-ascii?Q?DgbDIJRt1/4fMOYya6NbSahXgfMSnJZpDJmuBFkr2SETiZNzTV00p41uYFiH?= =?us-ascii?Q?LhAdHaHgLh3GqqySLFHfeTM1v1la4uN5kdQ4tEgbxcMzPDx9icMr5j2vdm4S?= =?us-ascii?Q?IDiehsRu86rl7FDPRRXjVk0a?= Content-Type: multipart/mixed; boundary="_002_SA1PR09MB81423BC23B431A3EBC9BF98D84709SA1PR09MB8142namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA1PR09MB8142.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5b0cac17-ae2e-4b72-31b1-08d9bb49f4e7 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2021 19:27:36.4185 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR09MB8768 Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-rpkimaxlen-08 - ends 25/October/2021 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2021 19:27:50 -0000 --_002_SA1PR09MB81423BC23B431A3EBC9BF98D84709SA1PR09MB8142namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alexander: I have just a little more to add to what Ben and Job have already articulat= ed quite well. Just wanted to assure you that we (authors) understand your = scenario. Hopefully, you agree that the illustration in slide 1 (attached p= df) correctly captures it? However, one should not lose sight of the advant= age of minimal ROA for route-optimizer-type leaks (Ben mentioned this) -- s= ee illustration in slide 2. These are *accidental* forged-origin subprefix = hijacks and are of major concern. The minimal ROA approach (per Draft) stop= s them close to the source in customer cones of ASes that do ROV. In your s= cenario (slide 1), AS-X has the option to peer (ahead of time) with AS-B an= d the problem is solved even if AS-X employs minimal ROA. This is mentioned= in Section 5.2. Thanks. Sriram =20 --_002_SA1PR09MB81423BC23B431A3EBC9BF98D84709SA1PR09MB8142namp_ Content-Type: application/pdf; name="maxlength-discussion-Alexander.pdf" Content-Description: maxlength-discussion-Alexander.pdf Content-Disposition: attachment; filename="maxlength-discussion-Alexander.pdf"; size=164518; creation-date="Thu, 09 Dec 2021 19:22:37 GMT"; modification-date="Thu, 09 Dec 2021 19:21:21 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjcNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu Zyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDM3IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4v TWV0YWRhdGEgMzIwIDAgUi9WaWV3ZXJQcmVmZXJlbmNlcyAzMjEgMCBSPj4NCmVuZG9iag0KMiAw IG9iag0KPDwvVHlwZS9QYWdlcy9Db3VudCAyL0tpZHNbIDMgMCBSIDMwIDAgUl0gPj4NCmVuZG9i ag0KMyAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9FeHRHU3Rh dGU8PC9HUzUgNSAwIFIvR1MxMSAxMSAwIFI+Pi9Gb250PDwvRjEgNiAwIFIvRjIgMTIgMCBSL0Yz IDE4IDAgUi9GNCAyMiAwIFIvRjUgMjQgMCBSPj4vWE9iamVjdDw8L0ltYWdlMTQgMTQgMCBSL0lt YWdlMTYgMTYgMCBSL0ltYWdlMjAgMjAgMCBSL0ltYWdlMjYgMjYgMCBSL0ltYWdlMjggMjggMCBS Pj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAw IDAgOTYwIDU0MF0gL0NvbnRlbnRzIDQgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFy ZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAwPj4NCmVuZG9iag0KNCAw IG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMTU2Mj4+DQpzdHJlYW0NCnic3X3b kl23keU7I/QP+7HYYR1t3IEehSJ0sbs9Ez2XtmLGbkU/SDQlalxFqil6PP77ybVWAvsUzyHLpPgy frBMrAISuXFJ5A04n3z+8tWP33/75NX2xb98uf3HR4/2bT/t+x5i3Ns26r6VvG8vn3706H/9w/b8 o0ef/NPvyvbDzx89CtsPq/Jew57Kvdrf/8NHj/7HR4+2XxvV7ZP/vn366Sf/8uVvv9r2zz7bvvhK PbFpyGkv236lqy++tu5+E7YUT3vevv4efVqHW9jiqKdRtmz/V8L29R0ZMfzlD2QwBHIo7F//6aNH 33xqHeU91N/sIfz6s5A/3cOX9bOQ7P/3uIdWDf+cf8Of+peffZzap/ZJX3xWqgEDjKbPQtC/Q9g/ +zh+ivpqCxr9yz2Ur6z81Z7ql59FEAr7gY/P9f/9iz18UdiPdffv29f/+aNHv/76+mAFH6z91PaK /3b7z7B/4kPjKKdet5THKdbt7gCq/V/aUthP1f6v8c8pdv5NpScfPUq5nfax/lzDeVMv5VXZAZuJ am28abhHOazK3rGAyZSa3ufZKj/TSomnWLa/YEmEnu0bU4z231I1fX83n/q7K3Mc33VDxC2U06j3 NkQK6VSydZZOvfmG4Pa00cMWzT1uXz/55ubz3z1++4pLH4SbtJ+sw6vcfHPz8QMs5A/DQjm1NwzI Nzd/eICF4izkYRzEs3U3AS2esudTWwurxMS/rXVXcsCynn8u9bypl9bqmIAWz2wa7lFe6252LGAy pab3eT622KO/l4+5tonqh1gzZW+n3D/AJmofhJtow1LfdxP1D8PCONU3DMg3N79/gIXhLNTe7wvv CWjxtD2dCe8Ww33h3fJ+JrxbyedNvbRWxwS0eGbTcI/yWnezYwGTKTW9z/PZJvp7+Zhrmyi8s252 bdGYpnIa7QPsohA+CDu2jSB83m8bhQ9yOjfbR+ENQ/LNzb89xMPZmbz0JI7mNza3p1a2f7detj9u j4yzU6GWYjLTegnot29xj6eUtlvO+tUezo/c65RLPIV8RroZTZOVvZwwn28hXf5W5rlKyz0dr54y dg+V37d0UR/i/v7WMtK9G9G4FVPu6lsH5kySf+zzP4at7reaSBh2U8Yw9zZqVDEzVJF+StsT6/2T 3959+8NTG86vXmxXe+2H2t+S/bdT72+u95eSQC/YlDR+zQRqO9W2ldSM74G/lVDxmV56ghO/sqaA 3PfZiP8UQVRDyca9y8RCi1jOCaqEsxud+d+cC7W7z+QhQAMWwP+/n3BVbI73kBH9noDIw1amodl4 C1dkZvgbRWZ8Hwl+n5US+qnW66w8LC/j+8jsfqH3GPQGBr54iIF4uWNty5YHdmzKGP+5Y0spp3q5 YeubNmx8Z6spXXx1SjQa7b+9X3z1l3/++fG4efW437y4e/pye2KFF8+fPv443myPP643L77fHjpE Yr4Yl5ytJzBnnU0+b/XPc6fO7WpQo4nkjZX0LZfWOuRT7aYAxA26o8lgqkjDgWZVbh0omx0mrUYB 1QE0ueVWq6b6e6tBKiN5uTceBwQyGvXWBOyT7FhE8mnAX3Qau3gxq9ykKYCkNlZu5+WGBglfXBdQ UGEBpq4F9DJbZGcDXcxu+6SSg47L/RRZ7mQV5TDuAeHEctCIsMxug04oUkjkw6bt1vvIBHL0fnEq kwqWObvNp0o+YneyF4B9DZvYET8BdZxKWk3g3LAmDkSvEfe+Oq5OJu9VPRtf7KhEpztUCl462WcA 6LMsmmXyZe05L2YvCqheIx+9ht2p1Kxeg4lslLudrrcqpyEgTQCagAFlASLbS51AZsc9OLD7ONd8 dJydzEga6NCwjFKwHaEPBFAFzLLtFZYXMMhrGGnVIM3Qi4DsHY+8+u3yd9lccFPQDoAxfSpD/Row uNLK0MIKXKiY8YNMjKeORs2XSeSmgJ9VOwkAbA1ba2LFGohqCweRyi80rc6nHFs1Aqh5qBX2KshU jaS1INUY2iRCkmjThlgBQKpdu4lAEaCVAUlpgM2sT7L9E4NiSm4cs8ngoMwpxHxzMvqxdkzk1wwy EIPsuZx20vWFgHJiuWhQTC0oOBZsVMIEMOnpFCZrBXvUOCnNaWTICgB7Wh13uepsDrM6tr0WAOTs ZGxrDQJJayWbBgnV2AyLMAEY5rZ2+5hNSuTXVB+2zmGzUVpSqWXT2a1SsSWnGcvyGpoS7zMEIAoQ K7nYGZjK0bFZGI2cjD5bYOkYr8NJREw3D9S1VOwsj9aqYnTYrw0cfK9msop9AEGA5tRU9QD301qB BmQ2CTJlmp3OEDB2UjfnpPrHxLqWV4GABZmk7VICxZRtvaqOATQB6ti0PUhuO/qjZt20QPsQkHDx ZzXEme9s68OmyTjL6eg30Zax86xocRWKGQAjTrLY/p3nPQEbNPvG6iUb8iHA+aq077HFnEDj9+Ow WzVSBVB8DM3qifxYnakoBw7G2SYuXNP0LRQxasNKIPp8ngH6/opDarMVGHzgARQBeQK2oOH1y6uG SQajkaRQACiFRMuYvcBGsp3Q5tcNlsMxmWZH2bdj6RfJikqL0hacqXgiewDeD0fZgLF7jYxBMmDf 02wC4yHMwwy92EAbay2vUbJWNvm21JOL+8rAU7YBdf7PAO+5OSD+UTYJh93SVgsbYQOiH/C1YJNg j6axOrZh2WzPhShRUbGiAETvpUOIoZwFtIBYGbaCLwIDwIdtEz/wqo0pGUu+xSu9QwbEtD648RRB 8MNPiBbJfju5LES5suzrs2Xr0oywtWBbgasANXwhtQQhZqxVX0hGw77UgBDr6rgQ6xQ47LiZnNyw j11UAGgC0gQGa2QfyGZbwEyqU/UZtQq2UiFR2mKts5N9LKncupzgRksdd5O5ZoysgewcEpMX1Sew QUVCixCXhO0RwsL29u7s94wjomAZaLQ7BCrEQxRz1gIV4vmhaHUqrBCuyTsBdlYYMJW07n73U8oa 3N5ht5gS5nK604qjG17cmoadoO7baggTsE1SsA4O9qkr2N7LQdIA7ncDjLg2Q5M/HoAfTYPDNNYR aGVbKFZhKpgDqghozuPalH/TD4y10tfoj4itXWAyaKGbUm0am+3FuU8BxM3kxjx4BreW1Ugu/0ah 63OfdFGjoTz1qQEtA6y57vdMjUxGGZWhkZb6b2KjuSAaWEwV6o+XK/RSaxDq2qVWx04viJbIY6ab 8m5lnFUcA5RRwaYr+aDwyK84bSeVTgvAGrUUJ5EhQJocgS4gCaAya/vX5ew5UARkuYNtm9YJ2HlT sSPCBEzdNSBLkpmWhfma1SO+3s6ilBabVJMgRXoRn4VO5jH39RnQnSTPX4im4nzy7G6wQlSuHI4+ xTRJtI3Sb3bbceq0QKLsli4TkyFlMm5AEKCPDxAJm4mdqrXZA6bFKvRUZwv7BqPZ+uLLVojxNcLc E2iEfjLHFB0HyIQNgqp6Pwfg/SSs8GbzP8RawLmAGtnnxWrYUWxEq4xK9GJ6CERkX58c0CfI9JLV c8HR1CC3vNUBeM90mUKWFa/R4Lc1IEhbQQ1rYRNSwmRNrC7NGG3sg6FQdnXbsUT6Uv4JVAK7Vmbg uW0S0q23Hnfskg61O80amD6zZXqZjNmgNwz4FP5s1TfIUHkFuxkzIGNnZBMZAJWAj70ZJkbXpGyW CgDA6FqNFsds0ki0tDB5s0kGswKeeasEb3bITT3zsIKYjf5FdAYCCN5zhubUkR/QXgdmuaOYfKdF qs69TtECwLZ6r1PvRwv7CnBRVqdogi269p+1AmcQyT5IBTqAAanFSddGHYAPvtldtp87LNiygEJA UrxHY3MzSZ2bl7GkUKHXNivg880oj4tmDvi8lhYQCZQ9Ll4bDlo7EjBd5HVA3I5lphBoBPKYgO2i kaZe3BN3sQHBdy1N2W1gnhezDczXtYJpRG8m/+F8QL+wu41InU4cAmUb1LK9bIvCpP+eNFs0Yzcl GKmM2m4WoboJMDig1imAFtZ2YF3rY2HVGgBzr0+ajeXZB22nsGPcBdDVMrBL6qxR2GRPC8CH2HTV JScSI1zBjockOQH7LRvAkOCtA0lAnIApCgDm9/NDAbjgMCCpiQsOmI2ZzPZjnCu0zbBDhtypXMFJ PYU2qdQswMk2TF6wE6H6GNhhxXKcfy+gwOwNpzDURW6rW1t1BnXYqnde7gR8i58BsxMTqyEE15vP gbyAIsCbDJKA82eVG8t90RQTaX0Ih7RDT5mM8kgKARbjncrsNrmH8hKAjWTlPOcFhokAzTcqkI+E GXUg6FOWOgUM84BIJA1uAB2M1FNaZCaQZkcV39vnwMOOjwTSYqVlEV2AHb0AypoaWFbgl4kDdwKw jkzoauRh8DSWfUVkWhJocegYNn8hkTs/gqwVPjJCkqgV9jaHwVUKABoXmw+U0mDJdBWUAisjigNa nGp6MVEqnTXtz10OEY5uUOV4Eve+TsBIJLejrKXWNAhr7ZVKwL6H612DlipLe5sj9kSru2sIcSQl Os7x2WG7PwYeQHuDb79c+Pb3AMNAMQ8TVuFKIMKUKxMZDD+MnW7LWLkdIjyO/SzwEfc3Bj7qilRe iwSkAMEFG1Bmc7Jx7DD4NJgo2iKGi0mKRTKloNJEzMv2Tji/WQmqBInQwZShuFeROYAmILvt3XTe AbAeMPFhNbFRxZqR8ohezJgzYCwnTooUo1hKzXsuEEKH6UygCvAv6tiuWOPDgQZ5gVUkeYcmARVy WiR2+gVcNWTHVJawMXTEpxTcNRCcSuJGIJAnMOjGGGHVgGdgnydUklMU8kQnOJMZg1wh8wxDwsig 56YodJMSfUgZnmDv6AA0lEq0y7Dy4gTgZVzaRoKbkh4kn2W4QzvKde34hINi0CGklWKrP9NjtEf/ HhilApzKgNYNj1GJE4DzFfKqzyYBFXYpT+jDJhctlmcyGUGkfCGIwiMMgKk8RsU9qwToVhv+fXAD 0ZUXpPgB2OlDjNKm0AQeQSz+MoEgYCm7CauGjkepKMg0pVtRgQrbvnTb4+B0GhlnLUTEkraIUAYk ENkayyIy6CiG+8d5OwDxVqhBg66UzlSUq2nLUocnsyRQLtW/psFrX5h37P0WSnlggW6OVCjVqVWo 3zPA+810gMJBPiaAaEGe/i802enkrjlNVulZHqmvjgs9+3AtdXUMxdXqNJ1rKMt13nzoi2eVTAMB gMIHeTKiFF87gqX6oJNGf/zynKcyGGKQU/tOWcKFVFwJJZAFiGyNHhyosqUBmLCBXikjCU0SQx0+ suilMuIQV0QvwRUhdrtkAYAqQJ98rwaB6oELX21XgcaOjxaFwakxnHnlLsOROvsoDBCVVWwKaxyM NiZMm1oeJTpq53aL02wkUAWITKOaAr1ZVgYA5IlauzFbxMBAVXRGG+MT0HXWmmh02CIOpeQek9ZK Nz2N4f3IhQ9AZGB4Kz5UZtkEO7OW82wR2PG+e40Akx5iN61dYPZ8IYYJvROgYFyVLnAOaMpb94FO 8S1AFTDLmWHC5EMAIAoYs5PKGGctC8gMJNYRFq+D6zXMyLAZpZRR+5pyAAjWqUCXRpq6PspZsXdf MZ0n0hEmRwfiM4Yl1LuiSdBYvdMM/ZOcaYsDSPcA2iGJUtnLmfH7LL8BWigMXl3KWydirfW1FmGF coi6Du4hKW9SWA4LAGkwuu4LvDfvJ/UlXeHaZCulvKWRGPhfkeErQMbIM9EhTcBGmYkOq4lJPR69 GvYRnJP9OJRoaPIbfWENenGYVuZkLoAOOY9x8kN3cPdFrJ4+m9hURaw377k4b7UvOTeGk0lS3/PO QA2D/2SPQL4HREw8hlI9A0jsKMhiy7JvoRq5fjaG85aWBybvNGgwDi2o5wwTmwMzROYCqJx5CPgF mNSHyiU1CUSVmuFWPQDxtre8em5OpsmzCKA44K0OgEssw7PIFJCiZQtAPZdRZhNMIezQPAHVaGtT ZrPZnIz8xtnMPLKbspPlfoFzxsc2hNlPOqgUNYoKXORAk5QeHA3LVWAIKAtgP35AAIjsBybCrTpR jbiszAyTTWQUXc2RAR2qvOI/0viL0k9uvYk6yov/mGaroDUH/xXKVTr0WVncRoYyAJS8AHZTdYKj BVYtdEoH0mQkjNVvm2R2SokMgdE2ero0ThSyaOWjjxbqZ1+rh6cVp0gRhIxjlWUtFRyI98rZ68fZ SfZO5JpgA/KepPlmnQUAxuLdNCCnsmvSE89WDKzsYQIw6QzwfsrsZ6UiZOjCaiUq0FPZaChkfAXQ 5saMHoDVKDMrC00gZ0xRc0DpDeAkrDnPaZJJ3nNikhEmSEIjay+boiIVgwA7auKfTSJ7lopJomIl xdVRczJVV17K7uWic5wAG7nGzBYEal3sluCt8nAyGYcC50RUtFFhYPQFgMgq09MGQNufJNlNHm11 UyYV31DQbglEGZy59An4agEAKjH65zQv6wAiSXa7FmwZTiIo7yUzYkZAWmc2RVU1FBJgGTRmUScA 3IHex9DfQ1/r0xREJ5GzOkFEjYDaVG3Z4rlNLG8RCU8anqp0yLIkNyiyvMzkXNukoQSkXAcUdywA OfFy272G5/0QQDezzCAVgehAcz72NSum+olIU1QiNypHAHzJtOw1qoQjAVBZZSjOuM+TnI2gv7dW Vy9l0pBTMyNqzRHwDd2YUHZW7rB0UB5tAolUyzhaNAJeLs7VCn/mNpxI9RMIwRcCzRdYjxQbeQFt eDd1UUE8Ro2UmGGGiAMeaQUgKgtIk+yyZnNvs5Uc6Lj8JWD4QTx2bzWB3ibdpcNkhBuG5I1GcmQH PMYFIFFyBHk+0ETAvpTXjHCyWmkFD5yw3HouOaBhsVH0ZTDKJHscbkjsVispVGYwOeAuIwASBA6g idNdsYVieou3kgAqe3UgyytR9rrkiQNTGqblc8AFN7UqMmNL2B2QfEHZhZ8TmcKwLO20wEeuNiWI SHagSeED4KJauieaONkSFxmmu6CV8nuReC7Aj5biess6WtDE6fZFZXijIbumwLPHk9ETBwBI8Hg5 uLQaK+CJG4neJhURqQ4ESR8AJLLKyYmmsoi02UZ+ypJ2B6L2H4Ckg36ISHOiaycVOfoiNwJpyO5q MxuNQJV24ESDEz1svUhXPlx0Qz6tUD2bJ3Z3QjKcgPz2niaAGjAtkcEJZxBKMalkmgi8QMY3Lj1H ph8ZUOkjKMwPa/RoghBybaAOJd2QZkIFXLoKi8AnHOkTjg7YBGW6Lts+JgDuYHEjd9JKSi5rLCR9 2t7FC+O/iGbgdlLgfQ8lBd8bheU/v3RhX17x2XswDt+SGa9rBLdnd4IQbH4taV5edtwQN/ncoBnI LRIQ2kQuQNCCBIAbfYj9ylILPGBbOSJeKUCqM1+g+ZRyYyJfwC1am2PE05dLBk0CMwraMnU49syA GG4YR2QwMwPC7WDEaZiZ0d2uDzyGGlKD+9kC62wFg+5Oy8f07YabKofDPW1KNbtVi0yy6TDS5Ty3 OkhdJhVmGtJttDzUSDXpHDsHAtNC0vRh81BE9spcTA1rB4Ab3FQh0KT25bhhEj0qId3E/eudCTvV HVEJWU21zNMp8WYCKoxx7is3U75iP2swEyPztfDguRVghkLN04pKChEjDyife77tQKk6tu8E1ALA c0GTgqgA3EOLtEgkDyV3mjAUWbGN2mxg4hpOurJ89GY71RVUd8+3rRRkNg13QNNhWVc2DIDEBKre loe9ssm+9BY4vysTqJKvhcxzs+5T+SHQBbhPGqmyAHwXAbB5LsunAF+36ZIFfhR3fienkZfHIEm1 h2dWWcWJqXjI76rTcz0QmjCVeMaBcvXktDWJcIcXpaul6cm2pWBtQnTHNR0TBXaTe5QZEICiffjD odqhTlOeA3zKhfl51acEBJkHOFkptAMLjJW1FArzaoriYe5lxo35PNX9hMkYSB/0ZFw0CUziO/aV zU9gnV41sQbgk9LyxQNg2XdRZbi5xOlVBYBPRLL08l2DM/iu3ZdLEYBk6cU908SYMSlrEt5bXrg7 5b7cuXaalX0mRKAJK3gUjlRszgCF4j5VRp2R3emBoMZ4IAH3PEZ4ZzD5bZZxXiH03meLTGDuj0qz t8BXObttvPWRxxq0Ro0ViageJmjV81mHL+PGVIzMmz6TCvUrg6rM2tR3yEFkt+/OC5YrjsMZbGjV E2tX9gp8qzuhHOTQ7kweR1KvT0fnpkNSr4c9OnOasLHKEvZdZ3qlsLyTj5ONyu6NuEgRBPVQUM+e TZyW6Zs6JxF7eH7SwGLBDnVlAkAT4L7IwChunleD6Uhl0LOsFo1R0uF+U+skk+ah8qbB/ANgWXLR 1OvCIG5RcJgOTMQvi4unIeUgMX1sUlFeNq5BSNSP4Qng1dfToD1MoE5AZZfig0kcyI9IqwUmFQFW 92dWD8+mFTyG0xOJzNTf7tzzyEY9L1dkYNxUo5Z1IwxazwptwOWpRPqa+3RNRqba7+5abZ6c75fC 0CIwblrrwYo0rp335O4EjKAUd1ljBvQhQHSRKdkAOLNW3hlsdRcBMmt0G6HO8s50/T6WHRamahal EMOHGNjIoyxwbw6GRXtyP2Tkax/Q6Ze/AtkQCie3Pv2blSFb95Ey0xlFdxQF3hwDkbKcmYMR3OlF CQq6dC6KW3E2mi5jHO7B3ckE5X3Ch7gz7ut3yeDdHLwZ4k7FrKwQRIaXmZNNE9oZlW5uR8LMiACy uyYV6G0zcR79iGwLayHE7pc9kvsgYveo9PQSRoU1+wwk5cT6wd3PaXeingyN+kU3Y3wyjC/xkdrh ZmQKMsgoppeTYo14BcB7oV/nHNCctmWiJ95iQ9x6AnTtIBVGxw97Yc8hrjULjUVklJAJf6Zu7jj/ KPf75cHHAvr0q3ZORj1v0M7LZfK1rvXBVTmJaNcqOQmAD3OOk+r0zo4J5MPpmGYrn3MlIBFw32VG asJZmZcbAUgAZmkqIDsBkahHkzQ7Xrd5Mo00kvFQBg49juJ0kQ5G/QBoo5fdx35Mv+TOga8z3YEk 2PGi0SZrx2YpmkKEAvp0kGqhhOaey+wLxdMMAAxfomUBQ0u0TYC8Bo8mlOBrYk9Hx8WpwKhmx1Du sLt8taHMRh4uZwsCLg3cJ8pG0JfdJap8Db/Hl3XniYCYhQpFidHzcpKOpvWYZpPIRVCa+4iH1yhl LbianMxwAQ+NiMLNZxllSrfgQa9aaepCRPYJuHTzg6TqMmefCbPoRB2Pw/Fnxk+XQN+1RGHyUaBP l+XuM+rxKrSQcMsrvzEzdR6thvssOetIf/FV25AZmrjoblVfRMfhoW8rf8jDP9CIeIJ5uKdVP5w8 RgxHZ1UK0l4m0HUKaq01nor4GD8mdeGHdyTXymnDL34FPxW7FI5wct5R1uHrZ+tRoa8aXefovmp0 lTXyjemdCKIcQT/obtQDPFzXmXsBRcGPK2aIUxHwtdaZHZr3ZbXA7WknDHQUXzZQoJjLNcVS71Ji 5tGECHjRbbNZrlSDPJ6HBvpa3yZ6IQUfW5ePGnoc9TaXyYO3S5CY5Et8MBOZQJuA0upmHHHQG80s yuWLzcx/8wtE6KRqPMa5LzZRF0weLoIzlprqPr+ve2re7sfqYAiQuVrrUNErG7wt585YGg3IHGzu 79Tdxul6gXM2sMWQIUpvLfvx3BK0YI5g9tiqIuhQW9dLBnDF7tTOo5TQAp0NB89y3UZe6huTC0ZP yOcioQcvEfCT53bX0ur0hN3KdRvoptuzO5Ybv7aeUQnM+oVjz59dQeIxrJ5Jg5ICWWXBPbnI86M7 bznG4d3F0oHarFEMzNmGAVbcxdpo5IwZEUKTkeRvXIMCJUxmnD4oMpCKsJgzE3lvvKyXCdAC+2Bd kn3m3l3dylMQt8B3SVvWk0EBGJ8wMqfvltsYVvzyrxW5+fHSizIu8PLZLptZyx9ACqyxPMI2zjCR 1+VF1IF7gae/e4AL79yFvDzApQrQHCWZ5nB3aOgS84t5ObjMJp3Gehh5AvAJpCn9nqlVK7wwKI88 PEZwR3i6aFFiMf/u3WCL0rGwDsGi1HtrlaVol0wTBrcBJTUBNN4ynJ/DFwtKOROreOsvuc9Fg5C5 +BGnnFQS1hQBDW2mp7JARV5AoQ+meSQgMx+7rDvYJQe/3thW9LTgmmyAP2iXP65karQV8WgNHRc+ LytGJ0OPHXwo60xDpS5Xk9wYxeaYbjE/90rhc7SHL6rQ1QCyea2EQhc2fGlKK8WLMpk+Og9lwPGD v7t8RoPBXo8XCvCIIr14QU+XFDjI6E10WWRlW01Wwb+m8NEruH/WmFQm3cK5qMO1VNosFQnomkPG VetKukQLY5n5fmvHQ0vpugao3VGZrVuXklhq45jAj6fvq0zTomNpDQoyBCPcrkkWVYFXloDLvcoz qC7LpzQaoHQbjQk0em5d3KLJoGO29To50SXJFYMrjUuy6qoZ+m3TO921egDQzzyql3VfE8t7cd8Y 58CdxSqB1ZrfHvR7gAUR2YgaOTnAazfwNq3wOyrZF9CJpbHkRTTdStQM4KJxRo3hESvTIkKRT36t UiTkDXj3fcd3RtMQd/aTC3eICwMEMszQorOfeMhg3AFmWKEp7bp0DifUJd8ynZecocZJ50aTwrBC 39cAwwOEEEfM2niDd+rbuvpWBk3nBveURmYw7oiA9LJxUaluinKTCO/3YkzVYhY9SlIG/eYNrow4 AVv+uA0uTgcvqvK6eJ1cWFuok8d0DHrsENNGp9VOc1wY2ef9NAAmqpE96ftjNOfjMJNRaei2Y3Ey tIptxP2NiCq3DBx72g51Z+4v7kOuRK6qh3Yws8pnqMpMQxalJA0AG9G+XlipOyMMuKq+ro3WnTki 8BnqDnrFIT7m5cZbAdYemZTRydCdY02Op4QqfDEBrYps4Rp4lR3aqbeCP6fqSqTKkVcC7SuWxoE6 Jil6my8Y1MB81j6vTaFsrCOOPxxg3klf/nZSodMOrkh/xcl0A4znmBfyCAQBIhOjA77HAdihggXu 7MbggPsT0YstICi+Kwe0wunDm5FR0ZnKPBBcafQ4W4287IZb7pJAaGJrBRtn+eQrU9HQakhNqczU 5K3G3dmjPjfiNBUqs/FAdxzc8JkmtCp6GKBCXcA9x6Y9gDL/7pdqqx7PGXFeziAR5i4NnJbihQ/N bMx38FYHoF2Q+NQPdlz0Go3XEE2+KcCHJmA/u6VHEhHlMA7uuXWwTaXFV/gXIy4zDp2cAHrULUz/ no7FwBe3FpnMfBxkXyhEUGlv4NZkkfiudD2jhme6oImt79HOnmip1OF517I5GT5Kg2uUOpMr9ODE G4/R6fJxijFmkt0zVeINR96FA5nChF6zZua2KLxaihrd6YIA6S49thbeM9unPK+lzJuVkjsActEF TQ2NVFH0kxYRvjyKRgpm1aI7itVvMtTCgCxuV8pnVPVmDO+BrvWBWwiBraTBVXkyAMgrC6A2kpGO AGCPBFb4oTK+xJudRXu2UsEHGRnY6Bx3EOEprxOoumIKpaX4DVS+e4tSUGWzlZ7oY7tfnkVIlbyg hJisXs9BaagylUD2rZkDkDUSzZlJugBb/QIsANy8BIDuk+aD3heWGr8tBDGDfYhy6vxryvpylY5x ePs9vvnuZ6CPa7Otc5IqDsD2jJkAJ7IfEqNTgS9ceBnsjXZaAZSgG1MBSeqThv0xjN0XJho1lqV+ oewNVpAVjbB4O8NWpMIXYAMFtlp1jkWvvhjIfCeg5ULAm6x+RbPF1Q8j+0EPnXg/WO89ur+Wn1MJ tAV4kxUsCPThGcZEECeD25g9LGZ087d1v8fLxz4FtAV4k7o6cqIrrhTosrNWvN7HjrS12rzpHHQd LbTs2x5NcBW0ZV9y/GY12VfPTnTlWoAMdgEUrjE7qgB2jzuCjAN9AVh/aHJGBbKtTk9dgLMM761W D+CiBoRSPaaRN4HRpK/V4HeNK13nTgYXnGtxvxIAzFKl39zpmtYBYM6jnjqt5WygQiGwLA6QwW1e vMtSZ0e4jl14NfX2DQCu0srf63RVnhM9ZosD8E5Waggy90KhCsleaTkECOMwO7EDOMBVPcu7WqzE CjTCEChF2KlAzhU+zTRZBbC71J2jBrP/jAruAhfOk1MxYRbymAN5CfD1q5CbR+kIDAK+wPA9fFl1 LBLeIk0+nGQ7gERgHHPDmCaoSAkBgP2Rix8zVwG86Jo8HWiOSI5r8oJa5DUiQZ2U0woosnpmq+AD mygBMnX02zcAmC8tMecEB14aa0ajXpvd5xD4qAZn7ZmomL7M/Vpnx9Ym1fV9l2UMG247zk7Aebo3 IIHAWCO2uWydnWaKUdw5DOpUt9hT8pzpc6BMADIT8bQ3lSHZ0nwGAXxiB6Tgb5bwS1WjHSOa2Edb NfZBtvZ6xiqeVE7z9i4B4z2ONZ0H4MNMZ01QXPNNAMTlujkRmB5AIBzfnwi4yMrkMsQZliaQyNgh wvQURqz+WAaBSiC02fEFAN7zPPFW2dmolAExucuB6z4RWIz3yAarnDvfnJ6rP+uB6nl2PBNVSNbI 21V3AqCgxODO2nNgTAAaUeBVv4eANQ0jEIj9NSCtj8GLCHHmKax54Ytdk1l/q6C7rgcAgiX0xay/ g9AXs03PS0xt8Axos0xOimvJLrYCrzt5mY9cVFeROWT4umM9cEBDmMYmWeV7I4HRyDuVUycwV9UB lAnwhYd1pJ0BzqpOsBDmkeydBH8YA9+CFWAtXKVguizfmeh5jU9hr/kQtHwojU+QuKAdelpidy3w rBwmQAOA2tprgIak7FLCux9YBKqAMYEqYAoJmsVQYOewDpki3f3AAKgcjzUTUknCIYf75HTlOvM8 1FMweh0CAEQxtGrnjVko63EYlKXE+0Y7yv73OM0QGYJIw6CKP/9a3Dpa5CC29jwXP9POZB61ORY0 CcsUW2XX8zV1HpCFWTsAlgGFY5ymSvZrVQBaOHtLBwBUcZl7BPR6yR6nUlQkqve4mmTNZJjqb+Hr YAD2OolikcESnd87ZCCWPgHZmMcSK2Var3I5hSLDYt/nVAJQ2aliMsaYu7ZwssaYIU8qTyj7w5hB F/LHeowKBO3L+EC2DzI9lWck/Uv3UzqGtPvLSd1HdPBhqUbH5a0APL6ELAXvhu/woMZKhAp6PCko wkhdWr8MgPf7liIGw1GZZK4OYEkMTgxLbI8HZJRnTmpMMA/+6g58Q1EaRVZJ+kVQZeatBz5kS4PN dwgzLggUt8bo1UCL6ADPedhro/FExjYdlMso0XSjqHhy71N5WtP/GnTX+P4wvCUzfrz1ZyhiY6gq Bt6duTsAXpHZYmFILSbdkqEq5AXrMgYe5g4EeWG95SyJMD5GQBi6C66moeeDsBdAWN3Ov4ql2fIe x2c/6vP38SnXfpsi/fIfhIiBceS445LhL/htivTLfxoiJt7jvMrKw79Nkd7nt3xeY0DWwhsY+Pwh Bn75z0QMvvC9DQY9Xu8/PNT/O/+yni36/eK3NzsFMxODL3+p4r++2B73m399HMLNf3sc0s3/fIin 8q48lSs/sIRMUjxvUehzulyjOyISWKU/xZ8eYuidf0ruGkNlMIiHCx+2wX8ZQ+/8a3JYNXxO4t60 6T5RjLx4ebF0nzxON08e55sf7X9/fPrcSq8eh3Lz7a39a3v8sc3ksx//97dPHpebP20PMfzOvz13 scwns9B2Lnh98f2GXJfT44/TjR1vn8T8EEPv/AM9Fwwh7xNp5FCGLn4Hb3uOX2J58fLORivfYMT+ akPWbr59/hw8vvjz8ydPf8a/Hhq5/M7S+k2Mwr65lA8YNaP7Saj/6UFW3llav4EVvHhy+TM+z761 Ack32/MXzx9i5J2l9iUjg/bQdU4e/DXSD/DbPjvv31/v/+7H59hztnZszRRIzh2Ss9x8/uAU5UM/ M3Mefc2fBTYhGDPf0rvz2194ZGe4Jsl7aYOAXN4RP2FjLTzWzltpTS8itfn4jbzXfnvxVnfZ8LJY 2Ff86ZoSmad8T3LpplA8kpCbAiONLtXbj3hLHgq17uTf6r4Zf+1khqueeYqp6bAtemgE6aGwNet8 yZJ3/OGC7qf2Vs7W24UbUkvxeKH1wh9YQw4BUp7jSQ8vI3SFXygVcHsGBAdWk3AWAau7KhV34VY+ 3U0y+wqkASjjtB4UucrqOx8BOrhrfu2XGYdysPmgyesL0VZexMrLD57ZeQr4ql9Wwx3R4ClKCum1 7F68ootwiEV4vH8wcozrqushByRD8TfeqieW4pfX8Bhp22diogcYmb3ytoEal5d5EzIs3v7rXzLV OEhFP8JTgmI1tIvPXsJ840+Alf2i59pwxeitb3AGprSd91z8HdaLnvsbe/7lkho3PeEqaEwiunps 6KDdTFL9gT859pCuW3652EYiFGwoXlt7gKl/o/B86BdpS7oqMVPTS3VwytcpmvhLP8FvrBEokmF+ C7HzEch8FjuC/EKjGfdBWro3monrTEFJ527+a6u4vLOeflXj4/t0ughfLrWWswG08dseV05seXhi 31lhv5jYysRG3FO4PA5/S11qe4kTUErTTy+eU1d4ur0yJl9sr549fehkLO+sw18dQOcTQZILPn/+ 83dkToyaWvz9j/93e/aj/cO05D/Z//2Ko2o75fcPcvteCv41TmO49vuyV9RQY+veBnqAweP3SPHT SnDq4r/NDk3+3h9uT298hsxTvCpfMs3u7EYZ93rS/ME8XtGhinokm9HlivuzwWn4xat9JZcxERGX e/vbjsryAXR9JJ4H+uKvGPm/3+6+fRyqqfh/gd72HMZRuXnxuN38H5v1py+1Pm0N017601wFP5pV 8Pyhga4fQP8X88jADK8bnrZqX9yBtafbT1wRL1/R4rN/4TM6LCv839+ww+oHMA/EKQ66K5xyvGxA aYU+ffk47jc/PwXTMFRfYZ+RZ9NWjGljeK3rL7/8+SHe59FkczxPgMSnCHFXMeinZ/EMNpQPfAZ8 hDHwdQSvUfge4L0KkwR+DMQsV0TUXqfhVZI8uHFnMO56laoXEm1g7v/98mPeyzy5PCusX1wn0S3K 1yfjn90x8DOXB9wEL380WfwK//mPP/N3SP8Rk9Fvfvs9TuPfcyaeffvHTZLnIRuvfpgDD3OE6y3X P+IhQ6/+8oNtjmLgs21/u6UHZ8GvHqdDUrza/oKfeP3z7R/le3n+4tX23dO/xYVQ3+vou/YVSXbk xWny3e1TSQn8Gu327dyj2qh3P0Gk+PH9BDWWYMQ3/3X7zv781wc/4pefiPMjGuO6bzkSKWh+cPFh Qy3x3W/uXugjNiofPy3Zg/rf//jkoS/45T4w5mbxd2rSFV/vw78I/IeHWHyPk/KKUYnLXxX3q2i8 v87mb2wQjbM7m/V/3P7LaTM2f/cSQ0iJ/u3dPB4fWhHtPU7GS9e184q7jv1SQHz19MnTu+9sMMev tBxsf8Yd/4wPedbbOx+H+ZrTmLfWGJ+LlxonPOsUG9WkRrtqpP8/ZuRvbw0KZW5kc3RyZWFtDQpl bmRvYmoNCjUgMCBvYmoNCjw8L1R5cGUvRXh0R1N0YXRlL0JNL05vcm1hbC9jYSAxPj4NCmVuZG9i ag0KNiAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHlwZTAvQmFzZUZvbnQvQkNERUVFK0Nh bGlicmktQm9sZC9FbmNvZGluZy9JZGVudGl0eS1IL0Rlc2NlbmRhbnRGb250cyA3IDAgUi9Ub1Vu aWNvZGUgMzExIDAgUj4+DQplbmRvYmoNCjcgMCBvYmoNClsgOCAwIFJdIA0KZW5kb2JqDQo4IDAg b2JqDQo8PC9CYXNlRm9udC9CQ0RFRUUrQ2FsaWJyaS1Cb2xkL1N1YnR5cGUvQ0lERm9udFR5cGUy L1R5cGUvRm9udC9DSURUb0dJRE1hcC9JZGVudGl0eS9EVyAxMDAwL0NJRFN5c3RlbUluZm8gOSAw IFIvRm9udERlc2NyaXB0b3IgMTAgMCBSL1cgMzEzIDAgUj4+DQplbmRvYmoNCjkgMCBvYmoNCjw8 L09yZGVyaW5nKElkZW50aXR5KSAvUmVnaXN0cnkoQWRvYmUpIC9TdXBwbGVtZW50IDA+Pg0KZW5k b2JqDQoxMCAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9CQ0RFRUUrQ2Fs aWJyaS1Cb2xkL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDc1MC9EZXNjZW50IC0yNTAv Q2FwSGVpZ2h0IDc1MC9BdmdXaWR0aCA1MzYvTWF4V2lkdGggMTc4MS9Gb250V2VpZ2h0IDcwMC9Y SGVpZ2h0IDI1MC9TdGVtViA1My9Gb250QkJveFsgLTUxOSAtMjUwIDEyNjMgNzUwXSAvRm9udEZp bGUyIDMxMiAwIFI+Pg0KZW5kb2JqDQoxMSAwIG9iag0KPDwvVHlwZS9FeHRHU3RhdGUvQk0vTm9y bWFsL0NBIDE+Pg0KZW5kb2JqDQoxMiAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5 cGUvTmFtZS9GMi9CYXNlRm9udC9CQ0RGRUUrQ2FsaWJyaS1Cb2xkL0VuY29kaW5nL1dpbkFuc2lF bmNvZGluZy9Gb250RGVzY3JpcHRvciAxMyAwIFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDEyMi9X aWR0aHMgMzE0IDAgUj4+DQplbmRvYmoNCjEzIDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9y L0ZvbnROYW1lL0JDREZFRStDYWxpYnJpLUJvbGQvRmxhZ3MgMzIvSXRhbGljQW5nbGUgMC9Bc2Nl bnQgNzUwL0Rlc2NlbnQgLTI1MC9DYXBIZWlnaHQgNzUwL0F2Z1dpZHRoIDUzNi9NYXhXaWR0aCAx NzgxL0ZvbnRXZWlnaHQgNzAwL1hIZWlnaHQgMjUwL1N0ZW1WIDUzL0ZvbnRCQm94WyAtNTE5IC0y NTAgMTI2MyA3NTBdIC9Gb250RmlsZTIgMzEyIDAgUj4+DQplbmRvYmoNCjE0IDAgb2JqDQo8PC9U eXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAzNTkvSGVpZ2h0IDUvQ29sb3JTcGFjZS9E ZXZpY2VSR0IvQml0c1BlckNvbXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL1NNYXNrIDE1IDAg Ui9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDI4Pj4NCnN0cmVhbQ0KeJztwQENAAAAwqD3T20P BxQAAAAAwLkBFQkAAQ0KZW5kc3RyZWFtDQplbmRvYmoNCjE1IDAgb2JqDQo8PC9UeXBlL1hPYmpl Y3QvU3VidHlwZS9JbWFnZS9XaWR0aCAzNTkvSGVpZ2h0IDUvQ29sb3JTcGFjZS9EZXZpY2VHcmF5 L01hdHRlWyAwIDAgMF0gL0JpdHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9GaWx0 ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDQ0Pj4NCnN0cmVhbQ0KeJxTzhgFtAayDAyh/0cBrYHTaDDT A4wGM10AMJiVB7rgGgFAioEBAI29R9UNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxNiAwIG9iag0KPDwv VHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMzcyL0hlaWdodCA1L0NvbG9yU3BhY2Uv RGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9TTWFzayAxNyAw IFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyOD4+DQpzdHJlYW0NCnic7cExAQAAAMKg9U9t DQ+gAAAAAAB4NxXMAAENCmVuZHN0cmVhbQ0KZW5kb2JqDQoxNyAwIG9iag0KPDwvVHlwZS9YT2Jq ZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMzcyL0hlaWdodCA1L0NvbG9yU3BhY2UvRGV2aWNlR3Jh eS9NYXR0ZVsgMCAwIDBdIC9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvRmls dGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA0ND4+DQpzdHJlYW0NCnicU84YBXQFsgwMof9HAV2B02iY 0x2Mhjn9ATDMlQe6fBtpQIqBAQADNHk+DQplbmRzdHJlYW0NCmVuZG9iag0KMTggMCBvYmoNCjw8 L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjMvQmFzZUZvbnQvQkNER0VFK0NhbGli cmkvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDE5IDAgUi9GaXJzdENo YXIgMzIvTGFzdENoYXIgMTIyL1dpZHRocyAzMTUgMCBSPj4NCmVuZG9iag0KMTkgMCBvYmoNCjw8 L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQkNER0VFK0NhbGlicmkvRmxhZ3MgMzIvSXRh bGljQW5nbGUgMC9Bc2NlbnQgNzUwL0Rlc2NlbnQgLTI1MC9DYXBIZWlnaHQgNzUwL0F2Z1dpZHRo IDUyMS9NYXhXaWR0aCAxNzQzL0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL1N0ZW1WIDUyL0Zv bnRCQm94WyAtNTAzIC0yNTAgMTI0MCA3NTBdIC9Gb250RmlsZTIgMzE2IDAgUj4+DQplbmRvYmoN CjIwIDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAxOTEvSGVpZ2h0 IDI1Mi9Db2xvclNwYWNlL0RldmljZVJHQi9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUg ZmFsc2UvU01hc2sgMjEgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTYzPj4NCnN0cmVh bQ0KeJztwQENAAAAwqD3T20ON6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgCcDNCoAAQ0KZW5k c3RyZWFtDQplbmRvYmoNCjIxIDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9X aWR0aCAxOTEvSGVpZ2h0IDI1Mi9Db2xvclNwYWNlL0RldmljZUdyYXkvTWF0dGVbIDAgMCAwXSAv Qml0c1BlckNvbXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL0ZpbHRlci9GbGF0ZURlY29kZS9M ZW5ndGggNDIwPj4NCnN0cmVhbQ0KeJzt20GNw0AQRcFAMRRDCRQzWSiBYiiTLIXxodTSKwT/8E6j ntcrxvnWC544133pDQ981vrTG/b91n/0hn3vtdapR2w7R68vfOganc7w8O+1Lr1h3/zwDz1iW+FD he8UPlT4TuFDhe/MDv9Yhc/8wr/1hn2FDxW+U/hQ4TuFDxW+U/hQ4TuFDxW+U/hQ4TuFD80O/1P4 zDF6feFDhQ8VvlP4UOE7hQ8VvjM7/Nnr54c/eH3/x6D+jzmFD92Fz3RUDfWbwCl8qPCdwocK3yl8 qPCdwne6NII6sXMKHyp8p/ChwncKHyp8p/ChwncKHyp8p/ChwncKH+qo2uk3AVT4TuFDhe8UPlT4 TuFDs8PvGw3U/zGn8KHCdwof6uOk01E11G8Cp/ChwncKHyp8p/ChwncK3+nSCOrEzil8qPCdwocK 3yl8qPCdwocK3yl8qPCdwocK3/kP/61H7Jsd/uyj6vnhn3rEvsJ3Ch8qfKfwocJ3Ch8qfKdvNFD/ x5zChwrfKXyoo2qno2qo8J3ChwrfmR3+8Fed13lfesIjhx7wxBcy/GOwDQplbmRzdHJlYW0NCmVu ZG9iag0KMjIgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjQvQmFz ZUZvbnQvQkNESEVFK0NhbGlicmktTGlnaHQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0ZvbnRE ZXNjcmlwdG9yIDIzIDAgUi9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTExL1dpZHRocyAzMTcgMCBS Pj4NCmVuZG9iag0KMjMgMCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQkNE SEVFK0NhbGlicmktTGlnaHQvRmxhZ3MgMzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQgNzUwL0Rlc2Nl bnQgLTI1MC9DYXBIZWlnaHQgNzUwL0F2Z1dpZHRoIDUyMC9NYXhXaWR0aCAxODIwL0ZvbnRXZWln aHQgMzAwL1hIZWlnaHQgMjUwL1N0ZW1WIDUyL0ZvbnRCQm94WyAtNTExIC0yNTAgMTMwOSA3NTBd IC9Gb250RmlsZTIgMzE4IDAgUj4+DQplbmRvYmoNCjI0IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3Vi dHlwZS9UcnVlVHlwZS9OYW1lL0Y1L0Jhc2VGb250L0FyaWFsTVQvRW5jb2RpbmcvV2luQW5zaUVu Y29kaW5nL0ZvbnREZXNjcmlwdG9yIDI1IDAgUi9GaXJzdENoYXIgNTAvTGFzdENoYXIgMTEyL1dp ZHRocyAzMTkgMCBSPj4NCmVuZG9iag0KMjUgMCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0b3Iv Rm9udE5hbWUvQXJpYWxNVC9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA5MDUvRGVzY2Vu dCAtMjEwL0NhcEhlaWdodCA3MjgvQXZnV2lkdGggNDQxL01heFdpZHRoIDI2NjUvRm9udFdlaWdo dCA0MDAvWEhlaWdodCAyNTAvTGVhZGluZyAzMy9TdGVtViA0NC9Gb250QkJveFsgLTY2NSAtMjEw IDIwMDAgNzI4XSA+Pg0KZW5kb2JqDQoyNiAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUv SW1hZ2UvV2lkdGggMzkxL0hlaWdodCA0NDAvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNv bXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL1NNYXNrIDI3IDAgUi9GaWx0ZXIvRmxhdGVEZWNv ZGUvTGVuZ3RoIDE1NTU+Pg0Kc3RyZWFtDQp4nO3d0Y3CQAxAQZL+iz6UNUcJfkgzFeTryWss8XoB AADwS67H9lcAjHeR7vvWJaBDl4AUUQJqdAmo0SWgRpeAGl0CanQJqNEloEaXgBpdAlJECajRJaBG l4AaXQJqdAmo0SWgRpeAGl0Cak6Xtr8CYBiWgBpdAmp0Cai5PrY/BGCYl4AaXQJqdAmo0SWgxtIb SDEsATW6BNToElDjqBKoMS8BNboE1OgSUKNLQI0oASmGJaBGl4Aax0tAjS4BNd5xQI0uATW6BNTo EpAiSkCNLgE1ugTUOF4CasxLQI0uATW6BNToElCjS0CKKAE1ugTUOF4CanQJqPGOA2p0CajRJaBG l4AaXQJSRAmo0SWgxvESUKNLQI13HFCjS0CNLgE1ugTU6BKQIkpAjSMBoEaXgBpdAmrsl4AaXQJq dAmo0SWg5nRp+ysAhmEJqHEkANToElCjS0CN/RJQo0tAjS4BNboE1DiqBFL8GAfU6BJQo0tAjS4B NX6MA2p0CajRJaBGl4Ca+7H9FQDDj3FAjS4BNboE1Fh6AzW6BNToElCjS0CNLgEp55c4R5VAhyMB oEaXgBpdAmosvYEaXQJqdAmo0SWgRpeAFEeVQI0uATWOl4AayyWgRpeAGl0CanQJqNEloEaXgBRH AkCNo0qgxrwE1FguATW6BNToElCjS0CNLgE1ugSkOBIAahxVAjUecUCNLgE1ugTU6BJQo0tAjS4B NY4EgBRHlUCNo0qgxnIJqNEloEaXgBpdAmp0CajRJaDG8RKQ4qgSqDmPOEeVQIcuATWW3kCNLgE1 ugTU6BJQo0tAjeMlIMVRJVDjeAmo0SWgxtIbqNEloEaXgBpdAmp0CUhxvATUGJaAGl0CahxVAjXm JaBGl4AaXQJqdAmo0SUgxVElUGNYAmp0CahxVAnUmJeAGl0CanQJqNEloEaXgBRRAmp0CajRJaDG USVQY14CanQJqNEloEaXgJrTpe2vABiGJaBGl4AaXQJqHFUCNeYloEaXgBpdAmp0CajxN7tAimEJ qNEloEaXgBpdAmp0CajRJaBGl4AaXQJqRAlIMSwBNboE1OgSUKNLQI0uATW6BNToElCjS0CKKAE1 ugTU6BJQo0tAkC4BKeYloEaXgBpdAmp0CUgRJaBGl4AaXQJqdAmo0SWgRpeAGl0CanQJqNElIEWU gBpdAmp0CQjSJSDFvATU6BJQo0tAjS4BNboEpIgSUKNLQI0uAUG6BKSYl4AaXQJqdAmo0SWg5nRp +ysAhmEJqNElIEiXgBpdAlK844AaXQJqdAmo0SWg5npsfwXAMCwBNboEBOkSUKNLQIp3HFCjS0CN LgE1ugTUiBKQYlgCgnQJqNEloEaXgBT7JaBGl4AaXQJqdAlIESWgRpeAIF0CanQJSPGOA2p0CajR JaBGl4AaXQJSRAkI0iWgRpeAGl0CUuyXgBpdAmp0CajRJaBGl4AUUQKCdAmo0SWgRpeAFPsloEaX gBpdAmp0CajRJaBGlIAaXQJqdAmo0SUgxdIbqNEloEaXgBpdAmp0Cag5UdIloMOwBNToElCjS0CK pTdQo0tAjS4BNboE1Fwf2x8CMBxVAjUecUCNLgEplt5AjS4BNboE1OgSUKNLQI0oATWOKoEa8xJQ o0tAiqU3UKNLQI0uATW6BNToElAjSkCNo0qgxrwEpFguATW6BNToElCjS0CNLgE1ugTUiBJQ46gS qDEvASmWS0CNLgE1ugTU6BJQo0tAjS4BNaIE1DiqBFL+H3G6BERYLgE1ugTU6BJQo0tAjS4BNadL 218B8GVYAmp0CUhxVAnUWHoDNboE1OgSUKNLQI0uATV+iQNqDEtAikccUOOoEqgxLwE1ugTU6BJQ o0tAjS4BNaIE1OgSkOIRB9Q4qgRqzEtAjS4BNboE1OgSUKNLQI0oASmGJaBGl4AaR5VAjXkJqNEl oEaXgBpdAmp0CagRJSDFsATU6BJQ46gSqDEvATW6BNToElCjS0CNLgEpogTU6BJQo0tAjS4BNboE 1OgSUKNLQI0uATW6BKSIElCjS0CNLgE1ugTU6BJQo0gAAAC/6A/K4hNLDQplbmRzdHJlYW0NCmVu ZG9iag0KMjcgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRoIDM5MS9I ZWlnaHQgNDQwL0NvbG9yU3BhY2UvRGV2aWNlR3JheS9NYXR0ZVsgMCAwIDBdIC9CaXRzUGVyQ29t cG9uZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMzAy Pj4NCnN0cmVhbQ0KeJzt3FFtw0AQRdFAMZRAMZRlEiiFEihpakulMFfacxBYeh/t1SrzeDyOB/Oe nzX9CXxX+Nhh3PFd4fNe05+xvfPa4Tn9Gdtb1w7H9Gdszw4Jx8+1w/RnbO/e4Wf6M7Z3vP92eE1/ xvbuHdb0Z2zvygc7jLvz4Zz+jO3JuAb50GCHBBnXcO8gH6bJuAYZ1yDjGuRDw7JDgnxosEOCjGuQ cQ0yrkE+NNihQcY1yLgG+dBghwQZ1yAfGrwCNciHBjs0yLgGGdcgHxKOJR8KZFyDjGuQcQ3yoeFp hwQZ1yAfGuyQcLzkQ4GMa5BxDTKuQcY1XBnnQuI4GdcgHxrskCDjGlxIbJBxDTKuQcY1uJDYIOMa 5EODHRK8AjXIuAYZ1yDjGmRcg4xr8JusBvnQYIcEGdfgQmKDjGuQDw12aPAK1CDjGuRDgx0SZFyD fGjwCtQgHxrs0CDjGmRcg3xIcCGxQcY1yLgGGdcgHxrs0CDjGmRcg4xLkHENMq5BxjXIuAb50ODQ fYOMa5APDXZIcCGxQcY1yLgGGdcg4xrufFjTn7E9GdcgHxrskCDjGlxIbJBxDTKuQcY1uJDYIOMa 5EODHRK8AjW4kNgg4xpkXIOMa5BxDX6T1SAfGuyQIOMaZFyDjGuQDw12aPAK1CDjGuRDgx0SZFyD fGjwCtQgHxrs0CDjGmRcg3xIcCGxQcY1yLgGGdcgHxpcSGyQcQ3yocEOCTKuQcY1yLgGGdcg4xqu jHMhcZyMa5APDXZIcCGxwYXEBhnXIOMaZFyDQ/cNMq5BPjTYIcErUIOMa5BxDTKuQcY1uJDYIOMa 5EODHRJkXIMLiQ0yrkHGNci4BvnQ4LRGg3xosEOCjGuQcQ0yrkE+NNihQcY1yLgG+dBghwQZ1yAf GrwCNciHBjs0yLgGGdcgHxJcSGyQcQ0yrkHGNciHBofuG2Rcg3xosEOCC4kNMq5BxjXIuAYZ1+DQ fYOMa5APDXZIkHENLiQ2yLgGGdcg4xpcSGyQcQ3yocEOCV6BGmRcg4xrkHENMq5BxjX4TVaDfGiw Q4KMa3AhsUHGNciHBjs0eAVqkHEN8qHBDgkyrkE+NHgFapAPDXZokHENMq5BPjS4kJgg4xpkXIOM a5APDXZokHEN8qHBDgkO3TfIuAYZ1yDjGuRDg0P3DTKuQT402CHBhcQGGdcg4xpkXIOMa7jzYU1/ xvZkXIN8aLBDgoxrcCGxQcY1yLgGGdfgQmKDjGuQDw12SPAK1OBCYoOMa5BxDTKuQcY1OK3RIB8a 7JAg4xpkXIOMa5APDXZo8ArUIOMa5EODHRJkXIN8aPAK1CAfGuzQIOMaZFyDfEhwIbFBxjXIuAYZ 1yAfGlxIbJBxDfKhwQ4JMq5BxjXIuAYZ1yDjGq6McyFxnIxrkA8NdkhwIbHBhcQGGdcg4xpkXIND 9w0yrkE+NNghwStQg4xrkHENMq5BxjW4kNgg4xrkQ4MdEmRcgwuJDTKuQcY1yLgG+dDgtEaDfGiw Q4KMa5BxDTKuQT402KFBxjXIuAb50GCHBBnXIB8avAI1yIcGOzTIuAYZ1yAfElxIbJBxDTKuQcY1 yIcGh+4bZFyDfGiwQ4ILiQ0yrkHGNci4BhnX4NB9g4xrkA8NdkiQcQ0uJDbIuAYZ1yDjGlxIbJBx DfKhwQ4JXoEaZFyDjGuQcQ0yrkHGNfhNVoN8aLBDgoxrcCGxQcY1yIeGw3+tCae/0Qnn9Afw7xcu CHUoDQplbmRzdHJlYW0NCmVuZG9iag0KMjggMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBl L0ltYWdlL1dpZHRoIDQzOS9IZWlnaHQgNDQwL0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQZXJD b21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9TTWFzayAyOSAwIFIvRmlsdGVyL0ZsYXRlRGVj b2RlL0xlbmd0aCA1OTY+Pg0Kc3RyZWFtDQp4nO3OAQkAMAzAsNW/6as4g5EoyAwAAAAAwF/VdgEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4I5quwAAAAAA3PcAYHAABw0KZW5k c3RyZWFtDQplbmRvYmoNCjI5IDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9X aWR0aCA0MzkvSGVpZ2h0IDQ0MC9Db2xvclNwYWNlL0RldmljZUdyYXkvTWF0dGVbIDAgMCAwXSAv Qml0c1BlckNvbXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL0ZpbHRlci9GbGF0ZURlY29kZS9M ZW5ndGggMTA5Mj4+DQpzdHJlYW0NCnic7dFRrcJAAABBpFRKpZwUnCAFKZXS11AM3Ae5bN6Mgk32 8QB+bhz76gSmjfP0Lee6dn3bVmcw5XPtHKszmOJakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRa kWtFrhW5VuRakWtFrhW5VnRfe67OYMp97bU6gymuFblW5FqRa0WuFblW5FqRa0WuFblW5FrR7lqQ a0WuFblW5FqRa0WuFblW5FqRa0WuFblW5FqRa0WuFblW5FqRa0WuFblW5FqRa0WuFblW5FqRa0Wu FblW5FqRa0WuFblW5FqRa0WuFblW5FqRa0WuFblW5FrRfe29OoMprhW5VuRakWtFrhW5VuRakWtF rhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5 VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRa kWtFrhW5VuRakWtFrhW5VrS5FuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRa kWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VnRfO1Zn MMW1IteKXCtyrci1IteKXCtyrci1IteKXCtyrci1ou3tWo9rRa4VuVbkWpFrRa4VuVbkWpFrRa4V uVbkWpFrRa4VuVbkWpFrRa4VuVbkWpFrRa4VuVbkWpFrRa4VuVbkWpFrRa4VuVbkWpFrRa4VuVbk WpFrRa4VuVb0vbat7mDG99q+uoMZrhW5VuRakWtFrhW5VuRakWtFrhW5VuRakmtFrhW5VuRakWtF rhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5 VuRakWtFrhW5VuRakWtFrhW5VuRakWtFn2vnvjqDKa4VuVbkWpFrRa4VuVbkWpFrRa4VuVbkWpFr Ra4VuVbkWpFrRa4VuVbkWpFrRa4VuVbkWpFrRa4VuVbkWpFrRa4VuVbkWpFrRa4VuVbkWpFrRa4V uVbkWpFrRa4VuVbkWpFrRa4VuVbkWpFrRa4VuVbkWpFrRa4VuVbkWpFrRa4VuVbkWpFrRa4VuVbk WpFrRa4VuVbkWtHLtSDXilwrcq3ItSLXilwrcq3ItSLXilwrcq3ItSLXilwrcq3ItSLXilwrcq3I tSLXilwrcq3ItSLXilwrcq3ItSLXilwrcq3ItSLXilwrcq3ItSLXilwrcq3ovjZWZzDFtSLXilwr cq3ItSLXilwrcq3ItSLXilwrcq3ItaKna0HDtSDXilwrcq3ItSLXilwrcq3ItSLXilwrcq3ItSLX ilwrcq3ItSLXkrbDtaLr21jdwLxtrC6Af+EP+9f/og0KZW5kc3RyZWFtDQplbmRvYmoNCjMwIDAg b2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L0dT NSA1IDAgUi9HUzExIDExIDAgUj4+L0ZvbnQ8PC9GMSA2IDAgUi9GMiAxMiAwIFIvRjMgMTggMCBS L0Y0IDIyIDAgUi9GNSAyNCAwIFI+Pi9YT2JqZWN0PDwvSW1hZ2UxNCAxNCAwIFIvSW1hZ2UxNiAx NiAwIFIvSW1hZ2UzMiAzMiAwIFIvSW1hZ2UzNCAzNCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9J bWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA5NjAgNTQwXSAvQ29udGVudHMg MzEgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9U YWJzL1MvU3RydWN0UGFyZW50cyAxPj4NCmVuZG9iag0KMzEgMCBvYmoNCjw8L0ZpbHRlci9GbGF0 ZURlY29kZS9MZW5ndGggMTIzNTk+Pg0Kc3RyZWFtDQp4nN19WY+lN3LluwD9h/uYZYyuuC8YQYBa 3TY8GM/ibvS4W/ZDuVRSCa5FLknosX/9xDknyO9m5q1K1fIy/aBS8lwyGNyCEcEgv8+/ev3zD989 fvLz6Tf/8PXp3z/9JJzCOYQQUwr9NFs41RJOr59++sn/+ZvTy08/+fzvfl9P3//06Sfx9P3OHFoM ud7K/d3ffPrJ//70k9PvjOrp8/91+uKLz//h67//7Sl8+eXpN79VTSwaSw71FK5U9Zs/WHV/G0+p nP7wHSq02k6WzPE846mGcQ7j9IcX5MLw19+TuxjJnrB//LtPP/nmixDy70KM9t/86svPUvzCmP3N lzV/YQBYyCH2Zv/9FhmQ/hI/pfFlbF8IHl9/OezPGr6cX4ASM3jeoT9j/erLwh+Jfla/YLEYnMRv KquPSQT+5fSH//bpJ7/7w/Veiu/aS+luL5URznVc76WLvrn57NHbOUkfgZN+ng8z8urHR/Xm5x8e 5ZsXP/zno9hunr4+PcBb/mDe6hjnlB5m7vnTx//2EDflg7lpuZ5DeZibn548ffRZuXn5+PUPrx5g qjpT4dxDw7/D/pn2J2imWc+jnXKZ59ROLw6g2f/yKcdwbva/zp9zGvxNqSeffpJLP4e5f27xsqin ys7sQE7nZmW8aLxFOe7MXrGAxZSK3ubZMj+TrEnnVE9/QdfHUayN2YbVVkBTn/3VNPX3V8a4vfvE i/U82625l2M+12KV5fPoPvc47az3IOTLSKc/PPnm5qvfPzDj+kfhJoezVXiVm4dl1vg4LNRzf0OH fHPzpwdYmM5CmcZBuph3C9DkqaGc+55YNWX+tuddLRHTev1c22VRT+3ZsQBNnlU03qK8592qWMBi SkVv83wssU/+WhpzbRHFd1ZMrk2aGvq5jI+wiuJ7aABX2EnWMe19l1F8j73/Gg/z3N7QJd/c/NND PKw9vo1xW4AvQBOoh3whwHuKtwV4L+FCgPdaLot6as+QBWgCraLxFuU991bFAhZTKnqb54uF9NfS mKsL6T30oPuzxrSV8+wfYyHVj8KOLSQIoPdcSB9lh+62kOIbuuSbmz8/xMPFvrx1JfbmNza2515P /2K1nL49fWKcnSs1FZObVktEveOUQjrnfHrOUb9aw+W2e51yTedYLkhzTuXT7IDfQnn+Wt5JsF4s rGwz2nTeYop1exvzKTzE/O2VZaQn7NB8arZRlfg20hei/DMf/jltcr/Vzkavmz6GobdOo5ZZoI2M cz49sdo///sXj79/at3221enq7WmQ/Pv2f4dVP27q/61ZtCLNiKdrVlA6+fWTzV3mzETv9Vo3ZBW 6gk2/cacAszOXIX4pwgiG1K5YzhWiVQvCSqF7RuV+W/OhcrdZvKQnxET4P/fJlyTmuk9bFlblLfs 7Dlh8cdivMUrIjP+SomZ3keA32al2gZiK/wqK7/C5fA+InvcU3xs9byBga8fYqDdX7G2ZOsDKzYX +BLWiq21ntv9BdveuGDf2XDKd1sdRztXQ6NNtny/1b/89Gje/Pxo3Lx68fTRZ/nm9enJoxhvXr20 VLo5Pfqs3bz67vSQZZPe2bq6x2fNtrnbMGNlvJVLcDjvMvjQTpfmvdFLY85E3iC3nc3n+vPSgfl8 l2i5UV7e+k2Nuu9hgEBtI9kSM2XpHFPW3lbgpjTlyeYASgNoMGLO2ZQXApHauc2W2gE8A2Zq3ABm aprvkMYICsWqQuNczZ6x+ssUYPMM1pBVXDaVSds1noNRBpmZzjWyVBQzAJSeK90KgDTKAjJ8EJaj LcC2XgDV2Z+0daBRxlXxNAWS9YQcVXFDxVYqdZUyAJ4OWxZBDbIimXR9hyYZmlHAorrBANuLrdQs zs0BsO96sLYMAKlvIGZbVlbRWEUq0rPPlbYhhDKiBj1DoUhmDOMgQiE2QWaFmrglEAU0AdQMWU1a AIo005aiAFuOHUDLTsPGCiVsZu16K3kBVlXxgE4EKjWrUNeaySOuauZEhjDLpmKaWgQWE4e9mySw hnClsc09msZvEv5cehGVgelmGeLRB5ElkqZxh1+IFYehfgUwBDjNCj0IEre3BXT46a3gXEVyQw4T TQISZjWUaq0NVkuhUCxnUsUD6Xyeyakaqw4MARPKowHeFkvbDEpGus5VAm60ZHPESzQCxs2oq9pk qpGYLWowCFaW8p7HbwaYttcdCJjklqO23WmwtBMrb01kOsxeA1JSvyVOv2hNFrvoMAJ95E3FOG4o ZAaOqExWZaPWNXcAKK1esTWuDLWudDGqEEx5FbCGoZXqFKsCS8tEQ9vzBhYeoMzF1uGGjigyffyw JKL/RabtJwkbAKb9WtfP7ADV5ASFw4skyHkDStjttA2gEutDEzVPiglbw97HBkCnsn+HA6aAId1n W1TMmLVpbYVSVm+ZaVRYaCgTAOMdM0l1o4jIprJnQLHl0Eh6aOaZtWDbBaaTzBICUYDT7ejUCAEY F6CKimYWigyoJWdNEVSiDF3jwIqHU8m2hFFxtcFjxVHcWjpj97S0M2JiswDIc+0Y3VRLdkzoUUTq mVmG5ALSKNN3p9TkRELfA1IbBh+lsuSP7Rtg1ieA/Tz1s5IYFv6ed7qiipW27EyPEBfgPOTNdwuL SBDjLWH9ostcTgJItwDKEQLxEugHkLAcCHiRsFgLW9i2ssjIkuutYtEcg9Womlyk+ypQdrqzlrLz s5KVvyy20p6sbfgEaFWzrEeY82h/EqvXAA2UraENDPVzXkBi2kugEjF2iPO+hrt3DW2HHOZgVid7 D6g+72Y6AFY8U95F2MLhQhK1iLW+m9zbItMlWHpnRTAO1HH3AegbXAGjbYCzJLr8QhH2UvB9AbWI t7FHeNioc5X7XjLyOU0A1efJyE7WdFEBwRdAapt/U9hsq8GyT06mufQYLtsAUHSMIO5Gh3YDceg7 3dBUsT6Q4oUihcCQQodalONisuBYkmI2JI3ZtIGmFM9iD0Dmsl8C04qIlZD30ENlSxS9ko+W7kxX LUMCUYCTNU2AInVIXQOQKZKGSzorMlhx9X1sJuekjM2/KXlRm0yQfDfbNHKzK05lYkDAmVfTMO7c NRaR4QqcbW1cpcNUL+66QR2HdCJNnwkokAZb09MmUqBJW6nYnEqFoW9A0ZARaAKGgI5T2ASFuC4g cY9tbZUYZKxoeaASm78J63fsiunkMioYZ1QcbdMcVD6cXdPFIhUNCXeUQN/H89YHkMWEtpUpU9yb 4hRJpEoCEOgCogCaHaZchOLVVPZAXvo1imTWW6UWkQYVpxp3xZXKlrVLevzA/OwAehW3UaoKgLyA QTWwS1EcnIuo2Dpw52BrusZnmD4WyPyhBg6uLpCZUg0GFTrom9XpUjVDjuZ0OW3Y5LB2l4FaqMf2 RUbd0KhhP3dgCFCLoKE3AGsi2J9WGNqz9y3UYteF1bfQRtnmcVFzpxpqxJK6LkMZg26ftD0A6Kw5 DWeFviKj28rSyYYpcpXmS5F3a2SqKaa+Re9wA6BhQh5qJmfak0a37r1uQD/LNLdGEZlODQ56v5c6 ADU7U8mA8aUlD6DStIpxleiseEYNQNYSMl7jUTElOe1HCp9R1A2QpuL/AlC/FIorGI9lA4U5gk8Y K0JGfHtDJeI9l93/pvPZMqIlq44rWBy0dReVA1CDStOpCNa9pzONYdeQUKLTHnUdFgC6Fa07Kja5 Qfs+TU05uIo7gDG9lIIAAKQFzEJrX11fAyQNbHmJQWQQq270oJIsQz7vrrZSy9MgUVNhQABocixc AqJbM09M83I9jFqwFOGLmG0VyWSlSY8cleoJ3RdHzVj+IFNcTFRqSjYzozf5AogLgLuiLIcAgInj 2uXhYA4STS7jTIO1bocd0Y+aOSeNTNUWP0wHRbSFyUtnd6dFpNEwwnLQGgPA833bt7QQTFWMLOJi BHXY+jdG3PhHvQ3atkIDUGuj2QfbZDjVgh2VgJpnuqHtDRmyJS7ABgEkYl4Amle3TLc6cM6zBCmr beStLVUKwMQZoBEXswCGAOdk6vzdeqAuIOP83WCvR3PJJvuiUJkMx9SyMiZrIRGCVjFU0AZguEzs 9JgA8BlqmiD6dWsmo2cIDstRfFlbEfQRLBJx1qGu5b7W4zMVMpFiVHr2iiv0Jph83rEXgNINS7Is QxdphJDMs0wl5B+kWKtnKFwU0MT2httpxyHcQLYggEIgr+Z12AYEvHm0VEvaUx5AE8C0qZaB6SoV EIDZrQWW+y7Rp2otqxIcOgRXl5C2PoXxuj0OoDJZ75TjwhQ06EMmmYJ8BQSKAHXZyOQk70VyAcQF 2E9mrLqOYsppxO+5zfV7JRDaWHXYX2jsqoNuhALH097TB73xpXDKvxAwCIxFpkB5IOCc2WTsOLdb 2gSAJsAroiFgojr6LjQoNwrW285hC9eIzuCtMWWWrfUNc9CHhgPVdHTrwKwwsk1nlEO6eOGJz3NP M0N3eTUZwmWmeZC1PEw3t3aapE6u2cGJW8DZ8LkKJ25mY9LuJCuFWWGbm+xhAOjrsacJAGUQ2UlP Y4VDOi2g4qzKNgfPkZCjwFfqOZTKW8medNcYjR7V3EmBDemvXp2d0bZx2Qy2ZjErrZJxKLtzYCys 0NQ+ME0Vt2Vj24MbFgSKgJW2KVfL2pFmgClr25JUIiRNKGKbcuVgsg9xghyXjoRMNtS1Un9ktRn7 Z+Xcee5pJjWrkLbNyzYYN5Kmae6FOVKelzlwlDcE0K9vjJaSd72FzMP+T6q3IsQVfgmvh+ozgORk GxT5CiPJ29/hVq1j+SWQo5LmKJtGImujzF0xvd7YqILOoM1msFINw+elDFCayQgd5mRb3ZwbYDpF 73Y6m7BZ5rwI2EDDo7OPE1DIhoXuGK7faXaJ7QcNxo2oRlaTlh48IzSLU8NwjwXYomv2ryQJihiP DXKiL8BGEcGT2xhAKZuxtkHG3lUxHREN3irxHxkn1nAG4mSgEqBmt++eqU1W3jLlWkSmQbE0Mq1s fgcbLbOd7EYAOBtACrNERjzbxrHEkeoTZE4YfetInAtGevtByrYDpAbzNpv3T9SAxKABX7MAbB1B KYhjDQDCCuBC2kBji3DihFRhx9oM4GDxp240nvjoRVALNi18MlizrStud4Ifpr8hrjrs2IFrR105 8nik0LOBGAu4CyAQNWGQLBRuWXMyRwnmtlSvZ8gUYZ9BJLYsIgmtNMDdCJdAF1AoD62xsssBRO5v I+4iJk9LWVs8asnaAbbfMevcEf7Y7jVLkShrcyXQBHiLBgatwInkQIdmaJtc1r6JItwWS94kbDIA 2H7mjDiapg1bsSkwFaQ5OBUA0hy8YoSYdCgGM+4cjYrA1DLKNA2oOkgdYYRx5P675z8iuGz5W6Yq F2CG+k2FIwyv6ADUlVJxYaLJVAFQqE65VyRnaA3I4aNslZhGXrAZ5l0xD1wM03lUNh3PiCAILXl7 OjeTsByAOcvg2aeMAKxl0EDnWEUiMrhthjpscPOlwMrSCpGpUF0G0DqoTGmHBKjHTm+fjgoyfDB9 AbCIOk8XvIj9lTH56wKigH0mkTFrqHTLZYjwbyrh2sKzLYKJmHEbYachJRQO8z1DbYuPiOizOVZE ZNJ2aWsPvgTEW8V5DulK98lVAdSQnHEVYbo2bw3OEy3tuhHqrckNEcw21GvbLwxYE65SsS4Br7fQ Pqhr/wTQZd7J7kIRWMW2Y5a8WKXhNrd+mCsPXHDslIYq7uhFI6X9FOk0Bajbqsd52eyZC2huic5V JNDC7VIwUAmsjnLexlyuPEFk3IY6uvEczQq5L4RAESCyjeIdNqGcgQBM2MC0lkBHkcxTfe9Z1IKg yrz0UtTc8jKc5aQg0ASoybdyEGgcnbxm21WAJvw8SlRGAfg5HmNEFXAQVx2VwQZ1J0mghoPRzlsM to3JE511xJDT0jgINAEiY9YchgLCsS9AcQ99rhLycvTkjHbGNMDzueeEGYmNRn/ySL6eFQN+ntPr ybSsAYiMGXTyrixGcM594lWCskpEVhyC56DODbG7NeJsdmIl1mQCAhjkrsk/egloyPvwjs7pLUAT sNKFHiZ3BhNQWIc0RlTS6MZqdQO2bwDY4RYIAa5yOcnPngdPiPI+uiUAr40Syb1JPrstbZUmOPfb yp3YY8HnrlUgPtO2kTNsQLLau1da3F3WZAETyLeA5uEnZax0oXPQj0tRItGf1lzKj+ysubnHirvH rAxt3DN4AEqU1glAMSvRJ/joXk/erpQ84wpb0fBOavzoBNci7gPF3ZDdZZoBijXpbRfpDCUZLo5m dE7CsSnN6mTWxFLcKwM9ncw9YPA0fy41AoANJ87wvScnQkYA1OI1V+et7RiHPKeTgUqJextmfVUC 7nAgUG4BOrW3rlTNALLcz1KZUaSQleT62ZzO2+HGKWH5Sf10uuA8JqpjpsjcAxpHHgJ+A5kRNkNq EoiaHsYgnQ2It9DLrrk7GRy4vxBQHfBSB8ApViL9LehLTVsAqrnOuooUOrr76qbuOfpelCXGRSap ZjNJipzUTpbrBSFD3rcxrnryQaWqUBrquEjNPm0vw3VgCqgbYD2+QQBQrFKU0YlKlCPtM6fCeAT1 rthPigSDyiv+EyPBk/ST515EFZXNPw66VEr+/4LjDQZOSYe+SIvbxHNcALVsQAcp2sFRArMWOqUD eTES5663LzIK4Sr08/NwQiuEAAO0vPdRQvWEPXu4W3GIprjHtsq0pgo2xFvp4vnTqqR4JTqZZwHy nqX5Fu0FAObm3TQgpyIXUMncW9GxdaiUBt12fl8cua56dnRNyXOVEhXoqSw05Ri8AmhxtxVmRCDi RMrjjFAEcsYUNQf8fKetOB9UXPIik73m7EdqQwpkKVrLpqhIxSDAirr4Z5HEmqVikqhY2QfbReE2 OrBDPTV42t1NBFjINeaicxPMuR10V2r0Un66WuoO3VPnVi1UGBhjAwzCW+nMIDwDtPxJktWUHaBT FIDD2awFBe2WgB8IljoW4LMFgILwvDnd09qASJLV7glbp5OIQxO28f532hZBaclz6KyJaZ1lKqkd wAwGl1KgyPQOWCoItxGJUlSJTlmpiJKIlmw9+xpHmme5kgvI33SAmjcgJraZXFpfNOTjKm0ySAFK l8YSxwXMMZx3nh/wFNbbwitnAJID3fnYx7SlRyfSdb5aOpUjAD5levEcTcKRAM+dVxqKMw68s7MR 9fsRAlMUSQMaivop8ORPnWarTOeZ7ZEefsRcZ19AVnTlPErwJH6VqM5V3QKgTyfSfAcyRU+ABwoB gNgoG8ChhchsKgqaQSEFEZsh4oAH/QAQlQ3kRXZbs7j+76VGXZdGBXjADgCVWsDoi+7WYQoiYHR+ L0d1mcWB6KM+JXJtxsrzgSICwlZey6yrlGbwHIwZacsCAKBCyaeBImC4MLbkQPiKSkmhMoPJAXcZ AZAgcABFnG5b66nCPa1SEkA1NAeKvBIAljxxYEnDvH0OuHSqUlVmbI3BAckXpF34OZElDOvWTmuM q0yNIlIc6FL4ALiolu6JIk52R5tV+DcZ7Nx1UFmhc/SLraW63rK3FhRxumNTmV5oyq6p8OxxZwyS NAAkeDwdXVrNsImkvMooprFivAhESR8AJLLT2Ynmuon0VUZ+ypqDA0nrD0DWRj9FpDvRvZKqHH2J C4E0ZHdhlqtrswId2jplRAkRPWy9pJO2SH0P5gMCpnmck4Y7IQudg2PFzAJAjsFAJfooccXJZrZS ponAC2R84yUCABVAo4+g8mSw06OZGdVDj+/MeraAp0Jw6cphDp9w0pmXAwioouuyh7mAxoPTwmAF hByXSMc+EllNC0O8JLpKA04J0XAdhvJixGUvbC/2fRf2vfvTISKs5y13QHSv5/lx5SfEdUnv7hUQ +H9tykesM3fl8njLBI/HYQOwDGG4lM4afGRIh1uWhgIwqUtZSiNKuRO2YHc269YXLkog+DGMY+eH Y5aUqSqSCt0rLOU+Vdx5MKCd3SGTObjIkQ9meMsTWBEzhYF3KOWOrfsAb6kA6CvDQIbqccAAEACK 0zDvFdzXYIl9mEY/q8jqEC8j2nqqlKjwXl0MxQPjUC9CEHlPdRHh+RqhsVymY7CQ+3sndMUYGLD1 XCV6ZobD/xnEP+Oq3P/ZSYQlLFVFIrgnkwe/ALZzQQExUbdOX7jXUXl8YgBItwBeFAAQt7MTEaKB a8CL1Eigbq8r7nkZcLhQh9qH04XtypwE8uGXRD3xvJyqdC4AONzX8GZ63ZoFBiAWPiSPjSIQbwHO HT2lDnAWM7zLi3TlCBtArGqI58Or1LDpiT13NPLiAsh098Uiav80ESvh/kqIb2Q4Dnd60JLCucXy GrKq4HoufYATVIJPhI77AwBaOMgwWt8w338y4kKQzn4A1OnRh3vGpRsCogeAuUMJ4NMzcQ5dwZeU IjRwkr38YrgJNBEn7/7I4WRTPbxeifwNBgeSCk73mEkDO/hqENNxAWiiAeHI0VHPysAYUaSdDS7k CdN7r6jRvEFBG3kePL7CvSvvycH4zolACPceIpYSOcKOBIZLLlZgVdpfnnxNAHX7CRYAMeduJFyh Y/oArB24N+YzeXKSAujuJgvOiR9WPZOPLrKNUZsunWvI41cQcIMCD+z4ecmkGwpxy4dkReMnG+iG W6DDEfUE9wfRB0ZA2qPmOC4LN88RT/T7bZ+ZkTKg+rRBdAWBXg7PVXIarhWWUB2I8tsW3f1SrLbX qrSfkZFK4yxBeIz7/LjcLdOs7v+iD5qALMSgAa0uIpEBZAujOhzIAlzfR9zDICPpcFwFp4JgE3qu sgNuNOO4nFQ8bdUq7WGSJFJWmeJEqMzOuo4fCcRbAP0dBNyd10F0pzA7BHj+vNgoR7Vj0ZAQKogu FxDdKRVJw1NYIWXdNaH3Ka38brwmdnkd7moq3l+XwLwFVE52WHfL6aWU/8zf2j6zQ34RaBLYJY0F aG7Qs8pCnm4rHbc7Jc01C2Pb3i4Bbsjn7KU2EBawA/aRyRdV1qAxXhFz0M+iC4IPOazuNIKbDAC2 9sP31lcp91bzuJvr3YcO6h8ngwc/Fh7Kku42O0v0QjnI0lMwMQBVRaAKcNcTZjpXs7tZSvV6/NAU RSrryW4tluQ58jEkpTqZposLpQyKWxz9utNr+iyZebvFRKYdVKbLaL8CAtdSpeB0vxjSlJse/l1q gsqD+K3lwSEXua7sbUqIOBDYx1sdhTNrkCCkFWtE7BG3J19DdY3nIqElhBstewUwggmFplNpvGAJ s3o5gQJ0FPLpjHcfqnmQQXQu97Cy/FnUrLDBeqm2NjGPXUQR0T2IMIgBd0/cF9xs60Xa48GQtmVm RP3qKkoMVntEmdGbRI2hR7WoM5jAgOFrqjOYgIA7bWjrQOtI21WETpgrOhdFBnf14YcPVsuQbnCM SKcvFGSkQJTepJ6F5WDrfKMEior474hjwnFPOpxBjO+nsqVViZchpY5ptgFok1Tb4WKSZnX0wuCx GUrpxLqMIlWLy+q5AHIb/ZSvKDYUZMbelhCCKbXUXbdjyEbIHnJaFBsZ5VF5riJVmmE7yOieGI6X 9ktkvUjxdj9OWIr3AhLUx6gLQQ4U6fOShCiCa4shrZ1pzKV475C0MrOsq+JGG14GiaLrHrupS2HB /T5Zamy+cNZOXXsL3MDp98GdhwtDCUBym8edW13dVM5bv6yBYhCWk3tJMMaRgPwZR1pNhvdoqoRa iJfTouymsYtkcRLTApIDu15s1TQVdYQKf9KQxSnDjy9Yys5zHw+KZ3GyXSthyLqiuH8hfxLny3A7 lUC/C8w7AA3K7gGPBJIAVTxXH+1jlhpxD4JUpnw6scqymz7DALBBY5N1q6cfthIegYETAOqLk5HF EoPvtQDYoOmxw3w3Ri3cxwMV4XIsJMMNni1cAsYpoppwH9BtRkVQOoAlHoNfhUcRVByDZCHqYIvn Zb18uABUvPvh5Kp6PUSDxgs9zKFegc9ZjOz7RVW3gqJ0vBfyXAUBEmzu/AJZn9u8jERg75lVgW4x 0uFBMjzaA6A9n0C6BcDtTEAHFDVrjsVl4qMIBAeiNz2HREBcK/6ZSuGito24dJ+asUcgPb3QEGvV zX68XgK3B/yjm4i8C7F5oFuFogDm+lp58Fkk5ohOhVd/QHa7CQuD61EoO5Winlr+HwJdgEa+6PJr HG7aAWjKIcc+imDooS47IKdGbOftz66FJ1Igo3i5iotIYHe61AJQmSF7e8gT6tnHDhU3hAYLua+0 MtgqphX3UXWghhwyOVAEMjiuBU0yfH4Apda7Tjz3jXx1QKUqX/e5ADq9PSn68UWtDEhHDl/RlXc2 UbMWMAAuorl9KCiEPIkiBBVDCbG0u1lw0wg/Du8RRk6Tic1647YWcdlS/QjnSCagTAAwD1L2NYQi 2HRSOnwh1X0hqbh7EQA5473y51cBXcHnSx4LwLgjRlYj1mAKs+YSFw1MBDq9vWIepIGILpJVOEvQ A21Ng84NN/IdEgHWw6xlB6lXuEISCzVJtK7XA9KaK7XzwAI5dEyEIkXvae0tHpmwQBBBoNnU5dfk vUOVGvCxHumBOOSYxpKC9K5EBmes/Fhfqa050HmVI+qep1eLR3nQb4gdZbWDwf4AvJS8J1FqWoXv pLLWHW9bh/aTvNzDeGYaklTu2+cC4AXMwbdzFIHvkTcKNxm9gZGje0brpCso5rRW4aQ9whze5Mnl jyune1DhUBksJakCrR8PlOUlRKZeZ8jJFUKUgK6X43nH0yATBhE2ns6HJhVWvHolt2wLdPVEBkuK jHzeMCaXoEcmUKaofoF0VKHq0eMEyi0gcyLn5tsFAPh6QSOuIkWcaExIg+k4dr3w80bFCrPerjJ9 l+FBLHN4vRpmxT0vKgi+RyG92hkZrx3z8N4GAP0cV2r15pA0CFBtS+8xu5vzGBfPisjIHY/Lbl1k qgZ+uFaGIth5eWVuk2kUkyW49tciryv6KWWL8ufjZ72zFHlYi1r25odMkEYlujLbEp1xsaTV+7hs PZjD+ynxVn7kXbQLVtB3Jbsm1JI2rpLcqUduJvuh1AUEdYxV1PRSD1OJKU4/7lBP1LIkwPZzpjRS Nj7MrDGJypwYt826nWOpEmXpT2AX+0mh5HUA9AuFMlJQaQqPD5lS23RtgpkTgaHMENVo+jjd7oi3 37FY7zOSc7yf0N2wirpeHel3A3toKbTRWVyNjFk80WHrYxDR37ZuZxUNvlUSJy2E5yKKgZ3Bp1Tk PVAW2WucE64xU9hkoE2PNTMvgSFAJtLoPqt8MeApurnqgRiHKdUWgL16zOOdA059FYpe8VQ91QeR 8w3vc2QXmMgBkTry5qswf9iMQoyP5cx8JhqQ5IOT+4WAiWqDq6YEkgAxyzuZfChSrhvyEQnExQa2 7xFc8wDAV2zSeQdRgwo6qQ8/2wAAdntzxegKkPiyS/WDMjIiYPMBrbSvADMA6HecIBz1JhokvbiV zCmP5iSXjJeA9zOPoWJfD0pFXu0koI0JAFauAbMu1qAT9HJOR1frfZUe/DwuFjr68Mzm9IquAFh2 rbsOsFhp3QVw9JPC1n3Ksn2RtWzbOha9vdP48iNrhuUaW/b5eCWZmPZ1UWQRt7w7oFDgtezHqWzb ZA2l7Vrl1mg0clgrj09inbuXeN4OoO32Qudp61TvmUqhK3V2FaGVW6KtpaVnCSJU2bJo2tyr49yP Iee9QuSJ3vFjPUBafErr1amaXBwSGATWHKeiBiDEBXiO2BYnEC+1HJ4dkEGe6DtsLLK8cbVUZe6n ISpxJedN6S6glsUnN6tl6+CvphytLgCivwbXTsE4dJQaD1MTv0K6+x6OZGLSp/eRTisN4VuWQ50A 02pGlQKDq8sHgUSglNUQ7ssrXC/qGQh04txdwT2mn9PBpmRGoTZFRnniijmvMdBtHabjArh3RzcB rgPazOXXQyXs4+COm0ug7uZF7aa7P6o2vP1aTKy0d1BK90MBQErmuVYqAKXrSkNs4lGAu2lvTOGC 0uMknkP6WlxJ6kzLIRP1DFregrpKbuV53hcIOF+lSjbv0yrForo0uEjHBVDXLLshVYwWd5JgeWYB vkr9tF7OBwekjaa8mlZcsdxtmVJvDk4bXWw5e8hQrHpgLh+j3bfS7vUOGiJ52cAEioC6gCajY8xF A1Yk30pZQFKRUFbrqHgm1yIBsN/ThdpQp0oF9zADoP26+p5AFyDemhZJ2qu9cdn5Zt/kiEX0+04X pR3Qbpi6+8GRowpIRwVZNme8xcLYE0QmmF43d8CZ3LYsKppOV+KiZdXc3PgAAM02LcdObEVA9ZOX qFtWsJFdA4LIb7dyyI5gBN+uuXDmKfKKNTMUEOa66yaN4ZgEvA8VOJLy2sybomLSluw4EFGOsJkt Ijq3JtnYRSjVNZxtnt1D4U32rkxrysPEwXNYotklIVLw1iA/TeS4BHfrMnYvnrqiPiEyOjmFTtLl 9XHZpIdFLgFnPqyuB6B0WWk5gcJOZzmoZKsDCAK8xzpN68h3Jr1py9UUD1Yrd784Vwd1euDp1tJI dK0SAE5muPvMd273ZcS+xq4ryIlvGy6ADtDhqjfVZF4WhVYvMZv1KPlcCgAkO/TomfYmql6dPNJg igkoGYXOrcljlifKWvQrZbl8eTOdZWNO/USrhpJq0P4o25iAjgSDROlKK8I1uyxL2k9kMmOMkcKq 0MUJpGyreqLMnle+BEzgyccgbjX/LaF/7/yU+r0Hqmemm0uv+N19oTo99FWyd34/nS+hhjtfuRsM is56//kuD//j1enRuPlHPN/9Px/FfPPHh3h65yfV65UvUCAqA9cNK2KCr7wwHxo+aPbkm5sf048P MfTOn8S4xlCdNJtw9dzk54cx9OHPryPCDlfZEERylxsM2esXj58/yjcPftXuwx9Y5118rBSaE3c5 efzyJZ5/f/XLyydPX+Cvpy+NrZ8fYmt+MFu4M4SQY97ov/cloNNLvPKuXio36Kn/OD36rN9i9yf8 9eCH+N75U05v4rTyKb+7nEbbC85G+PPY/uuDvLzzd5zexAvf5brHy7PHP+FTgKeXr14+xMk7f83p PieTob9vYOWhzzqUD5fLvFVR3sTAix9e/mAzx+aPzZsK6RggHevNVw+O0hLZCAU3My/w6RK+dVL1 VmBs7hIr/mRtX+eDCMHgY7/VP4+DZxT4ZH89oqt5iyfRO1NWDEaQm8UvjnWel1KDWXrGtc2tLEHO 4xG8PMeVDp+rImYceH4BrMDcXWQBcN3iqaDJr0cFJ9MWmeBklKPO874eeZWzd5bo2vZaufPhJ7oC eUO83htiG9OEMS0P7nil3/sKRMiIY3z7NzwKXUlkpVJJxXMVSSNlQv34kIeN5hs+5FHGvZpbx1ug qnlkhKXer7ny3upFzfjoHaz1ezW/8Zs/5cNFdPZj6c5rPG+RfCdbaX/iJzke+oRb/XBxzNcAKq+h 5PufDLnD1YP8fLhIxkcscPsFN5/usfO3mKOvXp/+bDvYf+F+b53087OnDwmh+uECujfGIbyBsZ9+ we75rz9im33NL+w+qjff/fB/T4+60q9++RlL69ftsvXDxTmep7N19AZ2H7+G7H64295Z3X7TcBZG K1wROb6N/JEj+cdHtdw8fv7Do3bzrQHD9JNv1V/2Iz5f/PPpR3L+6sfH3+P/jy3nz2zKr+vXd1bV 75svCml7Q4NsKr54iIcly22jM4rYCAtdfEVfs430kSc+W7s+9l0ZcbIydFiCtzM4Bd5lPNGHUK7n wBN8k0dKb8iRdZ018z7S1QyZFj48L2Fcz2GWN9gYDHG9loNf3wWNyjvt13J0Hjg3PkNzO8P9Hv1w 8wLHIXiZEu8nXfskops6f//dgzPsI3zBCf6wN/ACVf4ZZMxjrI/5FrUM2j0l5K+Rju+1t6lXrnSi bnHeZRyGx9PH/2by8CfsJN9pHb84fU3O//nGeP0LFv7PzwwwKf9Pp8c/PcR4+xjWiJgO45qcfPUa LH3/w8t/fgSu4s1f8PGsX55/S4n0r0+3cPoJ7gJ+WevHH/kB8W8f5P1jWC/kPest1nsyHp15+vP5 IT4+gu3ifBS+MHqXj/+uzeZ7jP/pMXrsySP9B4n+LfvwJb5PT4H+XP0MExWzpd48PAk+fLNcDeAX he41AFO1YKrq/76Rc3969SMY/8H+efHDfz5KBr9+lAJ4tsX57asHWf/w/XWxjgDz+6y/Wl39y2ut qrWhPn590YjvTt/zm3XUWx7bOP38IOMfvpE646nz6PIu408gyV69fPL09csHJ/DaUAM/lxB8U0Xc Ig/tg8fgNr0AlfE0kX/njFcs8Jn4foRQThqKR3DTZPhk1ofGXnyq7/hyj3MbbugRxZiOWKZrNlz7 8F2q6VtJqfBThHe77KsnT2wevmVN3dJDH+rUD9/H8OUePCV1nduHPBrtw+2t1V2JwT73lsb9pYtu ykv0nF59xy8jvnj8Ev32Hw8tif7he9FiGPcZfrWF8SiNrf3yG45Y0hdm20NsfwSLzT/hhejOe2z/ BT3MPb0duyk6+mFjsn/4zrRYw6vO91h7ejY2jJ8zOk/WZFPPWd99bsrN15wAf6Kn9EFmP3wXagj0 mgp5vG6IF/CVoD59Tab+dHqQrffaYe6pdm3yPDXyO4L3+nEJmifG2JmMPbhY1v6BV9fXF6fp3cML i/24aM9wILgo8IBnp3jOvLJ5wn1SPE3LMxx8ULgxwhA3fE2oI5gaD8cHntc2vaCBzJGZG4KJADAG u3V9PbQzXq8NnsDhJc2uqEQ90571IBO+1Tn1TXg8JT14qxWZIzNf+wBx/ygHMng0CvvX4En2Bx3I 9LUX3fPJwuPa8ITsvuSvb2rhuQl/YXQwKhMPRfTtpMVrmiX6gewzfxyy0Fb0V2d1xS3rMbTn/uAk HrOt5/1M/7Vts38Eg6qJwdauqUjv6OHq8w3ahr4GgK9x+kXGCV0SF7L9Cl9nX5R9zYlFBi2PHSHP m4A4DGRAuG5Vnooemn+un/kOdD7CKK512lh7ET4OyLlc/DoZvqrEL2qseHR84Ak1pnV7rFdeBsK7 sfsOy/DXbyLD/UEmM0S56KtIIBN5xo73/nY8+lXO1nbTdcsC553+SYbCSBe+euxfCmL0CF4C8a+h wX3e6TU+PqblHwZCBIq+SGSiHk+51uWqxweH8LgNdoL+Ns7WboMPW/Ll3uBzF18ChKY6o4cL4BuF eAZ0f7NQnm3ohPvCNj7ah2dL9Y3eF/q4Hj+Jm877c4p432704yLoVb7WxpKD3oOO65ZoqrwamPq6 l5L8XTo878s1pqt7GU8LeA2p8pgJJ+C6DJaqv9i4Ii5TY9Rm0hMhb+Fr7Sx8fgdP9vJRZZCcfLY5 ScaCpH+BDt+LJF+ZMUdoyX7aIE19ka6RGKgMRtummjxwLwe9UqYnn9/CWN0r9NoL+xWXnU+4ha97 v7zuc8I1/bzv8uBzKXqGngBjI/lk5r7+w7m+whKrXmXGk5nJL78wHh4vHPgdHF5LKCmsm5+dz+xg D6tOIuuZprYuePSs79asuxq4x4Nn72N28wUAiGo+OBAnxYXfg+tybORNEQ0Lfd0YW3tk89AaMoEi dV310k6MNzHa5huf7AkHExEM80nbvgA8VhXWc8yVL1SXsJnSk4PYi/1qUdOnoGZfF08Rt4wX5tu+ TcWnDfD87qLBZ1r4WIlf0eJiyjMoFfD++vDb6rx7ho1z37tVbB7UiumGX+N51EjrvqO/mj7iuljp 38lC9HpftiK+GtWPS28ZX6/q0yO5IN6x6/Sxr/npCfi+bhbwgl4nEJxE0IenmgdmAqDi01ZnVl4f YJENJNFI9S6wbxfim1F9RXZXvaN5yRifcwDrfgvzAki7LZ2AX/eqDOJBd/ibfFWnSDtWH/0DP/KI uy28kc13svdNQz7xfwCMxuYb2O0uUNfA0UdddrV4EOcWMJSjbpv+APqaHFSjxr7Ndw/Qt/LmbtwF 4POvsJN1+2sBbemTzyVVsJvN9V4XgXwL4DeW8ly3pwk0AWMtDM7ysYayMer0NoC9bc61+tZami7N /aoilt9aXAfQ1vqERhBWwCCBJiCtJb006+qAUmX9jK9H6dvsC0AVZYkMfNEk7Du+XapSqFuinPyx G0/jG1ehbvL6VkloW8wdwCFMGwWb3w3vSa/abYnS3TYY+7j+AFbaRWeKd4C4SSxpW+8Cm+SgfPau vwDiZitSpB9tx84S67qw2tNS/y7kbTr5AztL3k5uHHEDnt4CGWpmnGue9ajPj8x1ox0CWZuTv5Co myQEjg1OSqIv98Y7SQT2PJvcAfNORqbTnsv8gFpdYySZTmDfkMX3wfRAtHIolZaEZ/6xCdwDGJtb 8kWgK8QBFpmJNr/qXhhHivf9l5TmLUKKlC38mvYCfpsqnmVvGvdVYe5M8fobAFg1yFv4cxMl5a36 Ka+sO+1SeNwV7S6nXerow94UulvYQep0XiqkO5MtI2edregwgZ8oa9OvprMhVbTz4FtKt/rkzaGd 4z1jTO6cAa03C7j03ie08v8BvW3+vg0KZW5kc3RyZWFtDQplbmRvYmoNCjMyIDAgb2JqDQo8PC9U eXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAzOTEvSGVpZ2h0IDQ0MC9Db2xvclNwYWNl L0RldmljZVJHQi9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvU01hc2sgMzMg MCBSL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTU1NT4+DQpzdHJlYW0NCnic7d3RjcJADEBB kv6LPpQ1Rwl+SDMV5OvJayzxegEAAPBLrsf2VwCMd5Hu+9YloEOXgBRRAmp0CajRJaBGl4AaXQJq dAmo0SWgRpeAGl0CUkQJqNEloEaXgBpdAmp0CajRJaBGl4AaXQJqTpe2vwJgGJaAGl0CanQJqLk+ tj8EYJiXgBpdAmp0CajRJaDG0htIMSwBNboE1OgSUOOoEqgxLwE1ugTU6BJQo0tAjSgBKYYloEaX gBrHS0CNLgE13nFAjS4BNboE1OgSkCJKQI0uATW6BNQ4XgJqzEtAjS4BNboE1OgSUKNLQIooATW6 BNQ4XgJqdAmo8Y4DanQJqNEloEaXgBpdAlJECajRJaDG8RJQo0tAjXccUKNLQI0uATW6BNToEpAi SkCNIwGgRpeAGl0CauyXgBpdAmp0CajRJaDmdGn7KwCGYQmocSQA1OgSUKNLQI39ElCjS0CNLgE1 ugTUOKoEUvwYB9ToElCjS0CNLgE1fowDanQJqNEloEaXgJr7sf0VAMOPcUCNLgE1ugTUWHoDNboE 1OgSUKNLQI0uASnnlzhHlUCHIwGgRpeAGl0Caiy9gRpdAmp0CajRJaBGl4AUR5VAjS4BNY6XgBrL JaBGl4AaXQJqdAmo0SWgRpeAFEcCQI2jSqDGvATUWC4BNboE1OgSUKNLQI0uATW6BKQ4EgBqHFUC NR5xQI0uATW6BNToElCjS0CNLgE1jgSAFEeVQI2jSqDGcgmo0SWgRpeAGl0CanQJqNEloMbxEpDi qBKoOY84R5VAhy4BNZbeQI0uATW6BNToElCjS0CN4yUgxVElUON4CajRJaDG0huo0SWgRpeAGl0C anQJSHG8BNQYloAaXQJqHFUCNeYloEaXgBpdAmp0CajRJSDFUSVQY1gCanQJqHFUCdSYl4AaXQJq dAmo0SWgRpeAFFECanQJqNEloMZRJVBjXgJqdAmo0SWgRpeAmtOl7a8AGIYloEaXgBpdAmocVQI1 5iWgRpeAGl0CanQJqPE3u0CKYQmo0SWgRpeAGl0CanQJqNEloEaXgBpdAmpECUgxLAE1ugTU6BJQ o0tAjS4BNboE1OgSUKNLQIooATW6BNToElCjS0CQLgEp5iWgRpeAGl0CanQJSBEloEaXgBpdAmp0 CajRJaBGl4AaXQJqdAmo0SUgRZSAGl0CanQJCNIlIMW8BNToElCjS0CNLgE1ugSkiBJQo0tAjS4B QboEpJiXgBpdAmp0CajRJaDmdGn7KwCGYQmo0SUgSJeAGl0CUrzjgBpdAmp0CajRJaDmemx/BcAw LAE1ugQE6RJQo0tAinccUKNLQI0uATW6BNSIEpBiWAKCdAmo0SWgRpeAFPsloEaXgBpdAmp0CUgR JaBGl4AgXQJqdAlI8Y4DanQJqNEloEaXgBpdAlJECQjSJaBGl4AaXQJS7JeAGl0CanQJqNEloEaX gBRRAoJ0CajRJaBGl4AU+yWgRpeAGl0CanQJqNEloEaUgBpdAmp0CajRJSDF0huo0SWgRpeAGl0C anQJqDlR0iWgw7AE1OgSUKNLQIqlN1CjS0CNLgE1ugTUXB/bHwIwHFUCNR5xQI0uASmW3kCNLgE1 ugTU6BJQo0tAjSgBNY4qgRrzElCjS0CKpTdQo0tAjS4BNboE1OgSUCNKQI2jSqDGvASkWC4BNboE 1OgSUKNLQI0uATW6BNSIElDjqBKoMS8BKZZLQI0uATW6BNToElCjS0CNLgE1ogTUOKoEUv4fcboE RFguATW6BNToElCjS0CNLgE1p0vbXwHwZVgCanQJSHFUCdRYegM1ugTU6BJQo0tAjS4BNX6JA2oM S0CKRxxQ46gSqDEvATW6BNToElCjS0CNLgE1ogTU6BKQ4hEH1DiqBGrMS0CNLgE1ugTU6BJQo0tA jSgBKYYloEaXgBpHlUCNeQmo0SWgRpeAGl0CanQJqBElIMWwBNToElDjqBKoMS8BNboE1OgSUKNL QI0uASmiBNToElCjS0CNLgE1ugTU6BJQo0tAjS4BNboEpIgSUKNLQI0uATW6BNToElCjSAAAAL/o D8riE0sNCmVuZHN0cmVhbQ0KZW5kb2JqDQozMyAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5 cGUvSW1hZ2UvV2lkdGggMzkxL0hlaWdodCA0NDAvQ29sb3JTcGFjZS9EZXZpY2VHcmF5L01hdHRl WyAwIDAgMF0gL0JpdHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9GaWx0ZXIvRmxh dGVEZWNvZGUvTGVuZ3RoIDEzMDI+Pg0Kc3RyZWFtDQp4nO3cUW3DQBBF0UAxlEAxlGUSKIUSKGlq S6UwV9pzEFh6H+3VKvN4PI4H856fNf0JfFf42GHc8V3h817Tn7G989rhOf0Z21vXDsf0Z2zPDgnH z7XD9Gds797hZ/oztne8/3Z4TX/G9u4d1vRnbO/KBzuMu/PhnP6M7cm4BvnQYIcEGddw7yAfpsm4 BhnXIOMa5EPDskOCfGiwQ4KMa5BxDTKuQT402KFBxjXIuAb50GCHBBnXIB8avAI1yIcGOzTIuAYZ 1yAfEo4lHwpkXIOMa5BxDfKh4WmHBBnXIB8a7JBwvORDgYxrkHENMq5BxjVcGedC4jgZ1yAfGuyQ IOMaXEhskHENMq5BxjW4kNgg4xrkQ4MdErwCNci4BhnXIOMaZFyDjGvwm6wG+dBghwQZ1+BCYoOM a5APDXZo8ArUIOMa5EODHRJkXIN8aPAK1CAfGuzQIOMaZFyDfEhwIbFBxjXIuAYZ1yAfGuzQIOMa ZFyDjEuQcQ0yrkHGNci4BvnQ4NB9g4xrkA8NdkhwIbFBxjXIuAYZ1yDjGu58WNOfsT0Z1yAfGuyQ IOMaXEhskHENMq5BxjW4kNgg4xrkQ4MdErwCNbiQ2CDjGmRcg4xrkHENfpPVIB8a7JAg4xpkXIOM a5APDXZo8ArUIOMa5EODHRJkXIN8aPAK1CAfGuzQIOMaZFyDfEhwIbFBxjXIuAYZ1yAfGlxIbJBx DfKhwQ4JMq5BxjXIuAYZ1yDjGq6McyFxnIxrkA8NdkhwIbHBhcQGGdcg4xpkXIND9w0yrkE+NNgh wStQg4xrkHENMq5BxjW4kNgg4xrkQ4MdEmRcgwuJDTKuQcY1yLgG+dDgtEaDfGiwQ4KMa5BxDTKu QT402KFBxjXIuAb50GCHBBnXIB8avAI1yIcGOzTIuAYZ1yAfElxIbJBxDTKuQcY1yIcGh+4bZFyD fGiwQ4ILiQ0yrkHGNci4BhnX4NB9g4xrkA8NdkiQcQ0uJDbIuAYZ1yDjGlxIbJBxDfKhwQ4JXoEa ZFyDjGuQcQ0yrkHGNfhNVoN8aLBDgoxrcCGxQcY1yIcGOzR4BWqQcQ3yocEOCTKuQT40eAVqkA8N dmiQcQ0yrkE+NLiQmCDjGmRcg4xrkA8NdmiQcQ3yocEOCQ7dN8i4BhnXIOMa5EODQ/cNMq5BPjTY IcGFxAYZ1yDjGmRcg4xruPNhTX/G9mRcg3xosEOCjGtwIbFBxjXIuAYZ1+BCYoOMa5APDXZI8ArU 4EJig4xrkHENMq5BxjU4rdEgHxrskCDjGmRcg4xrkA8NdmjwCtQg4xrkQ4MdEmRcg3xo8ArUIB8a 7NAg4xpkXIN8SHAhsUHGNci4BhnXIB8aXEhskHEN8qHBDgkyrkHGNci4BhnXIOMaroxzIXGcjGuQ Dw12SHAhscGFxAYZ1yDjGmRcg0P3DTKuQT402CHBK1CDjGuQcQ0yrkHGNbiQ2CDjGuRDgx0SZFyD C4kNMq5BxjXIuAb50OC0RoN8aLBDgoxrkHENMq5BPjTYoUHGNci4BvnQYIcEGdcgHxq8AjXIhwY7 NMi4BhnXIB8SXEhskHENMq5BxjXIhwaH7htkXIN8aLBDgguJDTKuQcY1yLgGGdfg0H2DjGuQDw12 SJBxDS4kNsi4BhnXIOMaXEhskHEN8qHBDglegRpkXIOMa5BxDTKuQcY1+E1Wg3xosEOCjGtwIbFB xjXIh4bDf60Jp7/RCef0B/DvFy4IdSgNCmVuZHN0cmVhbQ0KZW5kb2JqDQozNCAwIG9iag0KPDwv VHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggNDM5L0hlaWdodCA0NDAvQ29sb3JTcGFj ZS9EZXZpY2VSR0IvQml0c1BlckNvbXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL1NNYXNrIDM1 IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDU5Nj4+DQpzdHJlYW0NCnic7c4BCQAwDMCw 1b/pqziDkSjIDAAAAADAX9V2AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADg jmq7AAAAAADc9wBgcAAHDQplbmRzdHJlYW0NCmVuZG9iag0KMzUgMCBvYmoNCjw8L1R5cGUvWE9i amVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRoIDQzOS9IZWlnaHQgNDQwL0NvbG9yU3BhY2UvRGV2aWNl R3JheS9NYXR0ZVsgMCAwIDBdIC9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUgZmFsc2Uv RmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMDkyPj4NCnN0cmVhbQ0KeJzt0VGtwkAAAEGkVEql nBScIAUpldLXUAzcB7ls3oyCTfbxAH5uHPvqBKaN8/Qt57p2fdtWZzDlc+0cqzOY4lqRa0WuFblW 5FqRa0WuFblW5FqRa0WuFblW5FqRa0WuFblW5FqRa0WuFblWdF97rs5gyn3ttTqDKa4VuVbkWpFr Ra4VuVbkWpFrRa4VuVbkWtHuWpBrRa4VuVbkWpFrRa4VuVbkWpFrRa4VuVbkWpFrRa4VuVbkWpFr Ra4VuVbkWpFrRa4VuVbkWpFrRa4VuVbkWpFrRa4VuVbkWpFrRa4VuVbkWpFrRa4VuVbkWtF97b06 gymuFblW5FqRa0WuFblW5FqRa0WuFblW5FqRa0WuFblW5FqRa0WuFblW5FqRa0WuFblW5FqRa0Wu FblW5FqRa0WuFblW5FqRa0WuFblW5FqRa0WuFblW5FqRa0WuFblW5FqRa0WuFblW5FqRa0WuFblW 5FqRa0WuFblW5FqRa0WuFblW5FqRa0WuFblW5FqRa0WuFblWtLkW5FqRa0WuFblW5FqRa0WuFblW 5FqRa0WuFblW5FqRa0WuFblW5FqRa0WuFblW5FqRa0WuFblW5FqRa0WuFblW5FqRa0WuFblW5FqR a0WuFblW5FqRa0WuFblWdF87VmcwxbUi14pcK3KtyLUi14pcK3KtyLUi14pcK3KtyLWi7e1aj2tF rhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5 VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VvS9tq3uYMb32r66gxmuFblW5FqRa0WuFblW5FqR a0WuFblW5FqSa0WuFblW5FqRa0WuFblW5FqRa0WuFblW5FqRa0WuFblW5FqRa0WuFblW5FqRa0Wu FblW5FqRa0WuFblW5FqRa0WuFblW5FqRa0WuFblW5FqRa0WuFblW5FqRa0Wfa+e+OoMprhW5VuRa kWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtF rhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5 VuRakWtFrhW5VuRakWtFrhW5VuRakWtFrhW5VuRa0cu1INeKXCtyrci1IteKXCtyrci1IteKXCty rci1IteKXCtyrci1IteKXCtyrci1IteKXCtyrci1IteKXCtyrci1IteKXCtyrci1IteKXCtyrci1 IteKXCtyrei+NlZnMMW1IteKXCtyrci1IteKXCtyrci1IteKXCtyrci1oqdrQcO1INeKXCtyrci1 IteKXCtyrci1IteKXCtyrci1IteKXCtyrci1IteStsO1ouvbWN3AvG2sLoB/4Q/71/+iDQplbmRz dHJlYW0NCmVuZG9iag0KMzYgMCBvYmoNCjw8L1RpdGxlKFBvd2VyUG9pbnQgUHJlc2VudGF0aW9u KSAvQXV0aG9yKEtvdGlrYWxhcHVkaSBTcmlyYW0pIC9DcmVhdGlvbkRhdGUoRDoyMDIxMTIwOTE0 MjEyMS0wNScwMCcpIC9Nb2REYXRlKEQ6MjAyMTEyMDkxNDIxMjEtMDUnMDAnKSAvUHJvZHVjZXIo /v8ATQBpAGMAcgBvAHMAbwBmAHQArgAgAFAAbwB3AGUAcgBQAG8AaQBuAHQArgAgAGYAbwByACAA TQBpAGMAcgBvAHMAbwBmAHQAIAAzADYANSkgL0NyZWF0b3Io/v8ATQBpAGMAcgBvAHMAbwBmAHQA rgAgAFAAbwB3AGUAcgBQAG8AaQBuAHQArgAgAGYAbwByACAATQBpAGMAcgBvAHMAbwBmAHQAIAAz ADYANSkgPj4NCmVuZG9iag0KNDYgMCBvYmoNCjw8L1R5cGUvT2JqU3RtL04gMjczL0ZpcnN0IDI1 MTEvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA0NTkwPj4NCnN0cmVhbQ0KeJylXG2P47YR9ucC /QH9xo8tcL0Vh5JItkWB66VBgrTX4C5IL0n7wefV7rpZW1vb2+T645vOQ41sr0LRXAn3QlkSh8N5 eTjijFSWqlClUZqcKklpV6nSKSqtqrQi71RFytTcGL6LTxb8t1alV5Xlxqra8LVKWT5ZOWUrvsUr R3yhUM7zSat8XamqVrow3Jbcer7KQ2k+z3816VrVNTjg81Zpw31qvq8EFeasxP1a6YopMye6xnnP rSt5XKVtqZXl65a5tWEKzA/395qUZXqeiVmeE8a3XpEuuK25tdxWiqjk1igyhVWu4JZPOv5dGuKZ KKo0z4iFUeF8qahmObCYqPalckzHsqSYdXKFU47HcTwpz3Q8kfJMxzMzfKspeBxfKaM1tyxVyNpr ZYj5dV4Zo1lWjluct8qUfJ4laCrNkyv4xoq51EXB+mD5e+4BqeuCSVvIozDKOOiwYOKe79M8IeMh QqisMLiZ1VswM1qz1jULWjPxEhJgtbCGCXTYEgwzqnWpypK1CobLisfUmq2gNtCd5QOPS3yztbiZ u7uyhlrZPAiXiG2FedEEowHvpNmqDDPGkqk0y0wTmwSVzA+VbGIaZwwfgCCx8ZRsXZrVzYNXwUSr iu1RG6ZTM7+gVUENmmCQ4RLTccyvNkwnCIHZrTxmweqvC2ZBM9G6sDgDw4J8WDQ14RKbUk0uGB/b Hnhm36jLYIYFW2sFymyGNQTFfNc1a1LDDyzkw67DVulgs2yiYJ4lYgsDymxkEL+uYK2wY3YpGwZl p7Bh7jBc43CJe5WQD2vIVg692JZrtkrNHmgtGGMHsw6iY7ewHkqBA3q2PEzJFRXuYQsF4+wzbMos Uc2O5Ag8s6c5g+mw67kSHNYwbzZEloELYmancp7gYYYNGkPBkmENcB2voRN2JE/BCws2dkydTdGX GJMl7CvMmJ3HV9AAexObI1/iiXjLJq3Z37yF07Jjesdy1OyxHp4bvMNDFRBIUbCutIN1wnQ1ZlmA XrCigoArLmAMFINehYFdYKZFCXQBs0WF2fjgB+yZ2qNvDQzCvWyiQAu4iwMDHm7nAoKAAw8FezhB UQBNChyxFAnz0DBXgrFrME4FXAyGTQV8DEBKBXzCsFAJpsvWw9gAB2aLQA/4UAXcYD8GNlZAKnga 2z9pnLNAG3DGk8ZVjMsyVwBQPvLANrhJARTS8ApYJgWvQj/S8CYCB+yt7GmsCoJEyLBkieChJdCf 4LSQVTBPBj5cBULXmBFhDMtXGDlxBMyE1NlvgKYYg22DjzCuB/LCOBn+gLFwP6AHwQwMzIcMfIrY 6ggIxTDIfXlW7MosT2YSRzXOweErzBfWZWpI3AQvZjkRgM+wZwC34eKQH0zWeMivhAcWOqA7jqAj gF4JpyHAVgk5UXBiAlfBi01VhLWQlcU6I/7FR+wEvCbAo5m3YHll5bFOACRqzLcKmMAjERC2dJgH VsDSQYNwutJDVuzC7M/gKqxvBahgZazgFwTQqXA3YTWsTIVxPeCCwAtgIugI1l1VYUUK0MFyIqwH lWWrCb5ZObZC6B0GhnPw/6JAX4sjzBcrZg1UIIBvDY4gB8aSCudwX4mQIEBPBcupA3iEMeD2wGFy wBHLkiD4JmMh3wfUquHSAVhtwTbPayXgBbzAay18lwBzFvwSPN7CkxESMOgQVtGw0mM9BgpwoBFW WAAQ7oOvWiyHZHHVMm8ET2aX4R7weOthsQGyvMdVIEYBmQIFHNYvA592wC2CnzsKfYFbhvuagFeG OTXwc4ZeXsvhq64qwuqOI9aZCZDHywkf1Thy6IsxLEvDwKedxeoNFHDOgh7G8PADaNBDMwGKSgyL M9AzzN/bCis5DgDUAC6HgVmhCG+0+sMfrr5EOFeot1fvrt49LLdXX318aK7eHXaPq8Of75vN1avV 4XF5/1Xz4+HX//tp8Wpxv2gWPy6Wi+3imo926leL/ULxvxX/2vL53WK9aBdX/BtHB/7378XjovmN uvriO1X8U119eavCgH/84y9/0Y1PMv5n+mejc58SIefbaEctHcHdh/bHaG8z2tumpt3ffvWF0scu 7NB5knr1rpsvxQbOpvLbjoiZReSbjkgZFYEXIl/GRFcF8SKiD81lQSbU0LGbVOKn69vHXRPVoQsc dNxGhVFmqrI6dUlqP6LKOjpwLhVRpZ1F5H1HxEWJ1ElVdhKsggTxrHVJkClV2hmq5OUpMFKP0ah1 pir9qUtS+xFV6igMZZMRXWo9i8q3QiUKEbVJabPuhFjXXTOqjzoDH+vL6DquzbqDhnocGi7T0FF4 y+kYh7SMjtXUjlEMyOkY9XubXHfPFyB36lM/19Z9dOhcMmLrFPWYbCp/EipRj7FVytZtsG5syIRm dAk4CjNh63YUdTJ0aMuOg2oGDYo6u6NMMb5+3B/aTbNTq3bbqPZGCYZQ1IWcTsnVXfbZhCQ7lqdK Yarj0lTHpamOS1HHzekYXaSdT2n6zOPptLr5XOvoPd5EfTWbTB90Rn01nxmhEjV4n7RMH27GFmho Rv3tKMyEnfo5duqLjgM9RsPnBm5apBH1U5+M3Lyb46d+NDbAxnAe829a9fZvX8sMoq7rk48R2Iue MQVhND6H3CfXB3qQCUQhBFvgyRnMegQVNuMD5y6hpxlEsQxbxckZXA7akzMYXTmRB8iEhNVqfd1s D8t7dbf+13L1vZIJRTE2ny6vg7p4qflPcUWl0IzCL1IVKSHpzuGR45glrNEgBQmRvEm9V9t2t1ne 339Uy+22fdyumn0vr2hEl086CKtgYen690KyjC4ZyMgkxVWKuEYhGsmdPKbulnue8VbYia49+cRk CSuji08+mc16u2YVMPq96uUUBfCLcrIiJyftqH1kmVen6H4eU7dUpsZg5dQYrIzjFuU+Lx/XoDKO F5R8ZEbmcI7Qac5jchlFo5yOUVfP2WaJO7TJXfPPAFV9oySYq+JuSenV38wDUzO++ptnIZ7M5lsl u2hVHB1M2pfNvEjAzNkpqeLoY7Kj0KhSo0CADHdSDLOiUmE5OnCZa6Kfb9Wu2T+0232jDq063DUC 0lU8xMsmvH/88LBrbtY/SpjyQr3vKcchLJvyaSU/V4XQjqOaSTtXJ+1QftC1s57qZSZTzTMec5W5 y+17tVl+VD+st6r9T7MLCpU4kU+JkOKhT/YQ+3bTqId2d1i3W+yfnIymjgNmNuX19tDs9s3qnPLr 13shHgfOMh2ylxI2SPZDj6c/8nQ7HsKnc0ln2xI1nXXK3Qr4bL1Xq936sP73Y/M79fkNu9Pd8voU 7dVxWMumL9FeHQeybDJn0d4LtT6oH9rHe3B5UB+ORhJHluwhlh/uA1YtD4dm83Bg/FrB1D+qDx/7 EeIIkz9ChzDr7W2wwE27a9T+oVmtb9YrGSGOM0cTiNtiJTFnJSG/pHF0l8cJdUdzbFMyjTLPOIO5 j4M/2ySVBGgdh6cq/Ug4nirLm9j4o2Cdq9NPd+3md+qLl+rdbr1bblRvKnEszCb7SbNqNh9YTv4F KpFki8rGcbBO7tjpWswjI5mUklY9rv46F4jPd6tsHHfrNO6O59PyJjGKs6dAjdeJaLjfreIC/OJr nehRyRqaLoNru50K212zXb8uBYKa1NB011xHxXUO6zp/dd0IrqPZbaTKPqRs5vVbYv3GUr930j/s hirNrhXfpf682AIJNJAsYyT9Segbud8IfSP3G7leCtSUPdTIeJLKFpPstRlVtM0NzP730+Ivi2Zx kGKW7aJdHLi94Xa3uMUV/nVY3PGR4jPt4pF/DUpaiolj99nkmWTah8N6s/4v+/PTypOp9O6b5XGD biap/arZLnfr9mkhyoBa3eN7vAhIi6lrMXIt6ThtxTye5PaGtHuMT/mtLcYJ2IulQoVESKcCE+2e WyxUxwfPpjOoMZlK5punVSZDUaQfSAR1tBPvfpJmHJNqSi0uoZajXlOZd4GLJ5njoWgulg/16vVn nZ5bQKRHkCKb0LDuZCqd94PKkyGd9KO/LBpaVg3tEwpyGeVEwvd0DcvSJnzH6Rwzjhc1rM1Zr2cX Fo2AWzahXsXVTDp9cdEIpPj0XqkXiUpEoH1CQz4nJvLlPBV7QROfQJMsMJhhZTO4n9yVRiAjp2sc JSidMj33BKKzXs8tO6J40JBPqC88intUPp3XQifuUZROm1KXNg3vYnTt+CpykmzCE6jICVNSBlEK I9U8OnFgID25FEmiBoq7GOnkAyTpHMdOyVXTuGJ0NXVSfX1V3PlJl+lJzQxJSc9U8nTgMdOBx4yE Jzld4xEJUa5V0qDOZkgnbYQ01wgpYYSUa4TRcpshsbTh0VzDo3HDI3KZE/l5zc2Qkk3PIhGx583C jc/CJAPCZN3NkFJy55TMuE3kzeJJ/nQ4dm48+CYUkwwLbqZS6/NYm2Z7GNTbDEkmA02SvR8ycw3W jAeYZHINNqfmZirtVNHNkGbaLWR/jJ7k6gYkylzrjpfdTKU2rLuZSidRePM8WcmGKnVp0fCC50w7 kziwHHfKnIWuHNsEy+g6AqZlriWe6mhGAK28INO5sFyOw3KWAKY/xJUjKFVNKJ1T3/SFJOUINlTJ ShKq5tpiNR6uUJX7eHQ+o74wZgSXqvSjUpWzjZOcz/giQNnZv0/bnfr2xXk1yAioZVM8lYPs2sfD cUWoRkAum+5yd2RxBNyySbFLq6+X9+trXreukbt+2LUPy9vlGbcjgWT2ECzQzaC8ZkgqmUilLpEa 3lzvWoFmSR1SPdsdEo/mdTL4frJ/X5/1yt1Q/fxmWMQzHD97azaURjwpRTgz5RH4yqaOnM5e3eza jXqt/vHrH9aHO/VeLffD6pqp9Nvd+na9/cdvpHbiQ6P4efrhobkeFtlMHWB5UN++HNTUjKl6xAxl AZc8KkkilSS9RDbxCJd+X++Mzb8sd7eNWp7q3TvBC+MjwJFNPegvYJE6Jv326rrt6Y+gSTb9drV6 3AUkAUS1N+p217DgB1U2U6mvWg6rd9teiyNgckGLkvwjSf5Rl/wLn52YByLySq1YZD+tyQFHPRJi 5acGTzYUND6o4ZlKti+ZGgGUbDqnpHNIF7OtbJbbj8MClanUjysvL2P9Sx5dqDKoVRnaYjJFSZKi JElRkpMVyCWeIV3u7k3A1A4H+3jKjiDVJTYT4VB2qq95efvyxZNq09enwNWOIdEFxhLbKukXHIdx ZwmW6AlLY+CVZimRg6R06u9cVofVy764yo7B3AU+5m72SO2O2Fuv6F6u/WQm45EdgVufa97H3TA7 gmw+vTPp5270+Hlb4nYEOf2z7Pbp85IdQVGfDIjx8aCZosh5EE+IYnp2wE3PDrjp2QE3Uq+Q03Wk hCmn6/StGhf3NpP9ZuN5KsDFHc6kX2k0eqaVmUTG82I9oxR19ZU+fT1IXzQQPpTXtQJvhcBfIUu0 1CBKajV84K5r5bq8gUjyhh3JG3akhZ7UKErip8+b9JmHfu++36butxPDp966VsJBqcgkqUEkqVeW LZ5+a6R/Bu7D1/Chs67t4VvGkXfbyQtdkYOReRuZt5F5G8n6GqnFNF0WWRlJT4sRRJR0ppSvdk3z tm0PV2/b++avywcle9dfcpS/DVeVvGwStoI7xdRHwse73rCxfNF8VH11wKdMc9semqs3+O/P2+vT j96ugn181iyvm113jD798efb+/W2eXe3BKc48WrLFJZ4kUJ+7w7rmyUfhF9/b3fff2jb768+aVeP SECEM/u7pjmAycPVX5erXXv2+/Ud/3/2+5P18r69PTvx7p5D7LN7u3H4ttvdciPuLXN987jZf8cS 6WtSw5fUgoD6G5abZv9d97P/cln/+arY57SO30OKfJ/p+HWdyNd+ssqB5YMlkQ+oHGuEpWL4co1w /y2EyLcZVO/FYr3ytnz/zvnwterhe8Nj78cmKoyl31iFsZH7jYxzrDDuX6SJvjR1VnEcffHm7C2F rJch+ncHhtXxpwJzmEhmXeupjjFeYHlWBRctzzsroYrWdj0DivsClGhlzBlE95AtEHoRouV+Uapk f/v86TBVOEyDjaV6IlAu/X4G5XK/KC9zv/JsxyBrY+nS1sVpyUg/pfaPh/3TWP8I1D+CnC01cp/v l4pC2olLTR9Q/PIX/weoR8ZqDQplbmRzdHJlYW0NCmVuZG9iag0KMzExIDAgb2JqDQo8PC9GaWx0 ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDM1Nj4+DQpzdHJlYW0NCnicZZLNboMwEITvPIWP6SECQzBE QpYSkkgc+qPSnqoeiL2kSMUgQw68fW0vSdoUCaxPnrFn2fXzYleoZiT+i+5ECSOpGyU1DN1ZCyBH ODXKoxGRjRhncl/RVr3nG3M5DSO0hao7L8uI/2o2h1FPZLGR3REePP9ZS9CNOpHFe14aLs99/w0t qJEEHudEQm0Oeqz6p6oF4jvbspBmvxmnpfHcFG9TDyR0TDGM6CQMfSVAV+oEXhaYh5PsYB7ugZJ3 +7PrWN/kkZGbZcXJh1nDwOGK8k9rvwhpeDGKr0pbX7RHYc4N0SB0xKgjioewCGmDtEJCH4sdhSkS cxTPvgRp9qVIO6S1I3ZAwtsThrRHmpX4A+bE/wqn6dbKaJo7dUL573rZXbl0jdESLGmN0RIsaRsj YUk5hklc7Ci2t4TG4YjhZeGfaLZLdpiuIyDOWpvuu4lzbbcNbxRch7Lveuuy7w/ErsOPDQplbmRz dHJlYW0NCmVuZG9iag0KMzEyIDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDM0 ODEwL0xlbmd0aDEgMTA3MDE2Pj4NCnN0cmVhbQ0KeJzsnQl8U1XWwM997yVptjbpki7pkvY1aUvb pPsG0tCNYtkKDbZFoGWzjCIVqAKK4IZYF3DfFXcdUNKAWgQVHVxmFHUU9w0Vx7Uj4y7Y5Dv3nbS0 gMs4843f75uc5Lz/vefu9553300bKDAAMOFFgrbaqpqm3u8XtgI77TUA/Xe1VeOrz/1o/IfAFmNc BZOmugpu3l+eBcDWYqm2OQvbO7fc1vMCwIlXYAUr5py61Fb5UPPnAOvDANRr53eesPCWT6s2AXSa ALRRJ5y0fL6rb8V7AFetB+iq6pjXPvf745efjfUZsL6SDjQYtye+hPEajKd3LFy67As5lcc/Bliw 6aRFc9rn1NRVAdPvwezTFrYv68y8Oy4N0zswv23hvKXt15294VRg52Cf4NyT2xfOe7fqpTxgVTkA eRd2LlqyNGCFNTieXp6/c/G8zh/cf1kCsDwdwPIe8LlQV7z31dMz/zArYtQ3EI/DQNn+2RnPcr46 7rQpB9/oL9YlhE3GvFoQgATLqcEPbJduw8E3DqzRJSg1DZH4TdxiHQFXgwmWgYglTeCCNgDD99iu gKmidKywAyc5THWtqhCrTCaKL8BDAoSBEKERREkSBWkfOAM7If10rFbL654w1WYDG8BBifqguUlw 2IAFeJq4UxXORwrRUvih3rDncbVeh1j4J0U6Ay6WRsGkf7bc7ynibLj4aHa1/+j2f3v7T0Plf6Id LlIHpEqZ6FmH9+ElKByWbyzo/um6y2CN+Ay0HjXtUrynhra3bnj8p0RshjXSDdB8RH03HCovmH6+ LkyPO6K8isoIPx69rLoe233q6GnSG+D5pX4PFbGf6pHeAY9kP2weFkH1UcucDtZhbW6Cc/+ZNo8m kgQOcTfoj2hrHYweFv8Kxv6W+sUWqD+aXbMS6jVhUK8Op3SpARqG9UsDx/6a+oW1ED9Y5jmIVz8O 8VotxEuLDtl/TtQP/Lp8w8pMwB3+yiPb4HWpLIdsmpkQj75vPbz84WMN2s4cCLPv4MRf6gPmOfNo dvHVYfUcNY/6bDhzaHtH9GXC0dfsJ/MH6+LjEl4bXq+YD+OOVka1Z7hdeHL4c0Vlglhp8y8/a3ge lRtiNd2omb+cn+fBfi7/pXy/JOK9/Nl5FLsTan+qjPAolCisgTLhG6gQnoIK9gIkCjdAnHAQWtkK ekYKOzF8KrRKJ0Gr8APqN1CO2qqUAWQFjGIHsNzBQ/uqcA/1B9OK/tWx/V8X9Gtg7//evQhJSEIS EhLhevjbT6YtgOd/VR0men4N8LeI2AmCWHnks0lYAiO5/tZ6/zdEPPtffw6H5L9bhNcCzt+7DyEJ yX+zSI/B/H+1DjEK4kQdLBMt0PRLeYUTYJl0HSw7atpaqDjC9mf8fLUJzMKMIz+LhyQkIQlJSEIS kpCEJCQhCUlI/v8J/4ypUHf0z46Hy899zgxJSEISkpCEJCQhCUlIQhKSkIQkJCEJyf8NYdf+3j0I SUhCEpKQhCQkIQlJSEISkpCEJCQhCUlIQhKSkIQkJCEJSUhCEpKQhCQkIQlJSEISkpCEJCQhCUlI QhKSkIQkJCEJCUngod+7ByEJye8sYlAT6S9JsckYw5BYBxLjfxeiDGwgKf8LjhHSIBdcUA0TYCq0 QjssgC5YBitgA9zL8pNykpxJ5TatzWSLt9XYVtmfPSgFlL8NhSVtSskxMB5LNmPJOXDiYSXLhpUE LMkC32A/asVjlDr435u5RenhRDYlMEd4Aoo/O5+/+jI+mP1B1Qf73mt/l+ekv4dVFLyWKSMAqIC6 n50F/pdrRPFY8WocqxkiMV4Dy7F/q5iJJbBklskms1Y2g53EFrEudipbyS5gF7KL2Hp2HbufZTMn G8vKWAOo2bdKfd8e/ne5MC4E/4qXAD8vVJJ6c7QFW4x60i/UwYVGcuRIa4bEZg6GlNEO6wb2c/jo MX7U8Su5n0R99lf06vcU8ajG6QMhKZPIV/PXV8rmh+6U33CngLtu1swZx09vbWn2NE2d0jh50sQJ 4xuOHVc/tq62prpqjLty9DGjRlaUl5WWFLucuTmZDnu6nJYSF202RRj1Om2YRq2SRIFBTq1c12bz Otq8kkOur8/lcbkdDe1DDG1eG5rqhufx2tqUbLbhOd2Yc/5hOd2U0z2Yk5lso2BUbo6tVrZ5d9fI tl7W2tiM4Ytr5Babt08JT1DCkkOJGDGSmoolbLVxHTU2L2uz1XrrTu3orm2rwfp69LpquXqeLjcH enR6DOox5M2UO3tY5mimBITM2ooeAcKMvFmvaK9tn+ud3NhcW2NNTW1RbFCt1OVVV3s1Sl22BbzP cKGtJ2dn90W9Jpjdlm2YK89tP77ZK7ZjoW6xtrv7fK8525sl13izVuyLwyHP8+bINbXebBkra5gy 2ADzquwm2db9DWDn5b7Ph1vagxa13fQN8CAf4uA0YfpAGLBv2EMcX2oq78uFvW6YjRHv6sZmittg ttUHbld2i1do4yk7B1JiPDxl9UDKYPE2OZUvVW1b8H1qR5x39Wxbbg7OvvK24xvTbV7R0TZ7Tgdn +7xuuaaG5q2p2euuwYC7PTjW2p48F+Zvb8NBLODT0Njsdcmd3mi5ijKgwcbXYMHUZqVIsJg3utoL bXOCpbyu2hreL1ttd1sNdZDXJTc2b4PCwN6eIpt1SyHefC28H15LNS6Ko7a7ee58b0qbdS7653xb szXV627B6WuRm+e18FWSTd6svdhcqtKiUgrHdljugcx85Bp7mK1ZsIotfLXQYKvDi1w1ChNMuFxK lK9o1ShbM7PCQDZsJZiDh4bVgxHRXl3Pk0RetLremtqSSvIzXbIG+6Sye8OG1GVCw2CfqJ2f7Brl 5h3KstXOqxnSwWGVqoIdDNZ29H4KfC6CDWOJML6c9QNJoh3vXLQJWI1i4qsYZ/PCZFuzPE9ukdGH 3JOb+dj4XCvr2zBVbmhsbVZWO+glTcNilF5GMS+kYvJARKhGH6zLtg4sqxIfq8QHo/WHJY8bSLZ1 h8kNU7t55XKwQrDhHYSDVjvGtV9YFlmEt2Yd7m5yXbuMT4+67vbewOrZ3T1ud3dnbVtHBa9DHje3 W57aPMqq9HVK80rrCt5UJDSwhqaq3Bzce6p6ZLa2scfN1k5tbd5mArCtbWr2CUyobqtq6UnHtOZt NtzbFavArdzIIzYe4TVNwUiYkt+6zQ2wWkmVFIMSn9PLQLGFDdgYzOkVyGYasAlok8jmVmxccJHi OnCKcbuttc3ly3NGS0d3Wwu/ucCCS4lv5mXyaPAK8ugeJqgNXp08r8qrl6u4vZLbK8mu5nYNOgaz MJwcvid1t8m4T6FDNYOVkSuKvEpbbyDQ1Jy629rXkoqudjxqa7NXm417v8p+LOYby7UNzWO9q+e0 836Ap5mX1djHzWlBtx2oELOM82qxBm2wBsxRp5Th7oiF5uDa4AIq5VdjxLu6xduSzRttXtCiuLPJ C/VyBS471aly8IZcLd2RcoFyb+KtoLOfz6HFvsHUZrJYMYqNtdAkaQzY8zkyJs1ps+FsSzBnKro6 7aU6K1nm4ZYoOeYpqrMGE4EPS7TrjTqv1okV4puH9U5+S6rsmpYW6rwSOz+YAds2efXYI8eQqQwW wNnBpHG8L/g+H7vKsz7Gq2nshSnyMtxZeKeVmjSY7DXax7Xj5k/l9WiRywYKh/E9Qh+sYxdZNXzk Bpx30d7UG7hLXp46RHJzZP5w4I4J1m3o2NDSfbjBOz07NyfscKtRMXd3hxmPXoDmK8w4SDSCTyt+ NiZJrEaXHymOweuFYh5cjyqAJLpgLupS1D2okpgrjsATW4qYE2S2OMJXlpL+KEZvR92KKgZ2olHO qNumBBJtdWPmiKOgTBwJHrECWY4sQ5YiS5DFSDwLioVIGZmGTEXawAPZIr8VT+RXPGkqaRgbibZ0 MR+aUAUlVBSMfY0qQbSYATWo+1BF7HUG5iHLUtRzUa9A3YP6NWoYdj0NayzCFhmWtWFuG+a2YY02 LGHDEjZQCz/4kpNSeoXvfcnZiO98yTmIbwnfEL6mtK8o9iXhH4T9hC8If6ecfYTPyfgZ4VPCJ4SP CR8R/kb4kLDPl6xFfECx9wnv+ZIiEXt9SfGId31JLsQ7hLcJbxHepCxvUOx1wmuEVwmvEF4m7CG8 RHiR8FfCC4TnCc9RJ3YTniU8Q/gLNftnyvk04SnCk4QnCLsIfyI8TniMsJPwKNX5COFhMu4gbCc8 RNhG6CU8SHiAcD9hK2ELwUfo8SUWILyEzb7EQsR9hHsJmwgbCX/0JeYj7iHcTeXuItxJuINwO+E2 wq1U/BbCBsLNhJsINxJuoKqvJ1xHxa8lXEO4mnAV4UoqdwXhcsJlhEsJ6wnrCJdQ1RdT8YsIFxK6 CRcQ1lKB8wlrCOcRziWcQzjbZy1CnEVYTVhFOJOwknAG4XTCCsJywjLCaYRTCV2EpYQlhMWEUwid hEW+hGLEyYSFhJMIJxL+QFhA6CCcQJhPmEeYS5hDmE1oJ7QRZhFmEmYQjidMJ7QSWnzxpYhmwnGE aQQPoYkwlTCF0EiYTJhEmEiYQBhPaCAcSxhHqCeMJdQRagk1hGpCFWEMwU2oJIwmHEMYRRhJqCCU ++LKEWWEUkIJoZhQRCgkFBDyCXkKROaLc2LMRUYnIZeQQ8gmjCBkETIJGQQHwe6LHYlIJ8i+WO7Q ab7YCkQqGW2EFEIyIYmQSLASEgjxhDhCLMFCiKEWoqmFKDJGEswEEyGCEE4wEgwEPUFH0FKdYQQN GdUEFUEiiASBwAiggAUIfkI/4UfCQcIBwg+E7wnfKc2yb5URsW/I+DXhK8KXhH8Q9hO+IPyd0Ef4 nPAZ4VPCJ4SPCR9Re3/zWWTEh4R9Pgs6GPuA8L7PUoZ4j7DXZ6lGvOuz1CDeIbxNeMtnqUW86bPU Id4gvE54jap+lfAKVfYyVbaH8BLhRarsr1TuBcLzhOcIuwnPEp6hcn+hqv9MeJo6/xThSWrvCZ+l CrGLCvyJGnqcev0YVbaT8CjhEcLDhB2E7YSHqOptVHUvVf0gVf0A4X7CVmpoC8FH6KFmvYTNhPuo 6nsJmwgbCX8k3OOLwX2X3e2LGYO4i3CnL2YC4g5fzETE7b6YSYjbfDFTELf6YtyIWyjLBspyM2W5 ibLcSGk3UM7rKXYd5byWcA0VuJpwlS9mMuJKKn4F4XLCZdSlSynnesq5jnCJL6YRcTHlvIhwIaHb F92MuMAX3YJY64s+HnG+L3oGYo0v+ljEeb7o6YhzKe0cynk2ZTnLvRm5P6I25Yvw+pS9hokpj6M+ hroT9VH9tBQfag+qF3Uz6n2o96JuQt2I+kfUe1DvRr0L9U7UO1BvR70N9VbUW1A3oN6MepOuI+U6 1GtRr0G9GvUq1CtRr0C9HPUy1EtR12s7UtahXoJ6MepFqGO0wo/CAZgGKcJBZAeksFW+KH47numL 5K61lLDEZ+autZhwCqGTsIhwMmEh4STCiYQ/EEYRRvpMHBWEckIZoZRQQigmFBEKCQW+CO6n+YQ8 QiTBTDARIgjhBKMPF6WXGQh6go6gJYQRND4jX2q1ezry76h9qJ+jfob6KeonuJzvor6D+jbqW6hv or6B+jouy2uor6I+gvow6g7U7agPod6IS3EDai9bTTO9wmfmLr+cJmcZ4TTCqYQuQjWhiuZhDMFN qCSMJhxDQ44hRBOiOLaJoij43Cm3PyIK+OFOgF2oogjUl9MJU2nVp1DPGgmTCZMIEwkTCOMJDYRj CeMI9YSxhDpCLaGGkEZIpc7bCCmEZEISIZFgJSQQ4glxNMxYgsV9PbIf9UfUg6gHUH/ABf4e9TvU b1G/Qf0a9Stc1S9R/4H6EerfUD9E3Yf6Aer7qO/h6u5GfRb1GdS/oP4Z9WnUp1CfRH0CdRfqn1B7 UR/EFX8A9X7UrahbUK/nqy/00xyvJJxBWOAz41GIdRBOoGmZT5hHmEuYQ5hNaCe0EWYRZhJmEI4n TCe0EloIzYTjCNMIHkITwUVw0lTnEnII2YQRhCxCJiGD4CDYaW3SCTJBRZAIIkEgMLojwX0rMoDq R/0YJ/YV1JdR96C+hPoi6l9RX0B9HvU5nOhtqOeJ9pRzRWfKOcyZcnb9as9ZG1d7VtWv9Jy5caVH v3LkyoaVon6lFXH6yo0r31ypPqN+hef0jSs80oroFYJuef1pnmUbT/PoT2OGU+u7PE1d+7q+7hKj u5q65nYt7bqiaw8aNLd3be3a1SX2Bna6I7vKRtat7lrfJURjugBdLIKbU7v04XVL6xd7lmxc7JEW Fy0WRn69mO1dzIS8xWzy4rbFAubasjg9s47nLl5sSagzLc5b7F4snlK/yNO5cZFn0qJFi1YtunnR o4tUqxatWyRsxpDgXqQ11p1cv9Dz7kIGO4QAmFB3CgGfqFu0XfADgy8EvzvATsQJ+ANOxALnCZ6O jSd45jvneuZtnOuZ45ztaXe2eWY5Z3hmbpzhOd7Z6pm+sdXT4mz2HIf5pzmbPJ6NTZ6pzkbPlI2N nknOiZ6JaJ/gbPCM39jgOdZZ7xm3sd4zuZ6NddZ5asWSFHyCQDK+O5NXJ+9PlvRtSZ1JQmfS3qT9 SWJn4v5EYZWVRSSsSliXIEbgRaBLfEr8uvib4zfHqyKUgGjojFwdKXSaV5uFPLPb/IJ5r1kC8waz ELEu4uaIzRHipIhZEV9EBCKkzRFsc/ij4c+Hi5PCZ4UvChcjwnlcNLnDnfl1EcYUo3usyyiOchkr jZOM4jojcxudBXVuY3pGXaVhkmGWQbzZwNwGR1bdF7qATnDrMOELbUArBLQMRGZjjP8C28bEMFyb rSwmpU58mPFfe6qAsfXQlN3QqwlMafCGTZ7uZWu99qn86m5s9arXesHTOr25h7FLWnqYUN3kjeY/ W1fi5118MSRVNXiTpjb7xA0bkqpaGryredjtVsIBHgbM0pI9c0nXkiVLs5dk4wV15hK0LO3CtwKG V2TXUp6ydAlgluyfEJ5jCUeXkmlJ16wurAMT0LxEMfPYTCXLT9XxH5WfHMl/Qtjv2fh/twA6Mvfq JUMdkTsD+umSuFn0dRPNTQD+y4d8p+AsfN0AG+F+eAgeg7/AS/AV00EbnAePwgfwKXwJB/G+1bAY lsiyfv03M35J/OeoFoJR3AlqiAUIHAh84r8n8AluD+FDLJdjLFZyHLIEIgN9h9v8l/t7/c+p9WBS ypqEZ9C6n/UFDgiVPB4o4XHhfB5WSuzX3OTf7L95WHc6YbHyLRH+bYrTYSWcCavgHFgD58NauADn YhWGL4SL4GK4BNbBergULoPL4Qq4Eq6Cq+EauBaug+txHm+Em+DmYBqP34Svq5RUnnIr3An3wCbk bXA73AF3wd0Y/yPO/ia4D21kofi9aNkAt6D1TrTyXNy2GV9e6AEfbIGtuGYUH4j1wk54AB5EbsPV 3A474GF4BNdxJ67s44qNWwbiP52Trn+CXfAEPAlPwdPwZ/SMZ+BZ2A3PwfO/KeWJQQuPvQB/hRfR 1/bAy/AKvAqvw5vwDrwLe+F99LrPj0h/DXO8gXneDuZ6D3N9CJ9gzj7MSfkoz1tK6sdKDXuw7F7Y x8LgGybAQQhgiK/eVcoKXausI189vjq3K/PM12MzxvkK3TW4NvfiHN+L68ljPHxdcDXuw7w9OIMD 83f0WXsuuDo03zswD58LnrI7OBdPBVeC1/PIYNlnlDSfUu7xwVoPzSiN8OUhs/PWkDn8EP6mzAzN HqUemj2eYx/m4bPM6xg+t+9jWZp9Xpbbh5bhaW9g/BPcHT7Hmeb8TFmJz+CjwfBHwfQ++Dt8Ad8o 1/3wD9xPvoKvMf4tWvZj7Ejr4Zbv8PU9/AAHcAV/hP4hsf7DUvrBj2uMBwwmMBH8h0KHrIpKTMXU uKeFMS3TMQMzsnAWgccVzWEp+sEU8xEphqOkaRVLJIti0bhfxrI4lsCsuG8msWSWwlJZ2pC0+MEU G6bILJ3Zg2kWpWT8YNkUzBE7JG8Wy2On4ZV/n8uF4XxWxIpZKStHSy7GCzBegWl5CqtgMsyGk+CA 6mPhWaw/GneVnt+6a6v+CDGwIfB9oMp/a/8O8QHWxJ7FGQmHAK7UycwNG1Qz4URVZ+Bblhb4h2ps 4HPpQOBzlh/4GnTiBnE+3gfvSePhDDwFgn+J+Cbu2CJooBwmwERo2gFGdiNu6xXsma01NWG5mkcw KoCNPQNhuHw3uqMkwWi1VsrF6ovERvO4Ss1FQhNU9r/z9pN42R1Z7trNXG/3vdJn6n/SXO7q29OX l8/MqWZFo8MFjUatltOcQnGGo6SwsGC0UFzkkNPCBcVWVFI6WiwsSBbE6AHLaIHHmfjmj5PE2v50 YXnqyKn5KpZtj02JCgsTU5KN9kJbRMMEuSQzQSWFqUVVmCajpEr2nHZs2nO6uIzEpIw4HTIpEdn/ uCr8wJeq8IPHSTUHdwgflzePTlcvN+oFlTbsxszkmPT8xGMajBFGVbg1NiFRE2YO142ob++/NsEe q9PF2hMS7bwue/9InJHYwAHpT6poSAMHvM3PyJ7mbZAe+HirPoKNl3sDH7uTeMhuMMpxRrCwcItD r5PTdCDJzCw77Pip053s1oOBRYoGQ0ZSuiwn64wWkNPiNJFJUyI9Kg/EVVZWRsaWl5kLzTixs2bO KEzoK2Dxrpkz4nYXFK48f9cuFrdr5gwK5uXjCdo6vA/388C/0FZefnZ2i91ioTXLEFM14aKc5nCU lDJaqFiNLKZKPQa1pSy/sDzZIB3nT5giGZOKs51F0WoDW6c2yaMLR9ZlmNWPswfZotnpI2JUotZk ZFJ/eJReUseOkKUzzDF6UdRbop7sfwN98WIAqQS9MhmyoQxuHJjbFOHy+xP0MTF64L9zzHEU8t/C 6RMy8IP3lvx8TXpvcNzp+GHdrTU1FsXxWBH/WO/WNOH4EvqyK/uycXB95czVV+DqQ/+MLEf/tPb8 tlry8lvQpSU5Nc1RbC4qKUzFCYnhPp4ssiKnIMtm7uBRh4JSiaN6Rueqif67U3NzU1ntaXecMirO WZ1dOqM2078pLm/cMeddXl6Ta6lOrmitv+GR0obSFHZubee00ZlRGTlSR05GZuMZTa6pNUUmXcGk P7B3M0ZnWfxeq6uy/4fcsXkJ/vWxudX8e62TAp9JBpWM9/QFNHu+RMh+RHgKwiGOtUMqOIKjdPCf vERNlXpZ64PFecpQ8/iPZtzaaXyo/dl7+ir5BedrDzqYdcdvLI8zZY8Opxu/KLKkBF1HHRO8x/nd HxOdLPAJ4i4lGUS1zlI5vavmvFeumtx809vnlcz11Fh1alHShWsjnOPm1U1Y7slxHXf6hLr541xG nSFM2hUvx0fGpqdaptz29a13MLivNTLJYY1MdCQmj0gwyNlyZdedHYvvOqk4NdMWFpfN5wi9TGzC +zcBxg14WIxwBd4k2ogpMcpIYvhPoNzqgUVnrt3cV9w/lU5jFILeQGOJMXOfwHZ0Ebr+zam5xuRC R0ZBspFdjQbVyclZVgMu7NU6k06txsvBL/TxWbxvgQPqU/AOGAWvUt/cemNeXqzLpXPGxSX0CnO3 pucbDDoMPAjpJY3xBn3cdpYLbnAG9m81ycL4/N7AfreNh2JN/Gqka6wrL9+pTslsTPEM3vP8pucf UvBuLyjAQe7pKzAXmvjFXH6Mq7DQXIiDvv/f2sjATHFvMMuMbym4uTDZPGgs4s8G3F1YId9nlJlU n6JPyrOn5yUaBP8FUmRKXlpaXkqk6L9K0Ce70J6kL8nd5KzKsxlYnMTSjClZZfYea0a8MX1gdqWk g/uMZp2o0pv0UuLBDwbtZxWWRMjlI37sF9mIivSIcCzFPaQy8Il4kcoO42DbgIeMEa6+P70gvcBg 5XsQGJx8RkpBx3IfMJfiyzJqYP8Y1cty3YYxVlXWVIviLRb+w0q3alrQWyLLy/uyzeXlLpepz9TH pz2SR/qUm8z576mV9ic+pdLAg5SeuE51MH74TagWLxp/9n1zqpc0j0zQS9oIXXjh5EXj8sYXJ+ZN mN0xe0JebdfNLc7jJ4+O1qgEUWPU6/Pqji/NdmfHuCbN7Zg7MY+dO/+6E4osKWkJ+c6UEQn61MzU 2BGjHTmV+dl5x3iWNs64eIYzPC45OjxWTkjKTDAkplpj7EVJ2ZS+BGc9FZ+rNXhfumAZzfoOSBOu gDhIFya7dc5YlzMOX2DgX3iw6PEeuNJtBr1blvVZU2S9OWmKefBpVl5eiQ/LQldCnOntPnwrM4wX mhur+6gluHMeeuCJg887htcSxSmjovizD/PgUTUjUh9XWeYqSQlXffWlOjylNLeoPNoQxUr8eyON saPLXaU2o/qDt9XGpMLcggqL3uzfO0ceYVFLWpOBveTPNZi0ktoyQhaKhaj07BgVt/ub2CZuV1lG pPfv555owjmJwzkZAeMHPDFWuNJnNNj4M3CEFZ+IV7h1boN9ilUdOUWtDCYSB+9K6C/Hkb/CR/vg YYncOQ7dcENGZ7HEFpaUlA4OUriGdq0Ug/+mKH3s6FJnqS1Csz4mK0aIyoy6RBWRXJRdXhlriGSf +csH7in2lPCYPQvHo48M9z/unF9WMt/JRpmiDJIqZkQ6H1Mh7r934x6XBWcNjMkkfPiAzYIvcPAv nmnTzAN+b+5lHrfO2mjIULw+g//E360K7rwF+DwuwCfUbvJ7/jz/Z0oO3bf5bVHKUgdOnqkFlhjl gc4whL3VRWj7VZnZKkOsmX3rDzeY9SqV3mwQnsnKUBktZn+kkBQV3ZGUGa9z5uREp6ZlJoqJ+rjM xOSseN0IR741w55h/fEL/m1GHa7oaCkH0iETGu6Pi80wOIy9QuODsQ606B3o1rfeDw570gjssMmt NRgik+ZFdqg6QPFSPLpElqNrx+3BM0x5ZDn6tsK8/EOum3H4WU2is1q2PswysjS/LFEvjfHPP0bF z2q5+VEaPZuoNqePLswamZVg1klPCpcy+yw5E09rmgjjI73huHGio6aJ15qidBKTNAaz4Q7/eP5v itbgZb/kCJ7XPD2Owu3CSaDHA9uNgwe2F9zROfqEVRks490X8vfmC4vyGZ627Pw3lqa5hb0srEdz AlT2VeI96ppxSt+Mcr4j0vnMxI+hP3/OijnsnCXulyunzVtc5/clZ2Uls8Z5l84ticksT3dNHpnm fyjSUZrXfbmrKM1cEJNdM/KGLa6KLAurHjWzviA1PN0hXuZIT66aX59RWz7CEJZROY2dnuS0mX6M kV3+2bbC9Cj/l5Fp+ejBrYHPxAulkVAMx/jiIGO78BIY8KBfvNWWxJLSlN8dzxd6WeQDrvzKfCE/ p5ed2KNZgJ+V9szoUy7BU5Wdj+3Qhx3ppw5G4oXapML66cVdD6+pn3DBzqXZU8eWJRpUYcYwQ3rF lPLRbWPSMsfNG100oSzDoMHj0u1ZeUmJcRE1a589f+2Ll4wLj01OzC9IcsTprDZrfuuZ41vPmZoR nxQfZsni/yYPV1GqwFWMhBTIeBSihNvws2aCsAq0eObL84XPtfay/B4VrRILfrA7dN6hVVENOetW NF758nr/O8oKVFyy+5Jj/d+m1i9tO/HE5sUTHELalS+cPZIm233W4xfULWsp6G/POW41ziv3p1zs SQ4cww/mwqoHtbYoWxRoE3pZ+AMmB+5V6nj+G3PjXLw7zD3qQc85BTsW3AUKlHkVjvAZOTXmUJBO Z7l8Cvsf5x0VKjAoSXjxn8Vqw8K1kqQND/NvZ+egSdVuxc+B1GetxZFoTY/V7cOANcFu0fr92lg7 39fWBA6IOuy9DIU9KnOvcOODiXq9FRKtKnSFLWZzLB6Wi7fY5sbye5l3Gvvs2oWuHvRz9fAeDj0S 8U1IZzL7b2E12DWVindthyG5wOEoSDZg5xPNJvGxYqcfP6paeVf9Z+som07c4UjP5b1rDnwqJUuj 8BQ3bktyckQc/14jZEY8ImxAN65kkaACmWkfiFfhK0/Hv+NQMT+6l43qyVsQnOTBEwv6Lr9Dg14w zF9LSovloXuoOVqtoVPegI9LVpVWrzYXTjy5oeGMloK8acvGplRZt2twlnE1NGxFcmqMRW5qmZm7 5uUrJzdd//p545e3luLHxLNSMmK5A+e1rm6cdnZzjtH4hi4mPSEhPUabmeqfGG/XGC0mbX33M2ed 8+JlE6ISk6Jzg6siWXC/dUFRj2zgX/iMTdfj4myF2BHzDL1soVubnn7YHkuH4UOupCzD0BUZPOMP BiWLIbnQzpfDfxoujBLiC2RHsguUUGGyIUVHjqVj1/g7BsLiR3hRqTDqX8NWDISDfWfd2PcYiNqG d+qNW3WmeUovGT8u2o/oD+s2pFDTxiTedMqhBsVPtEbuEUZtIABxWO/lqrsFB9yHt7pacMQN+O9b 2FoZuLeBLLy4NTfX8j/EfQl0HOWd51dVfVZV3/d9V993qw+dLclWl6RunTY2tmXZ2PKJsY1PDCSQ YK4EwhGSQLITNhNeSHYywZZsRMyVwSEvGZjMJjyYZDckmbCPzbxxXkLYYUJQe7+vqi9Zkm2cmd1X D1pq9VHf7/e////vcz79In4rcAMKvwPoAYn/vCgD+sCMm1JZZ1QNxAocYMqF1IU4gq95a35sGdBq BQTevWJ2gvifMkc2EMw4VeLqa0uwC4hhxM8EMg4ZjJBk1X/BchJaTHDrIiRKGfZBVYxknVvj/5by Ui+tlrHTtEIiEEJtkSh1FnX1a1WrwqiWA97K4O/DdRrRrgQNkgSxbAaKeuGUgLMnfLrnQ/q4JKHD 39eoF6r2IH97DhpbDb9XMJOLQePwYh3hj86TxkANUeEr0CLkATsX0UX9UOmuL0rdsjgZjboz0NXv ghGsu217VE8RNma7bZeyBinKmnghVMNUDAJsRHlZodBKuger+fvl0idNWsOlT3qd8BXKkvAxCSuJ V38qyPc4o1YFUX0Lh88yTNxCxpjvRIsxB/0zwS9ljnC7/9v+SFNokh/9SKUQSGgJkf3ox41nTwcj SnchsHAeL4TaPYpIsK5nvRDVDhA75VKjcVSrIAEfoMBYszNUyIAMH7GzVWDqGibywGjFTzCM36NF QC9dDYpMY0STC0FvmPlhMKH+hatox3AckxpDbnfUJI0x/6h2mPXSH/n6nTiGY5jUFHJ7wibp2mCE CWGvDjzcax9gS/Yq3roYqcamrW4afYT1jE2MebGXYfYjRBEf9I1rodU8Ca2mBviRb9Ti34AKY8ef BiQwQROp2OFBciPcvcQ3tpQwOdfY4tEFJ0v3//2n7/z+3asH4eNtr9zLVt+zdM8Mlnf0WCzd2weH dhatuOvunz5S7vz0f3/0zn98uNL96deeGLtjYyI3fdvqtXdtjOem70B+G+rrs1C6bDD6Sp5iROeg jqrQzZ0GKugeZbNCIe1Dj7rtdIvLeaMRVyGHfYmXMdgJYYbxM0w9nnq24+BTh/ZwWpm20TEGiwTK 3r5drL/6h2RMEzLtOZLuDGjwt6c/N52ovtiKqkhMZUb3XJcbUQiF1TPmWA/g8MwI/hni6QMFkJuV OlUM2pMALFBSnp5TOaV0GHke/Y429CCgIa7ned/Dex01UgGhtib4tXpyXSiQPYGCotdjlwL+z2Il bbnrpjXO0P7ind8/2cBdH2j3JPZ0K5XVxxoEdHEE2HbZg7Zw33BQbeq8C5LwY0TC6w8O3nHjenco oxKl8eGxOzZBQm6FhGyChHwS1Bh5FzKShl627zloLr81l1SGVRm0/YLpUCHnYw3DvEQ829FhKEBq ziCl4FX+QqM8yRUE3my1ov4YsYSqRiBsqK+4xti7tLM9Gs445URFbvPFfUN18mA0tmbmc7vazW0j GVPI51auJSXV76mYzuzRm9I9IZ1GTAoJAamkfxMoMOrqJxtkvsB43ez+4eyGUpuStEe7/D+z2vC/ tyY82urvtL4M0v7+i/9ChCCvw2D8OdCH33aGyTAZuQ1tHAHyxDkMdRlIGBBrCvAyds9j1BlbvzC8 w4jCOF59UAVj2bJITZ9EV13JCHXvf2Kq7YaxgkYiwgkJTdLx0pZuX3vIEOhbs35Nb6Bj52fHYtcN pJRiIUGIKSkV6hpLuNJedbB/7fVr+4JYx8jt6+JKk02t0Dn0joCRtLotSkfE6k76XYF0aVvf0OGx kFxnUsoNbpPZpZUYzAal1a93Jxi3P1XaChGxQFnYAmXBCRyngAAGHLN6hUA5j+VmLdtJTh1h5np+ 4XU+8mthtyV+giHqFpXyInLm/qRNdlEiQ4zIJAQuoaH7+14++tErDZa6+J4H6lf44fffBS1XANrj MPA+D5z4bdBu6fE7zpDMjHLG0jRaPZcaraa/q2lPi9UNdB/7zs37vn2si7alfH7one2F0ViskrNS 9gQTjNso7MkjX76xPb3jiTvxPXVvuPCNyTU5iy03MozP1J+D98dAfP4HvL80WPs88OJfBWYQwCeL ZMqUTpnhBeRo74sR1Tq/VlQCmmHo6AxDaxwzmta4A1V5li3ytJRy/OJmMYdoljsMzUoHQXzPhFl7 wsm8Uy6ap8g5odzW5o1223ADJvkDV/uIZx0y8Tfk1JNCuTUZSRe0lOq9mYRXJRJIVTKsbLVWZ2kl KRCpPGHsPPZ1b1DDl3Testsxr1wN/6INuqvTcOUUXPkrXAUgjqo5N52W0Wa008ZrhOnyHTDld8wY ReoZEVokV8vhSjm/4Nppy5Vt0s2CTc1QW2XV8xqZtjMXyzlkwh8QL8FcPx3OtutoNXZ39fFGELoT 7/UGtEJCoqCrR2HwqJAQQm3QA++xG2Zi41B6g6ANVWf+cNaphReqzrx/mnRCMS7MmraTzDzWzieG KU6cm4WYJXUVpiHSLXWVcRifSRa2+IMCWqvCPl/dp9Ogejl+l9KoFAsorbJ6GDurUs+gDl7YH9a7 nF4zzsZzVqiRpNqk6NI77B7TwrOorlK6+FviKPEWsr2Yv9b7kBqg6d04B/x+0D6Pry4qVYQB+6MB M8zTGeyjDJZBk4tSGtKXycR6Q/OYsWj5lRsjbnc/4MaL7jH3FjehcDvcOC1wuwW2+Yu/KsppBVa2 GZVYxfZhbKgLdfuk8Jeud4p0RQCM8VqXKMx30qampqdQxSYeRqWNgxCh81y6V0BFSMX/35vhql9I RRjIUosrTbfV3GftGQGn+2LeuupRikcc1YZD0aAq98B1pWPrEl23zB1bp/L3Jnq2ldNKSkWJSOvA 5v0dux/bEvlgS9d1WVOpp+36mEOuFIuV8lJHn2/wRnbk0LA3G+oJaa1uq9zMGBxem8euCa69e9PP 1d60K1/Mcn6FhX7FRbwJU9QvN/pZ/hfxw1w/ywEcjZ6nFw1fa4YE38VYkIRAUhRWSUa4yl8ETXAX pZVaXyrcaGydT9UaW3/RBy3qcNU9koh3SKJFVRwXIRQb24fWxXZ+9cZc//Gv3xCo9LfppUJCq1Qx GTZ1wy5zupLODOcZmZQWC54xe4wKg8usLN4+d/juV+7olhvteoXRY2qPQ9C++Ah705DPwThIS6iG lFggPA6OgEOzO6fH9yDBT+TGgXUen571+6e1L+LTQAJ982EwDcKYrUjtL2X+vb3nj6nt7NpzcLFl UMIGiuSGCrAS7rK8bJrHKqeIIc5JIFO78MaFnjT6Hx/nonAl9fYbbyCJgpaJN0atsTu3fnHzCYap OWjB8vDoFoGoNzBMDU5CJ/hvfXcPbby94qatSa8vaaXVTJ5Jbs3Wf5VaqcxgTG/1kSJCq1K6U6uT NSyH2rwQS4mAEEr0+cHrOOSLe+5arXTLLcbsodMnchv6QipifbGnc9dnti38guRDfxJb6B1qsw30 L3yn/ozgPhwzhQqOWIdfofdY2uNmh5nnwO6zU+awy+wxKPQuI8fWyReOF4RCUzHSe+i6pJCk1Sqe IdEFyNAx8KnZ60aK1yOGHExRf/hFfAuYATTkRw924GfPHtDDa4Q8hz8LnXYSP3x2ZIYS7h00zyPW Npc8/x6M/dE1ya5CrHWALDZwZrCiKgvLyCk2WeqpRc2Nys1C6h1lg7DlMvS/gKFmUi+COT30RRco WzoQyLjUouqbl9BkYZo0bd39MWjCpGKtK8m1UZXy6odYjKZdME1DflaGvVkNXEpVqMhcC1UffYRt o9XcR1EKt6b6T9Wo1sbzJ3xTeBB8Atw2B47tHiXm8U1zbG5UDtP66SKV7kqPwuuYltkwjx8uksfK H0yse2/oNnYf4mk7mMYGZm+upGHE65iVd7FWtL0kWumfx6ynJANc/tiThn60TiCX8HDUcU1Z5asw bzuvQqrWgB260hrmKH7Ut9AkqIeSzGKTftXcYh+ZDJldT+zc/sh07O8QrlrNK7EOrdOoFotIiYBS OWMFe/km1r1do0WQb9P4Cj5P3q8zeKVCXKtUuhOrkpfYs1brV9xzEpJLnDX1RnoPTibiG+66boQ0 BGy5ePXg1KBYKhbrvNZIQiWnxczo8R3YmXjOFjCQmejqiF7vL3jC3V6FAVnCBrW8JXS12kxIbV6E 8rJhGBu8JtwHGJiFPFrzI5SlcA5HU7lx/OYiqXENUAW/RSAP1dtH0AEPFqXGocYYyOBcUV6BSmbs qU+CcDUaqGC8O5de40e09sRb/TBUsEbkTTRUkyMsR7xGGoN2Z8BErf7iph0PXB9I3/DI9PCJTtQo 9yWs9IfZbdlkKaxTB1dlzMl01ummoFoIoEBvG5oYvXt227EX72a7OrDfkEpKJKKU5EJmFZucmGnL 75lMKdy5AEJtCKJ2FkZUYZDBCB61WY3GFUE7scMZmNJA3FxERBPBLZFXBCh6MciwChAoBXh5TLBF gD8peEaACwTWOARkVoFV0GPRCV8Tf4cZMv4bkCvluIqQS400VpEa4Qukfypaa941/AaMWC7Ugpep g5unwhc2T6HsGMX5cQ7v/6dfzXXURR7XiioDf/dnOZbExNmgd+HXlo6p3r7tgwkFNGwELpDI2jcc 7js2e7yj++g39xz46o7E+8TG6UQpbsKxD2ORwlSvW2PQiNUuk96hV8iNBlXnie/efuylkwN9R57c 7Nxzi7drMg6tkOnih/iXoBfpBAdrnOiVwIKcfCLkI6GLmM2WzMx8c0zHcbaYYJ1lJcs1uvneJ8w8 0wvn02iw5zmYl1/Ve5ozBbwpabU9zdy1YXD4aj/+JYGEhFGAyW2w+M30X0s5U/LXtDXl9SZt1AGN Rgif2u+tHBv3DwRQXvKezaMRiyVila8jPMGbhIVY3bLjP+HtwPDG+zbGZAqZyc8jIvil8ATYCjbO lUruSS867iBG65FVJte41W41KKRjEgjN3IbSJDuKfugZ8OjjcJ3PFthg2VqmWa7qeiGVQtEOB895 ZHrTXI2y1utomM3lVu5aEQRUU2uxuTpX82nBL2UKiI1T156GyFBCnfrrdV9ZPUPbkosw8lWOjEUG TDQECb5LbXRp21PYMFM5Mh4umSiFRCB4PxEQSUTs5NqlsC2FsG/DvRtjCvhZJr8tCd8nHpwsjW68 d2MUfr7cGOBxFQ1CSdsHts+l07kZLQR0boPd3k8hgPdFc/DhbKXUP6MxwYSwMrdraHrAjwRwspSD bs1RJCtsVznKmmqhSQ+XJvbUynmvp/lKF8KY02jfyqGjSPTxpM5QC0ZUtahUNMjBmrBTah8KHHN1 lAW0mPQFw4Zop0f+ed7NPQb/5mvFPbDu5GZLdz5slBOY1JQMeuH7+u4Z3HRbxe2+TLh4twhiSqh9 ncEVpbiy4b6NUYFYKqWlUujokB2uavhIFPD4Sx6Ccv0YeGju3nu3fX47xPvMgcnJ7so6pO7bHtsG s9stRWk33b0NXgfCiA/HicMHPs8+hGT8joHt6w4gHhQn2D3lqXKFNZgLZR+a06vMmYdUAyX4qlPC Ehfhc0F+UwcQP7XIEYUf/FwYl7ryyrAC0JcJ/6/A4cfQH/z/BDlKchGjTIBJLMmAL2Gje+8Z5DIE W4LPEHwFJnFDG805RBsiWuqJRPSQaMVjpByp2hdaVO0Sc7S8qgkUSD0gXxIZdSlfl88cRNCeESqm I3jNmon8MbJzBJQHDVgLxk6tBufw7wISOKAurh13ItnIJiLjbAVpYGfJCZNVx1w2ocAU89itZ4VZ limbODV848KU8kKdY+hPYaz5D0ubFsRVMLMo0dWhdq+AkDlzwWDeJZO58sFgzinTtKK8WLF85cOj +mjATomFOKUUKXRWXVsC+5BhBD/ypR0ymSPt86accrkz9efM5fDirBZ0M5Rc7zEn/AKREJpAl5dH TDTMIXYb+NTc2Fj0OMJpLjIVuRHM48+fJSPwKnCn5Ny2KYr8hbS/q3CcraE2KxT2H0aatK20iV2P fhgciDoLyG30s+lyHdCG20Ap8VQd1nra9Q+c7qhb2+WXxfgycAuWcSNLORANy1y5UDDnkstduWAo 54Ic1LSgOncFmV/N1ETe5NIWkHeBFOni/iZFNm02gf2Z8V81RSuIt1y+xO8swyDvg1LQB+0HR+dW rYp3s6iKsQboYMYsAl5oBeN74+J5mDOr4vBa45nHn50zbV6/Jo+0YHuJXYPsn2ozO1LuZkNlkZe2 l+lBMFAvH9d8Uou142zdQupCw9Itblnz2a1umeT5GnwUcQj5EowUa52oauuQqVBWG6doypbicmdx M3cmKAnljYR1iz3VYgo5T9XVHqp5KuEBZKE++sMy2SxNyWE6cGna/PFdVs1L3QJ17AvgvzwHTuJn z3xuerpjbyeyR2w4rPfFka/quLHj0XOQubsAhTyW/hZ9B7xYEtJVpMFEmb2LEt4/+Al0UItt7ubS XnYn+mH9QGecRQTSE2xfua3sY1WNUKKhdD09tXCi6a4gfYsd1kojCdfsk5ZXxaY7vEReJLcgRoNp l0ZUfauujJBR0sczetUuybfYI/F+sMATbub9ICaRQHFC0yYyhQKJE025lmX7mrySrFVtKxvu3xhD /pCm6/5wWWnjpYT4PdTjMdA/53B4BkgUQo6ZPEhMCun48IAGKWxPydMIyk2ssG5dG77qjZpS+v7i yJD4/eUVa5kQsKlYXAjo/gvUBiFVi/BEeag7x8BNRenkZCLucFA8Jlvi8c59FHJMx6YT6ImBYufN HEhzO0rT7Eb0Q3kg4enk4uwBNltuQaypGw3Y+DgbgqdSfywAr1kFRPlG6EVKSe9/hJzDELwl3nP/ Bwry6NLAjmPnX2FeeRzMgOlTxSEUHdAzHg/IzMzQA+vTANk1vZIemcdKRXK6UmTTbHu7PoqYsZaG AI3qfHpWVAY1PiDwPT28r4GUnEeMqOuzf5dFuTXndjWKDVco/WHfWpJjl4+O+4c9cgmBUnKRyuQy oE0S2ASfG9noep0v2lmr84mFlMYdz1pRnQ9/f4UsnPfkrUn7D0glmo5Wkj+oVfSmBpsVPbWCEjGj xyewH/IIixko/w+Bz8x1d5tHUBnjjH/TJtmNchSnmUfNt3wa4a6T7ZOZ4eX/JEiG/bewN7KHDiV3 IKTXlkZY6CJsZ3IDn7bI/ahykWRdZW35HkjLKXGFy216uL0ntQith89tWkqrlyY3jancqw/LlqPo 4zEnZhDWOeswxLr6nZX1A1VKgqwXVUpaCyvYsK98dIIZ8CN6xRSk1+jSW9EfJigb/1mt9JpUXBn3 RCsfl9eaIuKa15oWrkuVjfdtisrkcmPAZvVooCEUKX2dobUriwAggKX6KPE14qegG4yAaQzU9jmN KhJiIu8ZSg+9MkQ4hrChX/+Qxow0Rv9wErNPYsZJbPIPr+swgw4DOqUOV+h0W/LEnzrZkDPS93wf DvqwvtfzQ4qNmJLY+FrROcrN+U9vnuq5MDUFM1uu8Yl6oPDXqTe5B7WBq9uubf1iagi78nc3v7qz 77U+XNCHKS739ZubN7Do+/kb4MqKnnpMyfhFMKDXG7ict5kt5FDNP5urV/71BhjoYxmm0ZNFM/CM 3y8nar8RX9Mrd+s1ma33rQmP6GhNOvaz8rHxcPvh7xy5+b/ujKtcCUc4ng17Qrkb7p0IVVyYRaWr vjA26Mv71GMlJu/TdLA9s2aHRjSzqTCS0BJbEjFjl2vklsmwTi7z6m0+XEL4+jd39h25LuUtXt/m 6sylDIbReMdWv+eGwZFb10ZJaaT6J3bMFC44Vo0aQ7mF66IJXKjxOO3KVMbAxLm6PJSE14i3QBeM C6ZPp+xj8/jmOSCXgwFUXJYFbGAiP5jqHrMLPL3o4K3o0PA8trpIesrkv2k1Xg2umb/4q2fVOlZj /JNwFM3Xhw9e4IaVDYUeVTrd2m/3LTdF1LZoNhk3NHR0acG995a/vbFj92SbChVzRbSYjrAz/e1r shZfb+9qf70GHygNsEHKFHA4gkZySRU+fOArWyKUWitTGhw6O6MTqw1qfWq8cJ075VCMnHxm65Hn 7yopve2h6br6Vd9eVUqOb8/k94ynFO6sH0UNn4Cx1E+EB0AK7K3vn6FgNJUKaWG8MGsPmZT1Si4q yxWlxeiQd4ArwnEb8sxoDys/ZwbF//RVvXzRvr0lpZ3GxFCtCkT8pG6/NN5FVZj6Y61Wc5nymdBT 70w0K2I42HvxQ+wB4QjQARfo59f+EtDjLwErlxGSwIHdeqZoUg7yN/+muT6SaXlu6Z8Wr6m2BA2K aZCuoR7YiUvvW9O9Zm1H19o1nY07J07AQBfeJ1xDotyeHyx3FHiGsBPEq/W57S1zJPe9K89tL/mm 5hfcVv+pxvw5yHwGbK2vPgnX7QY0/L8eePCzs9Gonsuq5EWgd1PCwKB1QNXgksuU3jBzhQrUDua2 wi33qhZsLj/Czec3xLlafgMz1rcuXQpKSFxJmJA4aJiQ/BmLwYRkua5tk/Llk4g6rnD9OtBd8xoK mQ6jKIwiMRnAKAEMyracKZLKAX4tWBzRzI2+TFlm688uS/xlKGjeWO0eRFJos8bAN/l7OAXDchgK 2u0pPqnp9p+DbKSAskWrTg8Pte4vr0B6eoe6B6L5wWjZ1Ap8rS8I5aTA7YJCW82h8P4ln3UF3V1J mXW18bJ6PC+lrWiM3EapPG2+6KYsV2iFMKncWW9sU0PFSXPQ4QwZyKFHx3LrV6dUgcrwsP/6E8PO Bpy4KnqJsi99pin1O8fGDOFOX7jbr+nceX+lYf8gAynwyRoDIQ2C3M6ZQWCH9uz3sxRW4ewaXbdr FLRrIZN3sAGRmgMozA9E12H+GG+8Opuou5JNbAD2+OQVbOIiUCAYW6FFZC/+ViCAWKD59P11m6DF j3BT6kfQlHpNUkzzmLkoVQx5jPwJEZj1dFFYaZxq0LSTV/mGlm7ginPugs4T87cee+ZwvuvEs7ce f+ZQvrqgS0325KHT1CfXdBfWZM3Yb29+/t6hvk/MH735hXuGej8xf2ff/olYcHR/CT5GgyP74Ro/ UX1MAOAaQzBO+Hyte+/KkohyHQjjJ4tSoCOzbS6BMFHXi8Q8NlyUMUOWQeVogVtAAR3x2VxAD998 r03DI/bPXuNHtADhX4Z+Xn3q0IhVei4+EwAYLGz293Z1OhtyYAo60G5R//DIZPyG+9cFqh+qgv0p E4wb7G1bMsnVER124dhLd7MKR8xR3VQ3SYK360KxO9AV1FbuPn2ssHsiCWOFQPXn/YOp8R1cnPUY F2chBOvzDw4qjOYfQiCN+vg63yDVFXYIlLH6+mPc8IJ5KM+tPc8NLygrwtGV5x+u8SNaJUl19fEY MkcQN8q7ahUbQHhltj+yxbdq1WAEhl9O+3LhV/XlOmrY066kQ14fhFDATGZrI+L6p9okxN6J2iQE Z3Hwc9xs6U01i8MoUOuNBmYF6SDjJCEjSDRpAI0HOY9NFslieIhR6JyDujK/6ZozGdNoguF8zdaQ V3z5JQ335YwLJ10i/JxAIiMlWpNdrQtFoYm5xLR4uvN5q8zuNFJCAU4Me2NmEuVv3s7IwhtLjcv+ VC+jIMRSktaF4NoHL/4Wfw+ufRC82zwLIdY4C2FVEUYfghgWeycHnTD5ripXRBY058zhBHeCgaIT 60THRVi4UwzeQScYDOmVaMwV6DGlQP9eXaMgOrVjDKa4bQDTU2ElalVNLToioej8z/2yazg5AX+v sOvBydRGNqGnBRJaSoWLa7PuNr/W11UZr3T5UpvvWRMaLUY0EgFBiGmJlCkMJ9wpp5LpHh0f7WYw e/nwiF9hMOqiEZtHJzbZzXJzwGwPO63uSHFDT3FvOUSrdQqFzmGwuLVinVEnN3u0jpDT6ooUr+c5 En5FeBA8Ar7wEsjjMTADNuGrQC84gPfPeYOaW09yVRSFSbGvd6ZXo1BoemcElTtB5VZ0UK21aD0y kN+0Z8D/bmz43YkYvNal32H2DK17b6ByUoHmYU3sfaieIuXqKVxBNt3cq6FC8srtmTwP9TkeR0P4 /Mza28i61sbBRSuPpOGXIqq7LAMtg4crFFOEX8FFEoU7hkpXJc9utU5IKaS7NP6Cz9Me1JusUkJC IRrKrTRcnsS2tTfmtG6Fydi2+8s7tj2yJb5cOcXq1snkjYJKfWRtVVSvY7LOaN6cCS7DX9fl2e/f zfqEAm0/U7xpItY6J9csqUAJMFz8V/xBwSnQDh7mtfRZlUrWEQQe1NU8bZBF6zY5isqSHtYmqz8h Q/wa2CQaRyyKee2Alvl1LihIL6TOp/iSMTRZ0Wv4DD5KWjqPeDn68AcptadWC9vLzxfuubSKhYYR EeyUSHgiEtdcAvpl6k8cVkKn8DjYDjafmejtTW1Pc9oxYmVSIOWGl2z9yHZ282ZRmhlBC1vP5uDC zrKVSNnK6tHMhKhUqyuiyiKqKUKkztfqia/XJoZQ73BxJbDmwlYos19+fLMOF5HzVY5OMCU/mveR SEViT1BvDZhkLeNDXOeiuq8FoJXRJF5uTlJxdT2ZdIW5q9Yi7mXgRv8mK8RXsEo4gjPY0zAMFeM+ bo6Zw12QgDLaC3pOx3uVqMIbttvDCjS2QrSFe1llGAlWRxurhXjP+ipSrnbe8/oFdDoRP/gHseWa snrdtYD3v0KuRmV1fwtApNq7IkBe90dPLw9DVLcyDLyUSQS/hqZ4Cq4W1bNPh0fWI0nTy/pkVniB tvAaMML2sizbsV6O1n66jVUjHfJVNjXL15yQvZ7iCtfnUc+gMRLMYbGoWq1fMpu4HA5XKEULJZTG E8tZUNm/emcLTIRQrHTHlgcK+2RTQ7keT2sb4UQkppXTNaxaILS69AqZfCUQP6gfKfPBChZP/ATU 4gfBPadvONyP8N18px8JVd+RPqUZAW1gPsWM97Uxej3T1jcuBLs233TrTbfuQkOSRfLe0p3sYbbf b96MgN/FlhDw6yuQhtKZzgo3+8hrON896KmdgIA0nXdyLc2DmlReaTpyeUG9avF1Lf1RIH4CVftR G0Bv4c1Abb6yJuX7WlggNd7lWCXVvityij2KzI6P9SukxJUmNFtVJKJvqMhVak6T9GZ3ibcpohc5 mzLH2xRhsm5TRN+CWrYH7Dzt6B7lmnR7Unvke6am9sgJywgSi74k6tWd9lkmUatOvr3ClrvZJJvP h0eBBZHvYwVI3XS16IZXNq5Vxw/ycHxzRMe5Xt3Hp+sq7BX29VaL3egFrcwJXgy5m9bskqYdzzP+ /gq9t5VRX9nctbbuIPK3oJl64lWQArtrORHl5wfqHZAEhSY66KeEpkGvsV6nWjz7zp8BAJNHLneU X8Wrl5uTv2SzajbXnJh/DSXULpgGDj0+sen2iouDDSZF3GDg1lx9Ut7dWlPZdd8OvPFEVTLAFWDw 8ZYKrPPih8QDcNVxcLJ5Rtn93BlloaKUP6DMQNHz+NYid/QnoafiwONBp5WdKcpBkQoOooPHBlXN YhK3idVsRO7NBCNno/IXaPxcXVA3D3OzLP8+7sCyWumBP68shuc0xDLHlRHESQlmbU9Ecw6F4Kmn BHJbJhTJGDHpB+9IMXMhGWmzy4Vf/SuCNkf9kTYDRr2dUenlQkIqI7Gu6iukTEoI5XoV9iz2FbVJ LiJEMrL6JhaS0DAKkZu01b1IIlYDgP+OeBmEwZO16iyp8GFKhQJTiaC3f+6sQwsvtIf0hdNSX+s5 XdAcm1hF45wu2+micHiFE74ABGfzFASk8dEf55O4YvDmqaXHfi2zPRXGob9DKrHwnMVGSBU0NlI9 rzEIoc7gLrlWJhZIoIzMYVukSkq00xY0Sr3BmNpmsapwQaIN7cMWKa26pNZhtSoXFiR6P8BBFn8e nxHaQRTG6d2nxbr2eexv5wCaKZjHvl3UKJxOi+6z8Thp+WLgYO4x8jBxiAuAuHo9DCk5HGrtLIxv VKywcbOZH7Xu28RnmHDU47q+KzbS7gqMHh1tI40hZ6Ar6iDVemX/3iK7s9fxYps76ZAF3M6kCf+V XEYrGHfAAHOY5EBUZ9E5dKRap0qEDCa73tQ2kf+sRGVS2+xWK+Q/j7+Am4VWkABtp43AN4+dLcpJ 3V/9GJ2J9XXFQeKpyPzFl1G3LhL4pvgw161bdBoWd9JX49Zb0mwRf/+cUONmQihxry888Eh07EC/ JuT36Sl+k79E5kza8t2dnZ4sQ0ulAoxoU5tUlM76pQfHjlYYqMAKSmVQy61GhcisroyNDRtcMoMT 9ZXaIS9fFlHAC9pA6rTU1HYOewYasig2V1SqHPtMUiLwN/qDqW/TLYy01L5qWwOubvcOpOHL7rjR oRVHt3aumiqYXcUtPbGyDx0nZWP00r+zZx2WgJGSGvxWS96D/0auFEgocTaaSI7f2Mkemgi7XJgO nfJFQGNfHfIy5lDWYs+FLO5wfS33QxnzgRjoPRWDnu2ZOYtKZWHmsb8pGoBFLpcKHniGeZnBGcYY fNR5UPq48XDzGC1OzOqhdu1UqsaeF71uEUXNHS/4/RZL9WmFJx8M9qZd0FyQFiY7EH3yq6GxQ0ND e1c5nyfSGUvALMeJDxx2W8SukNKkweO1ySFvDz/OHhkLB0pbC4Z8l9oRMkNZsuLfx14VmUEWxOfU aiCHadepoirEuCVfS9zkfkr/VGi/9ZB8PxeiXeCHamCq2hyybaRa+uUmwrLN2Q3sVVwoFopcapVB IdooV8hlU1K9z2bzGaR9cvhrrykznjOlzKQIF76sNcmEpERtM8TtoaCrulNMoSyMEmOPu4Iheyw7 mbeJJaTKgs7GM2Lv4UeEZtAJymAjON5LgXHsMyAA1NhD0EKuxj4HkqALe6hIisNJsTgZJnwV9M/a AcsaZAucPsEXC/sD44/p2IcVMTGRfYZ+mcZp2ll8OHtw3UPOow3GYHRy4e0LhZ7auVx8sKLk6i7c kQFXnC7ILhkugP+Jlw4XiES13/AjcqqTknqKm/KGkFxC2sz3tI22mQMjR0bKe1c7o36LzWc32X19 m3K2tP55Sv7bSEBn15IRv86hJR2M5wazKpNyh8yk4EceB21RxNiUSSKRqCiFChfixmCnNzjQZtMx bS5fv5lOWt1dBm1XLD6YsYhEji95AjKdTeFhaJ2lul2vxwQ6q9JkINUG5IM24N/HnxTR0AbFTwXU SI2tgIKiowBWVcAgPxU+6N5nOCQ8xE8W/l/2vgW8javO98yMRqORRpIl27L8Hkt+W5HlR/xI3MSO 48RuHTu1naQP2lq25VitLKmSnNitNw1c4HL3hlK6UNhSaFkKlBZok/SRlpa6JLhwcelSCgRainns ttxLFxc+aC448v7POTN6OE4ofMt+y7fSP5HOOXPO//z+z3NmxhrR+6Epz8Ohe4rKS9/eZu+DWC0u Ag+privYXKoDdymqtOn1tsqi4gqbrnZf/dahJhv784R31Le1lDviX1DrXJaWRq82/rrDUb5tXzuO 20Hw+DrIQfjetvw07B1+DdAR88gT+tJf52eFCeTXLnjEUAJca+qN6xIxl7qwmIc/c0Wju6tzU/32 rk1JVGyOTg/7AkGve2pzTXVTc021qr8Pg/6a0Vbw2AbmIfzsL9CiDTmZp2Dd0jNv4I0NvmccLpq2 qJpUFEmfAZaEV8VtoMXW5L1jIdtmYz8swkatFNI4/+n1qvx73mArLy6utuul7CP3G0UVvaRj8uP/ soE+m75NvmwHR/TFRXfFVwvyqExMEchE78ZDOtRnTRPcTP2GqmSK1uNIai05l6ItjQVy7S7UebzF icPX3WGhTreLebgzR2863nWzfLz95o6WmsZwTTQvRV/KA6Pq36Q3eS/hfuvr2MT0vqJNvTursYi5 lUXYJauq8xtLVfNX1BQ0JvzTWe9xeLybe/fb8xvqG/M7rmzIvbiPrq+zuSZ4tXncjbV2R56h/LKh dsVb7gX5XWjT8XJLMtpMqMj0SNXN5XlyWBXZSjKUcqv1EsImhcORdi9+2mJRJY20EkjMRVSSeqdn vKVjuDEvTYJWQPzABYgJVha1w7r4NGDNhpXR8TTKYR7H90hhjyLq8+813+z8DB+71EO8hLSbm7CR c43MDQwfHiivGbp1ePDQQNU3DEVuZ2l9idlQ6HZu7eJ+tys65K7uD/ftilzpqu4P9Tu3uvLz6joq K7fW5vXjiL+G+R37FUBUiVpR64lSjx4rMBdVMU925qBcvae+VMO7vuy4uTCcNdP0CIW3nfxtU/K2 ZSLSctPdOKFDQbkznUtvPLJfKdt+w2X5tZUVuapf6LJL8zzO+onLOq9tK/gWZIyiwhZHyWbQtN3A /a4veqVLtBRYVvAFbvwnh+zrAoQBaNbtqb8ysLukpS7fUXNXeUV+bTPefYBMn1Bk2nyi2NBKd1L1 zMnO7GxDa1WxxuQM137RfnPzl0wxfoZuprYTkRKbqY2+C524F2jLFdbvpnA2LoSdU93I5s6r2woc O0a35blcnmIhp9Re76D7qXyDaKf7KYsqyFvlDnVHJeY6CzZTsZ5J30/R7PEa2bNXnnQUIDNEeadU oH+u6maHObcknBtFSjgz9efPWNvTLwNd6Nn0gbzMayyvFwS90WI02gtKLKkxaquqcFhNxTkCx2ie LSiDT16js5ba4s+ku/ZWGCBqBJ1VBpQd4N08oNyOep5E7cydj8ku2SXln2IefBRJtbc3kN/5s+X3 NrTckd/OV9ysv8Niu4Mnm3DyoAi8F9/gmVspd2Ba4OxCk35BW9mbl2hYvrpntN2xraFUArQ6rVhS 2+p0uqo6erZWl3de3VLa5ioG7Wp1vLawuqm4sqz2st7Larhb63d78g0ms1Rckm038WaLyV6UV5Cb V9PV4tqxKU9nMBqKSrPzjBopSyrKsRfk2qq7yN7waWaRvxc1ItdJ5CytwhbJyjYbSkNVn803fDY7 VPegQGP5BfIX8GfOn/lxyunF5nVbwJRtIj3PwG3Mos5od1RmHxztNBlNpu049eCMerMJqpGCsvxS nhdgISgudhhFgfeOr+IdYAx8SKOBtxjeHy5XlEu8OZ/40NPsfXwO7Mg3HRedNCSKcZ60OEWuJpwX lk8kTi0Sj+3Y4MQi5XKHLe1qB3ufw2OXrTr3ZGvHUGOemEfWLbGmNr+1BCKanFioZxLtHk/5tuF2 ZgA7PAdv8Zda28odzAG1jr1ehsz+AfIs9uGnkYN5A1/hwLkyeYWD+eWjNkO9QX+K+b+Q752GmrDT wBeHLYl8T65rfJ1c1yAP50q5nsGoVy2qBPWqRVWlEuZ5yv5AENj3aFnbpkpnnV3P7ruWk/Jriqvc Nlb7jx/UMrmuSmetXc8NDXF6W0VpRV0uw7+X/X8GOLnBP+ny8MNaEayjMxoY0x/0ZkHDakXhU/dq RR4aTYbfg4TN7LdYLW9CVcjzJMpifvd4SQ4QcpxiqzoNYpnl/vyQ2flZPgIhsgD/Uq9BMGlXD7Kd iasH+JnhWoHAZ7Wga108Zs1lIeGcftRo0Whh2xLNtejNz34TIpnncnOLLLqCAtmYbbUaGLOzAupC dlF5YVlu/LfarCK8RiBugfzFowFJKAf/LeGzj2pFDn9d/bUXlO1Lyr6P+aD6B4rxqGZJ+XvE+EOY j6aSuZV/IMnnO4TPxEX43Lp1794tHXv3tsffx2/a3dbSA//jjwKff117i0X8FCxTNagUdqnsKSSj XPb2xw18ReGeLPzFuh9/W11ClZ934JJ/XJm+pjI/ZfT5daVybb6eKZBKN1fjp7zyxrIW8s1R8k3S ljIj84D6VxvcMWOOUSsYs41/HKxpc5jNjraa2nan2ewkO+gX137JnNUECTa8g2b/iWD7p8cNWbWA zo8AWtaZ9es7l4ypdei+qs+rkctq88QCsWhzXV1TsSiVNFVV0u89VlY1lUjMpGjElwZhZ/qyKRug Sdmm1eYK+o3Iispm/NmMr1JzTczn+FlUiHKOZ6FT7O0nrYa83Wg7Vv0ixSIkIiEx/+d01qLc9wsW u6OguDyL4W/JcjRXOBvLzLypqmtLa/ECeY6b3mJgcj7pqM0ThLxafKWcuwPm+h6r5a5F18HcbPw7 3H7+RdBK/tOgjT3gAogdOKHP4hG+m0FOErOVuZU/6xRW+aziurKa5kKNlt2vySraJNc2FWj4+Hlj lp7XZeVbtB8yWmiJXBO1cYLmZ+oM7WSG9vQZ+HUzMFbOXFQr1zYCW2ZFYyqqgynyOf4MjmDBnGfm /QazqNFCCWbYynyIbWOvQ2ZkOYEEw5NMGdIg/CxT5emJZdRzyTW7Nps9Pppvs+Uz90kWiWfe3uKu b29z4yfygna2sqXA6U1W4CKQg+8Ar5njJtgf8YdVj4ZwBfxlrPbxGr6wcncWWGn7C/gK5Pc3dJrk mU4l3Z2wp8VcR0GhM0e0S4UuWXYV6uMBMcdZUOjI1TF5DG7sauBuT/xcwrPqRfh4V3pbbi5i1txr r3Ff5BsV3cKeFXTLPJ6u29a0p/3jy70aMbuourisysIZuLtFazEpa/SCZNZrdFm5Zs2v8V+O6bJs JoSy0CS6RnOtZgAJoN88/Ax4yPqtsJPYjQbRAXQDOohC6DC6DX2/M7h3KjASaJud75ivDsdcMXl0 onxC19sv9aPOnZqdWZ7mnObAfGyif2dz887+idh8QCi66l32ossjhwYO7bjlyK4jjTcGW4IF11xf cr11aL9tP7tlm3abvtZtch86Erx+/za3e9v+64NHDgmVk2OOSlT/Qv0LFuVum3Jz/dJvDB5h/XNG YKM6HZubmxqrlM9s5TNP+VSPC+vq6z/XHxds6fWKdfzV+biXPc3Nno/gt7ebGpoaynEp3toIry81 NTQ0sUP4/XwBbmD/R6Lv+S97mhsby5mG5uYG5nl8MP4u/P427v0RXOLugjcP1OI/aGpq+AlUmI9B YT/mdiu8Mc801m8+3wulj3o8zaysdIoLUHgDD/ths6fZDQX8xHB2if0j/war1Z1EOI5m2X9mv8b/ AuqPkftwI+xp9jT/G9SO2k/W1RmLTzEnOs1IfyLLfaI6C8guP7v5FLt2wv4sf4qNk81ZyrNe3zyD 76xlpz/uoRI/9TZ5DaqVnPCSi/M0l4w0eY9ddfl1JeYcg8ZqFqwGY2lVY2nT5fU27/XlzZVFRoNV MFs1hhxYJzZtqbrmg+PNmqFr/zF0WZlFNNvkfI+s0wo5VmPFjms2z7zbaM3RaXWyJ1/OM4ui1Sw2 T35UkXMnkftZRe4ljYPIvUDk3gJyD4Dc3WjH43Wfb5I+a7XiX8XOyettwltukzm7t8naZM1r+9xl BXwliH4i70HQwFraA2/r6pRtkZpM3BxZiNdvu9nUJ2HQh3mxA3VXHLxM3t7qNhqzRM4giY7mXe4t HQ19+/saXP3jbYUdzVWCRqthBJOu1L3FUQIn0w2XH7i8gXtq23WXlWqlLL2YlSsXVsIGO2dTmaOu orJ9X1f7vvYincmq10qW/JzKkqzsLJMtX3LUOctbhkFqO/sCe4J/A/LEPrw7/BLZHd7ZaXTXOw15 GrJHtMHZLH64vATtelt9niHPyfE1xfgXvi2Ixwpo2g56abc0JZ9RB1V1f3jhz/BsfF+Lvd/A5bjK YWsuce//AGe0VRTK1VZWeuwBicuG9kqbpPm7OU6yOYvkmmxWeoAz5uab8HZQxxTG/0WA81mNMd/G XMV02wqMHIsvqZ9nONpekBt/FqS1gLR3g7Tl+Ln4DPPwYzzkZqHgK8yd0GRhHuwUBW2uBFu1Uukp EI/Dwm3H3+20tqvCXVbfZK+nD3CFoLckRclTfnOnNfHDQk/c4P2BxFlrHUUVdqNmUCqUGEO+cQ8n ZpcVODfZGDgnj/+moIAxMScxYk5rEJ8p2uko6y56RoSzL85YYMNPH2a/w/byv0BlqPGkxSIYTzFP nkD2Evh4VCg0fjkXPPGkvuTLGuqKytNbf3zmTav6qKMyR+q9Mby2Jp/byvZaDPGyRhZ20ow7/kOz xWJmFho1OpM+/jLTY7Bwpc661hZjTk6+hflinbOiuqHdYrfZs+JXk98bUXIJKK8KdXbmVcD5la1S Mhi48oKqisqnjVWlkqQtxZ6SjbTUU6gyAST+XTL7C43gLuSNuIoSEonfvcEXs7OVHynkmqrYt3i+ arOjOk/HeeLxTZyYU1naUKnlf60x5FU7K90FBv7lzw1x2VKeNleE8x/d7X+PH7FsyOHzjOxxySSw IKgxvuc8vqqv5D1YJ2XYL/SfzLUWV36FeQXpkZ159aTVqi87xfykMwvpc4ufOlpxRwVbUSEUPWXC gV/5lKAEPr3T0k7Pt+vpoyaI1vEvZDqVny2h56SCzVbVXEl+56YlWy2wX2updU33vmh3OOyn7/xg y6btQ//Wsr2uub2pesee9j3tO7hnt7+ruLigoIT9bHHBmH/zcJ7l+j+6Kr/cFH+1uek5/DtzSl5D VlT8JDIzr+JtFQZpPqu4hPIrCOruSrl8YYE3dqfVGr/T7qhtaXa9YbVyjnonTPScyWIxnf+CTHiT HInqwLqiA8kmXVmZTYu1BLsN5pUnbGWCmTNUFeD5sjkDma+JZoNkuDS1W5N3OS0ceU4tvpysTepH zQQYmMZR3ra58jmhqqmxln8SoquiSr65pK7EJt79KTG3sDw/Vu1gf4U9lZXO/8Yqmc2s+fxvSf2k w2mwldvjQ8yX8p15BqcD8vraU8KX2F26BrC47ji4bH2Tp4Eryy3bxR47H9M1vJf8HOunKDFXXJR+ xR75K9FSkrgP/fmkufwvopf5bQl6hpLWeVG6V9Cm0BUKPbgB/X/dTIK+S2gtnUR9go4AnUySvkb/ kRT62cZk6AB6SKpW6HgKvUXJ2PUn6aumrAT5KZlHLkG/TFLWU5a7rYeth7OtCv34QsqZxJRrzX3J 9qO86IVkH7kY5VcUtBWcplR4Z1E3puJtJd0Jek2l0msJPXwBvZIk+VpCn0xS2fVlv0glx/6L0NuO t50fK89V6PUkVbxBqfIIpSp31ZYL6Hi1t+aqmon1VFtWe8+forraFPpKKrlqgf6n681Nezcddwfc 36yXgA7Vf8bj9Mx5vtbgavhowxuN1zc+0ZRF6N1AL/+n07nmogxl6D+AbkyjJzagN4F+dynaXLn5 QILmN7/vP4heztClqUWbob9tarX/SZJbq1s/cgHd03p/ktpKE3RX20r7tgxlKEMZylCG/hvSPe33 bEEbkHvLHRnKUIYylKEMZShDGcpQhjKUoQxlKEMZylCGMpShDGUoQxnKUIYylKEMZShDGfovR5/O UIb++xL5Xtkm1oHwdw3hxWaRFo5819hEarjMIp3m+0qZQ27NI0pZg+yaRaXMQ/k1payF8u+VsoAO 8SalrEO1/J1KWUSycJdS1rP3JeYyoP3C40pZQrU6SSkbTVpdi1I2ocuhD0OwIkZn61DKDBLydipl Fmnsn1fKHMqzf0Qpa5Bkv1cp81B+SClrofyEUhbQVvtppaxDubZupSyiLHtcKeuZvYm5DKgu36SU JZSb366UjQKXP6CUTagC+nCI0YgAzsq/VylTPdMy1TMtUz3TMtUzLVM90zLVMy1TPdMy1TMtUz3T MtUzLVM90zLVMy0bTXb5SqVM9fwFJKNG5EENqA1Ke5AfjaMICqEo/J9EMWjrhlIEhcm7F1r8UAoi NxzpQgEgGQ1B20E0BceipOaDTx/0PgTvE9DTiHqhNAYtPnQYegwCNx/wGEFzpCSjfuA8B3xnyIwB KB0kSGT4H4I+czBWnUNOYPagJihVJmqtyEXm9wKHMPSVYV4vzIN5jKOblL6XQ20KWvHRGcAXTcgz Au1+IkPgongmiR5ktAPqY3AEt3qJFtJlpHxCiqQymWUGjo4TeVXtHoaxEdIyA70miNZkaJ8ibXtQ H2DC2vGTcUGi161kvI/08KFpmBNreYK8ywoita9M2qPEpn7AolovKQc+HgMUfhgZBS10E2n8RBJ/ Qg4v/J+GERQhlcdL5pAVW/uBI+bqhX6Y1xzUDkMpRuwQBfnGoBwgmCJEF1heP7wfVDRFucaITHTO IJFonCANklmixE59xCqT0IL9cYZoMEr4+hRb+IlMVBdR4hVR4OpV/BVbLKy0q7NMA58A0U9YQRmE lmkyK+UZJZpKIsAzhoksNDZU3VLsAeI12BOmFM/FqKahrxfmj5FakNha9WuqMzoLtWNQkStEdDtG eiYRp0qEtTZLxlGpb4K6m8RuqjWrCLdpwmGO6GFGidJUfaveF1Q8GctP7RIh3qD6qI/YGntuOCEN xXhQ6ROF2i0K9xhIQS10KGElL/ERHAHTaXKpmWcckHjJ/OPK/O4NMtSWC+TE0RmC+gTar3iN6vUt wKERskZ6/02J/hf3/hjBMUG8E2O6KWGXZLRemDsPKr4eTvTG3ky9IAj9fcSf/nNysD6Thf9msnA/ IBlH1STyapTjMtpNvCJEkMWAcA7bguqBJohu8cjpC7zHrfhcPZTniA8dJF6EbTMHrV7ATnWscqU8 AwQDRjBJ0NLcR3lt5KNR4udhIjvVgjoOW/VqMgfNPnNE01QzsYS11d5qrhhX8jmOfBfRAe4XVrwi NXeHiV6DSs6gXHxK3avkaR/JMn4iIUU3RnCoVl5vsZgygvpP5IKWyYQMrneUCehKMUF0GlNWJBqf dF5XYp71EtDMepjoaZzE00Y6O6xI6ieRFiAxRSP/Qt3jMXS1qYb+NWkevDF3iuEv1W1qfNAVX1bW 7Bix3Hja2rleguRKuR7X1hQfwJJQWegOQs2VkcRuZIKsx0GSR7wXlZT6njfNq2g+CCnvVCpaniHx QvPTBFnb/EpuoXxwzwDJ/hf3UZrFg4plktzVCPGn7DSmSL7zK3rGWd1I8qVPkUHddahaTvdqF7GM l5QnkLrnWp/n1kdC9bq84CN5+jDZZfiJ9bFVvdCGNXQQeqjH6hWeN6zLnTVK9CazRXKHoKL5c1an d7gayEXrePSrPOTihDffCG3UTqrX0B1LQFlFkt59qRVO9cqLr3LYcnsTkRNN2aNQe1Mv8Clz0Ywd VOzuIjJHlNVH3VfQvdJBxc6qH1O/Civ7IDpDiOzFvURO1VO8KLnKr89nfwVbJDTkJbJjvfmVXD+h xOq4sv8OEqypa6af7NCjxDcVjBe3LZSH09d5sHZNio4mUs4aUuPhHfNDyTMdtffG2c21Lrupul8/ OkDOFPzr5FZxJfdgyahJrkSqDV1IPWPDZ2Zq3ZfiIWFyThYg/jaVssJS1GMEi09ZqWYStkzNJdSG 9YrFoyRKAgkMalyn+9I712rqCk+lTF1p0n06qYnDRI/Tf6Ed1dVghpxxUs34UhBMkHc8Z1IvN0KP 8ZS1I3aJfEwz/wSRQF3xtqRlcbobO0TKG+26g2SNUFeZ1HM2dZ3YKKekj4qSXEFtNabIvfGa672I RSMJ6aPES4OEO42iC8+G/1IPUNe3XtRDjg6iXVA7AKvlEGnpgzYZsugQHNkPtZ3QuhNaqqDHsHK8 iljqAFmHeqHfPrLGUR5D8D4A9atJjtuFZFLHtSug/wDwwmN70FVkjh7gNkx6DhHee6C1Hz57lH54 RDe07IM6Lu8mWZDONwCj6DlEn7ImUqQj0C4nJExH1UdmVJHtgdoQ8O9VjnYB7z7CD+PH8+8i5YEE zl0K0i6iI8wZ8+wGRP2khlv3wede6DdM5u8iMlO0A0SGXXCcytJDEOCZ3YqstB/Wz37lCLYRxtcP lJSqi+igl6BJ6q8bPvcCcsx/NxwdISvEIIzcSSQdJtrrUXSGpe0ntaRU1FLdRBqsVawD/DPFe+D/ 7oTuhsg7xTKUwi1ddwfI8WQvKl+X8t5NNDdIatQa3aQ2QmyFj7oUWw4ROdbPeoB4Yg/p1UUkHk54 yC7ivRS96p10jsEUJHQ+bNtULKpXy5eIEcpFPb5PsfSFesFa7yI6wbiGEzNfjDPE5hfkRk9Dm7zH Px4JRUOTMbk7FAmHIt6YPxR0y12BgDzkPzgVi8pDvqgvcsg34Tb2+sYivsPyYNgXHJkL++R+71xo JiYHQgf94/J4KDwXwSNkzNnTJFfij1aXPOQNhKfkXm9wPDR+E7ReHpoKyr0zE1E8z8iUPyoHUvlM hiLyDv9YwD/uDcjKjNAnBJPK0dBMZNwnY7iHvRGfPBOc8EXk2JRP3tM3Ivf7x33BqG+rHPX5ZN/0 mG9iwjchB2irPOGLjkf8YSwemWPCF/P6A1F3tzfgH4v48RxeeToEDGEebzAKXCL+SXnSO+0PzMmH /bEpOTozFgv45EgI5vUHDwIo6BrzTcPI4AQoIBL0RaJuuS8mT/q8sZmILypHfCCFPwZzjEddcnTa C3od94ahjIdMzwRi/jCwDM5M+yLQM+qLEQZRORwJgTUwWuAeCIQOy1OgXNk/HfaOx2R/UI5hXQMy GAIyBmGu0KQ85j9IGNOJYr7ZGAz23+Rzy4qYVVF52huck8dnwKQUN1ZfEJQc8YIsEX8Ua9TnnZZn wnga4HgQWqL+W6B7LAQCHcIieWUwwDSdCzvP+JQ3AsB8EXfCobaoc8o7QoGJ/aAarPoWd2OT0r4J t6epPxbxTvimvZGbsCzErAnvPAhaD+Pm8RCoIOj3Rd39M+PV3mgNWFLeHQmFYlOxWDi6pb5+IjQe dU+rI90woD42Fw4djHjDU3P13jHwNdwVegZmxr3RyVAQlA69kpNFZ8LhgB+cBx9zy1eHZkBrc/IM uFEMOyxuxsoYB/PGfC55wh8NgxNTo4Yjfjg6Dl188OkFU/oi0/5YDNiNzRGpVJcEdYHvhCJqYRLP 4LpQdvCFiZnxmAu75CEY68Jj1AnARoen/ONTKcgOw6T+4HhgBvw/iT4UBG+p9tfQ0EjpDhwuhZZG Evg72D4ai/jHqVOqExBfVHltJRqo9sMsEBc4nURw9EyEDgcDIe9Euva8VFXgXSAOmA8XZmJhyAQT Piwm7jPlC4TTNQq5CfyXdscG8ZNYmfKP+WM4RxlHAPJkCEcMhqyo2iWPeaOANRRMZAvVCNWKL/iC 7sP+m/xh34Tf6w5FDtbjWj30vEHJKzVgXuIWJA4wm40T4UYJ7CWlRz/u8V2s5htDIBNWDcRTAJIb UXd6qsSqTEuWRuNebJwoCSSQG1Tgg1Hg2KCZCZc8GYHEh0MEgvEgyIx1DLoCi8JwOTQGCS+IleIl yVr1s3cuBQbkjUZD434v9g+IM0hbwZiX5lR/ADRTjTmmSSsPK9n6uzUE0QTJiNQOG/YjuRY3p7ib S3E3jF49HPCDn9K5Ma8IXa1gBhJEWEIXzuf+SfzpIwoJz4BA0SkSsMB6bAYHbxQ3Kl4CEtaD4FEf TtOhsJ9m1YtCpQEPU9KgUTRNQByeCk1fQkYcBjORIIDxEQYTIcijBMuNvvGY6mBJPwbnn/CTwNtC XRzS2CFfyqIbDMVwyNCE7lfCmHqKcig6hdeEMV9a5HpTBI3g6aMxcCY/mCix+lxKATjeenvk4cFd Iwe6hnrkvmF579Dg/r6dPTvlqq5hqFe55AN9I72D+0Zk6DHUNTBytTy4S+4auFq+om9gp0vuuWrv UM/wsDw4JPft2dvf1wNtfQPd/ft29g3slnfAuIFBWNv7IBKB6cigjCdUWPX1DGNme3qGunuh2rWj r79v5GqXvKtvZADz3AVMu+S9XUMjfd37+ruG5L37hvYODvfA9DuB7UDfwK4hmKVnT8/ACCy7A9Am 9+yHijzc29XfT6bq2gfohwi+7sG9Vw/17e4dkXsH+3f2QOOOHkDWtaO/h04FQnX3d/Xtcck7u/Z0 7e4howaByxDppqA70NtDmmC+LvjXPdI3OIDF6B4cGBmCqgukHBpJDD3QN9zjkruG+oaxQnYNDQJ7 rE4YMUiYwLiBHsoFq1pOswh0wfV9wz1JLDt7uvqB1zAenNrZbczcGsjcGvgzdJu5NfDXuzWgJ/8z twf+Nm8PUOtlbhFkbhFkbhFkbhGsz+aZ2wTptwlU7WRuFWRuFWRuFfyXu1UAsUm/g4DQmh29H230 YpW/1EdMNXzeT/7i/1IvjaZakhjowyy90/5GI+7Pht9pf7MZ9+dy3mn/rCzS/9Q77W+x4P6ad73T /tnZ0F/DfQzhby5oSH8N/HeSdwuo2YoK0DZIZDtRM7oezDIHAXcLJM3bUJhh0d8xWegDTAH6B6YE 3QdafojZi04x16CvM9ehl5gAWmZC6E1mBv2BOcTwDPRm/hdTyPxvppo5xmxm7mA6mbuZK5jHmAPM IjPGLDHT3OXMLHct8z4uwHyQizCf5D7GfAbEeCgdI/PwX4jx04Dxi4DxKcD4PGD8HmD8OWB8CzCu AcYswFgIGCsBYxNg7ASMVwDG/YBxHDAGAeMcYHwvYLwTMH4CMD4EGI8DpifTMXJTKRjzAGMFYGwi SeJ6SOpzsODcAkvObeg9gPEOwHgPYHwAMD4BGE8DxpcA408B4wpgXGNCjImZYYoBowcwdgDGXsB4 ADBOAsYIYDwCGI8Bxo8DxvsB4yOA8VnA+A3A+CPAuAwYf5mOkb8yBWM+YKwGjK2AcRdgvAEwBgHj 3wHGY4DxE4Dx84DxJGA8DRhfBIw/AYz/BhjjTIAxAsZiwLgJMHYCxn7AeBVgPAioDgHG9wDG2wHj PYDxAcD4KGBcAIz/DBh/CBh/BRh/CxhX0zEKe1IwFgLGOsC4FTBeARjxJvMQYPwwYPw0YDwOGL8K GL8FGF8FjL8EjH9grmH0zHVg1wBTBxg7AOMeQDQGGEOAcR4wHgO6BzB+ATA+Dhi/DhhfAow/AYy/ AoznuQCr5SJsPvcxVoZ4r0nHKB5KwVgMGLcAxgOAcQowvg8w3gUYTwLGM4Dxp4Dx14DxPFPCmCES ipm9TD1g7AeM1wPGENC7AeM/AMYHAeMpwLgIGH8AGN8AjL9n7mY1zGNsDrPIOpgl1sNdzm7jrmX3 AsZrAGMYMB4GjO/G+U8nrOkEu72jfPLI5KROC/VzS0vwb+mcjkc6bfgbC/D6RlinQTp+gb5WdCLS 6Z87+nOgt49+7+iPj34TSO2+Mmv/eJgwWlqa9Xhml5ZwRQsVqHk8pNs5u8czOrpwTssjrXbFPnv2 7KxWg7R8GLMPky523IrbcZfw2XMLC7M6zZpO4xldGcUvYKrVzp89G16YPbtCRgAwPOKsyCKRW1hA FKxy6OzZFTiqY5GOU6RY0OqQVv/7V/CL4iCjlfnghXEorSuEj1ZLIdntWg5pNcuUC8W9HPYsC5o1 QUPheQibs0kJgB0wJZ1XsOgrOpbRaQgHAMpxgAtaDTwSeZ0uK0uW5c7Oo0cZDlLwMscxOv6+++7T CUina2sLBALxxUWdlkkxFa7MnsHczszqeAZLTF7ndCKjM1zaVMBVWAwEMONF1W7UVNhuqxK21cLq xqYStUgUJEmaBxRL81qwiTC7tLqwMC/ya6KmbXQjY5ExGBses5RuLREUgLFTcynHVHvpkdbwx6NL CyqR6SgXZWZ4zeoSreAzpELBSRLV/nqrEc8eVc2G+y9RYTY0m8gyIjUbhqzhAOAoNhzIpNVQy6UY DkuDPVJEoliEilAL0DhZd547+txRUcuIOmI//F8UoNYxRliPdYg8I6pGXDgnGhjRuAyvt5a/M/oK 0P8Z/TYQ7iSAHZfDbWBIUYdE3enJyQ57x+Tk6UStww4vUQCdx7WS3Q62jAtaJAizx7DV5gWeEWiU fyOs1zJ6nWpNOKRlBB0odRWcSs8jPZ+w5yj0FIT5s8SioHMyMGHSJT3L6DUJmy7go9jgS8So6lH1 JegZQUo169ICmVjhpYJYotOo7ecoX0GnYAXUgoYRFPMu4LKW2NezjH0KDHyOAG8j/JYUAQXQA3Z9 8HwyAtsYjIwRqsmOWlmvwQeMWmTQSqBECAnSc4HhGA2/rOFBQBzrej3S6yVUAtQE5D16GxBRgcDo xVUIW/w/voqruo4jP8OHfnakQ1UQea2u6iVGb1oOr8Drh49getHzomcRiKh5dvXMwrl56djqLGG6 qIbuol6H9LrTCZOT6tqaYCpqCy/DJ9HdKth2ldhcmMUqPDdrEBiDqIXXIUC2GD9E9b0KRl+dh3Rk 4NtmQXdUeTChoDuCLbEwv7g4T4ZiyK/ioQAg3ez4MHaKhUUw/NmlRQPLGFLsTgxvfOXoWqrhYQJR 4UbK8wTUvD7RHn+ValMQFbyAnLgwXiEShl9ZGPWsEMNrFfCzbYQf4QxCXmB4sPzCygqGqBpesbyB WN4kIEnQpth+YYHlGJ5fxrY3ENsbRGTQq0HeQoKchvlzRw06xqCn1j99+nR8FdfFbbf9lEzz09u2 GbTAI6GX1VWDkTGYl9uW21ZmV8iS88LHX/j4ix9/3v68HXclLrA8W4R9AM8qPncUJxU8azLF4Fnh UNIf7LhOHcJOPAIvGsDqGETQaoCuIMB34czqrCQwUtInQF86gdFhW8QXvhafl3gkpXrFKBhapzsS X1qdXVg9AtYiw6lf/CtRuGJ51TEWcIekZ4BrSCwjpbrGgk5idKZXl9dWXieOT4mgUHmqkIh/GOiR RdVBSF0FD3KQJfHsuWXKm8einsOr37kVnNdUHwEnIVwXF1WpYb1NrIx41LlzOH+eOyexrJTIzoqj SJdwFC11FIk4imRAkmRCJtirYmo42nD0toXbFqDn6MKopGckwxpaO0o9J6UEZUlkJH0puu3o6FGY NEGjkGRKUUKp9BWPSyZGsiwXLRetdKx0nA2cDeCc9/yx54+dlk5LxEYdR74GftRh0r4fbC4iSZ/q SKmuJOlg4hRXsuPeIkA6yh0VQJIiZEdtKIyWEW7DKxmY5v3aI1iLZJVrm/8FYPrFfJtRxxj1HLy2 3vY6xMLrt20VdYyo7zjy+uk1HApGnjFqU51rVMKL53aIpUmgI6gDjcL7GjoN/+cRYYfFfW3t56fJ C7sSn+JrC7gL8cbnv/3quXOvfvv500aWMfILqS9RYkTzendb9BBoCc4JoAD7SIeEa6/GSY34HGlI SAUSktVZdboFogYIMIhbHLY4aySEnG0jvOk0z6/dShQIiX2+bR7yOhm5ivdhsA1bNbKsMel6WM5/ L+bK46Fa3/hs9jWDZN/35czYK/uefd+zb2mGmLJWjCUqoewSI0Ky51K2hKyVJGkllIgIRVF+Z0ZX brff797fH/dzzceZ87zvOe/7nPc8z/f7vOd9zpDBwcshsdEuSgg9JRxOvm1/pFJwLgBGbotk4MhS kiJSyI55P/G5B8zzMNbn+7508Na+DXFfI8jNXZJXIwiDleTVCgs6LMmr5xXgT9oGgdsgL3CfmGUj yWvkhsP+f0eTdICS9AD/ufLBb+YtlbgyATzXBXIq8Xj9+FU6KAWsAM8VCxZFwaBQFA1ARU4mQQ+H sZNBADdyaglyKAKKV4RBEQWWgDkguaOEs5A7ihO0F+LHlPQ8OIC0QkNcP1AlfgC+HY0hmEO/nQ1y 9rnhWOQ2Gjd00OnDexqhpgI8mzWAR3QAeHh5ARwGhcGQsqCKjWz7Sx/DI47jSQo3AnTb2oKcAAFC SGrCrRHkSJi1JQoJ7CIKlEhqW7dgXz+sDy4Ai2IE6ImFFEgKCy9PTADWE8UNcBJLqJEsv0xvRfEB PMR6OJLtR72VH8ZLyhLnhgnkNdPSALh306EUAGVAEaUoryQn7wCKSjtEILruH9GMDqAh1tMgEcam ZhYoEUBoS+TGavkFElPetC11eHUsTfYqaqN1pGQVldBSmoCuIkoIENi6Is5fXpHlVuIggIfy7xxh KBkEjocyQMByahgeCoXkFd4ZNH3YdK/6MsL4LWVxffjz7JKh7AavhY4Y+1Sxix+PVbgczbVGder4 zLW4NqzWCAhmiLKhH6IpnOLa8+zP7WvaP32f/Cv19ZM3DQfsx1iOaAwAXjZkelncty6spLwrlHyN Eg/RXtr9eIz9aynB9qn9/PlXLEMlN9w0FiMKTnA/Vay6WRWmT2HMZi+7l+lQLkcOa7pKRWBv6eUP Gnur2vry8wqzyVYkIvp5igmOgrMO3rS4uz4wmZjTDWypvlIWtz6vqxxAzhR3jNgMjtI5HMSYh9to Ob2ZOOFgpX9jyFPz2lhtAFOzbAFedgRQoFNjjtSBRi5cl7vui8dvLtfHzHF8Pg4SDAR6GQ+lAkeE DOACh5SLHsGKYE5tC48b18tJvTvL5KoikkRzGmWCJ9kQlwCCDWCNYhaQW3tioRtIPa++fmy9TqK6 Q76OAbAiHsCDMAYMAYMCvQKdeK3vuYYeQYd/SlAN9Pcjlsp8T/UMltm+jcS7SLqJoFVKg4cAduSU oGOSkVFAoQgj4ACg/7sMwOL3f+8gJCTkVx14Bf2PlnEAkqivEIIWjI6/Nwmn/Mkh4UQrEfAgSGcK Enq9bgqnjQ25Q9JKcXbJh7Sfe+eNG12XyfZ9mgQU1+4W/3gmaCpwPPSO+nTl9BDDKW9R4YE3WAG2 UPd9keQlq+nolsLbj9CRmCce/dld9ZDKLssVnTXjynwt12cKmCvQOQvuFTnFEwqre2cRrqcEmKki BXU2M1Po7Dvr84eTxEohR2W+XhHOjX0k3SAU2tWqd4OsPfGYfVbkqNTjkvKpIq5Ew8efpEcjwxm4 8jZ4CQW1Y0B+C0apxLPZcFZzferZymJkdIaYzxXIwL7joov33+O6n/OrQev2SgL5Skf2q2pwt+N5 He+7T104Kn1iwNVAlDdY1E/wJG0mpah0NIAnh4IwNrMDxjpnEtfCo81mNkkw1rlz1MDQHzjxj4CF KCC85fQ8O+s9vXgt/XxIiZ7gjSVm+aNIaKYIKKFQaAD8yG2h2Q8RwP0j+n2vh/+X+r9Eo4TTjYId FMk5UWEsG8KuG0EJkl9WLmcmZOg2XO53SZTZKyvNnRr6JbKMBw+tD+9nb4b36b7ryl5dR3AtxVFv 8mMJSz4qXSJsr0V5PiLSNDzmJm+ynJ1H5si/VAq0Ctg3V6FDBRi0tyYD2bT9x3pXg9NZQx6caUrr pozjneculf9w5PY4DmJ4euh56ruR0G9JXypcE1RabvBUume2dcXWpFSOVEk8tFqXf3r3yPk33Jtz R/z7T1Iew40zmusPf4D06BtdppB/bU/3NfJizxuHybiPIzkMPOeuTMXubh/py+eCdn/VL0Gel83k 00ev3RYshNS2WvbFYMUcoxeUsFHLTXNImne/o1EUOCKRW3AjRISbbWY2ooRueyp8B1z1j7jH3ndV nt30ue001NNU3tCBzAIsiNW7ECAWFekBOj8zjRyAJopkSAm0LACg0BIeSoCcu7yXm5ScsruclBxa VklKSVYBLeWpJI/ydkOj5eW8Pf4AgfpYz9dmZA/xV3crKvLXY0r7jsLS/zsE/hKhAgKDSSgImgto x6AVgwZMtF8X4kYKUJQClEgQ6LYDAq0BMFrZAYE6f9nB7yj4P7rAAbRExZFQ6CYCBkB+cmc4HgaF kLPyPLO9bdYjYFpoHvp4fu3r3ZZHtz585rCZt+zx0yN71Nk/N7GR7ZjusktJ9BaZDnI8Jyyh2bv8 WdM7mLVAg4pAqAamcu0DxCEt+zTnAFX6YA6nNlBWzNp9U8/xo4TcmfxkO8UOE84q/j7Gu6N4xjL5 xUr+nmTBK9FnxkQ4p7y5ElWlN23hxu3YmAL0u+t1MmY2zuQ1LGd7uDwagmknR8KFGcQzdErQMaoZ qrYGIQKJ32oYu0+/pmQx75JwQDkqH8ooLUrwzxAN+NBZOduis3vA3SS63opd71xWMeYWVuTOmghP zzxvGU3Nh3s0OWkTh/L8YggKjzG83+IebXY0ZipQfVNhbs9iLrsVP7CAby+3FtRiq9ePC40f/DyU p7bnCXPidFK+r2CC776y7igT4WlKPiOPrxcvsBjL1tu4mj4+cEPp3Kb0ixqXIi3/3tD7NU3+yTGH TwVdnS1ez3/BPqK84dmLUaV8HRlTU9F8+WbE/QybonC7fiY99yG+hY39nSiaVRlVz2LFAFcztQbt FNMCmjOtJ+w+dfuccnt2Kauz52x/gN6rW9Jp8zWfqgHM3CGD0pmMYz0tlJ3f9n2sDFYkr7W5v2e4 6WNa3ynOpahDUNPfOKKD6x468qvttWMbS3jv02lQIvNc6IzKwcE5Oe1UruZU2mN41YXOUSkCAnZO //PCC9h9eCFIAhQgCSxskQC1G6uvHAn7OX8OYV1IcEpNdV448cKSpCd0DysctEbUHmD3Hwqpto0V NEOJLdwU/IGbFgEBIHiCpuvn7efhhvPi1TiK8w0I8sOFEcEdUATkAFkUWl4WUAbBHY0iibIAUfz3 Yui/wvd8wuGasWf658Uj/aX3vGqZmOzKNhcwq7j3gs1EkOH9g5IHRhU4gHfXO4pHVuksBmkcmucr s5wA4acQ/7cRLXOJFAyr9IisxcQBnn5ZwVN5Sys+nJIbEdMJXLPTJpcJ7QKWfUlfdO5TDR6sGqzW RBR+vnL4gs9j0ee6ltXxg69FdaVFrsWbWlvQTsEl1w+lpADYU8v2QN6XEyOZdW/5Mk+sDSGXKRss MRbXdVLy9SEH9Lx3iYh5l2ZOPSSPPlD4ObZklx4zFT4/dt469Bs0h8uMMg7CCOjON7wU0G3qlLLK r+IO1UCFDOSO7Yu5QHCD1XPR1Wys5tZC7/EbWm1+Juu4zUvzO76XgyNSAjBsIw4ZAAe/duD5L6NL InxzMSAQoP3FA4zkVN85gQVKLIEA0Vlb2BydAkQnRTHTX8O7qtuIZL4WQm6Iv6K2TLefKiJ4FLn9 4+aJZwyrYCUcKCiuMAq2W6FASnsBZlukYACAPFSgVaARr/b34+LtauIbX0QoJxGC1Q5C0Ad0Ae0d hKD0/8TExOvQ2mr1b8bD4FgzZp7ucIJrK7yYuV4R8uxemLkxtEYad8QRQ4ssv9cakdwoPcxUeBbj 3mgL6zfhRZplvwhXn7BtqrLL4XzFBY2/1hS6dGZwbh/0/URrMjVZT5L+xKIlywvT8vNT00mHHkW1 v0lbIpeJg8+kigvyB65/2pgKzZamW6WYCGxmM8k7508dlN5IUL7oI9VlTj/r7qTGmnWGV22Cgh39 eQB14BhKRSKIpmc2UGUzjho5dpva7dzi48bd70zOnOySlzh4ue1d83EazYhhyyC+90BfU6iXkyN0 NzUz/dBT5qyP+29429VJyUx/josfMLd5mxeYdviastHwp7C2q2zh7mILhblicuQh7O69KtwYHvwi Tbdk032tutef547XTxaV4uQbTbqOCDAJH6PZb3H2iIOuFnNzXV21sU9PvuZmVBhf1CUWwPutJtNB 9p5L/HyDWjMSM00r+gOSw6PoKCNhcX1BF4dZm4UrL7Pz+vYGtESL4Mh3vT/G15aLbxex+q3mkEoi 4ZjbdSwBeaXtqt4iU8DX0+jDtd/GzHvOCvR6t+RxnWLyhKlIVdknN07xva6v7vO4HmpFNqwhbXYt rbo4tLyuIOMo+5Pzp5BH+WXQpZTYAsezQm0FC7F9fCPvuE17c94bjK9CvQISaY73+PW8wc6WZN5D iW3Sdzk6jRpzEEa/yFxSk7Zm9e9FXv4K4CnCATyZ++9UQJ8yRKIC+M/TgOiEfwSK0QCw5ZBif8ch f8wIUCBtKKEBeeUt0lAgiSiAKP7rMxY87M/cASNyBwzkDtDnyhe/BDFySleMYq/iGY3lbi79ZseX r8kh7j/jYHa1kVyJHWFw82QHLfcLRf87TKM0i0q3s8mre5QfQZlRmg8T6cI8T51IcxU8XHXJ4OKM 78GhsVzLWmrJjqonZRKV4VRVjzPs+1zZyWa8j71FWwgzyUyXU5rdr9NucB7tlIYfLfdd7scs73Ui sK7o3hxX8ryG9ZQPvVLgwSD1UP3C2uRLCrpHTmHFBmLTdK0FyJDWNJWF9UkJB0YeYxvRwvCgcaa9 DQYHR+fntVJjnkTURsRzPFGtOev8NtE0ln2JIGM/lbJPqlLWrqtB9Rv6YR1cpaa26rzSiaG8KMmP JjapfPJCHcpYz5OWNy8yVOwRiO1fuQmPT1p1WRy0aDubdqr5Fh9OyIVN9LcBEVEloSzlAwr3I2vO V3IKlJR5z7nxHHolapDnkjAh5PyQz1DVorPeVk0Qvvgg3FHmkcBkoDODuW5I3RrkVfM1GN7l2S2W uhaOYWvDaWUCw4yAQTNbo3akzlR7R1D4eNC04FibbnbXwm1O22cxSXPGBkBJ+bmxOcf8qo0X1d4T 7ZnREfMj84bTBmIlSNErJcd9ot6cdg91qZWJfWx70aktRFT0wzymQzRZMlld0bT9VZx2YieVUddw sZYMLn0VuxbKayeJdHZNz1E1lY19Wp2w++Ulk5WM6mbdgsNZQ+MjCWe3uXMe5M6ZX9DfD/L85bxk z/YJzDAELTc1xJKU6KoF0fgjr/6JlHfOeIKk9sJQKVo3mMlMXs2WdKMeCCTKAQ5b5EZ8hGpaYFxg GG/wfz30Af0W9FrQWbcnJS6ArAsaTaK5gztozgIwA0x20Jzm36O5/9E+DojOJyrPi4jOBKLTgOjU 7UGShgPRMYDa793BoKyyfzXNIr6FDV6ZH8YtKMwjMFjaF4cB1LcbgAFy3GheLogRxAviQ8opdiHl FG/loIeBUvD37Hiv7XcEpHm5fjUR81mKL84atwpjl344ivPhz6XJ2PXK43y2ZsbxoTDalHYvF2lJ 1bWOoAeYmG+tam+p+/a16ZVdXvZ75tHGL1+c6ewVm3L8jK6Z9Sjt+cghdkPO5f2aZywGq7/6T6pS SIvlvlHhKB6u5wpJU56Y8ezVVgkNF1hGHr+SgotJWukXhumK3z7N2FRURkabO+/7xVc6vUBcTdzf zsCDh8oP65CVMRWzcit5WVfi5ca+wRb5BaxQ5esqkfnBF8v0VdmimVnG9Co0S5SJIzwdaLaJxS6p e46XrhsoU9+hvn2novJ17ZNnLAnmOnZK6CMi7CdrVkTWXkru5fXLqrVP9MUGlDTgOtTJyK9AxUVV 8WpIY2+aW3XGH18ln+QMYDmuU3Lstbq41+UOZwv3+A4uD4XM+LGny2tLrIQckVd3izMH3zt7aEw6 Ulw8pUoeQv6AvOYoD3Orm1v94vM7HIjWMY1uetH3L71k5jI/EZwyRiEjBN0W++XMYipDfcbsKJ5B iFhXTW6xmk4It/ydocLC/PBw/i/66Tzl63oCUR8vrbX5NxhmTrw7Gso+N6uYHcZmuDlSJ+B79E3V l40z72iiZv32VW0A8wijc2NjRzEeqSoP8mxMTNuibPkJobvQfOELGtQ1auulA0XO7YSEXNsjNib6 Orc0e3OPOVJH6ft/Dctvb8FgDvVaBCPpws3uovCIagCPuAaDQoHo9H+buH79OPDH4khBdCcRfL4b MRUcRbtz5QXU4odEg6IHdtayAAI/TkSgQGjLGvD2y/LXWV8Vzn9fqXLaUBvWiQQ8d5xCi7IBrArE o0R/+eqi1Z9/UZIgHCX4Xz3bavtXFHh/4mYEHgphLa7Jx0FPhhVMdoe45x8vZvzGfK67Saynreha 97TssM9cE5pWvONGRR+lIqfAbdVzaTduSTY665cX7tLrUtIplvE/w77cWruf8yqLtSoqabgMRd4p m3LGLTRCgJK3LFYOBS/jt22M76pP9jh1/p3ji6dx2ss0VumpIZKyNx6aqRHML+CXWyWet6Kfmy4E /da74CIS7Ch5sGxOJ3tpgXW/kQbP0dBg+U9dF6wj7rz11/GwwivOmhvtXZSx4XSckzs07Xn48wkx XKqwQ5Aa7nLZVDcaP3FQIU7x4/k1t5PXaopap31CHt207lpL9qwMfDJAzZEAELQeXt8nxjGVvdjv ulrm95WAh4mC4Yngj3tEjsLDWMCiXSTTPPevTcR/vdK2wyadAbadJknzY8UQCna+XUOGYiA9OFZA yaNRxD+HP1mkijVvhEkaXdYu4Yh59fITftrPlch+mjIRbYVlyPNObUOTXNal0pAhnz7AeVw35MTg veNNzZGlPS0AGoo5aYp5l3Q1hA5d6jM0ErCMUvfoD9ITP1fWx9elxJNUxYRNVY99Y3tRC7hgO95o mfzRoF7y08CBz0Y1kjl6RmEJL/Rqi3p/W1rpShQeQ9FgbZS1Wdtx02s61QoW6lNXvmDZp4Pu29rC egct2WyuFZFpJ+2FZtodUQ+mGXgaH+/BUnWWKS8m3MKqgyNjQu11WOA3bdn13MIFhPZgf57Tc48m 2slgEQlOQ/UgxzlzPk2bfouAFgxhlPyR6Ozw+oBqqzdlgfjChHi0nUF+7qRojoHc7Tg8HfbEHHAg uQy26jqZB/kPLcnO9A0KZW5kc3RyZWFtDQplbmRvYmoNCjMxMyAwIG9iag0KWyAwWyA1MDddICAz WyAyMjYgNjA2XSAgMTdbIDU2MSA1MjldICA2MlsgNDIzXSAgOTRbIDQ3M10gIDEyMVsgNTUxIDUy MF0gIDEyN1sgNDc4XSAgMjU4WyA0OTRdICAyNzJbIDQxOF0gIDI4MlsgNTM3XSAgMjg2WyA1MDNd ICAyOTZbIDMxNl0gIDMzNlsgNDc0XSAgMzQ2WyA1MzddICAzNDlbIDI0Nl0gIDM2NFsgNDgwXSAg MzY3WyAyNDZdICAzNzNbIDgxMyA1MzddICAzODFbIDUzOF0gIDM5M1sgNTM3XSAgMzk1WyA1Mzcg MzU1XSAgNDAwWyAzOTldICA0MTBbIDM0N10gIDQzN1sgNTM3XSAgNDU0WyA0NTldICA0NjBbIDM5 N10gIDg1OVsgMjU4XSAgODc2WyA0MzBdICA4ODJbIDMwNl0gXSANCmVuZG9iag0KMzE0IDAgb2Jq DQpbIDIyNiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAzMDYgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCA2MDYgNTYxIDUyOSAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCA0NzMgMCAwIDAgMCA1NTEgNTIwIDQ3OCAwIDAgMCAwIDAgMCA0OTQgMCA0MTggMCA1MDMgMCAw IDAgMjQ2IDAgNDgwIDI0NiA4MTMgNTM3IDUzOCA1MzcgMCAzNTUgMzk5IDM0NyAwIDAgMCAwIDAg Mzk3XSANCmVuZG9iag0KMzE1IDAgb2JqDQpbIDIyNiAwIDAgMCAwIDAgMCAwIDMwMyAzMDMgMCAw IDI1MCAzMDYgMjUyIDM4NiA1MDcgNTA3IDUwNyAwIDUwNyAwIDUwNyAwIDAgNTA3IDI2OCAyNjgg MCAwIDAgMCAwIDU3OSAwIDUzMyA2MTUgMCA0NTkgMCA2MjMgMjUyIDAgNTIwIDQyMCAwIDY0NiA2 NjIgMCAwIDU0MyA0NTkgMCAwIDU2NyAwIDUxOSA0ODcgNDY4IDAgMCAwIDAgMCAwIDQ3OSA1MjUg NDIzIDUyNSA0OTggMzA1IDQ3MSA1MjUgMjMwIDIzOSA0NTUgMjMwIDc5OSA1MjUgNTI3IDUyNSA1 MjUgMzQ5IDM5MSAzMzUgNTI1IDQ1MiA3MTUgNDMzIDQ1MyAzOTVdIA0KZW5kb2JqDQozMTYgMCBv YmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNTU3MTIvTGVuZ3RoMSAxNDQ5Mjg+Pg0K c3RyZWFtDQp4nOx9B1xUx/r2O+fswgK7sFSRFXdxBQsqdrFEVikWooKyZsEGArZgrNhiIUVNSEzv 1fSiSZZVI6ZqYnrv7SYxN+WmaGJyY26uRvmeOe8OgiXx3vv9v/zv79sXnn2eeeed98zMOTNnNlev JIjIjg8TlecPzyuJucJ6BmnaRqLEEfnDT8/9vHrIJyQO9SQKnz9uQlbvm5/qv49IXIBW5ZVzK+Y/ eNouB9GZVxGZf6pcsti1Y/77/YjuQHvzYzPmz5y7+hN9ANECxNsyZ9Ysn7F7ynPRRPdNJvr2q1nV FVW/jlnuRz4r8vWfBYftgXYyfx7KHWfNXbxsyffFNpS/Jpq9uWZeZcXs/T2fJnEV6vtPnFuxbH4P W0Z/1M9CvGtu9eKKG87duIS0Noin88+qmFt9y8ED00i8eBNRz0Xz5y1a3OSgdRiPXcbPX1g9P35m h7ZEq7fict+RnIuwQZ9F5M5ZNy1myAFqayFpj3638mXJ741aOu7QwcN1EXstuCZFkEZsaBdGR0js jtx46ODBjRF7jUwtrO1m6XF0pdvITstIR0s7ZdF6orj+uK6GWt2UKS4jM1nM15v7IGV7Zv11WqeR hbQYs6ZpJl0zfUE9mnZSx7ONHsDGTHC5yEN0yMR9CL9Fy3CRaJJ1+nZztBwpJZiij/ZGvIbbfRu5 6d8wUx5VnNC/lzb/O/n0B07czvTbUb9m+tdzmzpzG33KiduGvUebzV1PXGc+nSr/1es1X9fXOifG N+LfzXXSa9RThxP6O1FP/Stqf6xff5IGtyr/jKfvX72miW7TX6K5J6yrxnPdMn9d6/LJTC+i20zn Us1x+ZYdbS/2/n4u1McqrQ0N5n2B22h7Ttw2LAzXvfzEdab7acap9F2Z/gznMTXQDH3fMfMwjkad sE0ptWt1zQ106ylf7zClhQ2lAcf5X6b++nnH31d9NuW1Kr9Dk0/1Ws3960vX69Op7ER14fOoLOxj QHA9YstbXe8QTTmVa2gLKD3sBkq3vEPppk3QNwb1EEo/lfZhS04tTuWT8WERuEbu8deQdaZ9R33h nSld3039jst1zFiDvuuVFu/S2j/qD2KMeFN7ukB82/SOhCzrd7TKc/2J2oZV0fUtr3dcX7JPfM9O Gh/MJcelvdg6r55GxSdqY36wtV97kNJa5fyK0ky1rX0nvDZizPGUFl6I5/uDP46XMejnVX8Up0y/ mTqYG4+/h/pS6qLfevx+qneh0pPl0jZTnvYl1WhjDR6pNdIIsYs6atdSV+0bqhGVVCHmNr2Pco2Y SjWmiYj9ykC+0Q5txC/gnjRcfE5u2UZbS079B+qmrabO2jpyagNo+KmO7b/V8FyTePXP7kXIQhay kLFpN4rIk9aV076WZXzH6qp1xP7fkR7VzHTt/81+6G1IaJ+S87g+LMI7BDjVPNpcWgusOM7vofOB FX8Ud0p97UcX/Tvt/ifMdBVN014it76XphtlL7/bTf1pdXNMf5qM78MjgQeBhYYvGt+Smc9sjoum 8aZcmqltoLb6OXxu1jdThsHb6SwVpz9G43GGKAI2ANWG71YaFOTm78sy5rj+dT7l/vU8Uf9wLhsp fsUZwk+F0qd9xOdWPDuTVBx0q+8A4jEqB3z/SVvtZsoWB6iXNp6GGHGjKcHgYu6noccg96nGNTQV UshCFrI/zUy7/rX/9nEi0w7wf9vQw6hML6RLDN/FzPokukTcHfTtoUs0lE1z6RK9Fvtm7dHvqtqN dIZWRwXN5c8pxeBt1E67CGikov+0nyELWchCFrKQhSxkIQtZyEIWsv/9pr5jKlPfM5vLv/M906g/ 5rvm/4s+hyxkIQtZyEIWspCFLGQhC1nIQhaykIXs902c9E+5hyxkIQtZyEIWspCFLGQhC1nIQhay kIUsZH+OafMpDhgApAfL7YPctkVM25O1P6VrzKChwFRgXLDcI8h5LWLyTty66d7/5NohC1nIQhay kIUsZCELWchCFrKQhSxkIQtZyEIWspCFLGQhC1nIQhaykJ3cmh75s3sQspD9yaYH0Y7/JSnNipL8 R7o0Mon9cPjIQ2ZKhrJRB+pCvakv9afBNIzyqIBG0TiaQBOpjFbQRnqAArRD9NIGpHZL7ZnaL3VQ 6pDUHFeEy+7Kc813LXYtcS13nes637XOdaHrkvSXD5majH87Cpld1Jm6GZkHInMuMo+kQhqPzD6q OC5z39QBJ8i8Kph5AzITMoumAxjaRPn/mq0/htX+NLAnOOpU+dFUqT2jF+hDqV9Tn+/WH/3Z1+nz 6Z9/8fk6/iH6fC3/fHoaUfDf2yoBJhpqKlBuYDrNAc85+v/W/Qe24hit66P1a3WvvlD36TX6Xn2f /r1+QD8DI4jD/HejLBpCQzHr+ZiZMlx3OVqtEZqIEXaRItqLzqJIlIkpYraoEfNErVgiVokLxUXi YnGZuEFsEzvFLvGseE68bNJNJrHHZDaFmcJFpughRohsUUhh4hejL78c+2+KoawF/wUyjX7fuKUx kqNOfbW+xuBWY0N5P/CTUcPjPGomIM546uT/B7ocO7UYvbQyY+aJFgHGTLTqxr8xK38wsj/b9N+v NnVmlnfz1JOKGaFV/v/ZKidP2bq1ixctXDB/3llza86cM3vWzBnVVdOnTZ0yeVJZqc9bMmF8cdG4 sWNOLxw9auSIgvy83OHDPDlDTxsyeNDA7AH9+2X16N6tc0Z6R3cHZ3JCrD3GFhUZYQkPM5t0TVC3 fHdBucufUe43ZbhHjuwuy+4KOCpaOMr9LrgKWsf4XeVGmKt1pAeRM46J9HCkpzlS2F1DaEj3bq58 t8v/Sp7b1SjKin3QG/LcpS7/PkOPMbQpwyjYUEhLQwtXfvKsPJdflLvy/QVLZtXnl+chX0NUZK47 tzqyezdqiIyCjILyd3bPbxCdhwpDaJ3zBzVoZLHJy/r19PyKKn9RsS8/z5GWVmr4KNfI5Q/L9Ycb uVyzZZ/pIldDt531FzfaaXp5prXKXVUx2efXK9CoXs+vr1/vj830d3Hn+bus+CIZQ672d3Pn5fsz 3UhWOL75AsJvTre7XfUHCJ1379vb2lMR9ISl2w+QlHKIzdOEeqUJfUMPMb60NNmXixo9NB0Ff12x j8sumu4IkCcrs9Svlcuanaom0Str6lRNc/Nyd5q8Vfnlwd8ls5L9ddNd3bth9o3fdPyi3uXXM8qn V86SXFFd787L43kr8fk9eRCeiuBY8xt6ZiG+ohyDmC2nodjnz3LP9ye4h3MAHC55D2ZP8BlNgs38 Cbl+Kq8MtvJn5efJfrny68vzuIMyl7vYt4P6NO1p6OtybOmDzalU9sOflIubkpFf76ua4XeWO6rw fM5w+Rxpfk8ppq/U7asulXfJbfd32YPLpRlXNFphbMdEq2A58vB0i8unOfRSebfgcBXgwz18CCrs uF1GUd7R4UNcPuEgFYarBCOkapUHBT09d6Ss0mXT3JGOtNI0tt/pkiPYJ3O639Iilx2O5j7xdU7a NY6WHeriyq/Oa9HBVknNwQ4Gs524n5qci+CF0cIib+dIVaWnY+XCpyGN4ZJ3MdnlpyKXz13tLnXj GfIU+eTY5Fwb97dwgruwuMxn3O3gU1LSqsT12VzyUxqqVUHLxTNYkOlQt9UojzDKzcWRx1SPUtVu 2a/6+qoG0tPlo+xoEIYw515U6h+XWer2T890p8l+du/WYCFrWkl5LtZqAbY7d0GFGy+7gvqKxqa6 6fUNHk/9/PzyWYOwLurdo6rq3RN8QxxG58f7VjlWyGvHUaEoLBmOVBoNb3CLC4obPOKCCWW+HXYi 1wUlvoAmtNzy4aUNHVHn2+HCC8DwatIrnbLgkgWZaTwKFiPescNDVGfUmgyHUa5sFGT4LMonqLJR Y5+dL5RhXMiDs2Jlo4lrPCraBJ+FfXUc3TkYbUGNXdY8QniRkFHJ1kBygj2RZo/FE+GxajYNUypd AXgeQWyEoC1WYROOBuQcb7gbRV1DhMexw8g0PhhZh0jpq2v2oecyrEUiXI8H7j06Am+Zb4uVkN/4 RMRwaXgKk2fhGcL7JN9VJZ+/laWz6stL5e5BSXhW8Sv8wj2U/Jp7KHocZvVHuquH+6Pcw6U/R/pz 2B8m/eF48kWSwM2Wm259uRsbMVaMjxyC15ouU7oam5pKfGmvOPaVpmEtTQbKfP6ITLzczOmjETdC ohzuEf66ygrZD/L6ZNvw9FGVpViXKiFCRvkjkCEimAERBUYbud7QqBLPWoXbkHBj66gr9Zdmyov6 Zpca69Xup5HuQf6wDM5pzpAXyiqtj3P3NjYfrPXI9PWSItA3muBjjwNFXKyUJyncip5XulFVWe7i Z2QC1jK/LCId7KnGnm/KqDYQ6QhWkhyWnh5li/RH9EBC/Eod1UPuOeb08NJS7rxRWh8MwLXt/ij0 KKPFVAYbYHZQNUr2Bb/r0VUZukumKW6k8e5l2Dplp41M4aj229JHVeDtxu2j4HFnq8YWuQlGBXPs Zm+4HLkV844tobHpHvfytBaGvUO+/eTzR44dWKhUWn+swz8ps3s3y7Fem+Gur7fYTtyA58tia2bD qaVXyrcCWD5wxvPmypevSvfoBm1spsHC4PrRbrxBtHQJHHR0LJ80V1WpjEKXi4y97KRBokWQfE0b yevtg1VJBEt8M+v9M1sXZzUXCyRwGEzvwWcIDEXutXhW5jj8NXgyVYi8I656l909yC0/jMYjJMpx k5qXBR5/PHVy0dRVunzT8bAjYUF5fUG9PKJWVgSnLXgl/1mZrVJiXQg8PEgkh+OvK3KVl7rKcTQV xb60NAdWI9g1A+dUd4V8FRTxeIrKjKNKRb18xAknlVKHPxwvphkV1e40vEH8cgfi2Zd9NAWXDTnq 6931fmPdFiAY6TOw7EZJwu/8THdFtTxCz5An6GqjbQG6a8yOzObId2MtV8NtzCUmDlvfdPlRWS8P 6FPKMzETsfVx9a6B9diCp+DtYcqonFiOV5V8I7mMW13hQAmTMEqWSpGIAyPSZSAvAdmbuZkNU8LT j3qM33mZHGwxsqJn433+IhVirCcpFmT6tTbZqJSDF+PLfGqf0mX1KEyvB0+VQ7Z2+bUSX/D2GO1H yaYOdcO4GTzGOyS4vprfNuo9NNmBOT2pHy8HfdgE7XntWcomp/ZckD+mbO1D8mofgN8Dvx/kd8Hv gN8GvwV+E/wG+EnwE+DHwY+Rl0zaR9QXKAH0ZlUF3Am8DZjpTGQSFIX2ghK0pygPqAIWA1cBZsQ+ gbo7kVGQSzt/a0SyGI0bep4S5ypxjhJ1SqxRYrUSq5RYqcTZSqxQYrkSy5RYqsQSJWqVWKzEIiUW KDFfiXlKnKXEXCVqlDhTiTlKzFZilhIzlZihRLUSVUpUKjFdiQolypWYpsRUJaYoMVmJSUqUKVGq hE+JM5SYqIRXiRIlJigxXoliJYqUGKfEWCXGKHG6EoVKjFZilBIjlRihRIES+UrkKZGrxHAlhinh USJHiaFKnKbEECUGKzFIiYFKZCsxQIn+SvRToq8SfZTorUQvJXoqkaVEDyW6K9FNiUwluirRRYnO SnRSIkOJdCU6KuFWooMSaUq4lHAq0V6JVCXaKeFQIkWJtkokK9FGiSQlEpVIUCJeiTglYpWwKxGj RLQSNiWsSkQpEalEhBIWJcKVCFPCrIRJCV0JTQmhBAWFaFLiiBKHlfhNiUNKHFTin0r8qsQ/lPhF iQNK/KzE35X4SYkfldivxA9KfK/EPiX2KvGdEt8q8Y0SXyvxNyW+UuJLJb5Q4nMl/qrEZ0rsUeJT JT5R4mMl/qLER0p8qMQHSryvxHtKvKvEO0q8rcRbSrypxBtKvK7Ea0q8qsQrSrysxEtKvKjEC0o8 r8RzSjyrxDNK7FbiaSWeUmKXEjuVeFKJJ5R4XInHlHhUiUeU2KFEoxLblXhYiW1KbFViixIBJRqU 8CvxkBIPKvGAEpuV2KTE/Urcp8S9StyjxN1K3KXEnUrcocTtStymxEYlblXiFiVuVuImJW5U4gYl rlfiOiWuVeIaJa5W4iolrlTiCiUuV+IyJS5V4hIlNihxsRIXKVGvxIVKXKDEeiXWKbFWCXXsEerY I9SxR6hjj1DHHqGOPUIde4Q69gh17BHq2CPUsUeoY49Qxx6hjj1CHXuEOvYIdewR6tgjFiqhzj9C nX+EOv8Idf4R6vwj1PlHqPOPUOcfoc4/Qp1/hDr/CHX+Eer8I9T5R6jzj1DnH6HOP0Kdf4Q6/wh1 /hHq/CPU+Ueo849Q5x+hzj9CnX+EOv8Idf4R6vwj1PlHqPOPUOcfoY49Qh17hDr2CHXaEeq0I9Rp R6jTjlCnHaFOO0KddoQ67Qh12hG5W6Ro1M4PtB/qxJk50D4RdC6Xzgm0HwSq49IaptWB9lbQKi6t ZDqbaQXT8kDqMNCyQGouaCnTEqZarlvMpUVMC9m5IJA6HDSfaR7TWRwyl6mG6cxAu3zQHKbZTLOY ZjLNCLTLA1VzqYqpkmk6UwVTOdM0pqncbgqXJjNNYipjKmXyMZ3BNJHJy1TCNIFpPFMxUxHTOKax TGOYTmcqZBodcIwCjWIaGXCMBo1gKgg4CkH5AcfpoDymXKbhXDeM23mYcrjdUKbTmIZw5GCmQdx8 IFM20wCm/kz9OFlfpj6cpTdTL6aenCyLqQe3687UjSmTqStTF6bOTJ04dQZTOufsyORm6sCp05hc 3M7J1J4plakdk4MpJZAyFtSWKTmQMg7UhimJnYlMCeyMZ4pjiuU6O1MMO6OZbExWrotiimSK4DoL UzhTWKBtEcgcaFsMMjHp7NS4JJjIINHEdMQIEYe59BvTIaaDXPdPLv3K9A+mX5gOBJJLQD8HkieA /s6ln5h+ZNrPdT9w6XumfUx7ue47pm/Z+Q3T10x/Y/qKQ77k0hdc+pxLf2X6jGkP133K9Ak7P2b6 C9NHTB9yyAdcep/pvUCbM0DvBtpMBL3D9DY732J6k+kNptc55DWmV9n5CtPLTC8xvcghLzA9z87n mJ5leoZpN9PTHPkUl3Yx7WR6kuueYHqcnY8xPcr0CNMOpkaO3M6lh5m2MW1l2hJIygEFAkmTQA1M fqaHmB5keoBpM9MmpvsDSdivxX2c5V6me7jubqa7mO5kuoPpdqbbmDYy3crJbuEsNzPdxHU3Mt3A dD3TddzgWi5dw3Q101VcdyVnuYLpcq67jOlSpkuYNjBdzJEXcame6UKmC5jWM60LJFaA1gYSp4PO ZzovkDgDdC7TOYFEL6gukIjNWKwJJPYHrWZaxc1XcruzmVYEEqtAy7n5MqalTEuYapkWMy3i1Au5 +QKm+YHEStA8TnYWR85lqmE6k2kO02xuN4tpJvdsBjevZqriyEqm6UwVTOVM05im8qCncM8mM03i QZdx6lK+kI/pDO7uRL6Ql7OUME1gGs9UHEjwgIoCCfIK4wIJ8vEeG0g4DzQmkNAddDqHFDKNDiTg XCBGcWkk0wh2FgQSVoPyAwnrQXmBhDWg3EBCHWh4IK4ANIzJw5TDNDQQh/e7OI1LQwKxpaDBTIMC sfLRGMiUHYgdARoQiPWB+gdiy0D9uK4vU59AbDdQb47sFYiVA+sZiJVrM4upBzfvzlfoxpTJyboy deFknZk6MWUwpQdi5Sx1ZHJzzg6cM42TuTiLk6k9t0tlasfkYEphahuwTwElB+xTQW0C9mmgJKZE pgSmeKY4bhDLDezsjGGKZrIxWTkyiiMj2RnBZGEKZwrjSDNHmtipM2lMgok8TTHTnRJHYiqdh2Oq nL9BHwIOAv+E71f4/gH8AhwAfob/78BPqPsR5f3AD8D3wD749wLfoe5blL8Bvgb+BnwVPdP5ZfQs 5xfA58Bfgc/g2wP+FPgE+Bjlv4A/Aj4EPgDet53pfM/Wy/ku+B1bjfNtW4bzLeBN6Ddsmc7XgdeA V1H/Cnwv2+Y6X4J+EfoF6Odtc5zP2WY7n7XNcj5jm+ncjbZPI99TwC7A07QTn08CTwCPWxc4H7Mu dD5qXeR8xLrYuQNoBLbD/zCwDXVbUbcFvgDQAPiBh6KWOx+MWuF8IGqlc3PUKuemqNXO+4H7gHuB e4C7gbuiujvvBN8B3I42t4E3Rp3pvBX6FuibgZugb0SuG5DreuS6Dr5rgWuAq4GrgCuBK9DucuS7 LHKs89LIcc5LImc6N0Te5bw48h7nWj3deb6e7TxPZDvP9dZ5z9lU513jXeVdvWmVN2qViFrlWFW4 6uxVm1Z9tMoTFxa50rvCe/amFd7l3qXeZZuWeh/R1tEMba1niHfJplqvqTahdnGt/nOt2FQr8mpF z1qhUa291lWrWxd7F3oXbVropYVFC+sW+heaBvsX7lmo0UIR2di0c8tCR/sCsGflQpu9YIF3nnf+ pnnes2bM9c5BB2dnz/TO2jTTOyO7ylu9qcpbmT3dW5Fd7p2WPcU7ddMU7+TsMu+kTWXe0myf9wzE T8wu8Xo3lXgnZBd7x28q9o7LHusdC/+Y7ELv6ZsKvaOzR3pHbRrpHZFd4M3H4KmdvZ2rnW6XHRjb Dj0hhxje0+Fx7HHsd5jI4XfsdOhxMSnOFK1LTFuRO66tmNd2TdtL2+oxya8la57kLt0KYtq81ubT Nj+0McV72nTpUUBJ9iRXkp4ox5Y0pqTA4Jw85l79jLE6k9wZBTGJIibRmajl/5Ao1pEuXEKQsIN0 C2K2ikRngf64kH8E0ExCXEYlmYWNFhpf6LcUTfKLC/zpE+Snp7jMH3aBn7xlk3wNQlxSavyZBH+C /EMlRnnthg2UOrzQnzrBF9A3bkwdXlror5Pa4zF0k9SEkNLMqYtqF2X6PKdR7J7Y/bF64pP21+xa TIyIiWmK0Twx6HxMtDNakx9N0bonuteAghib06bJjyabnuSxwSPH18laVFIQE+WM0rw5UeOiNE9U Tm6BJ6p7z4LjxrlFjpOvnLl4Kj6mLlqcafyiVCpqZTFTeuXvosUoy59ao0yZv2scBpq2CLZYORf/ fqv/7Sb+7A789xv/SZ5hTdr5VKWdB5wLnAPUAWuA1cAqYCVwNrACWA4sA5YCS4BaYDGwCFgAzAfm AWcBc4Ea4ExgDjAbmAXMBGYA1UAVUAlMByqAcmAaMBWYAkwGJgFlQCngA84AJgJeoASYAIwHioEi YBwwFhgDnA4UAqOBUcBIYARQAOQDeUAuMBwYBniAHGAocBowBBgMDAIGAtnAAKA/0A/oC/QBegO9 gJ5AFtAD6A50AzKBrkAXoDPQCcgA0oGOgBvoAKQBLsAJtAdSgXaAA0gB2gLJQBsgCUgEEoB4IA6I BexADBAN2AArEAVEAhGABQgHwgAzYBrWhE8d0AABEFUJ+MQR4DDwG3AIOAj8E/gV+AfwC3AA+Bn4 O/AT8COwH/gB+B7YB+wFvgO+Bb4Bvgb+BnwFfAl8AXwO/BX4DNgDfAp8AnwM/AX4CPgQ+AB4H3gP eBd4B3gbeAt4E3gDeB14DXgVeAV4GXgJeBF4AXgeeA54FngG2A08DTwF7AJ2Ak8CTwCPA48BjwKP ADuARmA78DCwDdgKbAECQAPgBx4CHgQeADYDm4D7gfuAe4F7gLuBu4A7gTuA24HbgI3ArcAtwM3A TcCNwA3A9cB1wLXANcDVwFXAlcAVwOXAZcClwCXABuBi4CKgHrgQuABYD6wD1lLVsDqB9S+w/gXW v8D6F1j/AutfYP0LrH+B9S+w/gXWv8D6F1j/AutfYP0LrH+B9S+w/sVCAHuAwB4gsAcI7AECe4DA HiCwBwjsAQJ7gMAeILAHCOwBAnuAwB4gsAcI7AECe4DAHiCwBwjsAQJ7gMAeILAHCOwBAnuAwB4g sAcI7AECe4DAHiCwBwjsAQLrX2D9C6x/gbUvsPYF1r7A2hdY+wJrX2DtC6x9gbUvsPb/7H34v9xK /+wO/JcbLVrU4mAmLXma/Asu4bcQHbmy1d9eKaI5tIjq8LOONtCV9CR9RNPpPKjraSPdTfeRn3bR C/TeKf5tmFOyI8vNc8mqb6cwiidqOti078jdQKM5uoXnSpTiTa6jniZ70/fH+L4/cmWT/UhjWBxF Gm1t2pvw/l0cbjqIVy7KTf1lWVsPHWO0+DH8liMPHbnnmDkopjKaRJNpCpVTBcZfRbNoNmbmTKqh uXSWUToLdTPxOQOlaYjC9mLoo1HzaD6wkBZTLS3Bz3zoRcGSrFtglGtpKX6WGX/v52xaSauCn0sN z0rUrDDKy4DVtAZ35hw611CK2XMenU9rcdfW0wV04e+WLmxW9XQRXYz7fAldelK9oVXpMvxcTlfg ebiKrqZr6Do8FzfSTcd4rzX8N9AtdCueGVl3NTy3GkrWPkbP0jZ6kB6ih425rMSs8YyoeZlhzOF8 zMFKjPC8Fj3m+VvaPFurMXY5tvrgSJfBf26LFkuC8ygjz0MkZ+H7ILOsOmYmLsMYWB8dEZeuNsZ/ 1NtyVn7Pq+bjphYzc6NRkupY78n0NXQzVuBt+JSzKtXt0KxuNXRL/y3NsRuN8h10J92Fe3GPoRSz 527oe+herO37aRNtxs9R3VIxP0gPGHfOTw0UoC20FXfyYdpOjYb/9+pO5N8S9AeaPTvoEXoUT8gT tBM7zVP4UZ7H4Xsy6N1t+Lj8FD2Nsozi0rP0HHaoF+klepleo2dQetX4fB6l1+lNeoveEzaoN+gb fB6m181fUDQNw9f/RzDPN9HU4N80/R8ycwol0samX5uWNv2qj6QZogQHyM24S1vpYnxjb/H3DIWT Ik1/pQTa2vSLPhnc+fCH5llHbm/6gczYNRfpb2KX0ymcBtIYGkvX+tdm+h4jG04pSTRIbNuWmJdn 6R7+BE4gGrlwhrGQELmeGJNm256SkuPe3i9sgx47qlF035oTvgGn85zDnxx+NevwJ/viBmbtE1kf f/bJZ/YfX40dmNXns7c/69XT4UlIsW2vQdN+7u01/fSwDTV6bI5s74moyfFo4RtqkCQ5JzPl1cxX szJfzUSazJ69SkVsWqyBhGgtPDwhzN2hh9avU0b/Pn16D9X69c1wd4jWDF/f/gOG6n16t9f0BOUZ qsmy0N/8rUwfdzhMW+3OmdjH3D4lJsEWZtbaJcd1H5JunzApfUiP1HA9PEw3W8I7DxjeobAmv8OH 4bGpiUmpcRZLXGpSYmps+OGPzNEHfzJHH8o11Ry6Sg8bPDmno35dpEUzhYU1tk9u23Vw2qiJMfF2 U1S8PTbJEh4Xa+2cN/nwusR2Mke7xETOdXgMptPddNC02pxAHSiD/iLnfQd1bPp6q9UuTnc3BkVG Y9P+rVEQUUpEQnhSpEq3y0+b8Wk1Pj2dRbqs7hYlxnR0Z6T/bI2yJndIdUfaRJLJSla7VXvI/aT7 Nbfutrqtcanj47xmL+Xk5MQNHJiVNWVKbJuBsZCxfez7esf26dVTZE4Jvv0zMx2e9khpTf+5pmXO lnmSVaLmNJnIgpuXnpQUZtyxTnqaHq27O2Rk9B8g+Da1CXfraaZai7CnO53p8RGmeYe/mqNHxrvb pabHCIsImGxtO7V3dU2JNp0tPhVPnZbkiDbp4dYIMfjICxG2CJM52pFkCkRFW3TdEhO14fDZJKii ab/Jam6PZ9p4nre0o8GZmNEtdjEGvH9LjMF7t9gM/n6L1eCvt2DaMp/AF+VoShZZlEYZolsgfoLp UdGV+lFP0aMhYiIe8Lf3SYisz4ypsb+7G491Q1pyo8jaUpMWn9Eoum2tiZ/Qz9Qoum6p6RfRU/4P GzVoiad6d6aEnJKE6LAWT2dYYvBplc9xYkJ7TT7WcnpMVs1sSfBMO3vU6pcuHTPhmjfWZM8pK3BY zLrJEmWJ7j1uwbiJG6oG9Ku8bNKYRcV9Y8Ijw/Tt9uS46IQunRwld/54822/PTQ50dXVER2fEpfQ Lj6iU1an/HW7Vp79+JphGVkZYbHt5d/P30xkuhT7QBw56To5Y57UnDQRn4z5irdjsuITMFPxcZim +GTMUfyjWm9sLSk8oynBGTXYZvAvckZTgjOa8ii+8kdgRq2B6GJHo8hoMJdQzr6c5hl8m6lXzymO hmhMo3VrTXSxWUYGahCKacsxtgA5RWkdMvrF9u3fJw1zE94X8+WOlVNlunTiXfvvPvJ9my5d2oj0 e7++uXhb33n3r3uoYeX9CwdqN9x76K7xzk6mczs5z7jj6+tnbzt/9G+xQ+t24UnZ3HRQL8HIO9F5 ctwN4fHB5yQ+OKr44Kjig6OKD44qvlGL3WZLpfap4ejxlvj4tmGNovOWDsVt5YIK7n5Zu2MH8uB6 y2ckXoZuq0FsBxm8tcaIxrJp3uWMIcbKwSWyVJuYGrNeYoq0hR/JEDvDbZEmQ3ssCa6U5A4Jli5t tALDuzu+XazlyMhwuyMx3hEbcfjLcFu42YwP04OdnNh9eNymIuw9WfSVHPfWnF7CbQ0O3RocujU4 dGtw6Nbg0K0Yuqddm45R8vmIks9HlB1hUZGIiZLPR1SjZve0IU+iGEOeePlhj8XXXA/qqY38z8io kPww6tp0Hd8RK8YTs9MqXrcKa+tdKWvKgn05IgvPiJzE4FTam6d0imNL1/FWbl9DVpGkW4/ZjbKm TZ2SmcMLLjiTLSeVF1kifEqaiiwJackprgTL4S1QbeXEWhI6JLdNS7BoY4yphkqxWOWMWi3a0MNP KW36UKnDB7Uwpen/sPIl4G1U976zaqQZLTNaZ7TvsizbsiXHtrzKu2LLcWwTO4Q4JrGdEBhIAkkD ScretAXKUgItXHpL3+2ld3kfbXYX2sL9XqClLX1876X3vrbQr+kCPFpR6L1QArHyzjkzkmUnoSwv yieNR3POnPNffv/f/3/OSJE2vh5I24ZthtI+2eUYdXzbQWKqwDFV4JgqcEwVOKYKHHsKeBB7/tmT QG4sP46EA4Sy5DZH0Ukw42UTLU0JX1+aiM4WcEiVw18asuoL74FRprFbEQYIDTy4eT3UaBIeBVh1 vKw6XlYdL6uOl1XHy0ID0dti4wGWd43zSzGmq+TyQHcJGFK4ymvU+LE0iWg0hl9EWWrksFk1DI7b 7eR7jDXoCtXYmWJ4pcbwH2t4R8Dp9FsYg7k4gf9MYNxag5bW8Czx+cWbyn6xpLl/I7p0eoaiwQmD 07F4fvFRpwXKBsPIYSAbp6LB72I2RRQ2VRQ2VRQ2VRQ2VRQ2uMce05nGbQt44rAGAR+efLGkOtdR 07gGfnVE1ihIV5q8AnRl+4SuP0yBeLd4yhEvz+4lGACHrS6LDqDbk6U5fPANneBW9KlJAGxrx/4d 6ZO/snNnJ2Gor3ckk2ydKDoXPiKAQ3V6ww16PQs9noUez0KPZ6HHs9A+WGih2PlnsxI013DTGCc6 DEmxoU7jqxrzrSs5dJcZMIM0EMDpki8DqlE+EjIdyXQa8o5pQBMv2oe41MkyUw/hkFYAgoGHlkEm Yhh4GloMEqQmobX6JEfAoiWKaZKzeaw2r5UjioM48GxJBGZS47rKXx8WdfheGj/IOX1R6VqTy6Jf 8phtHxxiWIakQKQFFPCR8vknqsN6Z5Xr3BT5hLda4nQWj03F2ZtpAevAnkBMJGYyWVWxo0+T+mlA n29BsVtVsVuR2L1sXV0Kij0lmuAbuDDF6+ERuCQFL+Exb8s4W2eKURKMJ9DGkIygmC+QcjINObhx RQNRbVGSqSJK4H4hu912EYF6SUc6WmGf1M0Gm9PQ7IyFQrbiVf5uN0EQWotPFH1mbY1z3BPzeQS8 1dOUahBxAgffSHa/WTtoBaSY86RixG8yn23LPTx07j/LDvkvVUHWEfct/qhx9srp5Oi/jhI/AJyP ooBvwieszxeo1+kAZgFx+2vItp1WKCMrNE0rJCtWSFasoiLGdFbnx+qxW0Ge41WF71Vt3qvSQK9K A72q8L1PAxrIYhIeP2KaCEHfpSeXk5bpsg8fNkkLePyYbJqgQ8iV6cnlpKUiC0GcpYLjUa8PPfjr Q1/++d19Q4d+fei+01/qPx674qs7d351Jh7d8JXrdz26qYp4+GvnDs9MPfHu44+8/+2ZyX/8z3++ 7vt3r7nsnqe3Xf/s3SOX3fc9xOCAnXHA15uwPuz7SCJevk5o1oKpNEOhNPN6A55vhkJqhlJpBlI5 Gc+CP+NdApQFOBJUmQgqDggqDgiqTAS4rdNdxy/g2hM7s3g26+hYwLnjgTGH6t6Q9UwXMmWQL3k5 AHUgpiN1Wdj0uAwaBmDLE7LaFJofokCZCqeOkXVkKLSCANkdXhIyIwZYoMVuxxujsWi0xAE5jTXs dQasHLXXVtt5WdsNOktAgjgJOKGlods5fMOaWKhnY8bfWFtl3W3UFhf71kpd6Qf+qW+2xwccXAvM C7hWQ+NUV2jxF2XHBpyJJg0tkzt6u7eNtlqNifY1DcXfhT3k5/LbHYymmA+0rQWePni+QM4Cm1yN VykRohukcCaQlHWr4uxWxdyt+nm3KtbuBaImm0hlLVY8n8oKIHNLhVN6lwjbuiDMungevoEmLqg6 11NEA8Taoy7EEJ49KqmfVuXzhAmSLX3d03gMa8ZYPJrlBH8z3pzl9HhegCv+LDxqFpoFezskpN0u Oj5hByas2jhQV0GAeVwiMc0X+AKE6zL7MitfLBl/cx3chyULLODrJ2XUaxx2e1JG/dKw47JLgNYJ tesl56BKzqHk8nWaSyRFGnK2d+83prt3TLU5OAroy5heu2uoZbo3nBrfft1V4+m27Q9clpgaabdo KILUcAyX7JtubVrb6ExNXH3d1RNp/Jor7p1N2f1BMeIDST0TrAp5m9emm9e0NaQ7L9s1OnbLZK1J 8lk4QbSYQa7kDnk89T2RpjXtqXTHxC7I5ILAz64CPCCMHVTypDB0saow7oSfUSde5cCjBrxGwmtE XFpQTQAdQAcUS2fgQdYMT0miJEYjvnGRNivMzpzpEsy4IiQoYmx6Gp+engapuOtk+TIRXQfdBQU+ CqJ1U1NFuEuBnJshTlJGKeaxB0RBz5DFy7W4uSroDph1FH4Djm8ntcBhfGEDqfXC/BkHrIfTUkdQ hq01sB88Q3XB8zDDhnOvB/zwXZQzrFHmHk/i8To8KuJRBx6z41UYHh8PcYJnXKigfA31cPTgH2B7 lV9Xsr1yfQDHy+WBigmV54OTvzfQ5njQH7ZxVPE3xVdovS3sDURNtAHfXPy2nuGBRqN2VoPbcSvN WoIeX0yg9MXvdNqdJprUcjqCXFwEMYSkTU47MUF02V0mimQM2qIb/73WwKC5Lj4HZ+sFs/0hmG01 tkvxZ+xjkHU9cEcHypiezephChUZd2nM4xpVv3ilB50sf1dWagXrXRIDwDtHuqmp2VLW7mqFCNq0 xS9ztCkW8EbsHH1USjkJR4N0jOQsQWc4ztMc/tdiqARn+CvELx1OI0WBTLF4z6rdbZldzfhnWCOg vEanHcy7DTDdQyCSxLEulBEHBeDYR11j+hjwcyV1T4H/ENCDLvjdcRl8SccQCijpegr8r+Sx0J+b 8UApDAIYtyEQx8EReQixWsrpJ1mzgVi3eIQ1wjhvZImXXD6KFYyLTxI3CuacxWXW+kMRg13y2cgn tILLDOmDzx/jJafXem5TEERBHujs91QUeGeVorXjoiOmjxoWCDyrc0T94DwXBdlJGyBN0YinOvYe zBfnzVfRV6n5ZkEwZ3ApKZ4+A2DKnHHyrygHkDXxoIU+9p681EbNMROg0TIzjgWY5WUuCpW5yF8y JB8NBCJWLTlVzI5TrCXs9oSMhBbfTunFmFcKiWZOS36W+Da+rd0OtERq9LrCH3V66IRuG/kcZ2RI nATJifbWIgt/3+8b4O0fKD/mxRJYC7YVaSyafpogMQ7zEfajNhtXs0B0gPlyzthvGxqYyKv8XPod ZhsiM3DCGUgTwcEZ/kxKqc82xH4rgyv5yKsyP8ek35HB1YjPlEI0wG1qWSVGDcnkUkHGsnRI/oM7 3b9utrv4P6zhsBWvmrl5ssYSbgolRjLBP9tq+9v/+Ximu8rW5mqe6PvBr1f1pT14unGyPxXkPQHy mwFPsG+2O9bXWmvUVveuxx8NtVbZi8+4atuLw4meOrH4TXuiE/rrteffIu+g6rFV2DVQCkdELLZA dGZZvf2DpKfLQ3iCC7gZhMKtxHv+hvoGoqFmAV91mNkOC3rTBfQGiMtpWMw74bF/IHsE1ICVha0N xHtyAwOvPyKDBivqeFQFv6MuVccj79A6G1dPN8tHbhkYvPWonJwaanPqQBLBcNGu6ezADWM1ycm9 qzumOqoMGi1NftUTcAbclsEvvnD7bT+9d4h3B5yhgNkpaH1hb/O2h6e3PDyX9oa8GpDoAbuHVnAO WAGs33UqFXwLkYElOsKa1enEs8Y511l6W4nAKoV4vVE8KxvnaNdZmd62nLCGLl5lI8+tvutHX/oA qVG469/u6PtO1brPyw/cv/Xg5TWE756fHuxWNNZ/5zM3j9+zrfXcmw3zX4G6geMzgvHVYOuRhTqB aqxZq85v8VswnfOv0ahGes8wF3tPs2SXIEuGMVC1SkvU+VcZXGaQ3pMNcxrghZoKo1yeNC/Z5PJa GkqijRTDaRZfg3MgzAzHACDkmOKV+DaGgxVkcPwI/i3AHag+IG1GmQ/Du8xmyaQt/pThnRZB4pni PzK8hGZ2/n3iLTCzELYWzYwW4MzMbo5zYW4XfVYQHNQH/jnHVcuLgqVpmQT6rAyu8VMfyOiqZcVA zYfVAu3EWyZT8SZ8p0YPJ6HXFO/XAr4Lq1NAPWdNJvJXYX/xmJaXLGYnGPtlWmWyWvLHAU8Ajl0+ /yb5JpXCsthOlJt6vSYRPseFVZkWiJYsuyr0jkSDVz0LN7K3brUCfzhcv13VENSN4jEAIZNwMpwU ekdGDVphi2Ny69Z62OaIXL+9pCvIairSoiU3aWoWQpUBQrBqGCWnL7kW+SbN6ChTQ/7a/ORdmxub Z784Vrc59qeSDvEZu58XAmsvm4zf8sI9q0fvf2F/7/Xrmq0seY/FxWs9EU/71Q9dvuXhbavsNtwL 1AdVynh8xVmrhzE7LVz+nuf33fKz+0dtPp/Fp+qW/A8QTZLYBqTbkB4+7OYIc/AnFTBH9XwYAoTu ghCCEu+UouGj1fP6sIIjF4aNj1OXJP9DawPa9VuZohfVKgKwyhUQJb9Vi/+WsfoREXCUpfF8sbV0 TP6lbOez+NdKx+oM8WEwQxsWVjkOmBnLz6O5AN3CCaC/LllaHC6NRQdHAMZSHgH5nxrlSAN/cVUA d9pIf46IYk8CWNIQUQH9Xur5t/Cvg/tXYY1L9/cYQ/MixGZ6u1ItU8YRmqdFhMD09lKhTLUizbL8 YWlsX3e2zAw66+MeMBiQD+gYrdUVdnqrHCwQF6wJavG6yevW1DCckdPzDpPdKzB6k0EIt2WJX5QH r9jBl8AoW7BNyihDxJXHamvtLekfEB1YEOMIK2bHWGI2a8DsVfNBTnDPC2V7UOow/NupM0kYZZGj VF50QdUT0uAPq3pC4oSDYPslrSUkucMOA128+QKL2KEx2f2iM2jRgURIV/wWvlej1ZAiA7CChGVr YfHP2gsUVVyF/xicJeFZDWcUuOINRZ3WaGBVDCd+AaQglnRlgV7AGOaBixsPU9tKlU2oK8M8Bc8e kaltS0VNzUVqmsQveFPRZw0vjRtm3P1hgFDkT0vDOncbI7gUPdDzAGtbsKvRmkWNrTYGTOJ8Vhc0 JNna2mAjC/8SsOCquVo7R3qic56reFUR5YpYypzpAJrIAP8UUF0ia1p5eanKuLLGWEpSPqTGaLfR 84zF75D8ZoYo3k2Fqmxus44sPkIwZr8k+cxMVJR9NQFRh8cpPKWXAnH3Vim85DV7z92p1wNj1ZAH zn2xfPaHQT8sLi42Ej/yVjs5f7CET28BjbRheYRPATN8KNNN1S/gPwGm6G6a56odMKqQ2ypNUUWm LFf5/TIr1EACoNT/rFBTF8wWpSJ15JIyybeCzht8Ub74etUoSOIInBHcdtEDZ3tAcFkFbTGxLk7g 4J/G7HaIHkHTE/T7AgQ3/Gg+ODQ8FFz8QeVctSaRL4bHvjFetW7dZBX+DqrNaOFaCoFtPf8m1Qei Fqz95eC8n8GsBEhaMC94hxU70xHT1tACblLxo0x4UJnOdEw2bYVlOlMZSD5Sma6v+5bv7dt3cn97 z63f27fn+IHskcDQjevX3zQc8g+Dz335AOG9/X8+sKbv8z8+ePOL96/pO/j8fesflNuzOx4cu+Lh a9t6dj4EeRrQ2NXAgj2Ara9RuLrmaYAeAhh8O1CZEHuHpvWRd21z+grCcLpEzU10DARYkPNG3pXR JSuXDi9WLmMqa2Tk1Y2z980fKsEFSN0NoT5/6xXZ4NGeTlvS/uW/b1vdIBF/mLj9imTxgUqVaBh9 es38UG6LQNPFa33Nw4ouNlLPAF1EsAx2JeIQOr8Qhc/IY656+LtOgl+nT0Bh27eugh+UHujklMIf FO6g1AaPgevsCaQe+1Y9vPSoDK8Vu04ptAHMkLaq/qepXDlXABHYI6wGrlDaMxojJ9w0OxqM3zqy 7+RNZd2ZI03BVTd2G43F/13W4mrwuT8f3Gjz2uo6ukKOcN8XfnLw5p8ATX7+h3f27r9mQ7iu26aJ EMPrD10LtPrltRu/Irf37HxQ1epjQKtpwKTmFGxkCduxBj4hNMKfDYi2IVJocieEV9vaHJl3oc8p qFTKwM6kYA6W+XcUHsyJNuFVGVzpz7wrq9devEQau0iJtJyNOYBIKjIy8jGtLeJ2BWwsOWkK13c3 bitZAaCLzis/d0W9Z1W+wVUbCfCXs8yfbPXD2Yfu7VyTkiwMACNSZ+T+Ut2XdBZHy1bxk4AnOrCt G+ZqPBeoz1b9X6dE/DrUnpCKT0pJ+Cuvq8+/SZwD9jGM3anIpYcwH482RhuNHvgrCZgRQJUhq8t0 nvX00omtAL6FE35LvYWwAFw3IAdGyRkQDdpxgYSk8IHDGdTWIGcSnWdl1NwC2x+VLZAnGErufUop Op5KXIovfEi9kTjXtvXeifRMfhXP0AQBuDNXO7C5vTbf7EsMbJjeMFjduPFArnq8t8GIvtcxunjH eDqWrRFrBjds2jBYg8eGdo/WmF1unuNtvNVj1XlCHnu8LRrvSEaq0/2bu7Pbh+K8XTJxgshbQH7n 9DhtkbQn0VkXq0r1bYI47wb21Qnsy4+1IszAKGBOR+0migcx9qhrjkVYkcKTp95+DpZlKBf84piM voEQkSpnE0tkc4lrg6So02QsntGZA5LTZ9UWz5RSIeJ1qGvyV5HAudvLWr8Zll7MLoGBQRmM7uso i4gCRMsqmaefsAA0thPW42x0np93LUFxVwmKj8Mv4A6PJRTuqkThJZJgXcnqyDc7rvv7LTOP7WgF 5is6AxZtqH8mk9nUF9Ba/KLHZ2HwR3d/ZXtLev6hW4idJQqx+Njm+b5gsG92PbGjgtkFgGRfBmMP YsOoZoA5gOn8+XjQ4WcdNpAKZVnO4Zm30yojhpU7VBtSCkOoKnSy/P2KkixxiZLsdRTriPqC1aKe Kv6dhjKF/b6QlSHxFAEYgc4a9HgCBorxKhuajHryObvLgDY8nfsGuZE1qOVYHGs+/76GAWNvx25C 1VhdktVj7fX1+tQC/laWbdc7REMkFNIHFwh7VhD1zfPV8/UhjqxMVgDFKc9ISsI6l8grx+aMWSVH K9uV1gorZ0qGyAvmbElb1B1e6hGcPfUqZXBWeYMJkSN/Q56m9GKVz59wAlH8HwY3R/3egIUh/4v4 E6k1BzzuoJkh38N/R2otUCpGQqNKhdcT7y/SetMKCbHn/oWc4AzwrEF37l+VY8rocgBpNQFNPwik lcb2KFYaJlowJ1ZFYFk2JaVTTvDCjPDnS0Q9KhAKmN4fjepr56N6i2/eUknnpWQ66RSBASAbAHiE 2CSvUPvKBhctcZMxhrxIkdviWCrs4uRtJtIc9/midpb+A8f9geKsIaevykwa8Zri7/S0uSrkCdpY +hcm/WmKtQC2HDVpuOLvOp2igSYBUcI/63AU79DCuqFBFPFX8J+gaiIg18XHnU58E6woaoxOazED ZAOrpjegqumggtIOwnLEoHfCX1UJixiMXTq9b17UmOc1JTdIvp35OZw/9IDyV3+jfr1kBoSkswQd EnDe4jE9Y4oGvRGbjjpH/BdwgJA7GDHSHP5QsYw5+M3EqFINBalMPf6SltNQlEmCXtCHYWQEYGNc ydG/i/HE5hN+K3hhUfjDRqwfgaQ0x0YRDm1Ty9cAidTyEkRMvwSvOi6Dy+iogkrbPqyQHS1DZ0Uh OwKHuniD6KO0vAH/bTHA85CzErLeoteQWpO+GCAwo6nf7OK1Pm/AZHe4LMSLgbAFYqnJaoibbDbJ stgQhMxq4/kC2UX+GHGKd5F/+009vp5kD8npHI16PT7SCJcGG+GCYCMPV5QaF/C/Zo1YLGbCcD0G 13yxVnWlsVXdYdCqLlG0llahWhcIbdYqOJ7DGvlGou3ZRhxrxBsb67qrF3Dg+i8F8WCQ8rxRN9Tx sn6EwpJqbW4aVsmT07s2TZeWw08lNk3DohZa9gW4sWnalTVwDrzR8ZwM+wuiDu0yFsTtFOizzvOG XDek73hZhv2KSbWQBzdrwa4T00oeooFusmpVBeFLr1JJnnqGQkGBUSK2HZaRyC7e7XL6jG0PjA3e MFbbufufth+wN6zJdGxe3aDX6nUU4+qZ3Nq4+QuXRb/5pb65Ht/la7t3dIh6vUaj12/oGogMbO3O 7xyKDDSuXeUC0VrLSybJ4wx5LDXrbr7slKO2Kz4w0dMHdPQI0NHP6V1YNdaBnUCrDQBN2UCTuiDU pC4QNalSh38jqTct4O9lXbYE3KKQ8MM9qFCLCbg2n+DR1lSCzeowG9u0KkDRgObQJ6JDrgE+nwGH h+kRFEqBIhyZ8g6PJclPu04q7aKwYVYnK01p2BaY9YgSbIG0HZmKiBuzXRh6FfQuZUKMYLcjGvnz 9Oz904nVAwMxrdlls7rNGpDvguTdrK0azuWqttw9VfWkrXEy6+/M9sf6DvR2rm+W8Nf2PH3ngBBt jV+nVaqVWrqllNQt/iHeEuLX3PGdPf23z3WYq3tSxUcmptpn90N2sQHI2E++gK3CfoS4jxutdCvL cL9Rl99ePwaX3WLqzo6Yuj4XU3d0xFTxg883YIPYAsFlDUkjbpRe82VZQ84XXsCJY5Yh8o8N8FF+ nSEHlwY0h3UjkH0mCugNT6r7PU6pmzmzep/0mqx0YIE9nJQtQw3kH2XYyXHYiQ72ckTWjSg0FK0Y XHzrr0YhnZplCwZ+gmak9uH1yc0Pz6/q3vXI5YmxvlWiTkOYDaZY+7rWvbcEstPtmcmuhB7uR/pv giQYpIjHnN1/dM/nntnXxjuDotEimmO+QFXg5JNTd6xPhBMhrcWjSFXzK/pGbA92GmVt22bGroa/ jFrfPIa5F/CzR2OxGevT+FlMCxg7l3XOJAo7BrtaR1uJ+nw2T7TmW/ODXa+n5nKDYIpZdsMI5iaD eWNegnIjh5CBwsBX6EorOwmmp9U8HJbAUr8+ffqMoKyp+XckCvKOQVOrr5XA8nye0JOo97mu12XQ /wZ0A71cvgMpIaGCeyA7hjdJdKWVPQUAPaaVbF6JOJWFCyRfZulENKqSfOri4rctU5LdEY2q6iJt 1I2D9w1v2D8c1JlB/uSzMo76wYbO/f1aVPaxaLmQqWOqxRWuRboyRDJjGVVX67qqka6gZtuGp5Bm s/K9a2w1Foe1Yeuj2+P9TUED2TS8umPrFzcvvgxX4+E2b8I0sqkvvH7d4t2lM9T/IghfUy7eNVJv FJxCzOcN+xQdh5CObbxk1ksRN7KGO79/Y4Zh3L01Pddf1kAznNGgepbmOLCBvdgvkQ1MrsleDm3A F83ad/+AiGHzmB5YgB3bSsgndtrBaw37NDEGqH0DMAnfmnmOvma1s7BpsCs+Gifq27JtRLwt3tZU 93pgIgcgTnN89YiQp/Moza20gy4191e4Ew9Lo7/hK0wignre5CzImwZNcV+cwNr4NmAXqPeJutdl 0P9qeIMTsnoHlBwvt4IupWZwsYrqp1D9yq2nmuOMNeByhUSjpnjnCv0Hk0v633Pbx9A/vo4xS0FR AgTPaCo+he/Qs2hzEskYdPhfioaVNtCyLvlJbODcK/hnWIOOJBlOpxf54lPFiGBT7IJ+ht6B3aw8 k3IM27t9lISGkWsehbvzz2a5dEd6FLz2WqMbIJja93aNj44T9XPZOWJ8bnxuZuq1oQO5Gei5uutH 0mLB2JEDqEIdrx3pLWgHUFEOGESq0ixQMUh5eCTNn0nxz58+w58SkD04TeO+cQKb4+eAEaD+D0y9 JoM7XI9uYZDBPTrEggzuUgtvA2Je7Yi2tyCDW6H6HrCM1HL7gBhRVivgcKpOYS3FXmEGlFr4Vfle mXt8ZNshmu3Wuitun5j47HjiVcg9BP7V5gFH2G3T0loNyRjdsZRrcDbr3WsyUzoDs1eq7YlX9dRJ 3nodTZj1hkhLGTxKQF8ZFoDxjNoS5DFXX6Jnx3hd3eRt6zYxgtMS9he9u2Z0rI42imZv0GDgmMjw DVvw9/1hi1Nghtqnml3u1EB1y1jKaJYqTUcJEdbKYAJMp0UDOemVIBY/Rl+LRbEM9j3ESX1dbTjn ykAmmoF7gTNwp1oGcpgMpDQZGEIwLKlE6qQaoJNqgE6q7DSpBugkpD0gmRngMjEXZayGhEUcArSW OmocQThSQKSna8VzIwrrybKlhiJseUwWh4yw7TEZNYZlEER6ltX0K5kl8PSlIkMZI5Bmm8nHGMFt hc9wDT5yxew9U1WpLQ/MjN6RZaw+yHx0T/R+tq8L8BzAe7oDHdmBmFSiOXtHJkfuOLxl99N3Dvb3 Elxpf+tiP2A4Ww5k+26fB4yntwFIdxpI9xHA+BNYI/YGkm51sqmraUcTaYEc0eKHD6NYAjVwH2AN lG4NFHsN4v6AaZw93pf4ZoKAjzcdhxyykVIJEqXyIPQ3hz4V8k9BeQcCNT+8lbqfIp6l8JconKLc yZejQ+IbVxp3Ggmj7g33iFqCQ7x/1/Ulwp96JaEQIsjW0TMI2SBV80P5M6iPaPJlwDuN4hsyZuSN hIk0unVvyG6FCaEnMmC76fIq9yU9CPwda0K6YMhHYtLiEe/AzrHs3OqknuE0JAGwq2lyV3bHt65v bd/1+OzVD11Z+wR5096OjZ1BgiBigeEbJ+tsThtjlMwGi0nPSaKlc9/Cvt3fva2/74a/W2+5/VBd fr4ZRsPI+feJgyAatmNfQJUgOw8JJiKWLpXHu0r83aUSfJdquC74M6L11ZGF8y9lzfBJlwhbaBp0 Rgv1OX+ez6EAmIL8J3Eq/bbCIdNwm0lWaGILMriyPlqQ1WtRKEt1XbBGXglR5QWpJVxSVsiJgxSA FcbmjbsijX7jC1pOR5tNL8DCmAgC0y1KQnpLKHftUKgnDIsDJovDSOs4nZgea92iIMe5P5YCDGlT 4GJ60+cn4waT3uKCKBABvKEVSGoeuxE7jiJEdbUtnISsMcNu3Al/e3/MZstshZGBw/o6M+yunRsp +hqYjVg3D00OeAtDg3Wthb5cYz6c4/O7K5MaJKhSbnMqjfhi+kxKWayDmwxOKr1tRt05ZdjfkLcg gx77WgtyqU969/JsB4n0w5IejebjSdqh8oBLJEmaVgAQMEnqr9KaIXAIDKXT6NL1DY7OtXXCd5VQ 8N2ViqmeOjjtbEnHHUYSZwS/E34XH8qtjm25a6rqv9thUtXR3R/rPdDXub7lYkkV9RxJAuVJjePN l9TmldMH18UphmFYLatn/1YGhvSt3UPfhJmxx7G3kL4PHdrxONTz8QMzM0OXz8KjHZYdXQkOkgPd kH9oB3gdwBYId9a36uCtBx7PPVa4Z2Dn7IHCwdxn8tvzl+f6810cm6DqjVBNrSM0+DhZD1LuiYI0 iAxBRXrFIlLKynJaZYyIIGTQu7KRRt1+4n88d89jBRne6eCBgrzyXq1GFBZaR+rh7bKcDG8oTRRk cEtkJWp8UMwlpe4wWKFYvGwAK9Jk28e2qcAlzUvZ5F6mFzbmRyXVR3tRPu38oAmaiguYit1IoYVl YClVyFJA+p1Gttc/GGMsMEFHtscC27MD2zM/BUCBEkxPlWyvKK+0wnDumsGaHhsL8IE1aG3+KudQ O356hWUQwc3Tn5tU7Eh3gR1tKVumTinh6ajnFctcNdY8e6FlXmil62DvJh0FQMfi9wCE2rpzSsVp 6llgjZuV/dfHBgeDE2GIv3V6OzQ/32VBc9CMZdJ12sKGwYncaKFrIGRPFjK5eN6d1yMwVk0KIvKp 9CloUmm0KK7akXuDtiDDtl2jBRm2ziQLcrm9uGQfXaX4VVLUp9JyYOk09SwUvA8IvuMFBSpe+Jjq OhQBZxO9Nh3c0sz73VoowE8s+M1L51QdaDQgAlyLPYZ0kE43w00gZ49t8Hp7IQgcuba2GXycGBns nbfA0qoma7tqaGYgVpgYbO4tjOQ68rU5Sc0NlzAfpoUvppWlUKgSM9LHMdDFVagPpww7mYgVZNAN SCXkio7ErkqYX5b7XST7/8RwrxYWNBpFC1bGXs79kVI+KcoP3jd8+f58QPqQjP+TQrtSTFD1ps0C 33lIqfoc+8IXZg/NQfTeOTHROTIFI/jsQ7ONCMU79Z2z4LUzAWuVHt++3TsP5e4v3DowN7WzsC93 dX46P5JzODP5SL4eqOakc0gYGCzQJfCGywCXgu4Lgdt7KHfr/QUZdr5vZ0Fe3r0T9g/QGt6BHizI dBmt1ZtUYPVKaP7bZaD/bxgdIIoXgeTB+4YuPzAc0JqVAqlYt7q+c38fMAj4CCKiBLXNnwqWD1Hi xWD4IxSQAB6zuk+Lx5AdvE+eADZlwdYpu0gP92NPE9dhLOYDOLBuzA+tydZUXzOWGym0D/prCk0m uikXzUvI+U+/yBdKNnIm9crbp8/8DFqEfSzXPlKQwfVNNQXZlC21gF5+2vliIrVs/185VyA/guKW 1VttcKcpeUJnj3k9MQfLOmIeb8yuM3+IFga399lrwi5WQxFAFYIz4u5vJRinRP3UHYU9RN3uiKTT SZEPGj5Mnkr01OpYjhcFv5vRMgCfXaIiUfptJNED2BHkp2vX1t4I5XisZrpGBrRqxwm2BrwyPgi1 BzbWorjX25G5MWei6d7dhdnBjbn1hdUDtf5MoTeXzpeEXY57AFhfLIm8VIX7GfJLBXKzIdBVFvQ1 u7sgw95Wry/IsL/eTEEu97gsEoKGzhc/sk4+RD3URWLihTqj39Y5KnXmQDpDXlW85m/5kK/kQnEJ hcoBoNLaEFApTbAGxixFXf1tQKXOj6zSS7mL4YIgenGNFx9UfWgb9jDyoSnVhxoAOG8LBrfNpqCO xVxPZ711+yxUc26msGYw1VnI5VryAKOpw9Kogr0pVb1COq1o+EUAtcCvnod6dSnNgWpza2YKMugh 11mQYR8S7OSIDHpR0DVVUino59JaVXfOKNz4U3ud1HnVqDUednM0SVAaVqOT4j5Prcf0abzw/XMb d0/UgUY6jud5s4tndKyldvVqsv1j+WTxQdUn78OeQz55++2b7p2B/ndNEOhqB9DVGPgjVTcOFeW/ b1P3pu7Unh3XrE0/cG/ursL+gZnxawp7TPSe3Hx+fX4YyPpky2hdrnop31GxEDqoqroXS8wUaq+C nqI+999VkGGve65B+Kj02wI7BrESdi1VV2Y2KmxCX724QulLqEm46BbrT+LKF7rsogG6nlgTlpAe DYwgAT0i14OmYK9STIFkgCmYHAGnp9Zr+hjerQbIlRbx0v9j7VvA3LiqNOtWqVR6lFSlV+n9fkst qaV+P9xS2+1uqZ92245t4m7bwQ4Zp2x3x3YCcQjkRRIYZnDixJjAMNllgf0WJrbTfpCQGfZbw5IB 5wMGAoGQST5mIZBPCwwMCQOR995bVXq0u20nrNvdaqlLt3TPOffcc+455z8rc/nPk2VFUDgzhwRF zaihpHRRG97xUpdsLfo1aCMflOr+l0ZGckPlfwR/JDYTNjJGqIkItLZyt+aYC6R4zpSDX5vDF8jZ ksc5v21zb3XPWHlzdb48PTlUTk2qI6xvkq0Qo0oGSv1AqW5YYbPqt4XXmsRkT29VhMPMb66KVw7k aIyknDatBK1R92rBX2Q7UxsRm1BcwxFyOkICimt8BSywOo0FR084de0BhZmkhtG3d7UL17agu+Ky BU0volf//L0V4hnaFQMn79yUlq1nD9QBjxMvSZkmD5Di2b/duXPg1kFkQ5fTaSGKT8EGxIFHn4U8 vp/QI0ta+IAwAL/KOsTeKDE7Wb5fT3+0cveov3rb2K3l91W3jQ7mytXZ8trJrslo2VR3i+rbdbEo u0YNKxqyutWOlgoL4vLQt/mrIhp82/uqIhp+tlwVW24guUv13bt4lXDZuzaRV97Km8zzZcKm8Wgs IVdDHPBuDsWBzUnicN028jININnlXXGBoxS7HGxGITYoijad0QhF8SCrXznE9q5OLVp0ARSk5fb5 ipIqSRj1OagzNhC3YJ3h94dHdWiP2eAMo23F2teRmxi1VItjYelAw1mmFcOubkN/v64BbBOjRUtV hFcrBxj4ekfdUW7xkd+tS0x97i9Yudj3df4F6xIXBUja9l/h2ryD+KyUC7lpU3vO79djup3dlcsN 7sfnEnfsbEeE9I6WBm+DhLx5bGf5xurkaHt4sDpa7p5somhj8dXJKh1KQOKaZCs5cNvozZDAaJTJ G6siGmd0sCo2jeRoXWXvhODvfl3R/6osHkpaPLa/cPFAhiWanFrn/8fVscIhonRS8WvVl3CM4VFs D5fG0TEEuzccJjr37mVHt3UQSNMKPDuNLB7bzqlSuaPc3y9kqp6xcYKtCmU1DhgWJHO4WJR2S8jH i4iNZqUA8/ROPIBLrI/gyVRFNIbAVkU8ikNmoDRMujW7cQXWNAdtFOZcM8QM9l0RpBnbPx4d9bEM Rak1tMaKYjodAQ48rkFZJwGz5ucIx8rM/aK7LEQ9NgZepNLyvmROGNtT8lLZVcI4Evmboz4vKrg6 L8qRY92cEjn2hnijVh2dODRNGiWuqH8BV9kniG9j/TQ05JpGsa+z8R07DKIReaiuGdcH7kNLLGXY b3DBr/iHiHw6/oGyWD50KH9zdcvYdLlc7Rm9z22MV/Pl4KR18kHkvTBKUluh4aIWpZOjpqyAK4+O IvLIW26uimjsHrjR4dHz8aoojc88iD0bpp75Vmi4rEpVo+odeqgr8fidsV79Cy3vh8wa3VPyXc2m RbG6+IgPLsqW0B44HhlDQbywAcmHVs1YvfgPUD5QKSgaAeUb0Gb+51g+rFA+1Kobmxl69bU6u6Kw bJ2fe3Br0miUX4ZvwC+/d3UZQhgFXdC/fZj6JjFETBM7gYA1tM2cGUN5AmMaFv4I8BYwOdZRvHD5 LRRYLcoZAvDx1XPoT0VmBv5aMnBmMDnjVnHtVAfDoHg2j6OwXysZ4C+ZDsbtZjoyKhS5LXWi0O02 dIttAR6+bVsqWtLDxyjXzlC94z9mN71us+3qpX45WE4F1r7UO37jS4EZubS5iPNbqy9KYch0xyUU srVDKUSQLCb4In8pDf+nlR/Y9MLjsuM/FlmbbdPrIhp8kPqliIbvXfuS2DseuPElMTCjFEIXpURX /hv1oCQUEMXijsXV0BMT7DLakeKo9aCcle4eJXNFsEMPDXTG6smvCHYhFo8bKfkZ9bCFuyfsKcx9 eLrnvW6zfbj7jXULs9nOWz+/uP/kTW18MB/I5wpRf6Rzxz2TyTE/4E2mWm3vXPtYzr73xnw5Z9+0 c+MvA0mH9v7bJ/YOuanDYX9ka276/ZvavII56wtnSR0ZXLN9YGhhSz5a2t4ZHOrtcDon29bsikXn 1k7duTmj1QRrv93xvkBvJbH9Zn9P+e35/iKpcWaSCdvwOm/7EM4rgfLxaeqfiTXQ8nkQR98Lvg1I mxBGIzGKshQMCS8x21spDG3wqcLDqPdZZhz6utTZ8KTjDVpimxQxxL7zaxexjsDZQ4amd2bQW5fE zHgYvbmkFcOTtOMNkZaZIsX/JP84upLf29VSkE7a60v8ynyRHvFJMf/eTd1WDTrLQAe9lb8aKe1e G0iOj43FlRSS5Nj6saQSIb4iiSS6/+SuNr3ZZuB4K4vieBanxbVm7+TeZF+Em7rvqZsOPXPfmCk6 kNyvlQp2tLU3cVpJcf29ewbNyXV5tJeehFbl39OLREFCSlsqdoJUA8RUTmloQjeV0U7hfmv3SZCe GNwT43riZBM9+ptOQvP0pXB453xmPDJaD+jAFQRyMjyllJjcJ0F1OjM4jqMV65dLxqj5GuGa5Qf6 1N+3nKjfNSLtiRZGyUQe+0TlPVcPpzSnHysREpJ44PJ/go10jrARQeILElJneCZ8MEwJcga9INMJ P7fgR6yEBFljCTJhhWfJRcJD2FYDhZTJboOkPKfzl+A7UbvFJSdfwTR8sZqW82zkHCcJHNeJLjor SldB0n0j3b5SUb4FmYdIU0AVAYaW08bSNtCfRt916lD3MxItGNDen0r2wW9JbqCD9tUmbADw1pJO /oAKNoD8QVbGBrji1k13hMJKUVBs0f7wEFz/JyDVK8QWYrckpV8hxsmFMxsSO1CL6xt8Q5BOWBvg 4JQeaoP3DvnCI5WdmxDVtk9lK33LtcGLBegUYRDqhkL4/mu8BH2irw8whUY4J6Ihwn0rKoVvFNLK QNfSC1eUrfU0iNHEE7rpd+pjnbf83S35+Zm8nSFJFa1Ta5Pr94wUd6zxhdaPjse23zHmU3Z0a3pt zt23ZiSumIBvfxPyMZUeGEiRI+gneiYpDZPVxBmtRpMbKg07Vho3RbsjpoGbH5oiOxTav/2z/p3r IqZksZ08rLxWlwDlmyAv/6D2KNgD+RMh2omncK7wTAHhjON0evj470i2o0paGQIgR0IeRaxLs4R8 XRNMliT7dbwsxFKd00kUsmgdZCE/nk74K1ZkFkrMhKtB4iLOnZJWBFoPS/A9iSxeEvANtBXbeTLf vpGW+EW3QMwJrbWELQtlo6+0ZyyQcWhVgGK0jDpsD+Z8RsUesyiU5vYc3ZzW6Awms8Hs4hnamilX qP9x5QIiAKbbRriCIlJl5GkWTfUcnGmsZXqyhCLcIfyn1olcxzSu8dGv/onlHeIuuEN0Ek9j24wt doNkHuRLZjCVv3D5O5hdeTmdMI/4yeJHnE6Yf5aMEyGClbm6OmY03DRcQiZDICZLm4cQ0tOJime0 fuSFj7kuwu0ix+M8ucKriu5D4HHNVzvky68bNEOGCr6rccR0/3LtBDZr5LxrrQHlXR8wrHwo1Ng6 Vj7IUXQnpKiN2FjHez6I8Z5XhoxrrAmsY0cVHdvAdx59d4q28VmlT0V/B9pZG4AP89ltRqjOGNE9 xiNIyLgD/VyYBaNXop1L2JVNqOi/qtsJPp+AEFR9BQkPGCMDY1BgbC6gE6zzGxCu5YahuDxsU03O b5bV7GACxZ8Fb0GDhQfqMxPjEZzlPTw+NJrprWQmnU3S0gzI2iejjULPUMbWQ1YH7jrpPj2BDI8l cWJ8GI9mFFuHU8RJRoO4mimymm1ik6scZYGjvyOZKFBrt41k+w7hDBF0JiO0rcv2Ha5bLAgOQ/Dy zOTfVnq3j7TzmY0TY5Gtt1f8Ddsl3LfMdrnylcZ+eseWGVduOJEfSVmgUTOp2H+Q6wXiAuY6J3Ed /ZBNweWcXQXvHhWt+fQ8r1iEGPi9CfMdvHVeNgqxlafLjKeckYrCLuRV1a1C2SxUOOQ+LRmGerHp PVKI4pr8aCX/6qZhndAnpq5hGrYQExJxF7IMUR3aK5CKCHXkeUxHTzEJEmaQNCG8zxgLYhoQY0CK AkkSrIAy/OqKKMPIufHldEDXBF8caIUvfobUIbTX8xwxtQDZ6US9nrnx8AVAylmzqDZNJmuuDko8 p/yTYE/AksiNI9gTsp4Vez2wJ9Qr/Ye+fNvB/3agu+/Qlw7Bx55/cA/tm4GuTNBd3DdT3jcSAP/n wFc+MrH27qXb4OM4fLyrcu9NfZ07750av3d3X+f8vYh6J2vHqR9A6qFKydNKpWSwewX8eEkPNoDk kRtik4okcbkkRsWV6iVXrJKs8DOrVklevUgSvvNaRZIriN3qRZKPzCdGhkuRJvmz2txmJjk5tTGD 8nn/wdaBiyRH4yN3rhva3uMCv7z9q/eN8aHOcG1I0dqqXyqu3QdSQ0nb5P1PHVl/z55BC/Ttap/a tG1wz13Yfz6O/WdE3fOSZofk9evTaJmmdaxSYIrVcRrVZKSIDkkQO2QB7ZD1eYcsuB0yAzpwTYYt WtGvSftVfBbRxzXei2oy+Clkvqxck6GUZCjvc2Vx7q1rnO/FJRn4vS0lGQ3oh+v3sbVopfutTD1F uvDeYzsTo+vHUqjTjnUll7q2pFAWXEr2hTmlNqPVi/4PqThDSnmte9HkF3A9tpR3utAFYpwstpxM LE4RX06Waw6Jr1lugQE3QALJMeGCUh0tadPjMc4WqNgmCXkrw6ZPuuEvn07jC3Vi40qHvEstqw5Y SR9iwVSTXyDVWo3G7o3YnO1d/eHl2jA63N/nNQQjXlZFAeomwWfSarUaa3ay5+1TV+rD+7pH4hyl 0em0RoTHtfFylXwB0qQCeMluzE0UJ2YmPjTx1ATdBHr9BxnsGgvaMCrftSwDw8Yg2ODlkl9CvsaY 10hsZeBrVGKBNKP7GfAH3GRAh0xItqSXAXZjcLwi+xRLstmf9ujeMG0w7TItmCgJ4PonCIV6XHhd Ugh1aGsZ2HoOdRZpArZu8rZL0Z7sT0WT7g2RMPGmgIkyUjK49U8wsvU4LbyuqIo6rDWqbXk3yNbk Cx3z9063b13fLuhUCLk6XbyhNzVScMdLG7ZsLMWTs0dnI+X+pI2hKJwPEequ5FKlpC1Rmt2yqRQH xvUilBK70xrxW6CR7w64zeHuaKwz4Q+lh24Y7NpdaWPNNp7lBB7hVwpOwRJu98S7EoFQanAzIXGT 3k8fJB4hfiehavWCl4m9xA5I82FiAby6FElajj6AnLV+zsntH947bOE4y/Be1dQ9xNTRsr96ZLR3 x77RiTdmN8zuml2YpbKz2dmtHc/H9o1vfX106gGu6iw/jLwerbRrNZf/8ejAtQ8H275/0SydtJql FH/+FQR/JYFrdB4tH/FXRelGsxOQM7P8bGAWcgbfa1/H8yK82+jW10V4PydXFZ1l7cPYmdLKe15r HWDaJNl8zUXZK1b7kcv5Zbsqf5tqRlc5/qf3kyqG9SdwtMZ3lDPTGoPmTmd2bTKxrt0V9mqQH6cN dY03M/nqIpLZcOuQM20W7O077ts8e9fm1M81Bq1KCRDJAQCTYNLrOSUE0FwNmB9NlsY9Ad8K0tF/ ddnq370+plY7yrG1Bze2lCA2ggAIaefX5H7Vl4l+4mGsP5OEKZyRdUJG1hUZWVdk5E0oI+vVDA7+ 2Q2ZarjsNVTt5XwjZFS9hBRnh1wJeOkiLs2HQ1dFeK29ZDdURXuZyTeHgNIu/lKxBbv3ihDPKlwj 92v4QDJrH91T8t4t8eyDisv1CxTxhtTuGbNHPFYNraVbwy0Sra8SKME0Uv2Jfj+xhziObaTZ4eHC ng40eee0J1YgCiH4Zdg2vac8P6/uiE1Xt5V7UPRSV55qm/SUhap6TDZ6UBwNhbcgZS7K0bNLcoUD Dptx8hDbpqvitrI0ikGUhlELVVE9plhAKFyGRkI6rTXQJW/Hq8Sur15GqxCZ6g+X91dC61AtGg5z pttxFOt5Kbb5z8p2VUs3kXV1HlDnG6VqOGxl1q9S2NYc5AyaVmUSQi6FXKF+TefIGPgiQRAMGSX/ DrVVxK+/DCV6WMrWOJMb5pH3nvb50hzSkizVlR4u8+nqQFcZneg8HZ3SSkWsl6DuAzmceotOJTFH DPDSrnRVHCh1laNWbCTh67GRhDOecY5WczeW66fyF32CUpxey10nJd2uP5945/SSpfi7qh/BrePz Ml2MkC5n0tPbcJ6yYa3BA7+IrvRmYro8XB4YCJTby2R5mzFd7Sqb0UKNTu1oWuBIli/OSeHgiyh0 X68Rl0nnlIYhynyZ1FPlrm1GREhIRrNMRmZHy/JHIs2jKtSV4r/CFXWoK1G0ActrWklPqL6rMUmR +KKvNtxEcJJiOF9iZZKDf1IO7HCluNn4i+6xemT/Rm+QN+pkqjcxw2Q1GQyG1dgBgIL6X7u8sr5h dkF98zfEC5hTNx1ehzg1f08cBd/WHlnLuxDLYrF7YxvXdsUEIda1diNN3DJ/9MDRA7foqg+N3VM+ XF4Xd81Xb0FIIKoz26ZQGvHZwal63avEv4IUFYKcQxpJ2t+bQvoKJ1144Id0VbE+9C3zVfGW8rYx zMptU4No/HOifAMJ9yEthfSLMrz09VTOrrx0rntBNbG/Hv1ndqlorZqx4Ti8n6vX3pqDUmS/rYmb jCkYX0E6NHzwmrIBvo8yAqLDIcO1q3dXWbTXuZabhQerVRz2lzWiehPWiEuSRqRJRSOqh+HK3yed I5/xD81gRbivsM+4b25un5FyT6MsrLV5dM55JurehPYd+56p8uRQOV9OpwO97b1k7wzhrkbLKqQC bLKpKCuAorTXI82JZQgLD5Kc03vwUD6xMRbRy/dCddAbnSGi7qoYLdtUWAvYFEuwoQPqWT3vnPvX oZDB3mYWm/yraNwGi8l1XjvO4EJY37kmsWkoFSq7SpbO1Zi4ukZvTvOBfDyOcB6or9ZPDP3FTqCP I68sjryyOOp0E8eHCXEeH+KCP56T/Fu/bMn5ZUsOPr6FPWL0CzLl/IqL7Jf9Pj+uNrNkKnE97axE LgC6AfbQ3DCw7qZJJwta+Q3GCD5YaEA8LEPSriM8LAvNdTcic9SnGbPXZvea1FOP46NBJdxmz5Xb h46uZ6x+FGzT1k8M79gyPfi+h28iQ/U42u9ndq6LbttCHmlENXGnIOoopGIbMMio4ZffKtnRAbtf g35G/cAn/eIDgkwNm/xobRy740dzvQPX5d+UelD7LhOImUCcBwkahBLwhTUhEAmBIPq1GASRIAjg VwMgEgBxDtweBEEET6A12crBAPSXg6j/kBYa2UGEK4GeIX4F0fgsavWYqAT1rop+stGvJo26AM/h k8W09B/39ZG4g7oTpd1niSDgaXwjPbxRfQwJFzANl5usnJl6u76mkx4FAdFHUkcBSZG1Sxgr0pdw GlW1F1Q06htn94YtWlVNRf2J1FmCbrvPxFCfVWl1LPPn/46wIVUao47aypq1FJR7Ev7Qvu1iWfLn CO+Q1OgRX7ou/yd9P+TLepCX+DJ2+WulNZAIvSgVKdkLetBjNAtiQRALgJgfxHwg5gVxD0ioQJIC /QNgoB8MZMBgG+ADNjDFy0kA6LGkg+LPB+AIPCe/jB5xEyAOvcwNV/B1iOxFfoY/yH+IV/Els1Dm OyrRSv8n2kAb+lsbOtngLUL5fW13tJHr4av2SWw//gDRfO5isXgJ0lziTKNRlNQqSvqHWVLyDlc4 3s+jW6lY6T4lfKMNbYDCNzHDm8TauttIEoqqSroN5NgPEFBOeie6E7Q/5+ekUzp1nXUKjqUE+rkC F5t+pe9X0bU3KYM94fOnnCz1HEk+RRlcSZ8/Dp/V/gh1G7RPPSFoeL5Ekv+b1JrhmvObNeQPSfAi qbUEXQ4v4jRj5Rp8Jj+u1b59qMF1zspo9ZDpjAEyXauFTEfJcainp0N5Rmp0UAKScGVOQAnIEZ+T JCAPqWBCCDRIs2WRThvIAgdcC+cQuqID2GXtJSgvCUCLVkoKxe7QewYJ0BsG3XqgD6DwCOKzXp9v T1ZQu6uKqR4CkTp75epdvdDCkdYO6oXafHkLdKgCfE2tCBzaBBu6TmOJ+31hm171ox+q9LaQxxs1 AS1w1N7UAEs84A1bdapL31HpTH63N2omtbU/thktLE0hjM29tScQvC/NWozgPPiC0WJQUWodUzsN ZtSo36XeytXmkV6rHafuwlFtuS+WG1KiC+kkN0i6gQOHEx0gZuw2knEtcKFjun4XcPYisjqBv+LU WSq6CdUMMSGH8YpQqaQldYLUCoLWa75IDs4hUgQpiRI9FtQaNtZZh9e1SGVoVobseL86X3AFTKT6 Li1P1f5Jw0d8vpBVSwNAvaU2hQKeiEldO8ubaNZqBH0qs47aYXMYaUrDGd7Oki9a9DTaE5Gm2E4Q 5A+p80Rawjb/CsHDmQqoZ1sMd1PMwWs6tSNaUhs1XQDk084yF8dhmYk6yOjcpTnU6dZ9JupEl5wV 4TWoVRYKw0y8Q4RRH0n+UK0xat5+0eZGEg8+XvsQb0Hds0iV3sQy6LXaEfB5DfQHRhGoqCcYMgqC kyf3BaMIsFltFEwBo8Pu4t9+nOHdBEmMkF8nS7SbyBD9xF9jm42x9V8ANywRKNP6Athe8nLRxwIB t+1YIAvas6Usmc3q3I8lFnse1R2mDsnn/7hNswlj1Ten3kUD0cdE+Oas7ZhIZPnsb7IUS8H3J9yP iYlFXc+jIh5DjgPI6J+N3jehVZE/G4drzcCfZMntC7qic/1tE93+xIS4brPB3xGLDmZ8GoPZOLBn zchcn+sjs4mBmLnQ1laMkD9jWb2hPZoU2oqp7PqMEHanPAazzRT2WKw+h7d7KvdhVggI8XgkDmkl Qlp9Rm0hYkQPsQPTSudvfxZsRSFB8NGSibD4dca2U6FF537joY7T9GElANXXJ0P4Y6Kgq0Jtp0Tp OrrjtAivVMJNfcvgaZbbLpK8M3IU1CYFm8jPIHwwTyGbcbhDvGCk1bzLanXxdGF7R+k9va6/MfgL kehoLjGWDBf8PPXm6OKGtE4IOwZZA0pNpDw0Qi+HP2rPZ6K5DftGoiNdgWT3c9mMv3MdwtiFM3fQ TqKdmJU7a0UvwBlzOtsJb+iT3CJ1si3xaeYwAopCYJn1NlolwWs7IXq50CdFbrGNOim2MYlPi8zh lgZauJdYnaNNB+Nqia14xqSDVDGh9wx85KPpiVuGrOlEzK5XU0g9MbpEMTg2OTGeHo7pGQZ62J0G s0HnCD7+8ZlDExG13mTSGc1GvdWsUwXtu3bvutEb1ppQTWcZzupOtQnqsS4JO/iM1tn1LNgGXZkM eLjEm/z7nVoqcUpYLDzBNsl6n4RirnATXSQkTonCIlt4QmSbBVoObKlbDNGrQo1BIb7TGTQJnDq3 e3DtjX2uwPDOYn42wXCYo+qHEmOJCPQuWV8hFqlkyX+TODicy+dm/mpw9NBMOhYDWVqjouCeSNc2 ZbOBznXhyGhXMN2F4rBjcM4H4HqPElniLpyTlIVe0YNLbpPJHbsAtpbshNty3GjUZo8FEJCXI/lI YFH7mOOw0pVrUW5JoZxdIRr4jZbjInyPKguXuQq4Kfi+QPIRMbDo0D4mOg7X23Sh9d3c26qO+iXY WoSggflFHnBZasfMybX5WLEQ1Ok0xlA63xN47LH4+K0jo9ARelC1fiTcGbGQKsLljK9JCXqOtbg8 TiOrpR95bHRxOpUYne82jU7YE50+pNMj5LfAM2oP0U3cgM+hzWbCKFwA20qmVCykebz9QOiEcCJ1 0HPIeBCfX1SlwpHfFi5KBQfWds3jYvuBVOiEmBLgt3QlPohoDqnXz0aFleqouhu1BOAZUqWm1Gk7 8vaOsEaD/g610W21QWZP66F+mrbnxwv2vE1Lk/S/GM060sC6U95eh8frqBUh61WI/+B/OrweR3fP bJdLo9UYrARFpMCb5F64ZgeJSeJG4udSRGcjGCEShBnMwi1tPdh0Pp+GX1H3mgtg0xmGmELKzE1s BjeUElHV8b6DiY3HS7YNNtJWPsZlGaobmjUsGygd614MbAVbj5UCIIAAczX6cuB2opieqy5KMgKd 8+qLc9U+GfL1+y8jZE8J6vM1jBheyvepjovwBraNx0XCxsNbsGz5mIjv8iq+S3fpmIjuA0UqAAxU 040c2JGQEeTgrdL8N+bSfXUsnqvn0HdfkUIPv5krU+jVavkZudegnTAbg0M3dPl7zTpDLPBodrLT E64cnCjfPOxri3sCYZfgDA1t7fDkbOf0+uf6e9xJt6G/05N2G7JduQfDjomRdH+YU/3EKVjSjmy5 4DKwOjtvdpBq0hbrDSXWdXqFWFcgMewz5FzhAbvQl86VO9xq2vHZ9h6TN25t7+S9kdo+n49UueNC OMA5Arh/G/kt8m64I8l6+XTCjDjoIfRQnDnCY0rYjafTi6H99kP0ISUxu6+5nQy8Im08LdavUbKx +1oC8og6V8vGJu+GxoTVAjecnt5wOUlLu49a2YWy72nv31gQyH+rS2tveSyXqT2mPG/ef1KJyNCm PqipdsN1StJ/wpnYJUl6BfBjODkCThGBi7iWnPwCntcrjQ4/KEHadU50lvCf4HRcLyC5sFzx2Xua Mj//g+ZcNuUT21wcbQi1Z4OhbHuw8ZlJh1qjJkn443zK50um/D6CvPwj8CZg4WcMQW06Ifv44Mdn kiyBthE79Pxd52LeBetJ+nakP/HnvCh90FjbBWQZi7GSd4G2nhRpLNfyx20Ej7ul2GL3yh8cEOZM uVvICvDz6TVqLWczRSMM57agybChXC4YzuaC5PPt090+NcOwFt5jp2gq00d2XjEbSZp2Q2nqJLaj uQzriTz4GOpuBgkuwImdhVaiDlxAPc5QJuaCZ79JkStZrKQuZzi/uvmKplzNumlDrSBOPY1cTcYi CORuxuwRBI9JS39vuUwtqXRmF06n0Ro/9y29pkm4MrV/WUGwQi+pdWoKzVhjNZ+qvWHmpBkTv4Mz bspw37qk4/fjWSkZ7vulGawoRb9b/rkan6Nxb3mlUr+C++4ocQCv1O4w3GzPZAdNSFA8xCjcea06 4+nhxcDpvsXB7mRhIXnI3kRdOc8x91of/I8IbB+G63Z4sS9wWmx9w7JMxqus4uXPkURJaXRCvbb3 V3BiWJo6uwLrEmrOZbG5OabQFVpbX+bOcNhemM9XtjjcHbmco386b119qS9/TjpY+G9tR7Yn54k5 9ZE1s72yJB6F1GqTe2RFTA29ZiQ8xlPxxYg9sKAQSMosRFoNk8YYN54Sm65oyiO8CjUas0ca7Shi qAVOtbs3PJZQiOAMB52FXR0Ds/kWbVZBUzp+xZTwZKAmWw9trifhbCzQ6pJ7s1rBw6hfGbQytTrn 49xi+JOSt9DUm5VzPg6NZjr8ScU9uHa6Xjf5ZHLmtvLMQiUUnzwyPX6gEv04F12TTa1JWNHj9Bbq zXULs5n45P6xdQc3tiUn9lcSY10+T+dYW2q00zuPPq0I3iI/Az8t8nJukk7x23WI/Dbs5VgJG3Jx dO05v4p2L/BH6o4OyuOqNjs6guTlNC5t9nXQ1c0zWp5aV+fFlb5OcX6Nqy2VsCsCSBsFPuTq2D3Y 8HXKmcRoItKBfJ2xxZm01uK11t6mURcrNbSjqmh5Qhbl23Mzt2JfJ935XCaLfB3oFcD53ynPH3v9 Z7z6HskryIGHShaLvifuVRnDC6lTjsXOJ4yH6SOSY1DEiYZ1x0BQrnOkTomORWPnEyK+VvINiq2J hUox+LKkN8HGLHcOJEUDl+C2rtL2XldweNeQM9OW9ag5wRR0Su5B0KiHfi9yDzhlzkADHTvZQ8Ce n0SCL7X6B3jlge/i84BRXOcRchEccgtYl+5ifDHE2XwLtkONfLXfXpQQ2w1x3UWx8ffryFKTlpvU Ght8Fzp3tEYPty8OWlNCs2ZxpGJhizEoMNAb+Z7JYWRoNa13JLy1L7autzF/wq5RadRG1OtnLfl1 UIWzKEpYvl8h+sDms4G2QBvrvAC2lLwEmzr2av43eTLf/Yizj44u6o59zfQdE2kSHqEPN3ccm2tt OVaK5lPHRKl5dLT7ERG/16Q7hhPEoLY00cIjsoRLIMe48djcyvlg3V2d9aeqFq8XUqQaKW7vCgxk /ayaohmVzpvojmaGUkOVYjLQt7Hg64i79DT8C60WIjl/Aboe48UUdUd6bcah5zjWbjNYWJo3c6G4 J2i3J0pd8cG0oGUNOvgXE0sbeEPS5Qs7hCjunB2G9HqKfpIoSD7R00TYH0dc5y2c3n8wfsKpP2E5 mD7JSDrqEoZEuPjbr/8A+/g2/0FL/ITotJQs+hOi5SCTPim7+DjRRsFpw+7dcu+nxUNCzj56DTyl 1gm+ILdr87Rer2en1LLv+zH4TP+xQMoVU6vUNEnxggMaPaod8yCGvJ8P0hpapYI/Poh9o/+bL3Aq vRnL9NfJu2krtNGkDs3asLScvWg3MYW1VHLBvhA4VXfx6+0JpPZX8gVs4FSTc183Z1p9+6Ygk9AS YyLvdobNdgPdvrdjYGNeUEN72erk1T19wXJS2WrqznwBbx1gUi0tXnXtm2OVXAaIynM4Jz/5bejd WYm43LfMHISG70NLlqAmCC2L95T0TCAYNLgWDIeIBWmLBM6cy4G89nrfsvrfpQ1ShgCCxpdyqk/F Yq2H+qTf6uY0lOoZSmcNeTxhm456lqa1vMcqeMxq6hGSeojU8G7aCu0sljPUjBqEXqDRa8C/syZW Q5N4NjstFvAko1FTcB5t5Lep/wXnsY54P66TCQTzQi5nzcDJlPRBq3nAqmHWrLEW0UmkibF2L+TW WCl3YsF9SJmZ1Na13sIMty1TepihfmaYh8vf19zfdfmk46vPv+lX6m4okgyl+hylsQRd7qBNSx4A 5F5Ka0XPrDrqv6goxuSy2j0mhvwASd4OGN5pszmNaurDJHkb0JgkMuk5YxOZ9rJs7YkG0Yy8vk40 lgVPSgKgUdfm9PIztHoT0FraAmmYIw5J1kUILBEOIgJ3a23WAb8Iu569AP56SdDn9LoL4Dz0DQNh fXIhrKe9C6a6EYXJ+PUmIan77Niib76+KTgBBHkDjzNSbKKzxxKPyWSzyyY9w5AbaMAHXA6fRUO+ /4OUFlr2rgCv/vJ/VQMu4HJ6TRrq8CFKw7ltLj9Hqj9LvqFlGRUJl/O3vgXVHE7LBmxNY4Avqhn6 uX9UoTMuxqD9E1oN4E3yZkiBoNIDjADnntZodPYL4OGzQSGgFawXwMdKrE7wLNi03IL2Nup22XBs becnaXld01WOeuhBbv7b00M1Ii9NHdumqXTK7uWAauplBhh9Lgf0W1THyY+QapPX4fBxgCY5g16l MehOkwJnZVUkw+prR0jwcUYHl5TewhN45/ou+D1thOt6gxxxAD8657PCLyJ0AbxU0muDppPOg1z4 U/RtcKP6Gvzf0sisZAw6TSdFeAUd/pQIr4Fq+Gvwv7ID1SMMlnA9wgD3YST/WPX+HnXJrn2Ug6Kp Y6o/0xuxhbuTN+m4X/0RtwHVcFYDI9gcOo7j9WDS5TbC52a70+Kx1pZogxXZkAR1HldR6wmWSCh9 vReX1FoK4S+/cklyrZa0VAnjKbteudQ48ZccW7BRKVKuPaW6JJdU1k6jsVUBMEE/0Dr2HXjsPcvG 3rPK2BNtfb2pdF9vunaWjvakkz29cOyLBAl0l/8AXqbnoambJKI4A5OOuqd4BLv2UwRLeo6OlvBz dLDw0xeaDTgqVi8pbTXRwXPQi7XZPGbGBDS2sMcdtmmMWmfC7086tFpH0u9POLXgiFKVQD3Dmln6 /9H2JXBSVOe+dWrp6q6q7lp63/fumemZXma6Zx+mZwFmA4ZtgGFghm1YbFkEiSyyCGhUjF4Fs/o0 McEdhBlgoskVn0QTldxnYozJzzxjFszNjbnxvhgSAj3vnKrqYWYAg+/lgnZVnTpVnPrOOf//d77z ne9oIFz+vcYfc7KsM+b3l9lZ1l6GJPvR6EfgGNkvl7Ba6e0WfCXmw8x4zSlWKIHlXYvBwgpnCyOJ Uygx60R7bDpQ+oRBePp6hT5Mw55ocQoaIGqMIZczYKR1OkvI7YpYdTprxOUOWXQgg3YjIeAPPsoJ DEWxPHfJ547aWNYWdbuL7AxjL4JtuiT/v8Fm7JeYE3PLXMVaXZjwNoqZMcRm4TlEa8c5dQqMphXs rTKOFWUz1OnEuym90W4UrQwgD7C2kMMesrL3e9PxMvsPUfdBk7zAuMfpQyNxH9Li8++D+4jDcMyV UOR0PGR6EZ8FtXoM33GS8caSFI8lzsFiyHJCsTFPokQIjbaEA6VfY7QlXruA96Ha9BWh2izyodrU 6K3i5ym9ZJfkAu/jrCG7DRaY8PlKUY2W+gJl6Fh2eYb8CW9qGZqUAU4c+wT4DS+OXlC/IYqVK/u+ mkbwHacZT9DeRfGwJ51rPCe7Q6FqRmlZXu5OMPk6pZ9Qx1eVe/L11eUt8isJsEk6OM5RBmv3i7CU 62HtslixUkbNyOiZUxyYAXtkF4YKGHsZVbUuS3TJhVM29rvSHdcnptTH0f83T0/Ep8L/EQ6C/IcE Q/0rbOdW+a0ChcmOy+jEJrv4WdV6UBf40k+SepPbbPdLpAZfQuqNHrPdJ5HUx3peS9J6o16zQ8/r YDsxyXtfeUfT+BD5k8/w/jMEC99v84kkAf4E4doF/y2RoJ5GG7JqkE49S96aFfZe9P6pYBiP4w0Y ZFplDyWa/YjE0MQJavfDJPtRDu16ODYTokhDnuKNS2J+qQT/gG9o9XDk9reoxxuJeDSiY3QUm4q3 wveew2niFqjBPgD/pQP5J8D/oe7FgkobyZoJ5L5AoOUyhDxJTZi97AGsETleyk4izhPo2tYo+0lq 4NBSso5tTRonZHJQPhn8Z/+S/sUUMLjtksPIEZVzql3emjkVACp8FqtLwKnlP8gveuen+d43OJGl oDJDDb717i82bXrvZz9aTWo0hIaROW07LOGHsIR+rEXBa0nxcZJU7390PIlKKqGt/ZB7BeZglBLH ytUiowS1yKgTFrwgKqVMGh/TNiwS+NBVPbuS4IwOyeHWA6pv6dKlJC64rGaXqMVX34rbN/3i3bcG Ka0Gp1iRex088dN3wBM/0AkMLK2GPJefBcu7f5QHr5LDUKJJxe4sgMcwDeaAv5DZcOIEFCiGHFk/ fucDeb/u4/BaaTQFeZquKc+Xuzq62km9xybZjSxR2lxmscWbS+Cw2GGGmgNJfuHx/JPHjuef+RYj MhTScuY9e2yob8nw88/Mg2NAgmJQDK7tsHQvyKUrV6TpBbefMPPYi7iESRgFL3gHIxcPFk5QygcT bIl/IDwPAV6wljaX4izELYdHD8iO9rYukuDdVqjpavGS5rgNfNA3dOxZWBgoPljGb4Ke48fAwsd1 BoYi4Ah+3jPPD8M2emCUhC3yd7iG2IUtgdfb4fWH8vVubAnEtXuJQfwr1K3jWdYZmS5Mhyx7ToYy ypmVrxHLniufwLIFu9ekFIsZ36cRrJJk4zVWxuS32vwmHcjfNSEtGSHuHFv892+Fs3xqYpogIOzt H/2IzJAVMva2Ka3AhE9DNjv4y2B2YDnB98GRluU41T/BcCcvtrUM5/g+tNjWciIH79/oYlsyU7/j xV13nN5ahY57R7ZWnQh13TZ3xuZZRaGuz82dsWVWEW68+bUv9c556LVbc+j44Gu7F3xxY7b+pgcX LHh4Ezw+hEbzoxdxDVkE+1u9jG1WdgR3DGEix46A5iHXYqjgNDZePocsG0jcQ1zWhe4M5+RbaHg7 RsfKoJbWaJTpsqqwaheG2qHZZ7X4zOxF5IGMtuUFJSQnwpbtlWi7Do1gaJYhFh1iUXsX7SKneQmn cIC0BYQJy2FPuhvKdwq2RWnFFnztqYow/IvVjOD7h1mfr8Y5AmqyumrRQmjifULNCKg9rlkiO9ag +UWxJjFB8x2GT8TlR9hc4RkNeuhEDj4lO9qguUL42BVvGzWoFvyqSZvKalQPXkj38vbod1MMr7tc o7cYtKSO1wPz9N4Koy3VWTFlZUeS1bBwLEJpxboFtzTP37844WjdvPA/8JSWZ6g2ySnpaNFjM/vs Rt3v6we6p/qj2bjDF/VpIIoaLIJeCAVs0a4N09LL126d9pJO2WMpMMqQ5WQEK8HiqhUy7hdGcM1w lCSxshGcOm2JCf7FcWd0BFhPCkuYAXIJpgatRMGXoGCQYoDq97SSUUA5T+XUrDY1KqUaeEkTDI5N kWbG5FKInSEimg4CP1lulN5Em67b/Eb68ggr6TUoXDL4K2Xyl3mDKY/hTd6SX4Pny8BPpgfC76BN Xik4mn0HfqrV5HW5BKJJh0hSy+suHQwS4Ut59K27Rj8ifk75sHJsGrZabrHFDSN46zDncHAVI/jU 0xgXH62upkIjADthXNQ8AsyFXqf4Irw9zhdBVx0fzcHMaEdWbDhnXESh/Fe64Zj7wZg5jpwcuo+e tKS7sBT+55n1T2yas3NJY0Q0JmZtO7I+2tWUELVAw+mYSM3MiqV39sQIR/PMhcl1Dy6OPm+r7m0O d01vdPiz/dmmgSke8Nj8R25rL+rI3fPNpXOf/h/3rq7XGSTRDalK0BoEw4w9T/bxHhtfs+regYb+ 5qDe6pX2HF1XlupepewHjREjsMcksWZslSwldwpJCQVFqoNSOhXN5gMBuhIJqbTPhoRELxsnJNUv S5ZRIJvPwbyllbKMSvtomywjmH+SjMjJSxyrJi7OnjT/QIyYUnN3PL2xuLs1ZWRIDafVFU2Zm1l2 sLcMdzR19SRvPtQbTeeObN722PKiY4GWZdmmpfUue+3i5q77wJtzn3304GA9IxiNbieaZRKMQueu I32826KvHTw4u+drn5vW+41fb9lzLJdIzlqVrlvWEpbHRG2w/bw2Gaunylg9VcZqq4LV1mtitbWA 1dbPhNXEa6ncc7v2PrWyOHnzc7v2PLWq+Hlbw9rZHWua3LZ6+ejBpZyK1Te/irD6+7sWfnFDY+26 hxaqR4iDRyEOPkoWw14+W8HBYtyR5UWPyMK/mM0oBRcXiyPAVEC+X0DYLizok7deN0pZmEWD8lwB Oscvzk0GuQr/NWBcXrtEPKph9PTlPppjNRrYPYFhAqZLNsnmkzS/h4NWqhWt/qQFh1FyiDr8P2Rw t4o2kdWcKYD7pZ060YEQHuqnxNdgrdQqs0gI4W86lQjCv1hmBN82zFoSGij+mqGSPiEzDtsVF4Xx wA4zlqCcJ3MwqyYzAdLH7/QzEc8jV+0RfgXOv0bpIJxnDGaeJhieA7aO3pSwbEXDis5yPcXqKMbS 2Lu5cdGBRaX21i29H+FpLc9OhvLGZd3TQjN6fUV+regyOvyWUNBe1Jlrrlq1ToVxHPONMsSvVBRf egXFrSqKg08gijP+xVFnHLVDEmEzBPGKa4K4nA/FX7CezCk5IYZXfGYMJ35lkh7UGv3yrpWX34RK sAatNAYfkSZfmdef9PIPCpb8YyBfD743CcM9VpPHYdMTXTQne1xrL909huE3wT74XYjhaawNe1WN 3zZ6Jmvl8RkDHSB2ayMYbAQtjSDdCEKNoHEEb8maOJeL254B6zKgMwNqMyCWAbBltJzaiAEfbEDI eZ5XQiSdhq/BkhzgRkYvZhl4wdWOJpNURCGE1qsIIbbk7VhsyZIPZC94mRvks3LkZgzhL1k7moOP GyMFimi9AYrQ3AhFfBeC26bZO/sawoIUn/W5I+vDXdlSA03igGZ1bKRyRgWKXk04mmb0pNY+sChy 1FoJSaJjKiSJxqWN2aVT3ODx+Y9um0gSvMTqeaNBpgnR0LXnKZUm7h6o7W8OIZrYe3RtWXL2KlgP cyBLHJFZolXRrCayRMtw2Gi0IdjP6kqyoz4fXTKeKpD0BFWzGqOLYfhEifwIl/NlR3PyQxMZQ94C VNGsrkkaEyY3yaug9IgpOXvHU5A1mhMmOJhmtUxJ4+zUsnsXluKZQwO5hxZFy9d985bZt/dlo+Kx QPNAY1NfncsO6TXS0dIA3pz3jMIbJpPfBIFJK0h8x+5v9XmTdasPzun56tZpxTNuvufr0yBvJBOz Vqbrl7eEWYsHtdrVsNW+N5k5qmTmqJKZw3CCH4TUYDhOrb2aOQyQOQYRcxhg21l748zxXs0tT2+4 +fFcpnbj0xvR8WjR9OW1rataAtHpy+vQEbft/eEDXU373zi494f3d2X3v3loyyMDRbXrHu6Dx+K6 dQ+jMECjF8F7ZBRq+bVjWr5xyC9r+U1DrlXUGqTlv4o8NVEtnuCQkt8ElXx0Byn5r15Hxy944YD3 GKjqWb1m7W8EMwcHeIz2b6zR6pRsXpG2yZMUCAgG9jK43m0VrSJHfpXWKdMVsHx9EP9jZDlWj20o 4P+yKxr+HQUNP32qwqKJDyL1PnNcs1pR72uur96ns7qc8gRS7jOQCVaryn3NtZX7qk9X7i2wkFq9 9vLnDWa9hmIk/Y9aF1aYrGUt8Yp5jTEdWviAk1qxcuayTM/tc4odTVsWPwHek8RpokPSaXinxeyx W/VvtW7o7fIH6kptzoAD7RSsN4l6weM2l3aurEmv3Hz3gm8gD/LI6CXiABnCSmH/VLT6pJ8fAaPD UYrCEiPgqSxviTqTF8gyvyAw/lXMGnmqPSHVIE6YQAhZAbJB8kJuXFZbIS8khYIv5KczggeXKeGA xD9Cm7wWtAoxXwoJkUJMDu7WmLwxTyDu0T8CK1qTfxTPfwmsA3X+wAcFw+8HlOC2SS6b1YDPZg2M stjmc7Rgx7sv/xL1sPWjfyTWwFZQDvEop+j2EIZMBd3elDViXOX5eNxIeb3Z0AXjYPYvaldTw+xP Uu+t8crzOTW7MXQhZxyksn8Z633qMzes4EcmgPea8hX397VvmlsbFMTYtLX393uaamOCFo51tYw/ 1Vwyc8P0IG6uaumILtw9J/r0stXuhrq02VM1O52eWW4D87r291f5G3s33tkx/Qt3bJybpFlesNvQ NC/DMbXLdrVyFpFJzNnS3bdaJ1oMKw7MDgTqZmIyav+R6IJSSsMRkBxL4LgXMqFxGBMErBFJSSo2 mx21n8Sbz4dCdHzQcYFee128zlpg3njtJ7lQ8/mcnJ12XMjRa6+D1Jrrq/fjkFoJatVliLasfWhl ycwpUYNGg5M0Q+kiNTOSnTd3hHFLdXN7eNGeudHkwAMD0zbMrQ+LT3lqusvTM9L25as8DfVpvKbx rn23LsxwgsAyvKQ3OwykXtRXDeyZroeiic/ZMq3tjuU13voFmz5fufyuOcFg3czYkkGGt0AZdUMZ zYIyQlajKYWZj0qI1T7cnNVxzgviYPivk2A6y4nOCzlxkAr/9RoITV4XoWeV9B1aN3X9vIaIWLz4 0E1r/qW3+DlH5ezKxu6E5MzMrmqcHRdxacfrD8yCtL3toZ6dP3hgVse9r9+z+bEV8Sm5wwvgsawh dxii4H0QBUshSsexWQX9XjrtEaFqzxqlEZA9FVxVLH6i4h6yyZyVuzgyyxizQZQjy+RgHo34yRjS jTPPjGn3FdfV7kspHau5/ALFou0BWOr9X4tmjkRtGmgpqFNINo+keYmGd5skO0/TvF2S7AKN/+UO HeC9VtECNd/HCZJAzqL0pc2wa4+OYnBASqRhXWiI/6VD7bd29CKRu9paAQp67jdlXItfIGM3hmtx iGux/w9cUzTdnJHfqzP6rTavkc43sgLyoNdpwE6N5Cn1ovioe/Xm/AiefwIsBiV+/1u0slMt/RbF u2wmt83C4ctZUV5Hrbu81od3Xv4J8ktW2yFCNHkV0PEYRDRiGGmzENGwLI9x1b+Nx6nIJxDNzqst 8mokM8arfwuRDGqhn8godn6shd6I/jnRN26s3ZYtvX+gY+Ocaj8vRFvWPLAsPLUqwmkoAD+cpn2Z 6aUz10/3ESV39ize0eX7pqmso3Lq5hJn5exM1cyUBcxDAfuCjYs37WtvuWffLfMrtBzPMnojZ3Tw GlbP1izf02YvSczf0h1vT7ui9uV3zgmF62dgau+cokqlR9E7oTCkEwasAcnEEG3+bSBAV58vHbSd p8eL5IO3a1R5BJp/Kxslqs/nSgdp2/kCZN24OYKcbI6YIhRPvenQ8uL2uoigwzUsJPyqztTsW9qC wJRu7Cjp3z3DX7bkC8s6Ns6rChiedFZ2Z6pnpszGRGf1tA14TfO9d2zpKdcZBL3dbbLzFCfoa5ft mYpgPD5v87T2vbK0NuxPrYBYFa6fWVTWXuEKFqzHlB8zYUVYh4JVZjwBscqLJ05gjGMEMCd4tGsx c5zqURHr7AcJRbNEd6FmORfZuxioWfZcV7M0X21Abtz13dt3ntxa3bDrO7tvh8cTJbO2dCy8rcNf 3L25c8FtnX587+E/P9vf89SFr3/pwrH+nqcvPMY98Preuhl3f3eTeixYkCkr1C0rFNTy42JWZxVZ jnXNoeaj6fBz8m4qyFrPsVk5UZ4T/6cYjjkdOe0QS3AeqyQbjgmKACjgVcFuDCU7BdtR0CoXX9Eq 95xmxeoaRbGMy4rlXKRYFh3XzBuvWE62MJxWHkLqZVxVL+fK6mURVC/nTVAvr2VuMN6A+RjZG6oL 5uOLC9dWiS6oN9QOtCUY+M0UrtGJtT3rpyy9b0ncMn3/zefwBDI5dEguo44WPBaTx2rVA6bvwduW x2IzagOBqF8rus0Gq2gQwiFHpm/71Ck7Hzi66R2d5JStxxdJkjLJeDx4BY/1BTz++5BFtjmwWUbF 2TnM/OtC8pBid2CzbG5c7muh8rhIGNe1IZMm6XWtSbY/aC+fH7Mhv06Z/HFPMOU1vG40IhvyYvAE 2Fvkzb9f2Noe+DWC22r0upwi/olWr1PMyD/z4+9c7oScpFqRcQ1xBlPspX8gRmBLQfbS+fLMqAEN ff9cmv0vhDJz4QBWd5zumaBGIRySYK7Syj/nAtn/kuFoLhrq6uBQt+eGhrr/bfZR/IW5zz52cHU9 K5glt8PsFDSyffSJPsGF7KP3zpHto4//evPu5xX7aP2yltAV+yiUhBGLAVaWhH1S2NpwIWxtGQoH EEZGmzIwLiAtiu5sQpE/TD4Um8KGzl7Ey5DypQRq86lTuT41iqhPDf8Bj79DvgAhtFIML8vqGB+s kCxGoECvWR18IsHMYnBMjkzBywGjcWTxOSNbeeAQnCkrdSpoGR6HlmgNfQ3aigUtnRc+WDI+onBM Xkt+JfatswCn4X8Ep7CyyHFoShKvJW5+fu/2JwZjydzze3bA4/MGZ6x+RnL+ugaLp2lVW/X8hiKb Dr/n8F+OL1vw1IXHDl2Qj88u+8rW+VX27oPfyf3LG3tqQy1LbzmAFWy9EFXjgJNrIRTygJAbhFwg 6AQhBwjZAVo2bwXFcu1IKJJAUt7bBlVIEmBI+FixGhuvWBV5sRpxpVgVebEaqqB4BGK2wWNDD9lY 9MuKqkkNHt8egu8UUShOQb4upJ9Br5CDjOjgE4+JQERqauNQcE6xMALoApAiTVUN/HEudjZWIQdr j31Plj0WuxKBYklBjW08mYOv0KB3XMHUaymy/3QzNfHuYUYxUwuISkgSQB1P8/f7kZlatVLLfPK6 XCf64koQ84BiN4r5kR0pmDCzwIJ6g0V2qLD45EgQeNkY8Sg1UvMCvhtjFRGyKMIHi+Jj3zAhociv KieprRiTY3n899PTJHP43xesrZFcme50w7L2FIe0YpzS2uoW3VSn0NOdG87hFZ9OT0UBreQx8xbB YA4FbTI97bj/2C0yPUFESsLxwo8VfgKyB0C2FoVbKQPRUhCKglAEhF0g4gRBuVOEbSBsBRELiJhB xAQiAojwIESBEAliTiD3EEnpIWUWGzyx+AR1XxZlP5Zfnkb7tbjicWFk9FLWDXMIqDIFBG0CCmok IGgTkNuM8CIuYlGMVPoHCWEJVSYph3WBt0kymfh04lSje8TUeJSxchHtHQWPV+pz0p9/Lr0SP0bm fZMSNPHy76HGSiFPTvAjyugp9fhTHuFB0Zz/ukKvG/2R/J8KQY0AJBSPzYisWYSEHBEpyLGXXg3i /365FsX8Ui38kF9fxxSbxUfEEZVfP5Tr0FgcByUUKJZj5JREQIQBrahyfKhyWkFKizaPkHuQe3sK 1KTaU2tTRCwFUiN4aVaHGQw+bCOGK3Z/mQV+OYzs/3UI0OCjdQiVJPT4rXWgsm5a3WAdEaoDcPAV yxoSYRDO/pfPR1f+uQRRu1aldnWUIU8FoD28YkvU2YDyQhdT6sSZ5X2Q8JFtG3J/iUz62jHS/9Qh yKcZtysLtu3Y7KZSkw7ZttmihjkVN2Db7jyIvzDv2UfvXVPHCpLkdVgcBoqXeDQj6k3WDR6ce5Vl O1O3vDVchuqqDT+L/5z6EKdJCuLbV2FKEH8D3Er9BqZo1JRO/C18tZyHVlPC+Bv4Sep9mKJTUxbD 93xFzsOqKa0wZb+cYlBTBvAOsEKzEaZIaspCmNInpxhRiqyBFOM/x7tkO/vYCrgheQXcCbQC7hV+ W/AVaudVK+BeyfHbqOArOXirQNrhf2Bdx38enXN7z/wd3ZGi2eg4K/qQI9FaWj61xOhMtsbKW2PS d/oOravJrD7c33t4XW3l6sOr5m5ocUfb1jTBoyvStkZeETOaBLfi7QUfGjgCAkeH5QHQCDAOuW6j dqg+NMogSPWhMQ7n5FtjPjTUp9nXb9VKTrSwhT5skBhkm6BfIFiImSa7nhyhdRQBRwU0vqWbxhmL aDDpGWoDIHGAPK1gCTtHK/HVUKaVygjz21Cifz5Z5i+DY7YRvDnL6KzvFm3j0q8Q2zF1r2hlxCPL Vl9kfTcHbxPpV3Iwg62wBzQl+yKOt5xfdxrVgq/mDPkSVmQpQqtnvlzeEGCydeG6Mh8c42gIjVRS 11bU2D/Fq48vaF8HZnL8/W4PCcfOgsUosg8nZ2YrbYl6k8Wk4a2CxSnZzQZf9cyy4NT5a1pXybMz 4dEkfhJvnWRVAs8URjF3IKuSLf6yipq3MTs+zapkE+Iv58ZlnQSwNzZ/SlTgJzn9Vq0gV5wm/xzy 0MQpWgPchMEesruK7NxW1pA/j1+8ZHW4vlxYsfNlkrOaeLvZxIDTGhqm0TpNvsgHvpo/gL50Mewf X4F1GYeqsTxeOx6tGgHPDzM2G5MYAceyVqgKp4U0/qc0SB8tKaECZ8Rt9S+pPQZB3JJNk6xLJemj OZhRDJzJiduo+pfG+pAKZeP60dX28Wtal/CvhDpybfPWZ52cJz1rY6c1UeLjtKiNau2hpLt6VoUN +HrrpvXXO+43+NKRshkeY6gqHM0E+HhV//SiqhWf706uWja/KUxpOc5iFs16Squlw00LUiZ3KLuo IZAJGm2mqb2VVgvUqnCsFUplP5QKYpiVhblMKBVkFa+DJ1lLlM96s/hoFmSPIteXM6XbbC/RE4Uy zi5uDGSPKm4vZ3Kl22jbSzn6KpmoFvHK643n4sT45bb7OW+6e0OnpyruZzUkznIae3F1GA7sHYQQ KatwT1tW7wy3r0dCczyAm8KZUDgT5A3+dCTW9bPk4MD8ppCGNTAMx7MBC8sx4WxPuU7Ua4NNCyqq BqYXV6/4fG1Tb7XdEq1w+dNBI1rbOJA/BlbgPyn4fyLv1F2yd+oe5J0Knhkye9n9WOPZK+6pJ1CC rfGssoYFRcQoLNmZ6J46UFdbX00C1mbmzbwOD2aCohRK+4FWbxUlO0fgp7devGPf37chjQEnKXLK rr37Wlv3793diEOsIrQsLN1CWLo+uXTpgnfqLtk7FTwne6fuGeIdjFI85J4qI/0JlKKUL3zFPzVd VVkJ4We8f2qfFMwECB1vMVhsLFFXU1OH45zNKFoMGhDIhIz/s3Xf3l1TYMlwpNBs/9v+Oy5uRaEu cYLCG3fv3Q/bVPXox/gq/OErTJSVTJiHEezAfozf7Q2C4DHqDtiANsH/QOLlt19WmehYjt9NBY/l 4M0bnefFVwWm3dTWvqbZ62+9qX3WTVnHQcFfGQ6m/YIRfkdRhVcPps/Ytag8vuD27vadvenKxdvb qxfUul3Vc6tbF2fMnrq5UKKp0YtgH/4gZKLqAhMdyzIyFV1y7ab2TuChLIOI6FJOvvGpnpxjLLRP KzrNKFgYYiESQLB6kdTpzYLZzlMiWl6LoxVAf51JEzqTCNMZcj3AAYANALFQPYQvB5RnJTavwEJv n0IsVIZoiMwKOsEKrMeKduu9ELqOEXuQbMtl4Y5ftQT56FgOZiLSx3IwzxgfhT8LHzn0TH4FxyPX aZY9EC736CvjgUzUQZNaiqAM0UxTEErWKRa3V/UDt0GfcdkhHxl5s8TrtgfT8VJ7tFwwCihImskk mCTOWd5a7G9smVHWLfORafQi3oDfJ/PRyit8dGeBj3ZnJUvU6Y2D+NMqz+xi9l6hpE3XnOl4Ojcu 7w1yknEcJxGIkxo4tlMNwULnf4UMZnCQq/kDYbAGba6onelk9H/AX/vBiMO1SaNVlhBuImHPESyS wIB1JK0sEs9vsYKp+R8pI7SP8TJYr6WwhpUZyXAFol7GYmHgpz6TtWGMkATJI0VFlOADvidg56kG 1U+NdR6Ev5M5qSh5JAfz874nUG+qfmqsN13NSfh1OSkynpLKAs399a0DDW5P+/bFpljEzaHZenmX ZEeqpcQIvDPLoLptvTdR721y8Z4ylzvmNPykbG5jONa9pX3GgeU1FM2yoiCYOJKmNZ701Ihk8mY6 UpkaI1/ekbBKvhiSRxDKwwflUQLloTC0PTYCnh3GOA7LIHlY/d5aUHvE5aKQWJ6M7PaagOnJyeIY z0au2iM5mD2SfDIX2U2ZnpwsjauCwEwea1wV/cHnbbttoStd4uIgw+pswYSvrKnEiPtmlDbMrbAG mgYaW/obXAcFb8zlKHHzrL3I42kBSzv2r6qlWU4vGnx2hmWgDKKSyZ1pK4krYqqp6kiYRF/M4Sx2 60U0vqjGb8NXUW6o4aPlfnfBlBS+F+yj7DDFrKbU43fhDjmPRU0x4XvxBsoEU2xqShK+p0zO41BT gjDFJ6e4UQoGRjtH3yPWUxnMXMA/4+iZwo61Z4ZRiFwtPDkJB/RaeREPSMTk8JrjlvKMrXgAhdWa AcpgcpksTpbQEvspg9lpNjs5QqvV6WiozBo5SqdlNQRtMLGYgA1iveRiciZGYzxmxbyQORJYFdaI TcdmYQuwfmw1tgH7HLYbdMl8sr57TW5ervq2nfU7izZuKd3iG1gZWqlt6+K6sGwr2Sok06Z0bueW lV2t6XRr18otO3O0a2GfzdVxy9aZW5u375q2q3zd+sr1jt6lnqXSnB5LD147RTOFKYkb4lt3rV/a MyUen9KzdP2urXRkcHkggiXOJc6JakB1dZ+HT/8B6AnpszyBmmv1/1v5shF5Pd1nLKLc+oOBTLqi PKoejerRqh4L9+lJ15OPk+/TlonX4UnvL/x7xNvJdDp5CP1cqEhVpELoLF9VDv88V5FKVeBz0O9l B0rA943lvXw0mS4vD4FUOp0Cr6Gb+T70ewHlPoTOiIfLEbinKvI/rahIvQ8vwBfhSQ962w74A75b nshcboNnh5PJNO5TM+VpePI79NjP0sl0HJ7A3uLCz+FvU/+Oa7RDcvz1Xvx7+CnqT1iFuiMFZoug OI2CflaqP/V+inCmnKli/1lpBL9zqPisdovqaIM24AGJj5SQjUY+5U09miL0Sm7JfzaH8p/UFp/N abcU/GyU7XPUgMDjdWSoXMrxHAJQcxsfVK1KjiuEn4LkVNLYXTpzz+KK9JI7ZjZtKRF0BlbnYB3z 6hPdtf6Nq9xViTAnmHUsR8zzuTnaahUrVj7Uv/yruZpA0BAw+TwCLfjCbeum3nunTi/QDGdBmPQF /C38Y+o3UBanZVl8AcqmifoN5lSjPlB6FEOAM+kwE3VWrxfJs7YR/MBxUY75oE7PnxUuyzLg9NTZ HMxjI8/mCrlsjY0TYheOC1whL2YU5fV7FryJEfMfjwp6vTDqiUY8DgdYKTLUk27vLy1+dyD/rsFo NOCveE1uuczn8HNy/b2IKd9wDtjk6++o12/iI9Tv4fW/YoVvbJKvX1Kv/414H62s0p6Rr++D7/ud fP2yfN2Lf59wUn+E16/I1wvwN/BtsoxelWU0DbaXWuo/salKVKpvY/Vg4clQKpTSO0bAXVk9pucr +AprzfF6B1WMGo1VDfYztosWFJqyrcNHshonZy+uOZ5THzhJWcdC/oxtkXUlRqI8AEFtxkMo8VAK QxJlOR+Ub6EdoagoaAyA15a0r6qrX+IySDrCyjo41htNuuvarJEKZ6itLhRu7q10ZuIhltFaOCtr mlJWmbFGy12hjtowMVSzqMHrRIstLGKLSNMCz9SlHVGPgxMjmc7KdHelS8sbGcZiajVQrDsTcUS8 dnivsgPKygFl933qQ4j/tUpUJJ0DtowTJsKAGgixuRAnHTWgb8Pc42/ZJsUQiBLXCt78PdpfbPVI LHFBq+ECPpON1xE/eIWgeYfV6WYpGv+9kUOmFvwlk40j0NnlYbyTMWgJgrPJu866YBm/DMuYUOIB npKDP1hgRRw4xVoTQVJ0w9OhsYgP8q598moCuczF18hmGxcnY2yV6JUo1MZrfQgBx8U6Lui3Ongt +a0jlI63m31+OMr98Rscw8KeYxcYzSOPUFqDzewNcjr9G4TOAseXKJorcOZ/SzMaqK7bTGA+aDfZ 9Sg4tTb/N6CjISWT8Jn8C8q3nsM3wG/1KzHChsxaPwYb7Qmd1gVLfxLTmmFmJH9Srhr5W89dPicH BPk2fHpSFtuV7yx06LFv86rDJbmW7vFGIr4fMTTr85gdgo5cnUiuIHW8zegLcFqGxPO/5nU6HrjB k2ab/v+y9yXwbV1lvvfcq+VqsyXvu69jO3YSx3b2xM4ir7ETx3ZtZ09oZFm2lciWKslZoBA1pMUp oQ1QCgVmSKEwQNnStDTAo7jEk5bXlK0Fwg9KUxgo77UFTx+lYUic9z/n3KvFcdLAwPweb6TPls92 v/N9/28550rWEf0UnPyLseALsk3WwUpZVPJuRPEwMlOJsIm/55SSmwYSiuTClMksyPOorWhSF4we Ib3kWf6BD/oZ9cKslEkfHfNVm65o0qcLxh0hrX2QOO4E6eXR4x0IzU3DtrTpuuwCkb5n1j39RKbV mkkezi6w2adPkd1pNimlUMktLDClOjJSyOXSQiUvN09JL8mZ1hfQPbC62ghzhHKhmZ3WUjZZWmi1 pjF3SYueI4IbmNf4vWjZpG/GgBxtxIIEj6ooSdyjwZ+MuK/5rp5YinJyCuwGXeP0b1aLsqMgJ6fY QvTELJpw25pV5DCLfYPfFf+YYjeJRG80nD5FP9sryQ6b+ILRpBNFndnw0envQXp1fRDSEMGN/DXo dHI30mAe2X7alDtpozLmTRqC6qvQrz1PlXjUlouVgDqUIW/SZwgm3v1reT+6GS91sNuSf186+EHP Z1Py81MeHbx3z6J78uu2Ne/c2bC1vkg3NPiAZ3F6jvjNnPRlA+/btcLdVnnlpTktw+qKhdUA0cv/ U7bUeobseCS7zHKGYCnPng8pnKbSye/T41GvwXw3++q8K+oK9jVhPgbbrKWTPsFKsqTZbMAOqEo4 g6xkljMZY991Ij7LDyFONU4/Z7Dnp6cV0ZMKitLS6SkRC7U+8SL9qDJ9jZp0TD+qlcU/aqXp58hC rcx1pisedvfzuU0EskMwC3YEpXoI42tMHbWBn8NIrhGT5MyUKCZHbG42H1tRsUPqUP//2vwNsp2e bQd0Ssz2fIqSPf5InJrX2N36164dEX8IjvqFaLN+Bbl2u04PWYHLY35bXl5+WZp++s96/kKyUU7F zXu+Xf+mwZpRkJ2dZ9XJliuEfgr8Jb1M//XeQNzT/8TOwaGnSr4ZRfNx0k4b6Blhst02fW76PalW vvthOwUhj78Od8pIqJp2IQvCk0kbc3Ko9izTDI2P2Qj8nLs3y4El6ksrLKNoupBskqnXXiy4JzVf E1v/kyshoz3bkZqVYoRv/0wVj8nBdihCPX8F/9TCXOrMpbVm5tOly2hkVWdbpKJKWioKxU4UZQn7 +dcW21/j8C+bbWTCOU5R5KPnN5XGndjJozQ7fQk1Bz/c8kV6JFN6forxfxFTalaqPSvFRH5OiNGe k0nP4ypKb81Wcu2G70jPGdMyc9M2mNOtJvFXUA4PgO688j8keg6ZzqBD+Wy0/cd5mWDhuPK6aEvL SzXorQ4b/U9gvjcT1vBXyk5ZlpwhWx5ZU5nxDbJZKMIt9Z2nU6tz51Dvyp3hf8+rEFwzZqYHanuL CnoGsuNa3Yuk7CVzl8ZcU/ytCfuouWn5OTmpP7CXpROdaExBHOekGIscKzPyMzMsD6YW5OU6kFpT 8zLtNL4v07MejI7iHDJe2Fy19JbK6Z3acePihZxMQ0pu+vQPCrBuLlzSVEy+oPks/QZtvhvFXXSp loHtagZ+72k5k2bgu04XT0ZPwtQycCbLwNhLFk9eexamdozzNf/Dnb9wx3t2PPIv9PlLD9+bUdtd v7p7cWZ6bdfq1bcsztS5b/3I3rpnv737fjz/6+rBjfMXbvKsWDNE/w5CVnWnLCwXmvkZgqer1wkr cDN1el7BOge9k8gpqF43KTgI/27Yi44ph97hyF47qVDraCeTqt+MsIrUIDM//9qkgx1HVljtWIfE nHCtScLVytpJX+z6HH4WM03Uty1IODwXu+T4/wZg9s1Sj7k2wsjYOktL2ca5NJMtSId01qw0e2G+ zbDBnF04v2AlTdeZMGd+6sNF81Jr2hblOMpXlmYUF+TYWk36c3MqrEW563tKFimp4ovchGb56wW1 penTT0T9/Gc5aRKR5yxrnlexrrbMKueX1RZ9MSsNbrjIIknPOwrn0UwUe7D/espnT9u319IdRRqp EHfrAuzVePaZKvGZ075Ufek3xGcEn6AXfyisW0DvuN7ypfbdyvrbbukebSkubr2tp9vfUvyOzKqG qiUNc1OzqhrxtzxFfPbWj/nXrPR93L3nY/7VK/d9fN+uw92li7bsb915uLts0ZYDVNYVZLm4UudD OGY/asvOlyxcEIkJsrhmCZUkelgL/Zd7dpQ4v7Vlr8aKK22W6VZzaorlS49n2c3WZ+S83JKs+y02 4s7NyMjNyxT3DFszirMzje/S683mK3WZmLWcrBI36g5g3S8+bZfmpDMU5kgL4yevWUA/5RmbPeHF cFrX1hj+Yri40ZYynetIT8l4aFnrPMeGjaVrFpWaMo0ppsq69ZUNe9YVZyzZ0fo+8s584svJzywu Kk379LIt6+vzV23MzM3E/sRqzMxMnbOqY0FF5459TcdgqyKyUOzVeYUCQRHKTuelWeCozzhNPqkw y2IxZhnPUDlr4l6+Jhn0xWv+LR6q0CSKlFQqlYi9ud1FhYV50xOWVNlEbPLc+Qvndef+TJwmgpi1 8CGLzWZ5KK2kuMxBfuaw2VOuXCYT007qN7nwmy3wmwXIpvNOVSyCJI/5Kir0jmKGnUO/KtGD+H17 nBfp4l6ouOF7nltK149s7Bt15lqLlnT7N6zeZLEZTRZDVvmysnXbVuZJZSONLbeuyg055tYvWLWr NAtet3BdZZq4apV744K64Xs3L9nn2dY4N80oO+gRNGa59pZ99Vnl5c5ta8vr52cVZXf5GguKatdx rcqZVvOwWtY+kpO/iqmVn68vr2kwM33KxecEvZAepxt/TWKVphyN+Ru8Xpz47uWWoltOBBd1ZaRZ YcDcihVzG3bW54ulnqa2/rrcOet9GzePOvP2k9TypuXVzgqHvXxt9aod4qudDx7tS8XtdU5eutli ru32rsooKXNuW7aCaXxPU91gx8Ki2rUlZfULstk5VmuFL2NV2suiXEGUq8qkihegTKmqzI8Fntbf MtQr8utvbWrcWZeXV7+7uXF3Xd5QWtny8vnLi21pZSvKFywvtoi2rjt2La7Zfkdv1xH698j2jr2N RZVt7roOL/3bj5h7m/B10Sh5EOn5p6zZZ8SfPBIX7T+i0b4O0V7+FtFOb0zfb7JaTSc+kmYzWj5r yM4oTLtdtlzMdKRlZKaRP22xpOVkpBmGdTpZvvII+06hLuGbYrY0IlQLFY+mitklaXzWEvHCIyax ildEVYQFS2jUl2fcZNBnZ03vS0m1OI5VrZqTsmZt0ZLKQtlhsBjn1NaXLO9elmtfsKFuP1mT9fJ8 e15eQeqxhetXL8qqWePIdMxzZJgMaQ5rfq2zrMTZvm1VEHarFh4TV0huFvFzacTT6HpcC/iviz8R jFTOdTeO+fT4mF8irsjqy87Lz5z+mSXFKF+SlYrKkr6sZ8jvfk/2zz0mm83ysdSC3KIUcneKBam0 l9w+fZT6UDN8qAQ+NE9YJVSfKl/IQqO8XJ9amOBNyxK86ZqwF68f9glvK5UU1u9c27pzeWZOQ3h3 bZNsNsomfXrRgqJlG6qzSdHOFas6azP31LfVdBSmlS8vK19Wkko+UNO7pqx2y/71zrtGWnAfkurI TjWajJXN2xelFRctb1+ypi0vrXH7ipyceUu5Rl+MalRzKn9FLNifUGP9Ao/1R3wp+jNUoyUzVHqL YI//7N5ysSS36eDb5jc4UsyyyZBZUl28vKM2Wyzcsnz1LYsyC+t3rG3dtTzTbVVWVs1dVpJSt7F2 o1jRcNdIq002wpXtyFyVjVtrHflFy9qrqnvXQtMDK2s3O8tzK5fmQzO20l89oHtdyBWsguOUVfyG eA5aWMUJgYZ15rKSxZn8pWIdfYFk7tY9nqXHPpnryJNSlXyHQK5+Vv8+nV3/umARUk4ZLEDjlM8g MGX566wl9GV56Q8pePz5+wUF+tczCwqzFy3FlV833ivWGt8QJEGmB0TSZVoqySxpFfdfudv4xiDb e3yLE/Fdn0RdHN1xA7oSI+lRSjrjdelDoN/HSH/KsCuOfn0jMn6Gk/zAzZIpO47uMccewyq9dD2y DFr+LUbWpSo9OAtdtd2rUYrAaNkMcjL6YMoHcU+Vlbo1jl6074ijM7MTdsSK41NptSo9F6P0OSpF ZqVfZIxplClluqL0LKesT1yPsm/JvhyjnOk8c3426ByngjuvpcK8orTi7Uq+8uackjn/81oqPXst ld1Xdl/5F+feX/FU5QCneR3zsyktWFLVFKXXNVo4Tqk65Rpqqm6qSa/5cq0E+gKjN2O06PXFH4qn JUuvQ79a8qulH1pWzGm5IUYrlqn0FKeVH1j5zzNp1fxVV+vz6ytm0mrL6i/NRmvevvYdGq3LW3ev Rk4hge5vSG94V8OlxkONrzW92Lyp+RMthpbDLY+2bmx9ZL1p/bE2uW1fu9QebP/5BueGX250b3y6 Y8F/OW3veE+SkvQ3oAvxtGmxSr5N3+0s6ey4Sbq98wtRutD50mzUtbjr7ij9tHs+o8XddTeg438T +t+3rL7l/C3nexpBP6LU29870bew78t9X95cBvotpS2Ht7ywdeHWx7c+vq0WdJbS9s3bv7Ijf0cp 6IEdD+wsY/TwLsuubbte2fXKbg9ohNHrb/vqrZE99XvqWaIvZPSK6w+uK/0GUCooh1GJSvP7l/Qf 73/B3Qk66z470Mnop5w8lZ6Dnh8MKoP3D94/ZAXdR2k4f7hseOHwctA6UBujW4Y/kKR/bPK++Jb0 svflvZ69I6BvgZ7a+z3QT/a+uPflvb/f+yajq/s+xOjlfS/7dvu+PpKVpCQlKUlJStJ/QxpT6Ryn UefoQdCr/lr/Y4HloOOUbluUpCQlKUlJSlKSkvT/Aa1LUpKSlKQkJSlJSUrS34jec9u3g5mgnaBz lEKL34JuD30tnALqA32T0thcRi2M+pOUpCQlKUlJSlKSkpSkJCUpSUlK0l9AoSQl6b8vsc+VLRTn 0GN3aVG0sxaJnayVwmoSOyk/RfcVtSwJZbon1LIuboxeyNH9Ui0b4tqNwn7df6hlWZivf5daNgmK 8YhaNosno+MtwhbjJ9WyVZhvvKSWbSkGWZMzRdiAMern8omcVamWiWDMrlXLomDMiahlScjJeY9a 1sWN0QvWnE+oZUNcu1Goz3lYLctCZlaNWjYJ9pzfqGUz6Y6OtwgLcv6olq1CZm6JWrYZpdzlajlF KMcYSSD0ZHoxTR9QyxxnXuY48zLHmZd1cWM4zrxsiGvnOPMyx5mXOc68zHHmZY4zL3OcedmWkqOs Ussc588J9Hvta4VFwkqUNglewS0EBb8Qwu+gEEZbE0pBIcCeXWjxojQqVKOnQfCBFKEHbUPCMPpC rObBXw9G78fzAEbahDaU+tHiEQ5gRBe4ecCjTzjESorQAc6HwHeMzehDaYhJouDXjzGHcK02hxKV uVZYQj/5G62tEKrY/C5wCGCsgnldmIfycAv71LEbUBtGK+0dg3yhqD59aPcyHXzXlWeQ4aAIjaj3 o4e2uhgKiTpyPn5VU4XNMoZeN9NXQ/cArg2yljGMGmCoKWgfZm2bhHbIRNHxsutGGa717HoPG+ER RjAnRXmAPSuqRNpYhbWHmE29kEWzXkwP2h+GFF5cGQIKTUwbL9PEG9XDhd8RXMEl5Pq42ByKamsv OFKuLoyjvA6hdgClMLNDCPr1o+xjMgUZFlRfL56HVKQ41zDTic85yjRyM0lH2SwhZqd2ZpVBtFB/ HGMIhhhfj2oLL9OJYxFiXhECV5fqr9RiAbVdm2UEfHwMn4Aq5ShaRtisnGeIIRWTgM4YYLrw2NCw 5bL7mNdQTxhWPZdKNYKxLswfZrVRZmvNrzlmfBZux1FVLz/Dtp+NjEkcrxFF7SC7jmu9D/VqFrvx 1qxg3EYYh0MMhzE1SuPx1rxvVPVkqj+3S5B5g+ajHmZr6rmBqDZcxiF1TAi1t6vcw9CCW2h/1Eou 5iM0AkYS9NIyjxuSuNj8bnX+apZdhpitaM+1+aruGq23qJ6jef5ycFmMzHF9Tw+zOQeYJ9JZ9kVt EIvMa/PkkOrXgeho6rnc4qMY72G+81+Tb83JjPsPk3E7IIlbqGRRNk/tV4T1zCv8TLIwiOarOqEG NMCwpVeOXOM91arP1aB8iPnQEPMiaptDaHVBdo6xxpXz9DEZqASDTFqe5ziv2Xw0xPw8wHTnKGjX UatuZ3PwTHOIIc2RCUetrY3W8oJbzd00yqsYBnRcQPWK+DwdYLiOqvmBc/GodZeakz0so3iZhly6 fiaHZuWZFgurV3D/CV7TMhjVoeqmMgFfFQYYpmF19eHxyeetis4zUwOeRQ8wnNwsnmbD7ICqqZdF mo/FFI/8a7Gn1/CVpRLj5yV48OzcuQx/Lbbx8cFXd0Vdn8PMcu6EdXKmBrFVcaZc9XE+QDXhuvDd gpYrg9GdxwBbe0dZHnFdV1Pue64Er+L5wK8+c614eYzFC89PA2wd86q5hfOhI30s+1/fR3kWH1Ut E+OuRYg3blcxzPKdV8WZZnUby5ceVQdth6GhnOjVVcwyLlYeELT91cw8NzMSKmfkBQ/L0wfYjsLL rE+t6kIbRWgII7S+GpXnrTNy5zw1emPZIrYb0KT5S1anm1wNlIIZPDo0Hkph1Jv3oo3bSfMavjvx qatIzLtvtMJpXnn9VY5arjsaOaG4vQi3N/cCjzoXz9ijqt2rmM5BdfXR9hV8XzSk2lnzY+5XAXW/ w2fws323i+mpeYpLiK3yM/PZ38EWUYRcTHeKm1fN9QNqrLrVvfYokzV+zfSy3XiI+aYq4/Vti3Jv 4joPa8+Lw2gg7g4hPh5ump8Qu6vRRs+e3apmZDcN+5lX+9hdgXeG3ppcsT1YLGpiK5FmwypBuzuj d2Fa3RPnIQF2/+Vj/jYct8JyqfuZLB51pRqL2jI+l3Ab1qgWD7Eo8UVl0OI60ZduHtX4FZ5rGb/S JPp0DIkDDMeRv9KO2mowxu4uOTKeOAkG2DOdM4bLXoxwx60d4RvkY575B5gG2opXl5DF+W5sPyvP tuseZWuEtsrE359p68RsOSXxqhDLFdxW/ares6+5rutYNBjVPsS8dJRx51F07Z3vX+sB2vrWJrSw 3i6hFbWtWC17WEs72hRk0R70bEGtGa3NaKnAiF61v4JZaitbh9owbjNb4ziPHjx3or6d5bhWQWF1 WtuI8Z3gRa9tEbaxOVrArZeN7GG8N6G1A39b1HH0iia0bEadltezLMjn68RV/B6iXV0TuaR9aFei GiZK1c5m1CTbhFoP+LepvQ3g3c74Ufnp/K2s3BmVs1WVtIFhRDlTnk2QqIPVaOtm/O3GuF42fwPT mUvbyXRoRT/XpYVJQGeuVnXl4yg+W9QeaiMqXwcoplUDw6CNSRPDrwl/uyE55b8evX1shejClc1M 016GXouKGdW2g9ViWnFLNTFtKKoUg2aUN+F3fRS7HvbMZemJ45aI3VbWHxvF9WtQn5sYcl2sxq3R xGp9zFa0t0q1ZQ/TY+asW5kntrBRDUzj3qiHtDLv5dJr3snn6IqThM9HbRsvi+bVyg1ihHPR+jer lr4WF4p6A8OEytUbnfl6nBGbn1MW1y5aqWzyuoP+kH8wrDT5gwF/0BX2+kerlQafT+nxDg2HQ0qP J+QJ7vcMVNvaPP1BzwGlK+AZ7TsU8CgdrkP+sbDi8w953YrbHzgUpFcolHPtEmUu/bOiSulx+QLD Sptr1O1370PrBv/wqNI2NhCi8/QNe0OKL57PoD+oNHr7fV63y6eoM2KMH5MqIf9Y0O1RqLgHXEGP MjY64Akq4WGPsqm9T+nwuj2jIU+9EvJ4FM9Iv2dgwDOg+HirMuAJuYPeAFWPzTHgCbu8vlB1k8vn 7Q966RwuZcQPhpjHNRoCl6B3UBl0jXh9h5QD3vCwEhrrD/s8StCPeb2jQxAKQ8OeEVw5OgAAgqOe YKhaaQ8rgx5XeCzoCSlBD7TwhjGHO1SlhEZcwNXtCqBMLxkZ84W9AbAcHRvxBDEy5AkzBiElEPTD GlRacPf5/AeUYYCreEcCLndY8Y4qYYo1JMMl0HEUc/kHlX7vEGPMJwp7DoZxsXefp1pR1awIKSOu 0UOKewwm5XJT+EYBctAFXYLeEEXU4xpRxgJ0GnAcQkvI+3YMD/uh0H6qkkuBAUb4XNR53MOuIATz BKt7PENjPlcw6ld12tR11B+WbQFE1ATLqxcvSYA+HHQNeEZcwX1UD2bSqGcOAfEAbXb7of6o1xOq 7hhzV7pC82BFZX3Q7w8Ph8OBUF1NzYDfHaoe0a6sxgU14UMB/1DQFRg+VOPqh5/RoRjpG3O7QoP+ UQCOUbHJQmOBgM8Lx6F91cp2/xgQO6SMwYXC1FlpMwXCDdOGPVXKgDcUgANzgwaCXvS6McSDvy6Y 0RMc8YbDYNd/iGmluSOggt/4g1phkM5Qda3u8IOBMXe4irrjflxbRa/RJoB9Dgx73cNxkh3ApN5R t28Mvh+T3j8KT6n0zuNhETccHG4kLY8i+DrsHgoHvW7ukNoEzA81XvUMgUovZkFM0FQSpJEz4D8w 6vO7BhLRc3Go4FlQB+ajhbFwAFlgwEPVpGOGPb5AIqLIS/BdPpwaxMviZNjb7w3T/GTrg8iDfhot VGQV6iql3xWCrP7RaKbQjFCp+oJntPqAd5834Bnwuqr9waEaWqvByFvVnDIP5mVuwWKAspk9Cc6W vH6ojuigI56jMO/1QycKDWLJh8TG4E5MkxTKhERps3VT44RY8EBvQODBVXBsIDNQpQwGkfRoiCAQ h6AzxRhYwaK4XPH3I9mNUlBcLFFrfnbzWlCBXKGQ3+11Uf9AnCFljYZdPJ96fUCmknJM0FbpVTP1 c/OYRAMsG3I7zDqO5VnaHOduVaq7Uem1bp8XfsrnpryCfKXCDCyIqIZVNJd7B+lfDwMkMAaFQsMs YMG6f4wGb4g2ql4CDWugeMhDU7Q/4OUZ9bqi8oDHlDxoVKSZEAeG/SM30JGGwVhwFMJ4GIMBP3Io k2Wvxx3WHCzmx3D+AS8LvDru4khj+z1xC+6oP0xDhidzrxrG3FPUrtAwXQ/6PQmR64pTNEinD4Xh TF6YKLry3AgAGm9tLUpvV2vf1oaeFqW9V+nu6drS3tzSrFQ09KJeUaVsbe9r69rcp2BET0Nn33al q1Vp6NyubGzvbK5SWrZ197T09ipdPUr7pu6O9ha0tXc2dWxubu9crzTius4urOvtiEQw7etS6IQq q/aWXspsU0tPUxuqDY3tHe1926uU1va+TsqzFUwblO6Gnr72ps0dDT1K9+ae7q7eFkzfDLad7Z2t PZilZVNLZx+W3E60KS1bUFF62xo6OthUDZshfQ+Tr6mre3tP+/q2PqWtq6O5BY2NLZCsobGjhU8F pZo6Gto3VSnNDZsa1rewq7rApYcNU6Xb2tbCmjBfA36a+tq7OqkaTV2dfT2oVkHLnr7opVvbe1uq lIae9l4KSGtPF9hTOHFFF2OC6zpbOBcKtZJgEQyh9c29LTFZmlsaOsCrl14cP7jalnxbIPm2wF+A bfJtgb/f2wJm9pt8a+Af860Bbr3k2wPJtweSbw8k3x6Ymc2TbxEkvkWgoZN8myD5NkHybYL/594m QGzyzxoIwtUc4S5htoeo/ke+QCrxaxUSv4Pv2odOV2m1EowRl97seJuNjpecNzs+NZWO13Xc7Hi7 nY7Xb7vZ8Q4HHW8YuNnx6ekYr5PopyNkQcfG6/C7hj2nAeYcIU+YyxLZUiy6DcJqGGatsBMmG4Yh xpCsjgg7hHuFtwkfR8r9HBLsV4W3C2eFw8L3iSi8QFKF3xK78AbJIwIpIjZSSXJINyknO8hispus I17SQXxkJ/GTYTIG2k8i5J3kveQYuR/PnyLHyVfICfIN8lFyjjxGfkgmyAvkSfJb1P5EnhJ15Lzo kDaIBdJmcZ60RVwkbRXXStvEdskndklB8VbpXaJHOiyGpQ+L75ZeFd8rvSZ+RPqd+GlpSnxEel38 lvSGeF56U/ypdEn8Jez+SiIW4u//AizeCSzuBhYfBhYPAYtTwOIJYPEMsLgALH4NLKaAxTSwMAGL bGAxB1jUAos1wGIjsNgGLIaABUXi3cDiHmDxALB4CFicAhZPAIvvAIvngcVLwOJVYPEmOSfKwCId WCjAYgGwWAUsGoBFJ7DYDixuBRZ+YDEGLO4EFh8CFv8ELD4PLB4HFpPA4gfA4hfA4hVg8QZ0v5qI hf53cVhkA4tyYLEEWDQAiy5gsRtY7AMWh4DFCWDxz8DiC/Tb5YDF02h9EVi8Biz+TETon0oyiZ2U AYtaYLEOWGwEFjtAXmBxEM93AYsPA4vPAIvHgMXTwOJ5YHERWPweWEyTE6KZfFTMIo+JZWRCrCVP iquBRRew2Aks9gKL/cDiTmBxD7D4OLD4LLD4MrB4Elg8BSx+CixeARZ/kF6TROl3kl2akoqk16Uq 6Q2pTnpTapMuST2I712JWJg2xGGRCywqgQX9D+VWYLEZWAwAixCwOAIsPgYsPg8szgKLH6L1JWDx H8LbiUk4jFgQSQWwWAIsmoBFF7C4FVjsAxbvABZ3A4uPAovPAouvAYvvAIufAotXgcUlcgz+/17Y /bg4B1hUA4s6YNEGLPqAxR5gEQIWh4HFPcDio8Di88DiNLB4Elg8CyyeBxa/ARavAour0oelNOlV KR9YzAcWq4BFG7DYCiwGgcUYsLgDWLwvEQvrT+KwyAcWC4BFPbDYCCwGgcV+YHEXsLgfWJxC63lg 8TKweFMIEaNwiMwBFmuAxSZgsRtY7AUW7wAW48DiAWDxGWDxOLB4Cr0XgMXLwOJPxA/bj4n5ZD/s /k5xDbDYACx2AIu9wOIAsDgKLD4ILE4Ciy8Ci28Di+8BixeBxavA4oq0RTJAu0xpmzRH8knzpKC0 WnqX1CgdRs+Hpb3AIgQs3g0sPggsPgUsTgOLs8DiOWDxIrCYkS/s347DohBY1AGLrcBiGFjcCSzu Bxb/AizOAIsfAYvXhR3ICm8jVcBiDbDYASz2AYtxYPFpYHEaWPwrsHgOWPwaWPwf0i3qyQ74/G6x knhhb+Q5YOECFiFgcTew+Aiw+AyweBxYPA0sfgws/g1Y/IFMSCJ5Usol56Ra8pS0lpyXdkobJK+0 WXoHNL4TWNwPLB4CFg8DC8SIhBiRfg4s/h1Y/Fl6TWeVfqcrlKZ01dLruo3SG7pd0pu6EemS7hCW jTvpeisb8WO3V1Y2337kiKwnsiEwHsFjPCAbiCxPjR/FY3xK1qFnKhKZon2sB82XaZ9MiKyLqA/G YPzEyYmTJ06M02v0aseULBPZfPbsp/F44AHGYHLyoYfuu+/4cVY5eJQ9DlIGxqnx8fGpE+OMgWHP iYhTsZ/YwwQ9cqS5uRJrrGwQZMPRtrba2ra2o7IelfHx7m4FD9ZzWSfbFWfkskFPDMYp+eD4OGcM OcYpb4OOGPQBKleAtct0CAax8YHxS5HIQVknyLpa55STPjDIYDh44sSeSABQcE5feZpewrUXuJJm 6aosKYLCHxNM/EiEonHyRAJMBpkYzF/9zjE82JSclzo7HlQqg5HLykA1GLmAsmyQiEF3kXOBFoZA ZKLWftGoE4w6LmwtY0NHf2TYoBcMeo6MwSQYTOOR8chm5Ls5IN6Hnu5xOTbM6aQT6C+iELkYJ7MQ kUSBSGiVRcFAt0+CgIqBEIMUoZUIwUOKWPSCSS/LdrtCeUUiRMKm5aJZBCNapQ+nk1VpgT4iEUmC n5w8eZLZkenPEEBlz0mG5CW1R6ZW5ZXa2u7uE5fgCLSy0snsGogyOCjbL+pEQZacE06nToIlodDF RFeH1xlXNlOBmlf+ta5unN3VTUS2PBl5MvJJ0H0gCnuiyxuJbFrZfAQPTH6TLs8qzShVNh+5KZc3 6YnJGIn3eQP3edYhR52eduw5MUU7dIIJTj+b12vMruP2upjbm3TEBLdX/d5EiCmK2X/K8WnMfmVi huOzMHXO7vmGG3i+Ieb5hlk8P17q/5zrW7B3iro+XJ7VNd/nzm/izg8viDk/KjHnZz2a86MSc37q w1HnVxlQ59eLgpk5v1MvCWbdBCS6aDIJJpMsZIAoCg3Y2VGRTEZiklc3MvEaV9Oa6dJR6plHjl5i Rkc2jFzSRppoxzR9SjSsyQAuR3k4jB+l1xm0rksmMzFZJ/B40Pmg8wOMjoNMMjGZn3zwwfcfO3bn ne9mtdWNd9AHxKDsLiHkLo0jKpkYdFkKyPJ4gOlBGTdAB6oJ1UgWTPTnjsayspyyssY7TEbBZFQj x25ntWmRh8i0UU+MFNCD8BOzgZhl8Dozickmz9AuvgCOB1iXTqcLH0fX8bDRQIx0mbocidxu1glm fTROnBhpNN5OjRDBgIMJPCE9A0qNlYhVumqKBQvCxawnZhpYKnZmQswxWCNGEzFaTwvnWQ7hxARR eWtCHeXTqu2TZ2hU0qoqO/3Oex0xquEToWWaCvbY7RdpyOs1TWoZP8YOClOYaGwgOIxmwWhpdjY7 50coOQSHwLvR2d09bo4bCt9n/KfsNAqmzEQ0a5kRGCArizrq+CaRrlhOFkvOiJEQI7SmwRQRCRFR thkEi4F+93RcQBGd/qJNIma9EhdRCmuhBf5Al05HzIYTeKieo4YVq6lhpVxS+9gEzkvU44w5lZVt beOXZZn1IbJ4aLE+Hlo8tiw6Hls6waK/iKunzCbBDAeMRddh+CbLjTIxm9Y2cFkb1tKq+fIR5uV3 HLnMbB+NLzbYTHuusv4ZrsDc6qi24hylVWO087LZQsy2iT0Te5BLTr5feb9yN+goiDGlYcbjzGwi ZstaVTrt0YBdrtkISWnIIeaOHj3CRKORsMdOg44peG3QyYKZ/rCwY3FnNqIajTs7q7LA45HH3VV3 O9zLYiAWGiXxoWdUQ4/16WaPPQsFHbEXDT4j+t5FAyCCZf32RLZvGX0WPbEwFNXwsxBiicP87xR/ VNWDLJ1N/b3jz0JEixZ/f5sATJGIJS4AaeCxplgEqiFoYSHI3Fbd3lOU9KJZVqJBqPayaRTnZVbN iYYhq652qsY8GGVFEZWnjJJg1amcsAG2IhQhqXPKYhYsZitu6CiVgJyRwxEwcUacFplYTEUuLrvT VUTr5kt38YA8ctcl5j2XWUCxIRYTsVhi3nA1zjNmeorFCNZHokvgEcoqFp+RyxYbsaRO5EzknKw8 WXmi7UQbTUl3ynfKR2Q2y0TkJOgEaDxyFHQEdAcXoEBwJwRsg0C/2J5NSJdqHrBsQqADvWoRO0cP Mhio0viJlDAgKCBWkMWEH8qHR7Ic3RJQNQSLzPacLIDtFhn1q0QL4avq3RpCGFawGonVxIONbgkm zyTsqlmviEddK+1trWPXrmymYYxePSy2MhbHTugjxwL5yO0zmB85wvNhFAebdNUcH8vKhNVArHJc MB+1EmKNt1FEthA55WsT51hm1IjtxrVJErbmllgPi2lW17SBYmy3rgZ1RN2A0YSJfIn0aXA6L3HV VjKufALAgJ28HN3WWwTZSqXY4Nzg1GKb31vQaEZwW+KHw8FZ5yWZunrkkpWI1uhOKyG+6U2W3qnu VrF3JSK9QxHiIzzFKFiNoqjFuBriev3FVIlYaYhrMY6SwtpYSYtxFuRWIw1y5oscNQ04i6m2+wT3 Ifs0qx88CsjYHmyaxaE1I6OsufnoVWRH1s8DPXY940dx1l1CqNtioU5sBjXUrRbBaqFf5J7PaFFk UWTPxGEsg3QltJqI1VwsBCJ7hIk42oOWYsFqJlbrtHAWt2kTcY8nI2cj0wJzvWlan+bNbHRs1NX4 SyasImyQ0CBj4rPnzp+/MHXhwvlz585SfnLcgGlrCrHaLxZcLJha/f2qC74Lvqc7zp+fPP7U8bPW s1Y22cWJqYnvT1wAnQedA3174uzEkxNWC7HaioXbVB012jNx2wSUohpfFs7932KuOy6KXQtvB5al 6AIi0ntndunSRLrSm0iR3qvUBRssSFMUkarSRERFKaKigvQmoCIioihVBAQEwYIC8mYWRa7X9+59 f9zfTdhlkswkJycn35czsxlYIyW2wKDjtVR9JKVTym51dUMkdnoMppNEUd7axVCElLemRkiha31o dHNTZmVVdnNrbMRhV3E0jpGOkdIwKHKCEfcz0oB/q5HwSCQMA0YcjJXyDghI8atrfsPBFgzmcEvL w1A6ajgdFlLCyzeNUHjzcs0DcaNoxk2ZUo4Eg5I7pdxdCXINQMFbWsDBcFKmw4DDr+zg4LDo8D3g oPIjLWA4WHcYvOLwr000NtIh4HSoujoYbH0IGFGrdGgAgMGAn2GIjgpORwOVtoBDN9fX2dny/cIN gQYHp2F4OTQOtPwhUvyX9fbWvBk3yrGbMm5D2ZuXawZCg13vH9hXynqzb+hHE5D3Q2qCBgp3nAQt UTA/u6tAqft7O6ByIG8IutngDIOiHBjZwUhDD/5BxuTM6p7pkilTpjzH6sDqQHGSKIMKjSnu99ey UkaPIsQyjpUVAO1jmQ6BoNtg46Ae0Ug4Ag3KUwcuqkAX1sGB8oSKkgGCPg0a0jYMUjjEAGBqExWM ngqDweHAKlkhbUOn1sFRcDS4VIGm9FrGWgAPAUom5eh7gMrR4OhTd0KBYqDfVfxDyzisAqmP9XtY pWQcbAHVCzYLdmOVMj3oQcNlAXsqCHODaYOTYzUSs2az0NmclM62/KyP0oCzGlTDIrjGoEcHlFFk AUGIHjMECVU3B9vw3E4Y/CBcfPzcvx9LBq0dW0LH6oGOTuLc6oG+fuLcGuGBPuLcOq7+3pTvQPA7 0BU8hn4lL86t7xjs9/+dTZEBTpED/HDkgv+Z1kTiyADIHKcxNKKxurGf6eBUiDwyRwyYBbEAgRag waDF6JEINjQMcMRgxTDgiJDlEXBUnhlgAohvyGE/zxnJDlOmRCPK7zn8Kb+wgn7/owpFgGdDZSim AuSh4qfmNyyXuGrTlUqLnE0s+Q/lkVktADKqESAji/OQCDgCgZcGRWwhRcrBQ9g8AykCtwB069KC bAQDwihiIi1QGDzCwoyABzZBCWo8do9jkIenn3uwvx+BEaCHMqnwVKauLr7+fi4EToAdysHimX+7 NY3AA3BB5Ug8689yc09fVwmzYEffAG5jDXWAcwsdQQ5QBOQJ8rIKstLWYFJhQxKIqvhHJKMDaKFy WjzKwMjYlCAECKwlOf00PAOgLSuaZlrcWmaG27VliQoS0vLy8hIK6vJyBAGAb61H7L/tkdnaxh+A DOfdqGE4GoYkwxlgYD4WQYbDYddo+bZdao8XZpIbbfSww8QIh6jHbb507rIMwiH/mvYtLN3Vwid0 2loTpTnsC0H7Vv2Xb2VKpH3axhf/yaRi/OweyxWDjvOyd8YcO9yZEFs0FxOYdfIksCdhpR1xdbtc 7ivUDB8Xe9sYK31LrI6t7IvQGQwQoDBYjW+KfLTLIXP/6HCjf2Xydp0RRtriwHjbw/wa9L1Xinhk 4l9cDUseG2Y4eHpLLF/S1iet+1sKP5UZi+dad1qXwVtTyU3wJWaE67RfzRaYRBz6VOK+JPnjNLk1 bkN+vk+H8nb1D6TmRBx6zuJWBxeVMhL6aj22+J5jih71yVuLk+lQnUt6f9edVe2HXrVBXAgkOI8K yHAaUCNogANUKQc9igXF1FP7iVgWT2B4szX1vWot4asNgoGGYkMcfChWgCWSiU9m8bmpdgB2ZsdS 6FKFWFmjbAUDYA6dwIUyAHYDenk6eVqxGt/3CjkH+vyywSzA2xPKlfq+VStIan0YoVGkDCJolZLg KYAVhhqcmGg06Leh9IFdgO6PNICIVf7eQFhY2O8acA38HzUHA3hIXgEUDsD+qBJJ/cuEREJWkmkD ezlboHvstbGieyp/nf/Jmh2DihfFDRLEL+1VJWK9Opdtt6AyAaPuVdz5owMCDajt1J8NX8MrBvw0 XA2HVCS1AkRCuo08jVhIFQ8PqM5uvWpQXhJCNOVHZyT36b6Y0FxKdmTZu+9BuZhFWq6pbX0dIET1 rldfKLyi8fMuWbqtBgWE5pdP2HiThGhkdsg/zNFlTwxJ1MjuEzG/cUnehymnjeRTufVKHKlA3qUG njL9ascR+02M5qlo6xdHKoR3b86RIR+TEnaQZ3zvztZDDuofJC4NSheM7pDlqZa3IXr4d/SJTcAd nU9lxL95O1eGKP3y2XZ5MKpR5vANk1fbuKZNp78CZAwchLHJDTDWNJmwGBFlPLlKgbGmjVqjBWHs 8D8CFsKA4Nqk59pY7uLKbebpTtmoBQ4stEOXQEEzeUCBQCACYJRZQ7OfSSD4H5Hveznyv5T/JRrF J97mb6Q6eSYynHlZ0GE5MF7864eCjPh07cqCDvsEqe3SkpynSF8PXuYiw29GdLBVI9u1p5qzPi+h OOaPYld5/fLn3VWahVjHhLk+olLVnadH7zIfn8GfkR1QCDD3V5q+pkUD6NXXnASycB2h9z8HpbGE PT5WldpKfZR7hvOS7Pv9DUPBsN2J3S9PTfWSviV9veYQr3LvDleJU0Ztc0x5cklvqdgT8yXZFw/2 p7zhXJ3e791xhDo0eIjRRLfnPaxNV7+ASnZsL93KwXNtb6xHj37sPcPAdeLi65gt9b3tuRzw1hXd InyKdAaPLnGxgf887HqNWXu0n4hN1KyCX+RC1TSeduoHGkWCGjm4BjcCENysM7M+NXx9piI3wFVH r1PMIwfFt6vuDbbdbVXFlY34TMAUKt6EArHogg6g9SvTyABEKInGixGlAYBAFHNWAGScZF0dJWQU nWQkZIjSChIK0nJECRcFWYKbI5EoK+Pm/AcI1PVzGTNGPyFf2SIvz3vT91J7CCLtv0PgbxHKPyCI goKguYB2DFoxaMCQ/dpDXxKAvASgQIFAxw0QaAGAq5UNEKj1lw38QMH/0UQwgIMEx8PhqygE6M78 cTojyQg4DMPC1b+nwbiNz+i8CenZzOLKg3tP695/2WY5Y9bmqYN+2tQxPbKcZZNmv0lBuA6thR86 Ex5f7VbcXzWFsOCrVOEjqfuWLL6HWadmJbJ30qR1nWHXBC4XsrTe1bH5KCZzLPeklXyjIXspbzvj gz4y42XZuRLetpP8F6OODQqxv3bjSFCVXN2DNKj3i84jTt2okDK2tMOUMx9v43CuDMKN9kYIMoim axURo1XTVffohfElfCtnbE0co2Y2aRazJtgoeqVfuhDvnS7s/76p5O09rS2dToZRN83ZdE5kFvrW +Qm1LApxtc1wX6Ytf/+Q9kzqiFe2Z3S+3DNf7m9Hn6423s6Qo/mmwlSfyXS5LrZzllxfbMGvwXpT 9ygptutLd7ba1udMCeNJuR788R5Kl1sjDQXHqXn0nVfOnWY2kL5p6WD0bNcdhROrkq/K7S9oeN8n PSqv8j4Z7RMXeOVt4VLuK7ZexWWX+76q1GMHo8uvVRfcPfAo3fJChFXHZh2nbp7ZZeUmAu1nKVWX Qnl/B2O1Ss1kozzaYzWHrT61usc59udkNrUd7/DXGa6TTJ0p/1QG+E576V2aTA9tu0fd9E3pY0mQ POa65aOtPVUfU9vj2OcjveBGt7ZFBVU8seFV227FOhj/zr1Jr0jqpcAxlX1d0zKapziqT+FCyaqz TX0S+SjECd0vs68Qj5DnQRKgAklgdo0EsI4sHjIU7Gf/dQlrT4FTLE2KYMLpeXEX+FYWJGiNhK3A lj9k0qwbK2iGYmu4yf8TN039/UHwBE3X083T2THYlVs9JNjDP9AzOBwCd0AekAGkCURZaUARBHci gZKUBqDkv7eG/it8z833KR/s100RPegtuXX43shoc5YJn/G1h69YDfkZ3j0ueqx/LRjg3jRF9dQ8 jVkvddvOlJJMW0DwBcx74sC96QQqhs/0qMy5hE6uDmn+uOz5D+7s4ssHxuM53o4bFuTX85m1J33V ekTTta+0q2wn6vyXiz6n3Z8Jv9Q2K4vtGhPWlhS6GmtkYYp7jRRf8kpOBvziFvYC2V8P92ZUTPBk HF7sxi9QV5r5mt7QSs7Vhe3ScdskJOJ2KeP1E0zUrvNfYoo26TDRkHNjZixI3+BnOIypj8IYAe2Z ygE+7aomCfPcUk6SOiGs8+ygUvTpfEfETQ668uXPZ6/DH/LuNl/9gm5s4Kb9ge/FoEaKAIZ1xEED SPDfBjz/7eoSgm8OBhQKtL9YgBFD850TmOFQDgyIylzD5qhkICopkon+Ktlhh6VQxpgAfll0GGuW tvf1hXznC47/uHmSGcOvseTvyiu8ph9k9YEKL+kKGK+Rgh4A8lCeRp56rNrfXxevF0NvbICgnEII 5hsIQRfQBjQ3EILC/7MmhvqhsVbr31wPg7pmzEhstEVqyr2avHEtrP9huIkBvFwyeL+NLw5f/LDm wMnbkj2bzx/3dbq9B9FhyI03znoVsWNkT1Wp1Rn2YQ547NUq0vyxrmkl+LuRmpNYdFuS7sicGfMr o+KU1+NJXk8j69+kzmOkjiInT4ny8wYsfVp+TcqSpPtMNRJQzWqYfcIbG5h2O1/xnLtEswn9Wydb NZbMY9xqI1RsxC+dhF2hBBWxQNq2twEqq0ex+MEGrOOJuWe3t0wZHjvSLCu2r6B2qvoQ7c4DPWaB PO+A9iqSq60NfAuWib77BVPmR+U7blYVElLjX47GdppYTmQHpPpcVdTv+RRee4U1wklk9vxZERlM GJvTfRVOXy7yHG2reNUjjYqxL9OHbo5euBQse9uweT/fZsFQWmXT4/uttTWYqisqygzc23J3rkaG 80TmMANuEzs372Nry+Hl6dKYFJus+qDbKd7TR4zUFxTV5be3fms5e3EgK7t9u/+9KKFgzKZ3oTy1 Z8n1Qua3yr1UEvJDHW/45eMv1l7Rmdvsv5JI9Ln+bdCk7Tjffbd72Rxxm10QKhKle0/efs0zdrOs 3fkGyRzdoy5pfDW1rJBUXJGXHsL2PCUOH8IrRbxE7Zdnc1ygNm82pp2nd4rT6P6Zd3pDn+Gu/gm0 h9o82974vS3KeEgQWaVvtrHtM9iW3/dVKkdN0oLF+z6+YAUgU0UAZLTTDyqgT+6mUAHyVzcgKv4f gWIiAKxNSJG/MyF/egQEkDYUiICs4hppyFGSBABK/useCxnxZ+5AQNyBALkDnHPFc18DGdklr/X5 XSEzGsjcnb9lxZO7c5uo96S18ZXbGAU2lN7dI404zlfy3i2b+2jnFBqyMGVtik/hTISdTxLowl3i Dqc68PuU5uidm/TY1z141uw6Vryx9PllsZIImtJn6XvbHdjQk26hE0RTwc1S48XUxo8qNCvt+pok kSHFHgsdvgvbbfNZPmjfHVJwuernIku6mOfMIPFkx+nF0QEquqe24YV6IuN0NXn4sJpUldmlUTFr Ri4DS+HzEYFDm7dX6u3rm5nROBX9/MD1A7HbnquWH7ebSDCKYZvPl9r7OllJokTaqrlS9RvxSQVS pfx6aYrC4e7sSPGPhpaneGQFGhX9XI6Y3T3HcG0rX0zHh7vI2KTP9nNdprXHU+Oq63iCBexZhW91 CgkrCGQq7pJ7dLA8pYSdr+iy27Qjl9ewsF62ffyIgN0Tnt2qpk0396jxI+ceR9hIPeUbDbBjMNEO q1iEDVdfRZDt++uYK+5t67HYPa6YzzDJp1fNelvzoNbr+sbAiKHAcf7BWu2s5tkG9j390UnTBnpA UfGJwWmb3NLlV2VuI/UZUQdmemd2j+uJFOGFLxYdco98k+hEsr8uFfNszznb2jBh4fczvo3CJ8VP 7pA3qh8+qpnQRKPf3FOoIRWc9tlvkcRtJY63c0g7o2okHfOiLH7LQI7hh/Syau08n8zuod744+vc OQNy5+Rv6O8nef7WL9m6fgETAoXjxMLMKBvVNGDqf+TVP5HyRo8nUGI7gpCscYcJbTj8tqiV8Jgv QQawXiM36BaqUZ5B3u5Yvf/rpg84b8FZC07WdafEHpC2JxIpNLdvA82ZAsaA4Qaa2/n3aO5/1B8M ROVCwnOjojKAqFQg6tS6kiSRQFQ0oPajOQScRfqv3CzoLUpgzzx9HQPDnQOCJD2CfYEd6xUgABlO IjcHTB8Gvbgd2hNoT9kTuLaHNBxMBX3f3eq6vsdXkpvjd46Y+3xsYeaQeTib5JO+YHfes7Tpm4ad U7J2ph/qDscl17vaS4qrLjYGPvaN/lajNoFtV6rVuVyw4NnvXMsrW5hh5xqTfOiYtrFFHy7lYDfb bvYF5Z3HTLvKVrxHVakkRc6+UdlW2HOTIyxVcWTS5b6mCimCbwF/6GJycHTShw5BhLZoQyJj1YXL aNzZGY+vHpJpeaJqot5Wes5cNJ5+1pnpr6M/1J1c0BYbWFbquic76ydQMlYqNNP1aoG+NEs4I9OA XoV2njqhl6uRyDoy1yzx0Cbnhp4itgXb0HKtZOz6837meBMtKwXifiG2I+UfhBYHxLdze2Ze35vg 4edfVBncuAONuQgXFVYlq+EN3GjrKgw+Dp88wu7PfEirKHRsh6hrQaOdqVNsI4ezXEbs4IuFxXmW /DNCww8KM7re2Tmrj9pQnYtTxYRhHmPKQ7iYahwdb869bNmGqhlUb6UXfjfgKjWd8SnfNr0P1puv fW/vQkYhzW5dxqxIri6YSHP52UI1rTBO2Zbu8+dzIyJ4v+qmcRUv6fBFfsxZrPWu3J0xMhVCYpt+ K58Vzrp7tbeCzyPkTenX5WNTtJFvPZVKl4EZlP6JwcEQX+dTKo+zLQ2NaiP38OaTNhF5ImbVseVq S5c6L9jV58ef3bPf0lBXq27n/bOhNthIXe+V8Nz6e76+XvdNg/B0EcYPCGRUGUBGXUXA4UBU2r9N XL+/Hfjz4UheVBMEPt+NmAZJwG188gJK8TNFS6AHNpYyA3w/L0QRQGhbSdUsOjH/vjdq86DIPd/k mFtTbAOAy4ZLcARLwDxPNFL4t68eMf/z2+DzBSP5/+vMNl9/Cxr3L9yMIsNhZjonLkbfyvG3FsL0 E/aZSlVVmFCpEeg5IkrCdMxta+VlGOQZn5i58VtgXpieYp7IPMPiGWgjXlLxWlKEUYBeG7vkGZei 49OS4rK7vyERNegxS4h9NnCj/dqpmaSLJkf8SZfhqOqV6so7bZMzK81xsBfjVdkuBd1KrT6t9kuT S3eZuzIUfGbEMPOzOnGbSF0cq3uUHoxYcVpOtMZTb2646JN1bmypTsR1UVkZeVX3Bq96BE9R9Rum zmSNJZttM0ahrOpXVi7rMiQqWdz2aqi+SHzlzFgjZ3UCLanGnmx3Pml8gi1hIjXzQfgn1Sl2bzK9 F7y92lLQ4wId16Cged9ucRuexHwyQhhcnvD/HCMMgYxgBrM2UUzzxL/miP/+SdsGm7QDWDeaJO3P J4ZwsPH1EjSBgXLjWI4gSyRAwfpPFqkxGaOUYyzcOiV4nNmvp86D4+yt8F9cJshWCIb4I4iEPUj2 vbsygqew0btEpNlEWu0WXozOvztYnHqWb4LovnkKN/LiaZKhgJdgweCZyH1ZEt1y+1yZLj8fLT3M 4vtWfUtX8KtV/1ma/J0587v2HxE1tc7heoeokNBL1eTpefeFlspxyiL8MHX44YwAvH2eq40wmsut 9XqbW3bPO8cB9VCdypWBF2Mr5G9jznsf3R29nkHn2dS9P+39x1DNO0NN4Y+/PbxwmzaXgDYb079d dYfLwi5/IWYyZSCpuow2agqfrSrn5X2u00798eSFp/0FFRMv+nGH8FZ9O8V7/KqeiSjFTO2kq4um MhnevlC8V/96Yih8trRBZD6kMJGg+DJJE/YfoV3P2A0KZW5kc3RyZWFtDQplbmRvYmoNCjMxNyAw IG9iag0KWyAyMjYgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNjM4IDY1NCAwIDAg NTMyIDAgMCAwIDU1NCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCA1MjFdIA0KZW5kb2JqDQozMTggMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5n dGggMTU5MDkvTGVuZ3RoMSA3MTgwMD4+DQpzdHJlYW0NCnic7H0LVFvHteicc3QkIYE+oA8gQEcI BJiPMGBswDHi/8cGLAfs2EZIAmSjjyUBxq0T10ls10ma9BunLU7ebZKm16uNsJM8x216c528VydN 7L6+3KTta3Kbrvbd1dX6tbm9vas3tuHtmXMkBHbcNC9p+nrPHs6ZPXtm9uzf7JnjZAGiEEIqeEmQ Y/OQvWp+12gAIWoSqKNuvyt0/Pnt+xHyZyLEaNwzUa7x91uOIHTgjwjRJ8ZDE/7QH+46iFCoGCHp CxNTc+NvH56dQejgAwjp7pr0ujzSb385F3j9Bp7aSSCoinN/DfwLoF0w6Y/un/KkzUP7AkJ7t0wF 3a5Nv26ZRuhzOoTWF/td+0N5r8iaob8TxnN+b9T15cOPAP93HdC+K+Dye1t3t4BsL21EqPLnoWAk uriIQPZ3OTw+FPaGfna4ay1CM7C+RIGwrtL6t11nvtW0W73xD8gkRxhe+ul8CNdvdM1uu/Kraz9R 7JedhGYKohEPME+KFhH1ouLVK7+6IlfsJ5ySIFuPKabPo37Es6SRBtnROCDnpC8QikRSQpUhFsnZ h9hqYJnH18wP0BEaJtFqhqZpCUNLfoEqlp5HBZ8gEgD0DXEcXq7wFV4G2UnaxiFqCfcxp1kV1hTp JCpUEZeGuoT+04P0PHqONaHnbtTHbkSBD8pX0nxjnh8mSIKo+KNe488BSR+Kfdwy/DnA/hzFJNEb yyx5AAU/KF/m0kdvB+YtVPhRr/H/ApJitPfjlkEEHiRlyPNB59Ln0dc/TFn+VoH+Kdryvse+hXrj OPUOmv5IBBJBBBFEEOEDAf0VKu89+3bAB5YI1wGjRF/4uGUQQQQRRBDhg4PkH5HrL77mF9Fh5nZ4 voAG4zT6D+hw8hjGgAr+0nKJIIIIIogggggiiCCCCCKIIIIIIogggggiiCCCCCKIIIIIIogggggf AYj/N7oIIogggggiiCCCCCKIIIIIIogggggiiCCCCCKIIIIIIogggggiiCCCCCKIIIIIIogggggi iCCCCCKIIIIIIrxPWDr3cUsggggfMzDCkyP8ta9HoAUYfS+SoLugnY00QFEAloby0WY0iLYhDwqi MHqESyl8ZYn8hS7o41DfDfqopT+QfjnKRc9QKip7yX256J9vEdYyAPcbSMR0Mw+iVtSGepCU+g2h vbP6b5FBmxb+chmNbg5UEtePAnhJMWwXKJGbCHMjjRF1kLzv/XAF+8iB+VC5/RXEm8PhHXZuHRoc 2LK5v6+3p7urs6O9rbWlucnRuOmWjQ31dRvW166zV5SXFdsKC6z55kydVqNOUypS5DIpK2FoCpW1 WdtHuZhtNCaxWTs7y3Hb6gKCK4kwGuOA1L5yTIwbJcO4lSMdMHJ81UgHP9KRGElpuI1oY3kZ12bl Yq+2Wrmz1PaBYcDva7WOcLHLBO8juMRGGmnQsFhgBteWOdnKxahRri3WPjN5vG20FfgtKBUt1hav orwMLSiUgCoBixVbQwtU8SaKIHRxW/0CjeRpeNkYU9jm8sS2DAy3tZoslhFCQy2EV0zaEpMRXpwP y4zu4RbKnj9+71kNGhstTfVYPa7bhmOMCyYdZ9qOHz8a05bGSqytsZIDv8gElb2xMmtrW6zUCsx6 BhMLUDG2UGPljv8BgfDWy79ZSXEJFGmh5g8Io1jFhJmgP44jkA0kBP0sFizLPWcdaAwasUMDw3yb Q2Om08hhLx2J0aO45/l4j96Jew7FexLTR60W7Kq2UeFnZjIzdmiMKy8D65OfQviBfi7G2EbH3JO4 dnmPW1tbebttHY45WgFxuARd2xYq7TDeNQpK+LAZBoZjdmsoprM28wOAwGEf+IaGyRRhWkzXEkOj bmFWzN7WiuXi2o6PtvICYl7WgeFnUfXSzxZqONOZalSDRrAcMUMLOMXWdnzYMx4zj5o8EJ/j3LDJ EnOMgPlGrMPeEewlqyZW8jNYzkJWJLNAt1Wj44Ox5rJCOTdMm5gR7C0gcO3wsjZvhA4NuIs0sUeb N3LDlAnFh8EqwgiMreADDaawpRN3MXhqS6fJMmLh4SYimQSZ2MKYPImXBggJmfh13lM0fjQWqIRr 87YmCbiCKSsIKHC7sZw0toWwMMyQY3d2xruYQti5QKOBDSFhL2ZyMbSFG7Z6rSNWiCHHlmGsG7Y1 8W/PkLVnYPsw8bYQJVtXtPj+DYk+AYvRLRCA7aWmuE9Ju4O0E83OVd1d8W7uuNzaM3Qcc7YKDBEH 2wc0ltq6XPdsSK+BfdkOqc3a7rJyGq79uOvs0qGx4wsOx/FQ2+hkPeZh7fIctw4NbzQR0QaHD5oO 4KXSUQ/Vs7W5vAwST/OClTo2sOCgjg1tH35WgxB3bOvwaZqiW0abRxYKoG/4WQ4hB6HSmIqJuMHh BuY0CA05GW961oHQIdIrIQTSdp+lEKHJ4zQKuc/SPE0Tp9FAk/A0B6FhAA9lToJ9Ide2cR7sm0+O TB4fHcE7CxnAj/BDxSjrJhSjrZsWKFqaGlNYvc0xpbUZ0xsxvZGnSzFdBlFBGSiwZtukNW4ra9uk y3saUZQ+w7phgULa2nK0kGJvUlEbUSM8NFVH1aINyExtEOr1VO3pDeYfNG2CNkV1og1UB3JS7VC3 Qd0KdQvUzVA3Qe2AuhFqO9QVUJdDXYac6BDVA6Y4RHUDjy6+D20GThT6HYyHw5a6BVXCQxMsBM8h eH4Gj2TpeeqWMyptOwIha2BQDXTVoB/AI4HB1YiD5xBVfZpJtTelUmuBmRreZniC8NwBz/3U2tOs Gp2lKhxfoXQ/f3TJ/PbCkvl/fWGf+cdvVJh/8rrP/KPX5s1vvF5m/qfX15t/cDHbfOnipPnVi98y v3LxkFl9kfKbL1JQNbx84bD5pQv3mr93odb838/3m//b+WHzi+d3m184P27+x/N+8/PnD5nRec15 7jzj585XnqcxSmMK3cCdp/7hnM383XP15ufODZq/c85v/va5iPnZc3eaz56bM285R51dev7MuQOH 20k9GeBr53a+bm7HtWPpnL2q/emFHvNTCzvNZxbc5tMLe8yxhVnzkwuHzd9a2GF+/NF95scePWD+ 2qP3mh+ezzWfnK8zf3X+8+aHTjjNJ+6tNB+nPu28myk138V0mA/vOOT81KlDzjt2HHTefuqg036Q sh9sPBg8+PDBSweXDkrndsw695+adZpn7599eJaZpQ44P7njgPMTpw44QweoYzuOOI+eOuI0H7n/ yMNHmCNM2LllZnSGngEkMO53xvzUbn/Qf4ef8QMluiPsjJwKOx3h0XAofCgsCdNB574dQWfoVNAZ lFLmPSCUr2PCOXlqwjne4XF6T3mc7o4xp6tj1OkYpW7r2O7ccWq7o9t5Kwzc1rHV6Ty11TnUMeAc PDXgHJC2mzd39Dv7mUJzX0ePs/dUj7O7o9PZdarT2UmXmjs62p3tVKm5IF9htuZnmhFDyZnnKBx4 LETkA2hrac9Z2dJgT0y+ZUeMOhYrHMJvx8D2mPRYDDm37xheoKjPjJzOhmyxlWRB0r77vvtQbnNP LHdo+DTzyCO5zSM9sUMYdzgIvoRxBENGdkVKr4fIKjwSwXVEaMBPNNFNwYOEulTAS0vj/dT0rkh0 Or4GGQcEvo0Sk6lStCtC6LBIFL/iAuA6mrkLIdlJ1s+cXfw8vuayqms/+UD38g60C82gr8Ft+ybf NX8a2BmkZBaQFGUgtPTu0uXFx+E5y6qSKEROSS5QtPycpZSl/wMjMghNTUa9g0ctnmWakZTMVV77 HlDh1r9UyKRAO22pFtq/p49inJ8hO7n45OLXSa9Ssp76CthhCNWjJtSLtoJuTrQb7UW3Q7sb8DF0 AOodaApNo8OoBb7stkH/OPKDDe5AXwU7PI9+CDOdMHMChdAszDyKHkAPolPoJbQTvkf8KIo+gY6j /4KeQ5NoH/C7E92LTkD/ToHPN6EOoTl0CH0afRZ9GXo6oQ+vuBnG7wcex9EeWO0BmDeL/772Xxuw 25EePbL0x6Xmxb+79h2mkEmlXgGdj4JG06DLu2iM1aG9bNnSv1P5S++wiqXfSO5Yeodau/SvSMF8 khmHXF8BH16vggcZJEN18C3X7Sgol9H1p1tV3zS2QqEp7ltyCUWb5RRjXSdlBrK0XY0SCtnffOvN t15thEebXldH2d98863LGLPbNZehvHmxci2ltWjJo1PRMplOas2voNcV1dRWV1dtotfV2Kz5KprQ amrXb2Kqq/JoRhenbKJJ+9WrLmbo6r/TnypoGq5hDXqFSsFKsvW6tU3F2uGxosZKTsbIWIaVy4rX t1jaxlvyfyZVGbXpmWqpVJ2ZrjWqIDrf/VdWdWWD5PCV2xnDxl0OK/X3chktYSUXjHpThaNgy21a vZZJUaemZshlGelptubt1z4Z5yDU+F8vnlt6V8qCpTbC92lxWmWl0W5XVGRmZp8vWJuaqjiPCmoH lJnGNHvm2gqpuXjA7Ex3sk7UCJBurNNWN1L21y5Xaas1+KWtu8VeXa2trlxbGFdZa6VUDMaKKKs2 QSTWyqONVDUFJsKoXspK1cZ0TaZKSi8ytFyVkabSpcmpxRwK6BmgMmtLb86y5erk1CmWek5hzMrV dqXoNEqdVCGVSPDr/it7JGA2hpVJJF+6si9B/3aBSanPy7hyVYIyLTo5NoCguWQXq0G3oGqHqUit 1p3PU1RUVJ1HeRsGFRXqIklW/kCWU0qUBV2TNLXHNeQVs9mKrAad/gbq5THGalsNEHjH6yW7lFp9 SpbOYjZnLG7IbzNTFDg2XQta29KrMrnsLDW109KwYb2J7wBzyBqwsxRZayxMccPBhq6Huq6eS9ZM nmE1Xfti/d4JT/XWZ7bS70gVMoaRKaT4X64CS7+VXGTNkAGLUJ5DrXsB5b2gKM46px6ynmO3ocbL jZcpzVuXX7sMUb0qRmU1FTSOZL0uj8aBLbnY8ZkfPfDApbsb2+9/47P3XTzadLjU/ejc/scmykvG Hv3EgcfHy+gvfeXKwuiOb/zbQyf++OTo9id+93eRl77oHPnSheDM97/k3PHQSyAR2Jz5F4i2WtSK ah05mgptieIFtP6Fkkbt+ZwKzTmHw3jLOcuAUYixy+l19suwDS9XvQZS4o24HFpFTAVjXR1TBmMe o8cbEyyfYTAwNbYimw1GYRXwwlkQSRqFZE5f2TracmTZ9r+vbMzuDnRaC5pvW29ZV16sm0uTvdF9 a27r+kfO9Ux1WAwyhUyCdxNVv25XW/G1Z5NdwErS6p17Nzm8fRsy1GWbBqoWf2jNZh4cimTJZYuF hY5tONqKIdo6IG8VoFKHDmXB/spKzTKeT8syD2ay6YNE33QIsix75mugtuZNeIGyZPNIIMZ4twg7 pspgkMrou5nUDJM2VadJVcCmaZNSqhxjhjFNxlCfo6gjtFSdrTealJTUIFdKGYqRSOVSySV1hoJh IEiu3CeJQJgwEkW6GsdKDDLmT+AkTEdmlONQZVxC2RdTMi+oPKYL7AQfKvblSLHm2xJhTkJFMPFP Wu86f88v1RaL+t1j52533F6287Phrz8WeGC0ks498vKxtiwz801zVueR5/YPPxhsvPpkzdSjYJvY 0rtsFay9ATU5LGX68qLMi/lpdkV5eX6N4iLKX+cpNyiZXJsnd1IzyU7Gkw+/IdMh50BcZOIElBwe OPNIpX8y8xj0bBWEgUZrTAMbeiTGHFVGqoxenKWlaRAcBhVr0XYaLdkZcsopoUYVBpNF35jOZUhT sP9TpMz81Z1yJU45zNeuuhPUH5qzlHpzxtVfMoZMC+x4M68l86LEihpQsUNnSX81R1L5Ksqp9SrX GDmPcZKZIImmTtAL9MHKSLGp+RQDO/FGOcZgMFZXMMs5hnkxL70ti1Mvfq/s1jIKgE3Ta3hF+rWZ WpWcyq7YXUGTHpVeqzWkshvMWTk5dGX/wwMFvb29BdceStZDptKrFqWDf3/rmuHh4VI6XaqE9CpT SiFmgkvvSCySMpJfIGZ0l1DeJUXWBfW49QLruy5mbpZdLJvmnpqefTK6YdOBp2b2fXNm46GCgTt3 775r0GYduHN09K6hAjrnjlc/29957Ht3fPL7D/R3HH3x2G0np1va958c3v3ITHPngUdwDIOFIxBH 1ciBahwmxatrNaXamku2Bu3FnFLthYYGY90FbGo+hpKTC5j99ctJuaXoBrkFbCtkFiPOLMtBH5Gq sjPSjWo5s0NTVNtzyww+rHFegV2w63bnmrzanoqcikKLeodC9t3MdUPtjz/Sum29icQQI09TvFvW tS5vcV2y0Yvb3fXVzpa16lRrVVPx77OM9K+KmitNi/fk1rTjbFIImp6DWMon2cQI+8WoMOovKo25 XgOr8RIF3yubkBOrtva6dNLAyDXZGTqTRsEs3s3SimyjIQtOY2qAptoYmTpLp89UMCxJJoxUKWfe 4lNJivTqLHOUTyU6NXhh79JvmU+xfmSDm9esI3V9sc6AemeqjlTR5WeXfnfGgPqg/qNjox71zZQd KaOLNXoYMJFNpeiz9HSKJktDy5WmugVVzZpMCbKfzqi3tCvrikwS1ZpHM7trHlX1sb2gHkQXSQL4 ADPWXa4C/Xbt3LmzdGcp/CSywDo+B/CBZzAu7xKbLTkA14PEaTq1Rp8m6/zyjrHjtxZXjT2we/BY M4vvXZAbZnvu6W0b25STWT/aWdDa2VemwxrjRHq4f6T38JNjkWcPt3d10Jb4wXCtf8do89Sx9p7P BFt0FV21OMd6wDIXmPNkv9zmcPgK5wrpccuMhR43zZhon3HOSB9Npx7UUlLtES0tT6OOyakU2adl NKR0ue40/geivNNwgD+q7rY+xvYtH+A7L/PKx+FP7Tfmwobg44E9D+9dtz74eHDPw3tqb89rnxke mOkpiNfUz6eeOdLTcvB0aOqZu7ubD54+0Hfv3sb6iXsH+u/bs6l+/F4Q5utL79LzoE81KnRk2NQL u4GWrXistNum1nNd+l7E5zPIAi/uvFy3nAawKLKk3SX4RE+uy1J6nmZl0pRMzmY01dQ12kgihvtf PFsVNW+sy0vLLzKnSuBUC6rBZymKFGP11luufTVufebT8XvQ/XXtRSpGrkyRKTOwD7bQL9OTUj2c w+tQmcOYkrVuHpXPa83+rBSm+IRhX9WJ1CgTEeKLJGPIYFVEeOn7j6ja9fSkListPZWtHNvYtH1D NufY3VjtXMOm6uCimcpOlg+Ul9QXaFX5G0pLBtfRv1DAGSJnOyurKvonG9r3bV5TUkw1SOBUYeC1 OFJdXVDfbSvpayiwN2AtekGLz7FZEEmFJPPOo7x5RdYJ9T7rCTb6/jNvLf25ot5Ae+9Uu6Wwe19P x54Oq1+7pq3G3l5uwPXwKPPHpuBAeVHPVFtzYEtZSc/eztK++nxuQ39FeV8dN4lz0TR9iXoZZClH Voc2Pxup57MVDxXty1fr80L6yHIMXHsx/SYxUIvPYj4CJNTLNCOVyFM1xgyNOb8oUwJ3HGw1XU5O elZpUUGGOt8IX2+Sn6amp0pZGZtqKrcsfhXsx2Aj0iaFUqnYbCmBMXKpEu76NJW39B/UBXYYvitL UJZDaXiG059RsoWmXg2yN755cbWxmLhTM1aZj/oGnKZqCDk2jYXrlS5bLU2X6SxZ2ZYMmSzDkp1l 0cmokXjsMf8zVauUsEpN6pXynEJDSoqhMCfHpk9J0dvAh4tLv6VOSG4lMpkcqYYfcvpLSs0akArO zjcval58/1LdziozSFylsapsXQYcPWkyba7RmJcuk6XnGY25WhmVLeXtI2WMCnWKhE1RKa7qMjks DZeZla+Ty3X5INUXmAl6BmIIS5XtSNU/pbQ8VcKabO2adnDlq1Ug1Os3FGoVxaCnR9nU9DRVupI1 pmhN6XBVlS1+cQWpyMx8Kr5jqR/HrbZYtJKWlob/i6sLOSWjkiHAtCgbWVEZ7N9NqB0FHPWNpqe5 Fq42/Wljg7EAPc2WsJyRZY0cU5XytKr86arStieKmpoqb3mirpLJe0KWn1+jfyJLU/NEaiWyV18j p7+9Gm5ccYTYHc4Wu90ufNjGX0IWWFdTXZURRxIU9jpK4Q0ofM28nW/r7++8g7wXewqKenp6Fr9P KnqvuQSI1wykop4S+uDVwxzHjcU78JvaU1Dc2/1SQVH7lmtb8kq7+n7OlUIfjan1XV19eGcepv+H RMe+idagIod+zTyrnc8sPMJJ1Ywu54guoozQkaS7NIk1JCU3e/7qbCM3Z+nyXd9gzKjOqCWYXivR GTizkV78J0lWtimTWXybMpo5Q256y5pS5b8xi2ob16Ez0T9VKlPoR6+NpMhT5PTXr92WgtsvZ+nz LNcu0msLTfqsa7W8pPRV9p9RBbI5MirmJTaTat6w5qgiPz3rSLogp5CNq16r4gVNXIwNIE2ymHCv yYBLsc0WTyta+qrJaMmzaRf/I3ttJkXRBnOe0aIp1eUYDaoX25rgKmww52bSv83JzqWeWuOsqJ1e v7hLCUA/bzbKtHnGxe+EPtH5WCdVpUxNVV5rgn0ySL/MNLO/QmqIRcjA6KQm+6RcfyLtmPmGGdgm nBfXncTNlaMPjH73dOXoZ0fPPT2dtXGsq8t9iymzYay7y7MpWzK268E9da/8w21f8tW9/GJzeMhe 5Qxtao0M2aud+0AKbLczxMO1qMVRoK6eN5aetKTMF6UVFDEWi1F+EhmrTxSYVKqMtSdMRzIi5Ggj V9/0usv4QwMwY53mbfzPW1WJQy5+/13hezCzTiqDzw3jig/rWvqMvkhrSJMy/Wl5xett3Zkcl5mt PsOt0bq9wz1r1mf3KNhvlFdri/J3+YeH6F9CAMC2/q/mGpt+8RkSDxeNGTStnhzo32XUdjScAn/l lDeqWGbxSjfERgHo+Dv2bfguLXfokU4/bzbLdRknlUpd9lEdozrKRBKX3epMOyhUZSe33fjnnw1+ +NtuRkb8sku9zuba9DlaOdNyT5tCV5ZuSJXS7/yalqYadTojXHPpf1HJaTZF9gw18ZQpjYaD5FqY vleawtKMXJuGqKVzsm20TXYSMUi+AI7A/yTEWPSWdnrq2hdkJzsRQl/86yhUOnVnUnnlZoXu+rPL Qx9SeeOjKUw3cyapXLlZkYT+7PLdD7ewPX8T5czNijTtr7CEbliewUUmF4tY/kbK4Ioy/1dUfiUW sfxtF/mdH7j8KGVtSpSU/80XxVqxiEUsYhGLWMQiFrGIRSxiEYtYxCIWsYhFLGIRi1jEIhaxiEUs YhGLWMQiFrGIRSxiEYtYxCIWsXwspVksYvnPWxBCVfQuJPy2Z1pDfgEYximUTdsEnEYq2oHiv028 kozCuCRpDIsy6X4BlwJ9XMBlaIY+JOBytIaRCHgK4li5gCvoR9hiAVeibbILAp6K1sjzBDxNJZV3 CrgKdcMY4XeGU3JDv4BTKM3oEnAayYyB+G8HR5nGbQIuSRrDolTjtIBLgf4pAZehBuNnBFyO9Aan gKcgjfElAVdQW4w/FnAlKs0qEfBUpM/aKuBpMibLJ+AqVJgYowHZ4nO1iDXGx6QT2RhESVJAgXT6 3wWc9wWP877gcd4XPC5JGsP7gsd5X/A47wse533B47wveJz3BY/zvuBx3hc8nqbK5KYEnPcFj2uQ KjFXC5xq0TcQh6pQJVqLNpDf6e1DbhRGQRSBZxxFgdZCfsN3iLxdQPEBFkAV0NOEpqBwaBBoE2gS +iKk5YXaC6Nn4O2BkWmoE7AxoHjRLIzYDNy8wGMrmiMYh3qB8xzwnSYrTgE2QSTh4AmS39UXTqzB JWSuRNWA2RKt9aiMrO8CDiEYy8G6LlgH83CjvcLYbmhNAhX3ToN8kYQ+W4HuIzpMvac848QOHGqG 9hj0YKqLWGGljjyfoKApR1aZhl430Tdu3VmYGyaUaRjlIVbjgD5JaH2oC2TC1vGReQFi1wYy30tG eJEf1sRW9pA3J0gUH8sReoT41AeyxL23rAfuj4IUPpgZAStcHwH1JAZchPMY4cNLxHsDe3sCpJ8i mmwjGkQSq9QCxyrw0sr55UnzV3Pm7eYiVsDx5iE6Yt57iT3HV9jn+midIO1p0DU+GnvfD20cCT5i jYq/UNQrxLj//ybue0ESNyoGSgSVCP0c6iBREbxpnPqhn9eA19dFZOCEaPCRGBwHqp+sNQetWcCi xE8RWHUM8CmyGh+52B4+eE8IluS5RonO/JoBorGbaBIQdhz2Yxfx2jhQcMROEwtHCF+v4Csf0Zm3 VYRETYTsLj6isUdDAj2+ip/s7SixIi9lACh+sirPM0IsuSwBXjFEdOF3T9z2vOxTJKpwpEwKkY2l 4venm8jvIxpHE3HP24xfhfdzQNCL399jZOSyxMkaYavtJ/N4rfdCu+K6fFZEuPkJhzlih2lhHyfb Ox6dASHSwyRWooKXI4kY9hJfc0IO4rXhZZwQxuD8eEDgHgUteA/NJLzkIjGCd4h/hV7x3OQGSVxk fbewfgWxVJR4rx7ZoXjI3sde8V+X3SqEnGgHfI54aYJww7ljDqgukJfPAXGuPM8pskew1uPEo7zX eV43yqERYoMQsTS/S+PzsA9GyBq83eeIvfidG01ko/jouJXcQiRjncvIHsXjQkLWSo7aEPFJQLAW z8UrtF1ChHqJfX1EQ166MSJH3M+rM0pUmMFHXvg6ynhCh7L3dVLxe8RDbBoV9iJ/fvDrliXWWa0B H1OzxE5usoNuZLNZQVMfOQmmSM7nT6brbY/n8PusGMaXrMiwN+bOy/BBbZucv/lcxwnZKko8516R NVZrsJwjVsvVkBQDWBNeFz53xs/ycCIPe0gmCpCM5HpPTfnYc62IKn4fB4U3rxWPT5P9wp+fHrKr fcLZx/PBI6dIZnjvGOVvGQHBM8vc4zvEl5RjJ0kW8wl2xreONHKeewUd4vk2buWVUV1GPOMiuCdx 2qw+h1fvhOJVecFL7hGzJL/6iPexV11AwxaagBHxPrvAc/eqs71E2L3L2WI5N8al+XNuT+/ztsLl rOLRG+fB5SaieQ/QeD/Fo4bP1VPCLWc5um92A4tH5XvfwrDntiR2TiTpFs37m48Cr7AWn7EDgt/L iM5h4XYUv/fyp8SE4Od4HPNxFRLuDfwKQXILcRE945HiQsu30NX57CPwRcJCLqI7tptPyPUeYa+6 hZtHgMiafKfzkbtJhMSmION7+xbwoZX3UPB2SZKNPEn3peT98L75oeU7Xnz0jbNb2arsFrf96tlT 5I7kW6V3XK7lb4TlXbN8EsV9WIbid1V8J423vUkREiK30SkSb5NJJywv9RiRxSucVNMJXybnEt6H dsHjEbJLphIyxPf1ylh6/1ZNPuF5LZNPmpUxvWyJWWJH/wf0Y/w0mCZ3bd4y3iQJPOSN11y2yx4Y 4U46O6I3ycd85vcQDeInXv2KLM7fxmYIfqOvwgA5I+KnTPJtNX5O3CinrJwVIbmC99WYoPeNz1zX e3g0nNA+QqI0QLjzu+j674APGgHx860TtZHezagdWrfCaTlIKF1A4yCLDkLPNmjhvyrXCpQiGDEk 9BcRT91KzqFOGOckZxzPYxDe/dAeITmuHXGkjVs9ML4feOG5bWiYrNEG3IbIyEHCuw+ovVC3CePw jBbytypaCd5BsiC/Xj/M4r9xu4QzkZd0K9C5hIYrpeoiK8Yl64PWIPDvFHqbgHcX4Yflx+u3E7w/ IWe7IGkTsRHmjHm2gES9pIWpTqi3wLghsn4T0ZmXtp/o0A79vC5tRAK8coWgKz8O22eb0IN91En+ 0kdvklZNxAadRJpl+7VAvQUkx/w7oHcrOSE2w8xWoukQsV6bYDOsbS9pLWvFe6qFaIOtim3QCngf PB0J2w2SNy/LYBK3lba7lfQvj+L1axLeLcRym0mL90YLaW0lvsK9ZYIvB4keq1e9lURiGxnVRDQe SkRIO4leXvp4dPJrbE6ShF8P+zZZlnhUczfZIzyXeL9T8PT1dsFWbyI2wXINJVZ+L86wN7/BVVWu 3cD1+dzhYCQ4HuVaguFQMOyK+oKBCq5paoob9E1MRiPcoDfiDc94PRVpnd6xsHeW2xzyBrbOhbxc r2suOB3lpoITPjfnDobmwngGhzlXVnM2XK0v4wZdU6FJrtMVcAfde4HaHZwMcJ3TngheZ+ukL8JN JfMZD4a5Zt/YlM/tmuKEFWFMEBblIsHpsNvLYXFnXWEvNx3weMNcdNLL9XVt5Xp9bm8g4m3gIl4v 5/WPeT0er4eb4qmcxxtxh30hrB5Zw+ONunxTkYqEAeq5FteUbyzsA0agxqB3YnrKFd7mDUfwlNqK qmqhv5z0xweDbC4uGnZ5vH5XeC8XHOflSZh1IhycDmGyO+gPuQI+b6Sid9pd7IqUgAhcRzgYXMnK HwSdQFVXIAKKhH3j3LjL75ua42Z90UkuMj0WnfJywDPg8QUmwC4wNOr1w8yAB5YIB0DeCq4ryo17 XdHpsDfChb1gSF8U1nBHyriI3wWudbtCgOMp/umpqC8ELAPTfm8YRka8UcIgwoXCQQgIbDDgPjUV nOUmQXHOB2q4o5wvwEWxHUAymAJmDsBaoOaYb4Iw5heKevdHYbJvr7cibt6iCOd3BeY49zREFS83 tlgA/Bx2gS5hXwQ71evyc2A4WAY4TgAl4jsAw6NBUGgGq+TiIAb8/FrY0O5JVxgE84YrJqPRUKTe bvcE3ZEKf9wTFeAAe3QuFJwIu0KTc3bXGAQdHgojp6bdrsh4MACqw6hl50WmQ6EpH0QR7qvgRoLT IPscNw3xFMWRi8lYJDcYOeot4zy+SAiimTdtKOyDXjcM8ULtAoN6w35fNArsxuaIzvHYBKHBg8Fw HBnHK5RdH0vgEc+0O1qGA2MG5pbhOfEFwFKzkz73ZJJks7CoL+CemoaNsCx9MAA+K/aV8HskaThw uJm0/JaCqAMPRKJhn5sPjfgCJCLivBqIBYp9sApEJ84rYRzDnuBsYCro8qy03v9t58vjoeze/81i X2soyTJ2We8ZZCk0GEwxo7GHNBiMZQjZWjBKVKKSrQWVVELIU0+0CCVtUmlVEtkjWhTle+4ZST09 2x/P6/P7vV4ZZuZs17nOdd7X+7rPfc2gcUwF9hgsJxRMBZ7XRYYBSvClw8uE+wTQg8O+tyggKYAi Tnd4QxhsxAYwvBmRMFkJOwKV/UJh3MIqT5taE+tNiwC6hjJnaOPrJqhNY4HO1I5mBDHC6L4MmnZo uL8OXNIBPb2mCWYR2F42LNhohMX8nBF/xmSt0z1s4R53YTMHhoI1waYBqA4GLMc29/ecCZvyO9YU FraHNyeCzUxg3cAEdDAKABtYxlcT6xcOGBCmHOAS/mDNsI2BrcCOguHYUG/AfEzYKDQ2a3/F2T9f BawQLSIi1IdBg/EB/AyQBzOSxiFXRjCwjBos8bvVYh2mafvuIrZGvmxe4uzDT/uxGQ+ungU3zWm4 wdp/bQ5mAJxy5oZlhXPCFpiB7UTwCjVhVmX4wa90tkHC1oEFRQSwHRaI9l4HO28EXDmNErBCHbDw CDpMlqFhDA63/amqHIcHU3KcZtrSbCWiA0JD/mKNsBusC2cCZehsAb6hgM3YugTSfSK/AuwbjgH4 fRlsxzPmQBzQWBR9VvRlhkbCLsOhVca0G3OQMt0UEQAzszf9O8+lzVpoODx9RCQAEwNs0UwM+CsD wP5mQ8Q6UKwcXQhUIpbkgLWnUpxJlkRLrCrBAZRVNbEuJEcbipMjFvSgEsiObliKFZZAdsOuIJEt NbFEV3sq0cEBS6FiSXb2tiQiqCORLWydLElka6w5GEemgCBPAp4IhDpSsPCE06JIRAdYmB2RamED igRzki3J0U0Ta0VyJMMyrYBQAtaeQHUkWTjZEqhYeyeqPcWBCKa3BGLJJLIVFcxCtCOSHUHwI4M6 LNEZFLAONgRbW/ZUBCegPZWtnwXF3o1KsrZxxNpQbC2JoNKcCDQjmNsSOVOBRVnYEkh2mlhLgh3B msgeRQFSqOxu09q52BDZVWA+Avi1cCRRyPAyLChkRyooaoJVUh1nhrqQHIiaWAKV5AAbxIpKAeJh c4IRFLYQMI5M5EiBTY39bkdAF7js5ED8poslkWALZDnAg2d31hb+lSP4lSP4F7b9lSP473IEAuy/ X3mC/z/zBJzd+5Ur+JUr+JUr+JUr+JHNf+ULvs8XfLXOr5zBr5zBr5zB/3M5A+Cb099t4OL6MgE8 /Oc/iOlX+FsISN9gpv/0e+0Izntn+D0hnOYNTrPhIUxNrEVseLAm1poeGsR+DgfP4XTwHr7dpIm1 pUUy/11vtg4Ith7gTyYfvIpzVJLJhlgye3j41ZNtkj8II3iRBSyZzaAqAYlA4AQhfh5uDREUUoqb C6LxCGjwINAIlgESgS5wgFZCmrNqpA/JJkhzLWU/KGxiDGVfqsCB1BR+QPKzhKHFJ2lK7sWne/WM Kki2PBORdV9qKyULWJJOEAtdD7FQJQUoJAKJxOgCFZs34udt2PSZm2PnZkh4RlsEN9Armq0mygnN g0E6OeAw0By4wIcRcKFFBDCY/pGhTJwYJAJX8mJ4qXTfkFCmL04WkoZrBDASP0344OQhObgdhZH8 1u7ICKFrOUTSQsKw9hYESHa+MG4xZAQZ4Az0DfX1V4Gi4awilFj1n2gmDAnC7YIYtB3FnopThZQ5 RVmmBSMMvvdr6UDEEh3IxgZ4Q0stCz19Ky0rI6I5ThlS5KxI+qcrcuDcQYdYCIXZFkZwc6FYCFEu UC+AZCEQXOlhB0U8i7JPn/1wrPS6bumL30UVVzIj+PrIH5WVd9/ydm1sSjw5WdnZu2HruGbHm+j4 Aj3J+Uapdn77UdbdC550vUn5aFiFltuRLu4qVpFh5PZxbFLNyG1zFCuIm0iw1NRkBb/eIDJ5iyC4 bs9EsO1Bu6qM5wkqH9dv9Puw/5DiTp0na52OHL/r05KpXKkxalK7JKoTKTVc6mHTU5GbbySuW5du Ydfbcofl44Quen0vLe03j/OZJTfjym161O9ohD1OYfG7KPRfm3+PW6Vm5NzYQiuDPdxQ6au0KNHk iaBz3LkIFEv0SAGPkV18bli1b8VDUQOezqi8jjljo7tikhF6GZn2m72QKOBHh1kIfmARbkgGmFRG BD0PLe73oVV6FaYZ14dUDc7yz3tWvLCymY0hGUW0JDQvQVxRb/wR1SpMYGjZRNRElcapev0qUcgR 7iCHtoNWQKQC6wJissX0TXef8OAfMjVhQQy4Vmc65xGhM7ON8C6yNxGgUht0gVx5+IBjcnPzIhBo W2g5ZPO1DCGTl05PEB0d/bMJ6OF/ITkSwsD6KqOFIIGvIlF8PzgkCkZJcMGUR0tszYOeMp6OGhlv XND7ff7HXgsEmCgfSLDks7lxvMW283nJYkz0aGHBHCnpT+uNlhFKyh7wuW+Uqb0+tKA4o14kWOKS 2oFlO6sitlqT7bE7d3kmvzmNwh9UumfGs19FjUXq0Otv7bh/Zl9lpWRPuR8R0WosUBXwOgqDpxs/ WHFyTZdxe3zcMPqJ7sap+aV+IXGXKp349ix8evlYxUofiYO3MhcRbT8anwxOe2/wRK1gUORuUNqI gi+ddqVCHa+ilL757BKNa497wz6fWL/unJat6qMaj509pzNHK/R6yw6P6Sd2XWSKBK0JL+pov8Zz /lGW05qgtQGqeYdtvbk/3oms2vgWYvEgAI31zaKxhr7U8bhE+74pNo01zLaaIKCxTf8JWahBKhyn l5vd7kvHOjD82RkPsLFw3hvHZjMDyBCHw0Pgocdhs29FKPI/0W+6HfUn7X/LRinbzirV86bnJcRK TKqsmQxP0fz09nB2SpbVmcPXvVJ1jHW1ZXfFfNpwXI6FqI67LlWLarYaaMz9MIGWGd0iMKXALBz1 N2lUlexWk3uHziT4DL48J7FjCJOn/8wwzDF0yWApkR8i1V1Ih3KFrkdd+xCxd170ne01mVf5tmCH ZI/pv1l7uSOSa8W21qe7BtpivqR9Kl2TYnL+d7ky7+yLjZsrMsrayjXuOk7oP765dvcr2anBtUHX 4/miIjvEVtrce8PVZGN7mFe/203484b9Ta9Wvdzyri1PVG7n0a7N8+vamvNlEFc/2xRjdutmy9vg xy8rHeKqvODQnMRc5J44bMhMGKsZxAgOfGWjBGCRDRy6UYbpZiYy2/IhZjwVNYuurrd5b769xqh/ yv+yR2tTTcmZekwORIWb56ABFx2xhog/Rho9CA8XuTEaeF0IwuE1fAwhPW99Ok1Lz8hbT0sPr2uo Zai7GK/la6iP86Ph8fp6fj7fUaAN07fbnvsu68R8AwOF6pBjzeuQe/+cAn/KUKFhEWwWBHABOAYo BgCG8esFP2lBBlqQIZsCabMo0AkCVyuzKJD4txN8ZcG/mCISEoIVxyAQU2gkxPWDO6NYSAQXzzy5 Jy6X7ZsUKYdWxjwYGv988/z9S28+LnQecmhiWHPfb7g+2DmZ677Xa46h2iVuIqYjLzal1q/kSc0A 0knxjIliDCGkbPwN16rM3G3SN/j3tuRJW0LHi+ZdPWft/k5Db3t+uqtBPVm6XKFZ7OZDlthx/ZEy haZ0paOJ25+rSnf5yaSaak+5oOzqmEkF+IHTVTr2zp48FRI7mmR8zkQIvWyLUxFVzyIW45NMs0xd SNGKqV8qxK5u6+aTWNmosQrnbhSYdexISlCWWuibhrL+88T5N7zJidWOUtY7c4pCLjFVr4yryjUN YY8LVry5JZiX2Rl4gJFUuPhBCPbLlvtT9WezF/N/MRGvyxE/fin5xjCrrsRJyUKy2mZLTHLLx9YD Zgseiaf2pOUHKKUELDl+NYGs0sMnb+vzef8eCTvdauc1lAfLfzfcOaXdXuF1xCLoWsztipqg9KTg reEn+osm8tul2owmfa+FmPJ1b0iqKK09fG797SznI3Gu1+dae7fKD08ubcAJftAx9S0yCF1jb3bG MoNSILj9wibX91f9t9KeHMxpaNpxPdT6xSXtzKGK96egkMFA0rG+rKim83wNX5a8K4sw4Kl0vr3g Xs27zOat0qMJgQjKbwsTI6ruuiuYGbtKPk957d9AKtZ5qrzdZHXLoJ7lLpnaXUJRLNPhhodahWjk TpuPw+3I26hDIAjwgiAwzAkCArR5AXps7pf+8RLWi02nAvy7VVL3jGr6IhbMQwE04hZA87+r5J8B K4ChBoc3lb7xJjU0FJAngC7Dj+FDi6RjCesiA0LDGZGxMLlDBpAepIvD6+tCRoDc8Th2UReCi/+7 a+i/4/f8wuCK509sdqtvCNJe8OJ858vG3JWK9qW32iXJSqKv7xTfsS2NhLBzBnjvO+6VIGUuNN9d luMBqTzmCupdf34wlVf0gwg6ZyT1htx1XaWtB0bf+ktrTq7vSZHp7yEfLqxTdGhO+0S8zd+yurzl lDn60MejwXv8H6g9tXI4ldzSrWalrXoymeJEFepCaU4EZmRAzK1jbtCBT5vasqt65bM3jbdixvjO OIRQTxMz8m24llv7zVFd5Hcsu+suT+LyQx83F8+xFudn5W8ecor5gsiTsefbwiUGWQ2deaZoVdOg 5ZhfLhtDwEXf2Pd8SdKeQhqyWka4YvLDvkrELYUVjlMfuesvYwW/8nsJsEgxJDrDONwQCrzM4vOf Xl3C9C0jikYD/CVDYjz80zFBAgHXcEGJORxuTsyAEtMSxEVOstYsc1bN7lbGTKq/EHDY69Z1pNDn CO0/hydLLLZ0XuHygqJS2wjXt7wYbTpkzwkKJAjEoQKLAkKy2T+/Lp5phj9KBlM5OyA4zgoINpAV ZDkrIBj+m2tieB0WHKn/8HoY2Fose1u9B8pycXvf6dLoJ7diV9ohKrQj17qHCGFKbl1Yn35W+97c QztCvM+6IK+TsRj73Pa4ZZ0uNeWuedIvZBDJJ2tiRre3DC5BvO68kC7A3ZRm0zniINFOKdnd1ZMW eD+h7lXmKI/OFlTfLnUlhbCJ95NdMbnawh94O8NqJckHdgYJhO89W2i031+rcaVIv7eH2byc7Viz Tl4p/McbuOVROBONcMGm/jCTqS0CmOeXBWg7Rx6cnT9A3h7fqK+x+vDFgdqNgubr7zmEy7+Gmmti 6B7uiPkC4iKtj8Vz3i393c+1Skun5+OW5BsrnXsPhGUGnzSyvfc+9uIJyTjvRcOH9i3S44mW8r5m IhsixxoRvKpZc9uiqvvj4Mbql0eOReqfJTeuVZyrEiW4lLpj7SorC/HaqqpTdv5N+eZTCbHyCQcl IL9e87mrpZoOKsi3WPRp9NW8tbmhee8hPsFWRd1GyWtVv/Pw0We5B5qNQ88nqkbyzHkdJX9xH6tO 1fG3ikCT1MIo2mlmIeboxRPWI3NDP2/DB1d+eb6yaYfiNb/zB2S2zvVFmmiVu6Wf7ZLvrj7V7HM6 xpH7HkHb/mTmqaKYkqqCrHVSj3ZvxaxT0MEf42MWuO9QvlgwvLlZvm1AlnIt7zWp4wOCHpoquLGJ 0fSK2V+cfQu3aEqk0d3jod3CwoefdA6aaTvNC7qGOfwZYvHGQSxu76+hQCSjlfO/I348BiSm/CdU jIcgjkMu+icO+e1EgANhwxAP6RtxgsZidhEHwcX/+YmFhfxj7EDCsQMJYgfwuZKRT+Fi0tqlD5kn WGJ2eudGf3OVzzdfqB7Ut8r+xFkeQyk06Vx8vZBsu0HQlbkPBUcML+fynGoyuo8Qx5nfTRWO9d26 KXONUnD5QdL+voDVrc/3OVQKaNaXPzquURbHX/4gy615jRR3n19UL56qMlenp4TP/naV5RnPhw3a qHUlAWPXQ8aMPQrnvbU612Hoe5Lpqx9ztMBHVOvusj3jL5/xCt/3iC0iLeoRvlCAib6QaTI88VJj lZicnbPaobjwjrnGZ0irHw4NWexKerS+cn3ywkemFTs8e1Mpm6VGC3XcujKWaJXpujaeMf2Cv1uF MqmoLN9tuKn1QILmO7LzLnl95Xojpm+8w7n9oqULFDdff3sOlZz2wWukhXpxR+bW2kvykcpekmq/ 3VBVM1TOMVq++PaGit1l0orFx/0GaXKBL9RIB7xSOpU978qvMKU2VLuYKaFG7sS569xXfBnmKbrS KrpqnOtF7Ukky+vJJYmq8wvvOa3oMSoU7VMk1UqetdxA7KqrD4/rCO9Ren7RKrdx+LK0y5OktEE7 ElRcsvP5oHt++WT7Kb/OuuzE9UNtQyt6SIuKMWpHizf6J7za5h3jVamz+YHLfo+L0Wpqb4ZC6tXS NdOXGVDqXmyxTG3gt228V2ShE7n3A3M8BuuqifFcszfPlKK7+fGplPnPDpLfZp2qtSoIzmntaEvZ MRM7h0Ds7PtJ+PsWPH96LlkwM0AciRaSFeByYGd8LLgI38fVPwTl2SeecC1jJC7D4ndxbvKL/uKr uDuKqXrQKk5wg2+hUgrsClYkk/7VTR/gt8BrgbPOHEq8IF0vPJ4d5lbPCnNUyB4izwpz5v8szP2F /EgoMR9WHotOzIYSM6HEXTNG0kZBiUmQ2dfpkIh5un93zII/jgxWxgihhcf6hEVoB0SGQMtmBCAh PVk8VobLlgv+Jx1wcs2LnVzjJGNjQSliOk1Mn0mWa2NlfnYQ8x9NLsrpcIyV0r77MNJfYZ9g1pwX PrtzzbM2tsYKZdTRvbQ1Tcfrw++EJH25YNYr0LzkovXxw2OMJz4XFfSLsj3pmzM2breyd3ootHtD q9QK6bGl5tupLac+B7005dVetO+VycKie9Uy0ZlGnX2+1yxNYuIUxzAbj2ZEJqW9va6CtFK/vE2s 5shxbqF9QwGfArT3FqibqQe5knzk+BnMVTlZXUlvL6WPWWk8m1zScl5/mKlc1l2uOtTSPiZSnquW nWMnYiI4ypfaJlePl+wcadS65X7wNMlI4IrA5SulZd2Vj55IpKwkuhri16pKxVe8VR1/pmmMZeRU uqUGMEOLz0TWL+PmOYpQVzNlmWHs/AQvVdm9e5EeLx0qsZFYHNW9TJ1+uN6T6p1cL+OzODv5+eOx 8dF5hXmqL24WZbe89vQhvHTn3b/VlCea5w5PxTo58Qs0WvXI0ysL0ReeE66KqL1+RtcZzH5f6JH1 kKut0Oq821h2Ef8KG7HcBLkWrkWNFfuKzIjRsvpXWg8dyo+LU/hks1euZMJaMeHdwfGLQWdWZHcO rIuRGuw3yI2VXDHVVqUYsO5V+afJ7QOCCf2MJeWT0BDadufz5+tCfHaZ3DngTKZcTHBRKIyZg5eP GyYIVJhNHLtxxLOuMGWfy1pnsg3xkvm1fVHuAgk2QZ9j8+vOh4QEXqNGYITj7G/iWOhTEAt9EolA QIl7/9eB6+e3A78lRwoSG2DymQYxPwonNDvzArT4VhLEiUCzWyUgxW8D0ThAbelX+lvH3/DVQ7o1 Df7VeclCxcMjkO+sIUI4Z8ixQD1B7aef4XP84/9YKFRJUPpTz3ac+ToB9ofYjGYhuJLW+B5YSUzX vnw4t6pc+pRqWBiP6KYbwduzQmNr5RRt3gW/uUd75jWcaaeuwvBLzLhk92WC+9NlQ5raYdV27/XP FJLk1d9vqH2g6OdB9knuHl+a3XaCWKLkf2syllB/cOCgnrpMZmVrOd5s16KMwdMnen0kCx8oFAQl tiu2ZsarmL2xuzgWdIflebtaXwuFPb7Cdh5RgC/Q5zNDu8z7Zs9gP/d+Udubz4oPnV1y4o75q546 5iGpTQtyjsk1E02nigWtez33vcXyNSVpP0X+Nia1/A3GlZ6tZt8wOJA0GNE3LCSiNvzCSOrQnoF9 5coEv1301q1nEtPOx8z1TAxRjlv89s4Wt92phSykGrg8Ufq2Rzw4FlICVM1hQ3Pn/+wg/vNM2yxM ekKSsyEp+C1jiACTz7Rw40TZN44X4/TxOPhn1R8QqVst223cOpe5Ogfd/v5x5qPMSb77PxyZYKz4 ebXHPf38yTC9dG+gYG30DXMSpGjj+qTKw+PD2rvBls1qA6M6ficYqwfnvupqFgt9f7hj7jVPyTP7 hSfcFhBGdIxvD9974n30LUk38CS2vNcj0CvNruWaNl1r2RULikF8yem9q6duMnUbHo0Us7TbUE97 G8/2J0cJqUmtbCYY93zQ97H3N0ONYdKx7tUBCjJbhqNEd8fpPFu6ZOOuJMm8rCuXrT45JwovPdfd o2Q/8D7wVJrKWv0VokjnMYP4x+FrBFTFZD4/DqCkbBIzHbHyeJ/zoBrPT1vdZS2288Ca4vxEHieU oOzYsRuSpwcy4mNC9B/Ht0ePZiBPy0uF9+CpV33jhylXuP4PnaNNqA0KZW5kc3RyZWFtDQplbmRv YmoNCjMxOSAwIG9iag0KWyA1NTYgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1NTZdIA0KZW5kb2JqDQozMjAgMCBvYmoNCjw8 L1R5cGUvTWV0YWRhdGEvU3VidHlwZS9YTUwvTGVuZ3RoIDMyMTI+Pg0Kc3RyZWFtDQo8P3hwYWNr ZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/Pjx4OnhtcG1ldGEg eG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IjMuMS03MDEiPgo8cmRmOlJERiB4bWxu czpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgo8cmRm OkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiAgeG1sbnM6cGRmPSJodHRwOi8vbnMuYWRvYmUuY29t L3BkZi8xLjMvIj4KPHBkZjpQcm9kdWNlcj5NaWNyb3NvZnTCriBQb3dlclBvaW50wq4gZm9yIE1p Y3Jvc29mdCAzNjU8L3BkZjpQcm9kdWNlcj48L3JkZjpEZXNjcmlwdGlvbj4KPHJkZjpEZXNjcmlw dGlvbiByZGY6YWJvdXQ9IiIgIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMv MS4xLyI+CjxkYzp0aXRsZT48cmRmOkFsdD48cmRmOmxpIHhtbDpsYW5nPSJ4LWRlZmF1bHQiPlBv d2VyUG9pbnQgUHJlc2VudGF0aW9uPC9yZGY6bGk+PC9yZGY6QWx0PjwvZGM6dGl0bGU+PGRjOmNy ZWF0b3I+PHJkZjpTZXE+PHJkZjpsaT5Lb3Rpa2FsYXB1ZGkgU3JpcmFtPC9yZGY6bGk+PC9yZGY6 U2VxPjwvZGM6Y3JlYXRvcj48L3JkZjpEZXNjcmlwdGlvbj4KPHJkZjpEZXNjcmlwdGlvbiByZGY6 YWJvdXQ9IiIgIHhtbG5zOnhtcD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLyI+Cjx4bXA6 Q3JlYXRvclRvb2w+TWljcm9zb2Z0wq4gUG93ZXJQb2ludMKuIGZvciBNaWNyb3NvZnQgMzY1PC94 bXA6Q3JlYXRvclRvb2w+PHhtcDpDcmVhdGVEYXRlPjIwMjEtMTItMDlUMTQ6MjE6MjEtMDU6MDA8 L3htcDpDcmVhdGVEYXRlPjx4bXA6TW9kaWZ5RGF0ZT4yMDIxLTEyLTA5VDE0OjIxOjIxLTA1OjAw PC94bXA6TW9kaWZ5RGF0ZT48L3JkZjpEZXNjcmlwdGlvbj4KPHJkZjpEZXNjcmlwdGlvbiByZGY6 YWJvdXQ9IiIgIHhtbG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIj4K PHhtcE1NOkRvY3VtZW50SUQ+dXVpZDo5QjE5QjVENy04MTJBLTQwMTctQjg0OC1DQUM3RDY5MTA0 Q0I8L3htcE1NOkRvY3VtZW50SUQ+PHhtcE1NOkluc3RhbmNlSUQ+dXVpZDo5QjE5QjVENy04MTJB LTQwMTctQjg0OC1DQUM3RDY5MTA0Q0I8L3htcE1NOkluc3RhbmNlSUQ+PC9yZGY6RGVzY3JpcHRp b24+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo8L3JkZjpSREY+PC94OnhtcG1ldGE+PD94cGFj a2V0IGVuZD0idyI/Pg0KZW5kc3RyZWFtDQplbmRvYmoNCjMyMSAwIG9iag0KPDwvRGlzcGxheURv Y1RpdGxlIHRydWU+Pg0KZW5kb2JqDQozMjIgMCBvYmoNCjw8L1R5cGUvWFJlZi9TaXplIDMyMi9X WyAxIDQgMl0gL1Jvb3QgMSAwIFIvSW5mbyAzNiAwIFIvSURbPEQ3QjUxOTlCMkE4MTE3NDBCODQ4 Q0FDN0Q2OTEwNENCPjxEN0I1MTk5QjJBODExNzQwQjg0OENBQzdENjkxMDRDQj5dIC9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoIDY4Mj4+DQpzdHJlYW0NCnicLdVpmE9lGMDhc6ZFm5hSSFRKKmXf xxjapoVSGEmSKNE2ihJFi6KUVIMWKrQgxUgoiTYVUSpL+0K0L2RrMf3nuf/nw7mvc53rPed5P7zX L0kyV1lZmrnnJkk507E5yCkOGmwKGtbANCwJGvXBrKDxVKwPmowOmg4PmnUPmhcGLWoHLStjUdDK V/LMkj80aFsvKLCgYFnQbkZQOCLo2CPoNDDoOiwo2hGMGhOM7R2U5AcTOweTemb2mNlt/XR/HICK ODBIbkYOUmTXVcp8ZfL87FOyL/bAPqiAPbEX9kZl7IdKyP7WSImREiMlVZGLQ3EIDsLBqIJqqI7D UAOH42jURG0chVo4AkfiGNTFsaiD43A8TkA9nIgmOAmN0Qj10QAN0RzN0BSt0BIt0AZ5aI0CtEU+ TsHJaIf2OBun41SchrNQiDNwJjqgI87BeeiEc3E+OqMLuqEIXXEhuuMC9MDF6ImL0AeXohcuQW/0 RX9cgctwOfphIAagGFfiKlyNa3AtBuF6XIchuBGDcQOGYShucriyx+IO3I5bvMuenOEYgVtxG+7B SNyN0bgTd2EUHsAYjMP9uBf3YSwexoOYiAl4CCUYj0fwKB7DJEzGU3gc0zAVT+BJTMHTmI5n8Qye w0zMwCw8jxcwG3NRijl4CfPwIhZiAeZjEV7By1iC1/AqFuMdvIGleB3L8Cbewtt4F+/hfazAcqzE KqzGh/gAn+BjfITP8RnWYC3WYT0+xQ/4At/hS3yFr/ENvsVmbMBGfI9N+BE78Bt+ws/4Bb/iD/yO LfgTf2ErtmMbduIf/I1d+Bdl2I3/gjSbQVFMJTLVv1TxUsVLFS+VyFQb0wqZfM6pGC0uXVxO2rpK kDckaDMoyJ9XTk7V0qDa4KBoe9BtXNC3OEn+B9kx2jINCmVuZHN0cmVhbQ0KZW5kb2JqDQp4cmVm DQowIDMyMw0KMDAwMDAwMDAzNyA2NTUzNSBmDQowMDAwMDAwMDE3IDAwMDAwIG4NCjAwMDAwMDAx NjggMDAwMDAgbg0KMDAwMDAwMDIzMSAwMDAwMCBuDQowMDAwMDAwNjI0IDAwMDAwIG4NCjAwMDAw MTIyNjIgMDAwMDAgbg0KMDAwMDAxMjMxNSAwMDAwMCBuDQowMDAwMDEyNDUxIDAwMDAwIG4NCjAw MDAwMTI0NzkgMDAwMDAgbg0KMDAwMDAxMjY0MyAwMDAwMCBuDQowMDAwMDEyNzE2IDAwMDAwIG4N CjAwMDAwMTI5NjIgMDAwMDAgbg0KMDAwMDAxMzAxNiAwMDAwMCBuDQowMDAwMDEzMTkyIDAwMDAw IG4NCjAwMDAwMTM0MzggMDAwMDAgbg0KMDAwMDAxMzY1NyAwMDAwMCBuDQowMDAwMDEzODk1IDAw MDAwIG4NCjAwMDAwMTQxMTQgMDAwMDAgbg0KMDAwMDAxNDM1MiAwMDAwMCBuDQowMDAwMDE0NTIz IDAwMDAwIG4NCjAwMDAwMTQ3NjQgMDAwMDAgbg0KMDAwMDAxNTEyMSAwMDAwMCBuDQowMDAwMDE1 NzM4IDAwMDAwIG4NCjAwMDAwMTU5MTUgMDAwMDAgbg0KMDAwMDAxNjE2MiAwMDAwMCBuDQowMDAw MDE2MzI2IDAwMDAwIG4NCjAwMDAwMTY1NTMgMDAwMDAgbg0KMDAwMDAxODMwMyAwMDAwMCBuDQow MDAwMDE5ODAzIDAwMDAwIG4NCjAwMDAwMjA1OTMgMDAwMDAgbg0KMDAwMDAyMTg4MyAwMDAwMCBu DQowMDAwMDIyMjYzIDAwMDAwIG4NCjAwMDAwMzQ2OTkgMDAwMDAgbg0KMDAwMDAzNjQ0OSAwMDAw MCBuDQowMDAwMDM3OTQ5IDAwMDAwIG4NCjAwMDAwMzg3MzkgMDAwMDAgbg0KMDAwMDA0MDAyOSAw MDAwMCBuDQowMDAwMDAwMDM4IDY1NTM1IGYNCjAwMDAwMDAwMzkgNjU1MzUgZg0KMDAwMDAwMDA0 MCA2NTUzNSBmDQowMDAwMDAwMDQxIDY1NTM1IGYNCjAwMDAwMDAwNDIgNjU1MzUgZg0KMDAwMDAw MDA0MyA2NTUzNSBmDQowMDAwMDAwMDQ0IDY1NTM1IGYNCjAwMDAwMDAwNDUgNjU1MzUgZg0KMDAw MDAwMDA0NiA2NTUzNSBmDQowMDAwMDAwMDQ3IDY1NTM1IGYNCjAwMDAwMDAwNDggNjU1MzUgZg0K MDAwMDAwMDA0OSA2NTUzNSBmDQowMDAwMDAwMDUwIDY1NTM1IGYNCjAwMDAwMDAwNTEgNjU1MzUg Zg0KMDAwMDAwMDA1MiA2NTUzNSBmDQowMDAwMDAwMDUzIDY1NTM1IGYNCjAwMDAwMDAwNTQgNjU1 MzUgZg0KMDAwMDAwMDA1NSA2NTUzNSBmDQowMDAwMDAwMDU2IDY1NTM1IGYNCjAwMDAwMDAwNTcg NjU1MzUgZg0KMDAwMDAwMDA1OCA2NTUzNSBmDQowMDAwMDAwMDU5IDY1NTM1IGYNCjAwMDAwMDAw NjAgNjU1MzUgZg0KMDAwMDAwMDA2MSA2NTUzNSBmDQowMDAwMDAwMDYyIDY1NTM1IGYNCjAwMDAw MDAwNjMgNjU1MzUgZg0KMDAwMDAwMDA2NCA2NTUzNSBmDQowMDAwMDAwMDY1IDY1NTM1IGYNCjAw MDAwMDAwNjYgNjU1MzUgZg0KMDAwMDAwMDA2NyA2NTUzNSBmDQowMDAwMDAwMDY4IDY1NTM1IGYN CjAwMDAwMDAwNjkgNjU1MzUgZg0KMDAwMDAwMDA3MCA2NTUzNSBmDQowMDAwMDAwMDcxIDY1NTM1 IGYNCjAwMDAwMDAwNzIgNjU1MzUgZg0KMDAwMDAwMDA3MyA2NTUzNSBmDQowMDAwMDAwMDc0IDY1 NTM1IGYNCjAwMDAwMDAwNzUgNjU1MzUgZg0KMDAwMDAwMDA3NiA2NTUzNSBmDQowMDAwMDAwMDc3 IDY1NTM1IGYNCjAwMDAwMDAwNzggNjU1MzUgZg0KMDAwMDAwMDA3OSA2NTUzNSBmDQowMDAwMDAw MDgwIDY1NTM1IGYNCjAwMDAwMDAwODEgNjU1MzUgZg0KMDAwMDAwMDA4MiA2NTUzNSBmDQowMDAw MDAwMDgzIDY1NTM1IGYNCjAwMDAwMDAwODQgNjU1MzUgZg0KMDAwMDAwMDA4NSA2NTUzNSBmDQow MDAwMDAwMDg2IDY1NTM1IGYNCjAwMDAwMDAwODcgNjU1MzUgZg0KMDAwMDAwMDA4OCA2NTUzNSBm DQowMDAwMDAwMDg5IDY1NTM1IGYNCjAwMDAwMDAwOTAgNjU1MzUgZg0KMDAwMDAwMDA5MSA2NTUz NSBmDQowMDAwMDAwMDkyIDY1NTM1IGYNCjAwMDAwMDAwOTMgNjU1MzUgZg0KMDAwMDAwMDA5NCA2 NTUzNSBmDQowMDAwMDAwMDk1IDY1NTM1IGYNCjAwMDAwMDAwOTYgNjU1MzUgZg0KMDAwMDAwMDA5 NyA2NTUzNSBmDQowMDAwMDAwMDk4IDY1NTM1IGYNCjAwMDAwMDAwOTkgNjU1MzUgZg0KMDAwMDAw MDEwMCA2NTUzNSBmDQowMDAwMDAwMTAxIDY1NTM1IGYNCjAwMDAwMDAxMDIgNjU1MzUgZg0KMDAw MDAwMDEwMyA2NTUzNSBmDQowMDAwMDAwMTA0IDY1NTM1IGYNCjAwMDAwMDAxMDUgNjU1MzUgZg0K MDAwMDAwMDEwNiA2NTUzNSBmDQowMDAwMDAwMTA3IDY1NTM1IGYNCjAwMDAwMDAxMDggNjU1MzUg Zg0KMDAwMDAwMDEwOSA2NTUzNSBmDQowMDAwMDAwMTEwIDY1NTM1IGYNCjAwMDAwMDAxMTEgNjU1 MzUgZg0KMDAwMDAwMDExMiA2NTUzNSBmDQowMDAwMDAwMTEzIDY1NTM1IGYNCjAwMDAwMDAxMTQg NjU1MzUgZg0KMDAwMDAwMDExNSA2NTUzNSBmDQowMDAwMDAwMTE2IDY1NTM1IGYNCjAwMDAwMDAx MTcgNjU1MzUgZg0KMDAwMDAwMDExOCA2NTUzNSBmDQowMDAwMDAwMTE5IDY1NTM1IGYNCjAwMDAw MDAxMjAgNjU1MzUgZg0KMDAwMDAwMDEyMSA2NTUzNSBmDQowMDAwMDAwMTIyIDY1NTM1IGYNCjAw MDAwMDAxMjMgNjU1MzUgZg0KMDAwMDAwMDEyNCA2NTUzNSBmDQowMDAwMDAwMTI1IDY1NTM1IGYN CjAwMDAwMDAxMjYgNjU1MzUgZg0KMDAwMDAwMDEyNyA2NTUzNSBmDQowMDAwMDAwMTI4IDY1NTM1 IGYNCjAwMDAwMDAxMjkgNjU1MzUgZg0KMDAwMDAwMDEzMCA2NTUzNSBmDQowMDAwMDAwMTMxIDY1 NTM1IGYNCjAwMDAwMDAxMzIgNjU1MzUgZg0KMDAwMDAwMDEzMyA2NTUzNSBmDQowMDAwMDAwMTM0 IDY1NTM1IGYNCjAwMDAwMDAxMzUgNjU1MzUgZg0KMDAwMDAwMDEzNiA2NTUzNSBmDQowMDAwMDAw MTM3IDY1NTM1IGYNCjAwMDAwMDAxMzggNjU1MzUgZg0KMDAwMDAwMDEzOSA2NTUzNSBmDQowMDAw MDAwMTQwIDY1NTM1IGYNCjAwMDAwMDAxNDEgNjU1MzUgZg0KMDAwMDAwMDE0MiA2NTUzNSBmDQow MDAwMDAwMTQzIDY1NTM1IGYNCjAwMDAwMDAxNDQgNjU1MzUgZg0KMDAwMDAwMDE0NSA2NTUzNSBm DQowMDAwMDAwMTQ2IDY1NTM1IGYNCjAwMDAwMDAxNDcgNjU1MzUgZg0KMDAwMDAwMDE0OCA2NTUz NSBmDQowMDAwMDAwMTQ5IDY1NTM1IGYNCjAwMDAwMDAxNTAgNjU1MzUgZg0KMDAwMDAwMDE1MSA2 NTUzNSBmDQowMDAwMDAwMTUyIDY1NTM1IGYNCjAwMDAwMDAxNTMgNjU1MzUgZg0KMDAwMDAwMDE1 NCA2NTUzNSBmDQowMDAwMDAwMTU1IDY1NTM1IGYNCjAwMDAwMDAxNTYgNjU1MzUgZg0KMDAwMDAw MDE1NyA2NTUzNSBmDQowMDAwMDAwMTU4IDY1NTM1IGYNCjAwMDAwMDAxNTkgNjU1MzUgZg0KMDAw MDAwMDE2MCA2NTUzNSBmDQowMDAwMDAwMTYxIDY1NTM1IGYNCjAwMDAwMDAxNjIgNjU1MzUgZg0K MDAwMDAwMDE2MyA2NTUzNSBmDQowMDAwMDAwMTY0IDY1NTM1IGYNCjAwMDAwMDAxNjUgNjU1MzUg Zg0KMDAwMDAwMDE2NiA2NTUzNSBmDQowMDAwMDAwMTY3IDY1NTM1IGYNCjAwMDAwMDAxNjggNjU1 MzUgZg0KMDAwMDAwMDE2OSA2NTUzNSBmDQowMDAwMDAwMTcwIDY1NTM1IGYNCjAwMDAwMDAxNzEg NjU1MzUgZg0KMDAwMDAwMDE3MiA2NTUzNSBmDQowMDAwMDAwMTczIDY1NTM1IGYNCjAwMDAwMDAx NzQgNjU1MzUgZg0KMDAwMDAwMDE3NSA2NTUzNSBmDQowMDAwMDAwMTc2IDY1NTM1IGYNCjAwMDAw MDAxNzcgNjU1MzUgZg0KMDAwMDAwMDE3OCA2NTUzNSBmDQowMDAwMDAwMTc5IDY1NTM1IGYNCjAw MDAwMDAxODAgNjU1MzUgZg0KMDAwMDAwMDE4MSA2NTUzNSBmDQowMDAwMDAwMTgyIDY1NTM1IGYN CjAwMDAwMDAxODMgNjU1MzUgZg0KMDAwMDAwMDE4NCA2NTUzNSBmDQowMDAwMDAwMTg1IDY1NTM1 IGYNCjAwMDAwMDAxODYgNjU1MzUgZg0KMDAwMDAwMDE4NyA2NTUzNSBmDQowMDAwMDAwMTg4IDY1 NTM1IGYNCjAwMDAwMDAxODkgNjU1MzUgZg0KMDAwMDAwMDE5MCA2NTUzNSBmDQowMDAwMDAwMTkx IDY1NTM1IGYNCjAwMDAwMDAxOTIgNjU1MzUgZg0KMDAwMDAwMDE5MyA2NTUzNSBmDQowMDAwMDAw MTk0IDY1NTM1IGYNCjAwMDAwMDAxOTUgNjU1MzUgZg0KMDAwMDAwMDE5NiA2NTUzNSBmDQowMDAw MDAwMTk3IDY1NTM1IGYNCjAwMDAwMDAxOTggNjU1MzUgZg0KMDAwMDAwMDE5OSA2NTUzNSBmDQow MDAwMDAwMjAwIDY1NTM1IGYNCjAwMDAwMDAyMDEgNjU1MzUgZg0KMDAwMDAwMDIwMiA2NTUzNSBm DQowMDAwMDAwMjAzIDY1NTM1IGYNCjAwMDAwMDAyMDQgNjU1MzUgZg0KMDAwMDAwMDIwNSA2NTUz NSBmDQowMDAwMDAwMjA2IDY1NTM1IGYNCjAwMDAwMDAyMDcgNjU1MzUgZg0KMDAwMDAwMDIwOCA2 NTUzNSBmDQowMDAwMDAwMjA5IDY1NTM1IGYNCjAwMDAwMDAyMTAgNjU1MzUgZg0KMDAwMDAwMDIx MSA2NTUzNSBmDQowMDAwMDAwMjEyIDY1NTM1IGYNCjAwMDAwMDAyMTMgNjU1MzUgZg0KMDAwMDAw MDIxNCA2NTUzNSBmDQowMDAwMDAwMjE1IDY1NTM1IGYNCjAwMDAwMDAyMTYgNjU1MzUgZg0KMDAw MDAwMDIxNyA2NTUzNSBmDQowMDAwMDAwMjE4IDY1NTM1IGYNCjAwMDAwMDAyMTkgNjU1MzUgZg0K MDAwMDAwMDIyMCA2NTUzNSBmDQowMDAwMDAwMjIxIDY1NTM1IGYNCjAwMDAwMDAyMjIgNjU1MzUg Zg0KMDAwMDAwMDIyMyA2NTUzNSBmDQowMDAwMDAwMjI0IDY1NTM1IGYNCjAwMDAwMDAyMjUgNjU1 MzUgZg0KMDAwMDAwMDIyNiA2NTUzNSBmDQowMDAwMDAwMjI3IDY1NTM1IGYNCjAwMDAwMDAyMjgg NjU1MzUgZg0KMDAwMDAwMDIyOSA2NTUzNSBmDQowMDAwMDAwMjMwIDY1NTM1IGYNCjAwMDAwMDAy MzEgNjU1MzUgZg0KMDAwMDAwMDIzMiA2NTUzNSBmDQowMDAwMDAwMjMzIDY1NTM1IGYNCjAwMDAw MDAyMzQgNjU1MzUgZg0KMDAwMDAwMDIzNSA2NTUzNSBmDQowMDAwMDAwMjM2IDY1NTM1IGYNCjAw MDAwMDAyMzcgNjU1MzUgZg0KMDAwMDAwMDIzOCA2NTUzNSBmDQowMDAwMDAwMjM5IDY1NTM1IGYN CjAwMDAwMDAyNDAgNjU1MzUgZg0KMDAwMDAwMDI0MSA2NTUzNSBmDQowMDAwMDAwMjQyIDY1NTM1 IGYNCjAwMDAwMDAyNDMgNjU1MzUgZg0KMDAwMDAwMDI0NCA2NTUzNSBmDQowMDAwMDAwMjQ1IDY1 NTM1IGYNCjAwMDAwMDAyNDYgNjU1MzUgZg0KMDAwMDAwMDI0NyA2NTUzNSBmDQowMDAwMDAwMjQ4 IDY1NTM1IGYNCjAwMDAwMDAyNDkgNjU1MzUgZg0KMDAwMDAwMDI1MCA2NTUzNSBmDQowMDAwMDAw MjUxIDY1NTM1IGYNCjAwMDAwMDAyNTIgNjU1MzUgZg0KMDAwMDAwMDI1MyA2NTUzNSBmDQowMDAw MDAwMjU0IDY1NTM1IGYNCjAwMDAwMDAyNTUgNjU1MzUgZg0KMDAwMDAwMDI1NiA2NTUzNSBmDQow MDAwMDAwMjU3IDY1NTM1IGYNCjAwMDAwMDAyNTggNjU1MzUgZg0KMDAwMDAwMDI1OSA2NTUzNSBm DQowMDAwMDAwMjYwIDY1NTM1IGYNCjAwMDAwMDAyNjEgNjU1MzUgZg0KMDAwMDAwMDI2MiA2NTUz NSBmDQowMDAwMDAwMjYzIDY1NTM1IGYNCjAwMDAwMDAyNjQgNjU1MzUgZg0KMDAwMDAwMDI2NSA2 NTUzNSBmDQowMDAwMDAwMjY2IDY1NTM1IGYNCjAwMDAwMDAyNjcgNjU1MzUgZg0KMDAwMDAwMDI2 OCA2NTUzNSBmDQowMDAwMDAwMjY5IDY1NTM1IGYNCjAwMDAwMDAyNzAgNjU1MzUgZg0KMDAwMDAw MDI3MSA2NTUzNSBmDQowMDAwMDAwMjcyIDY1NTM1IGYNCjAwMDAwMDAyNzMgNjU1MzUgZg0KMDAw MDAwMDI3NCA2NTUzNSBmDQowMDAwMDAwMjc1IDY1NTM1IGYNCjAwMDAwMDAyNzYgNjU1MzUgZg0K MDAwMDAwMDI3NyA2NTUzNSBmDQowMDAwMDAwMjc4IDY1NTM1IGYNCjAwMDAwMDAyNzkgNjU1MzUg Zg0KMDAwMDAwMDI4MCA2NTUzNSBmDQowMDAwMDAwMjgxIDY1NTM1IGYNCjAwMDAwMDAyODIgNjU1 MzUgZg0KMDAwMDAwMDI4MyA2NTUzNSBmDQowMDAwMDAwMjg0IDY1NTM1IGYNCjAwMDAwMDAyODUg NjU1MzUgZg0KMDAwMDAwMDI4NiA2NTUzNSBmDQowMDAwMDAwMjg3IDY1NTM1IGYNCjAwMDAwMDAy ODggNjU1MzUgZg0KMDAwMDAwMDI4OSA2NTUzNSBmDQowMDAwMDAwMjkwIDY1NTM1IGYNCjAwMDAw MDAyOTEgNjU1MzUgZg0KMDAwMDAwMDI5MiA2NTUzNSBmDQowMDAwMDAwMjkzIDY1NTM1IGYNCjAw MDAwMDAyOTQgNjU1MzUgZg0KMDAwMDAwMDI5NSA2NTUzNSBmDQowMDAwMDAwMjk2IDY1NTM1IGYN CjAwMDAwMDAyOTcgNjU1MzUgZg0KMDAwMDAwMDI5OCA2NTUzNSBmDQowMDAwMDAwMjk5IDY1NTM1 IGYNCjAwMDAwMDAzMDAgNjU1MzUgZg0KMDAwMDAwMDMwMSA2NTUzNSBmDQowMDAwMDAwMzAyIDY1 NTM1IGYNCjAwMDAwMDAzMDMgNjU1MzUgZg0KMDAwMDAwMDMwNCA2NTUzNSBmDQowMDAwMDAwMzA1 IDY1NTM1IGYNCjAwMDAwMDAzMDYgNjU1MzUgZg0KMDAwMDAwMDMwNyA2NTUzNSBmDQowMDAwMDAw MzA4IDY1NTM1IGYNCjAwMDAwMDAzMDkgNjU1MzUgZg0KMDAwMDAwMDMxMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwNDUwNjkgMDAwMDAgbg0KMDAwMDA0NTUwMSAwMDAwMCBuDQow MDAwMDgwNDA0IDAwMDAwIG4NCjAwMDAwODA3NjAgMDAwMDAgbg0KMDAwMDA4MTAxMiAwMDAwMCBu DQowMDAwMDgxMzMyIDAwMDAwIG4NCjAwMDAxMzcxMzcgMDAwMDAgbg0KMDAwMDEzNzMzMyAwMDAw MCBuDQowMDAwMTUzMzM0IDAwMDAwIG4NCjAwMDAxNTM0ODggMDAwMDAgbg0KMDAwMDE1Njc4NCAw MDAwMCBuDQowMDAwMTU2ODMwIDAwMDAwIG4NCnRyYWlsZXINCjw8L1NpemUgMzIzL1Jvb3QgMSAw IFIvSW5mbyAzNiAwIFIvSURbPEQ3QjUxOTlCMkE4MTE3NDBCODQ4Q0FDN0Q2OTEwNENCPjxEN0I1 MTk5QjJBODExNzQwQjg0OENBQzdENjkxMDRDQj5dID4+DQpzdGFydHhyZWYNCjE1NzcxNQ0KJSVF T0YNCnhyZWYNCjAgMA0KdHJhaWxlcg0KPDwvU2l6ZSAzMjMvUm9vdCAxIDAgUi9JbmZvIDM2IDAg Ui9JRFs8RDdCNTE5OUIyQTgxMTc0MEI4NDhDQUM3RDY5MTA0Q0I+PEQ3QjUxOTlCMkE4MTE3NDBC ODQ4Q0FDN0Q2OTEwNENCPl0gL1ByZXYgMTU3NzE1L1hSZWZTdG0gMTU2ODMwPj4NCnN0YXJ0eHJl Zg0KMTY0MzM1DQolJUVPRg== --_002_SA1PR09MB81423BC23B431A3EBC9BF98D84709SA1PR09MB8142namp_-- From nobody Fri Dec 10 02:17:49 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E213A00DF for ; Fri, 10 Dec 2021 02:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl 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 9nqIyd80J_Nd for ; Fri, 10 Dec 2021 02:17:42 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [116.202.126.228]) (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 4C7103A005F for ; Fri, 10 Dec 2021 02:17:41 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id A3AF1857; Fri, 10 Dec 2021 10:17:37 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1639131456; bh=m8K4MXFJiZDvCvk+kQMsweuBaAf15emjif1LEKeoztI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=gVnctU79bbNFiy1uR0IKVyXg5LpCRBrQmmFRl39mdwZ8+kLqjI0HixAWzT1C++tUE TNE76COsHSMjhbFqBXHGfncVayBpxsLQdSDBD4i6D5GUIWyskxwJZ74D0Am4kON/nh CYhEDMxY5nH/Mn11HFAdG2r6UB6r0UHQOFuyUecrPROwn9O72R5KGNsif5Md1kVFXi IyJBF7kVVOl6cX+KKiDupFgbP8JD4iMfiPLcTq5UfcWdGBSolEKgkGdGOTCXxGa+qm 4zRJktsLJwrRj87EK6YaK31o2Q7gDfj8Lpqn1rga/etWke+u8XJcAgO+5MM5gLjLbu QXU/rWUm5bhHg== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Tim Bruijnzeels In-Reply-To: Date: Fri, 10 Dec 2021 11:17:33 +0100 Cc: Stephen Kent , sidrops@ietf.org, Warren Kumari Content-Transfer-Encoding: quoted-printable Message-Id: <2D30298B-EE34-43D2-B2B7-978DE69CC9A5@nlnetlabs.nl> References: <813d1599-fc9d-18b6-a76c-b550855b1186@verizon.net> <20211130193034.344F62EA0102@minas-ithil.hactrn.net> <8d9b693c-137d-4a76-9fef-65968bb5062e@verizon.net> To: Job Snijders Archived-At: Subject: Re: [Sidrops] AD Review of: draft-ietf-sidrops-6486bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2021 10:17:47 -0000 Hi Job, Steve, all.. > On 9 Dec 2021, at 18:29, Job Snijders = wrote: >=20 > Hi all, >=20 > On Thu, Dec 09, 2021 at 10:24:54AM -0500, Stephen Kent wrote: >> In section 6.3 I have revised the text to take into account Tim's >> observations: >>=20 >>> If the current time is earlier than thisUpdate, the CA may have made >>> an error or the RP=E2=80=99s local notion of time may be in error; = the RP >>> MAY choose to treat this as a failed fetch and proceed to Section >>> 6.6. >=20 > I do not feel comfortable with this use of 'MAY', such a directive may > encourage RPs to act fast & loose with the interpretation of signed = time > values, potentially violating "CA Intent". >=20 > The use of freely and pubicly available NTP sources on the Internet > EASILY brings RPs within a -/+ range of 1 (one) second (but likely > accurate in the order of tens of miliseconds). The Internet's routing > and forwarding system is able to deliver with jitter globally measured > in the low microseconds. Time signal is also beamed through the ether > for free: GPS, Galileo, GLONASS, or long wave: MSF, DCF77, WWVB. >=20 > I would leave the text as-is, or suggest to change the MAY to MUST: >=20 > """ > If the current time isearlier than thisUpdate, the CA may have made = an > error or the RP=E2=80=99s local notion of time may be in error; the = RP MUST > choose to treat this as a failed fetch and proceed to Section 6.6. > """ >=20 First of all.. my apologies if my concerns were confusing. I did indeed raise them in response to a question Warren raised about section 6.3. = But, I agree with Job on the above - as far as I can see. I think it would not be desirable to have a MAY as it will lead to = differences between RP implementations, discussions and grief. And I lean towards making the RPs be strict. What I was driving at (or meant to anyway) is that I would like it to be understood and condoned that the CA can use backdating in this case, of course within measure (which would be section 4.2.1). See below. > Timing matters not just for the Manifest's eContent thisUpdate value, > but likewise the Manifest's EE cert, and the CRL's thisUpdate, and the > parent's validity window. Let's please not open Pandora's box and do > away with the concept of globally agreed upon time. >=20 > CAs should not attempt to compensate for *potentially* broken RPs, as > that puts a burden on everyone; it is safer to let broken RPs be = broken. > Hopefully the RP administrator at some point in time takes an interest > to fix the RPs notion of time. Well, as you said, even if NTP works optimally on both ends there can be a second variance (perhaps two if you count both ways). So, I think that at least a couple of seconds backdating should be acceptable based on that alone. I understand that it's unlikely that an RP will see a new manifest this fast, but it's not impossible if your CA and Publication Server are fast. > In rare cases where an RP is out-of-sync within a margin of a few > minutes, things will probably work 'as expected' after the next > validation run. So at worst a 10-50 minute delay takes place (because > the RPs clock is broken). However, in my experience RPs that have = broken > time, are likely to be living in the early 70s... such RPs should not > produce VRPs. Perhaps.. but then again.. if I publish new ROAs to allow new = announcements or fix existing announcements that were invalid due to an earlier error, then I may not want to have to wait until other parties beyond my = control accept my fix. Even if they are running on under-resourced VMs and run a few minutes behind (they shouldn't, but it happens). More importantly though, I think that in this particular *context* the backdating would be harmless. I worry about replays in the future, but I do not worry about replays in the past - because this object did not exist then. I am also not trying to publish anything that should be considered invalid until some point in the future. So, if I backdate by a few minutes then this is actually intentional. I am saying that I don't mind if you live a bit in my past - this = manifest should be valid because I know I just made it. I want it to be valid until it's either expired (protect against future replays) or (better) replaced by a new manifest and revoked on that new manifest's CRL. So, in my view being strict here on backdating does not improve the security - while it can lead to ROA fixes for invalid announcements taking longer to propagate. =10In other words there is little (or no?) gain, but there is pain. If I am wrong about the security risk of backdating in this context then please point out how. I would be happy to learn. Kind regards, Tim >=20 > Kind regards, >=20 > Job >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Dec 10 08:39:18 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368423A07DF for ; Fri, 10 Dec 2021 08:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Af8R0auomjnB for ; Fri, 10 Dec 2021 08:39:10 -0800 (PST) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 9F1C53A07E7 for ; Fri, 10 Dec 2021 08:39:10 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id u11so6632752plf.3 for ; Fri, 10 Dec 2021 08:39:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YOnduXpwXgZPAmnuuiE7IP9/BNYrz7GQFslackJomPI=; b=qw8P1dPXUCqj7tAhcKlcOmjWBZRw4/jacErvRBKTJcCm5BFtED9r2jCq008kqEPOqI kSCS4nn0RIFR/1HKt+9lf+xEG15xbPvtGEdcWZwvfe/LBlSh+txQlrux0zmXqxYp5Wqu kRoVPK4f7LgZLnY0D4ohWUG2oqDf95B9xx0PnNw+ciO73s6687NDRXMd4wVsoq5hQlC3 UQOBrCPETldsAq1J6wWkijVnuUD1Vji6HQPBBf70eFVcLzbr0kggvsSf7evZ1jS6c6Y2 0MN9W1HtjDkGbE5FPaSTpLWuMz1fF66Uj6wRqNMB5B/HmiIZaOlJDVKShfIkWb7Yq3Zf lkQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YOnduXpwXgZPAmnuuiE7IP9/BNYrz7GQFslackJomPI=; b=AfVa6EHq97nvYIv93uGCmuKJ/fJIxynBKw5F+qzV40/RPAopY4w81fbab68Q8Ztxwi hd44AivW9LkuTScJrMz+0Vyoqit3VbWJi4XclNRQ8iwJxQYWGxG2NF1SAJVnIiFYsqb4 xIsHxk3gn0dUlesLCblIVxdAVKi4PJLwlGnWtkgmtXbvNuQQOwbE7vLajwhltPopHBnk IMudh/Md1tFrGICLd9HjhCx9M+4sNqSJYB27d1OGheHWCMntwIqOUTftmTwtyiaF1Tg8 l8oK1eOKhh4TvomsDM6s1SFCcTHdbpRLVUtJAkFRja4GDkbh0HOLtBGhP/juWJ+zCGTw bWJg== X-Gm-Message-State: AOAM532Yak5ywSIFl+FzY6F0X337nejfwkhO5h1Ni7TTaes3La3Ntn+C rVNciXu/ZGP21yCfpuhPFImiqcp6gt2QlksGk8L4hoHt2nQ= X-Google-Smtp-Source: ABdhPJzMBOcQSXpiUdbwmtzf5oIXVModxyu+tq9V6ZP78yIS3j+3R45SyuxZmzVDXdC+7if8g/Kv55ixkBTpT19As1w= X-Received: by 2002:a17:902:a510:b0:143:7fd1:b18a with SMTP id s16-20020a170902a51000b001437fd1b18amr76969909plq.2.1639154349059; Fri, 10 Dec 2021 08:39:09 -0800 (PST) MIME-Version: 1.0 References: <00E18520-A535-4CC8-A287-56FB2F164E14@nist.gov> <5B2CD457-E376-4B8C-B901-202ACC4C465C@ripe.net> <20211208120944.5oq6o2sr6m6xzq42@benm-laptop> In-Reply-To: <20211208120944.5oq6o2sr6m6xzq42@benm-laptop> From: Alexander Azimov Date: Fri, 10 Dec 2021 19:38:58 +0300 Message-ID: To: Ben Maddison Cc: Job Snijders , "sidrops@ietf.org" , Ties de Kock , Nick Hilliard Content-Type: multipart/alternative; boundary="000000000000b5302f05d2cd5c0b" Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-rpkimaxlen-08 - ends 25/October/2021 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2021 16:39:16 -0000 --000000000000b5302f05d2cd5c0b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ben, =D1=81=D1=80, 8 =D0=B4=D0=B5=D0=BA. 2021 =D0=B3. =D0=B2 15:09, Ben Maddison= : > Hi Alexander, > > On 12/07, Alexander Azimov wrote: > > Dear colleagues, > > > > I mixed up the 'reply all' and 'reply' buttons, and only Job was able t= o > > see my reply and keep on the discussion. > > I'm sending the original message to the mailing list so we can proceed > from > > this point. > > > Thanks! > > > > [...] > > > > > > We have steady progress in signing ROAs but far less progress in > > > > adopting ROV. And you can't easily distinguish is it safe enough t= o > > > > start using maximal ROA length or not. For the network that I'm > > > > responsible at the moment - it is not safe. > > > > > > Can you elaborate? This seems a rather subjective statement. In any > > > regard, you are free to configure your own ROAs as you deem fit for > > > purpose. :-) > > > > > Another complication may happen when ROV is done at egress (rfc8893). > > > > In case of fast de-aggreagation you may need to turn it off, though > > > > such issue is much easier to resolve. > > > > To sum it up: I still have a feeling that the document is ahead of > its > > > > time, and in the imperfect world may itroduce new gaps between > > > > routing-security-in-theory and operations. > > The draft contains substantial discussion of the tension that exists > between minimising attack surface and retaining the ability to make > ad-hoc route origination changes. > > The whole of sections 5.1 and 5.2 are dedicated to the topic, and > essentially say "some operators may choose to publish non-minimal ROAs > in order to retain flexibility, but should think carefully about the > trade-offs before doing so". > > > > > > > I fail to see how this document introduces new gaps. It merely warns > > > about the potential pitfalls of using the maxlen macro functionality. > > > > > Yes, I'm free to configure whatever I like, and the authors of the > document > > are free to do it in a different way. > > The difference is that authors of these documents suggest their > operational > > practice as BCP, and I can't agree that this practice is safe at the > moment. > > > > Let's elaborate what kind of events we are facing at the moment. > > The majority of hijacks and route leaks are mistakes. We can assume tha= t > > the difference between accidental and malicious hijacks is absence of > > forged as path in case of accidental events. > > So, ROA with ANY prefix length is good enough to limit the blast radius > of > > accidental hijacks. > > Only if the origin AS of the hijack route is that of the hijacker. That > is not the case for all mistakes (Noction-leaks, for example). > > Minimal ROAs are the best current initial line of defense to such > incidents. > I agree with your point about Noction. At the very moment, we don't have any other technique if forged disaggregated routes are leaked. Though it is mixing up route leaks and hijack problems, and there might be more suitable solutions for route leaks in the long term. My point and my main concern grow from the fact that Noction-like incidents don't present all the scope. The incidents that I witnessed were results of redistribution of static routes with Invalid origin AS. I hope we can agree that for this kind of incident the length of ROA doesn't matter. > > > Unfortunately ROV deployment isn't at the level when we are no longer > > affected by accidental hijacks. And the best option is instant prefix > > deaggregation, if it is possible. > > And I hope you will agree - the time is precious. > > > > Now let's discuss how the recommendations from this document may > complicate > > things that already got nasty due to the fact that your address space w= as > > hijacked. > > > > *Scenario 1:* > > Being a proactive and BCP aware autonomous system holder, one may add > > egress ROV with strict policy to drop Invalid routes with an exception = to > > blackhole routes. > > In case of a hijack this good citizen will have to relax it's routing > > policy/turn off ROV on egress. It is still not that bad, but in huge > > companies with complicated access rules to devices, it may still take > time. > > > If your neighbors drop invalids, turning off egress ROV doesn't make any > difference: the update gets dropped on the other end of the wire. > > If your neighbors don't drop invalids then this can be done in local > policy using SLURM, in close to real time. > > In either case, this is a red-herring. > In this scenario, I was supposing that ROV is done on egress and is absent at the ingress of the neighbor. And, yes, it can be done using local policy, but it may take time if this scenario is not thought out in advance. I wonder if you want to cite it in your document. I don't see any references to rfc8893 at the moment. > *Scenario 2:* > > Previously I described this scenario as two islands of good and bad > actors, > > where good actors perform ROV and sign minimal ROA, bad actors that > perform > > hijacks and 'ocean' of Internet in the middle. In this scenario good > actors > > lose opportunity for deaggregation without updating ROA records. Let's > give > > it a more realistic and simple shape. > > > > Let we have an ASX that peers with two 'important ISPs' in selected > > regions. These two ISPs (ASY and ASZ) have significant intersections in > > their customer cones. > > ASX creates ROA, ASZ does perform ROV, ASY doesn't. And a customer of A= SY > > makes an accidental more specific hijack, and due to lack of filtering = it > > is accepted by ASY. > > Since it is customer's route it gets higher local preference, and prefi= x > > deaggregation toward ASY doesn't help. > > But deaggregation toward ASZ may be helpful, since we will have two > routes > > with same length competing in the intersection of customer cones of ASY > and > > ASZ. > > > > If ASX has ROA with maximum prefix length, this simple technique will > > reroute back to ASX at least portion of the traffic. > > If ASX has ROA with minimal prefix length - effective deaggregation wil= l > be > > possible only after ROA update. > > > I think this analysis is flawed. > > If the customer of ASY (call them ASW) doesn't forge the origin, then > ASZ will filter the path. ROV works, and no de-aggreagation is > necessary. > > If ASW does forge the origin, but the leaked route has length greater > than maxLength in the published ROA, then again ASZ will filter the > path, and no de-aggreagation is necessary. > > De-aggreagation is only necessary to influence ASZ's bestpath selection > if the ROA is non-minimal to start with. > I think you missed my point in this scenario. ASW doesn't forge the ASPATH, but creates a more specific hijack. ASW is a customer of ASY, so disaggregation from ASX to ASY doesn't help, and ASY will advertise hijacked routes to its peers, providers, and, especially important, to its customers. If ASX advertises disaggregated routes to ASZ it may effectively get some of AS from the intersection of customer cones of ASY and ASZ. Minimal ROA forbids this action. And IMO opportunity to instantly disaggregate routes toward ASZ is much better than nothing. And this is where the coverage of ROV makes the difference. Half-done ROV validation among your peers makes you half-exposed to this scenario. In general, with minimal ROAs, de-aggreagation is only a useful response > to influence bestpath selection in third-party networks that: > a) do not filter ROV-invalids; > b) are at least as topologically close to you as your attacker; > c) assign at least as high a local-pref to routes from you as your > attacker; and > d) you actually care about exchanging traffic with. > > For many (most?) operators, a-d define a small and shrinking list of > ASs. I can imagine that for access providers the list of 'important' targets may be quite small these days. But this view can be very different from the content provider sude. Last time I made this math I had 1000AS to cover 80% of egress traffic and another 1000 AS to cover 95%. I hope you admit that makes 'some' networks care about the customer cones of their peers. And as far as I know, these networks are primary targets for Noction-like systems. Because of a), the existence of a ROA is irrelevant, other than in the corner case that you previously set out, and which is discussed in > section 5.2. > > > So IMO minimal prefix length will be safe if all 'important' peers of > > selected AS support ROV. For Yandex this statement is not true. > > I disagree that this is the correct test, for the reasons above. > The contents of a ROA are (by definition) not relevant when discussing > path selection in a network that doesn't drop ROV-invalids[*]. > I hope you reconsider. Let's try to find the golden mean between our positions. We are discussing two scenarios that have very different (conflicting?) actions. - Leaked routes from Noction-like egress control systems, that look like more specific leaks. For this scenario, minimal ROA can limit the propagation of such anomaly, though the disaggregation option may be als= o limited. - Redistributed static routes that result in 'simple hijack' without forged path, in this scenario disaggregation is the best answer, though minimal ROA may again limit propagation of your counter route. Which scenario is more likely to happen? To face Noction-like route leak that would be filtered by surrounding ISPs with ROV or widespread simple hijack (or leak) that can be addressed by disaggregation but will be limited by ROV at your neighbors? I don't have the right answer. Cheers, > > Ben > > > [*]: Some operators might (foolishly) de-pref invalids. They appear > simply not to perform ROV at all for the purposes of this discussion. > --=20 Best regards, Alexander Azimov --000000000000b5302f05d2cd5c0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

=D1=81=D1=80, 8 =D0=B4=D0=B5=D0=BA. 2021 =D0= =B3. =D0=B2 15:09, Ben Maddison <benm@workonline.africa>:
Hi Alexander,

On 12/07, Alexander Azimov wrote:
> Dear colleagues,
>
> I mixed up the 'reply all' and 'reply' buttons, and on= ly Job was able to
> see my reply and keep on the discussion.
> I'm sending the original message to the mailing list so we can pro= ceed from
> this point.
>
Thanks!
>
> [...]
>
> > > We have steady progress in signing ROAs but far less progres= s in
> > > adopting ROV.=C2=A0 And you can't easily distinguish is = it safe enough to
> > > start using maximal ROA length or not. For the network that = I'm
> > > responsible at the moment - it is not safe.
> >
> > Can you elaborate? This seems a rather subjective statement. In a= ny
> > regard, you are free to configure your own ROAs as you deem fit f= or
> > purpose. :-)
>
> > Another complication may happen when ROV is done at egress (rfc88= 93).
> > > In case of fast de-aggreagation you may need to turn it off,= though
> > > such issue is much easier to resolve.
> > > To sum it up: I still have a feeling that the document is ah= ead of its
> > > time, and in the imperfect world may itroduce new gaps betwe= en
> > > routing-security-in-theory and operations.

The draft contains substantial discussion of the tension that exists
between minimising attack surface and retaining the ability to make
ad-hoc route origination changes.

The whole of sections 5.1 and 5.2 are dedicated to the topic, and
essentially say "some operators may choose to publish non-minimal ROAs=
in order to retain flexibility, but should think carefully about the
trade-offs before doing so".

> >
> > I fail to see how this document introduces new gaps. It merely wa= rns
> > about the potential pitfalls of using the maxlen macro functional= ity.
> >
> Yes, I'm free to configure whatever I like, and the authors of the= document
> are free to do it in a different way.
> The difference is that authors of these documents suggest their operat= ional
> practice as BCP, and I can't agree that this practice is safe at t= he moment.
>
> Let's elaborate what kind of events we are facing at the moment. > The majority of hijacks and route leaks are mistakes. We can assume th= at
> the difference between accidental and malicious hijacks is absence of<= br> > forged as path in case of accidental events.
> So, ROA with ANY prefix length is good enough to limit the blast radiu= s of
> accidental hijacks.

Only if the origin AS of the hijack route is that of the hijacker. That
is not the case for all mistakes (Noction-leaks, for example).

Minimal ROAs are the best current initial line of defense to such
incidents.
I agree with your point about Noction. At t= he very moment, we don't have any other technique if forged disaggregat= ed=C2=A0routes are leaked.=C2=A0
Though it is mixing up route lea= ks and hijack problems, and there might be more suitable solutions for rout= e leaks in the long term.

My point and my main con= cern grow from the fact that Noction-like incidents don't present all t= he scope.=C2=A0
The incidents that I witnessed were results of re= distribution of static routes with Invalid origin AS. I hope we can agree t= hat for this kind of incident the length of ROA doesn't matter.

>
> Unfortunately ROV deployment isn't at the level when we are no lon= ger
> affected by accidental hijacks. And the best option is instant prefix<= br> > deaggregation, if it is possible.
> And I hope you will agree - the time is precious.
>
> Now let's discuss how the recommendations from this document may c= omplicate
> things that already got nasty due to the fact that your address space = was
> hijacked.
>
> *Scenario 1:*
> Being a proactive and BCP aware autonomous system holder, one may add<= br> > egress ROV with strict policy to drop Invalid routes with an exception= to
> blackhole routes.
> In case of a hijack this good citizen will have to relax it's rout= ing
> policy/turn off ROV on egress. It is still not that bad, but in huge > companies with complicated access rules to devices, it may still take = time.
>
If your neighbors drop invalids, turning off egress ROV doesn't make an= y
difference: the update gets dropped on the other end of the wire.

If your neighbors don't drop invalids then this can be done in local policy using SLURM, in close to real time.

In either case, this is a red-herring.
In this scenari= o, I was supposing that ROV is done on egress and is absent at the ingress = of the neighbor.
And, yes, it can be done using local policy, but= it may take time if this scenario is not thought out in advance.
I wonder if you want to cite it in your document. I don't see any refe= rences to rfc8893 at the moment.

> *Scenario 2:*
> Previously I described this scenario as two islands of good and bad ac= tors,
> where good actors perform ROV and sign minimal ROA, bad actors that pe= rform
> hijacks and 'ocean' of Internet in the middle. In this scenari= o good actors
> lose opportunity for deaggregation without updating ROA records. Let&#= 39;s give
> it a more realistic and simple shape.
>
> Let we have an ASX that peers with two 'important ISPs' in sel= ected
> regions. These two ISPs (ASY and ASZ) have significant intersections i= n
> their customer cones.
> ASX creates ROA, ASZ does perform ROV, ASY doesn't. And a customer= of ASY
> makes an accidental more specific hijack, and due to lack of filtering= it
> is accepted by ASY.
> Since it is customer's route it gets higher local preference, and = prefix
> deaggregation toward ASY doesn't help.
> But deaggregation toward ASZ may be helpful, since we will have two ro= utes
> with same length competing in the intersection of customer cones of AS= Y and
> ASZ.
>
> If ASX has ROA with maximum prefix length, this simple technique will<= br> > reroute back to ASX at least portion of the traffic.
> If ASX has ROA with minimal prefix length - effective deaggregation wi= ll be
> possible only after ROA update.
>
I think this analysis is flawed.

If the customer of ASY (call them ASW) doesn't forge the origin, then ASZ will filter the path. ROV works, and no de-aggreagation is
necessary.

If ASW does forge the origin, but the leaked route has length greater
than maxLength in the published ROA, then again ASZ will filter the
path, and no de-aggreagation is necessary.

De-aggreagation is only necessary to influence ASZ's bestpath selection=
if the ROA is non-minimal to start with.
I think you m= issed my point in this scenario.
=C2=A0
ASW doesn't= forge the ASPATH,=C2=A0but creates a more specific hijack. ASW is a custom= er of ASY, so disaggregation from ASX to ASY doesn't help, and ASY will= advertise hijacked routes to its peers, providers, and, especially importa= nt, to its customers. If ASX advertises=C2=A0disaggregated=C2=A0routes to A= SZ it may effectively=C2=A0get some of AS from the intersection of customer= cones of ASY and ASZ. Minimal ROA forbids this action.=C2=A0And IMO opport= unity to instantly disaggregate routes toward ASZ is much better than nothi= ng.=C2=A0

And this is where the coverage of ROV ma= kes the difference. Half-done ROV validation among your peers makes you hal= f-exposed to this scenario.

In general, with minimal ROAs, de-aggreagation is only a useful response to influence bestpath selection in third-party networks that:
a) do not filter ROV-invalids;
b) are at least as topologically close to you as your attacker;
c) assign at least as high a local-pref to routes from you as your
attacker; and
d) you actually care about exchanging traffic with.

For many (most?) operators, a-d define a small and shrinking list of
ASs.
I can imagine that for access providers the list of &= #39;important' targets may be quite small these=C2=A0days.
Bu= t this view can be very different from the content provider sude. Last time= I made this math I had 1000AS to cover 80% of egress traffic and another 1= 000 AS to cover 95%.
I hope you admit that makes 'some' n= etworks care about the customer cones of their peers. And as far as I=C2=A0= know, these networks are primary targets for Noction-like systems.

=C2=A0Because= of a), the existence of a ROA is irrelevant, other than in the
corner case that you previously set out, and which is discussed in
section 5.2.

> So IMO minimal prefix length will be safe if all 'important' p= eers of
> selected AS support ROV. For Yandex this statement is not true.

I disagree that this is the correct test, for the reasons above.
The contents of a ROA are (by definition) not relevant when discussing
path selection in a network that doesn't drop ROV-invalids[*].
I hope you reconsider. Let's try to find the golden mean b= etween our positions.
We are discussing two scenarios that have v= ery different (conflicting?) actions.
  • Leaked routes from = Noction-like egress control systems, that look like more specific leaks. Fo= r this scenario, minimal ROA can limit the propagation of such anomaly, tho= ugh the disaggregation option may be also limited.
  • Redistributed st= atic routes that result in 'simple hijack' without forged path, in = this scenario disaggregation is the best answer,=C2=A0though minimal ROA ma= y again limit propagation of your counter route.
Which scenar= io is more likely to happen? To face Noction-like route leak that would be = filtered by surrounding ISPs with ROV or widespread simple hijack (or leak)= that can be addressed by disaggregation but will be limited by ROV at your= neighbors? I don't have the right answer.=C2=A0


Cheers= ,

Ben


[*]: Some operators might (foolishly) de-pref invalids. They appear
simply not to perform ROV at all for the purposes of this discussion.


--
Best regards,
Alexander Azimov
--000000000000b5302f05d2cd5c0b-- From nobody Fri Dec 10 09:05:31 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480EA3A0813 for ; Fri, 10 Dec 2021 09:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Yk4qe8GuwfJ for ; Fri, 10 Dec 2021 09:05:23 -0800 (PST) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 AA99F3A0812 for ; Fri, 10 Dec 2021 09:05:23 -0800 (PST) Received: by mail-ed1-x531.google.com with SMTP id r11so31354050edd.9 for ; Fri, 10 Dec 2021 09:05:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=3FXnGGIgnyUgNIBeGNzr+tBk/Lb1+3dn7uoXidGpkn4=; b=XsPQ2tH5J3N86rKZjX4SDjRDG1nDGKxrUp5F5SUal1igF5jHe4q2TSlFQ2I2vR4kQk E43UaSLf03cKeohemAGkhqBC5AfWrr4LL6VdjYNWQzY2TDG1ZQ6bmusSxDzhYU4XfbJU POyIwY2Grhv1Zns5RM+VG3yqqdWTyzUegHU/Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=3FXnGGIgnyUgNIBeGNzr+tBk/Lb1+3dn7uoXidGpkn4=; b=ubDMPoNdxbPE8CdGp2BLm5WA7T+efy1pLAX5VjVc2ygP2VYvkIBkUzFrYZHfDfASa5 fI61Lv3dnYP9s0SLKd4qt6nyfmVBFtZ6Mp9ChtQm/KfodFP4FtYYtaNWuf6fynDaxmRn 5ylWSgibWGpmO+H1zFTtmsbQhxHLIpjDOfh0wG9UiFF+rKng/Ojx+pwZJ3qRQIPU1J52 4A93KC6BAE0GpKLCwMZp9YFOe2lUBnxyXm2MLbwNC73yPqncDSNovDH2gqIH2QTy0u4m PlAFKeNTZatBRLZFRlYzzFGO0k1LSVMBEoejDiv3BfuH/Vu4TEuvxtR4ol55fGVJxdkm Kgfw== X-Gm-Message-State: AOAM533h/GcsCN+oDVFsgHNksHjYRs3wrD+pEa9xzZ/ip5Di4BF1xd+x f10UOOHXk5NZZcyftwoexbeokQ== X-Google-Smtp-Source: ABdhPJyBDUUnzLeh8EL6fGR0UpWqbOqvjpLPSOrSghwxMR3O8UvsbAzp9UcfG75FJLtWT/ZDA1MBrw== X-Received: by 2002:a17:907:7dac:: with SMTP id oz44mr24319479ejc.307.1639155915710; Fri, 10 Dec 2021 09:05:15 -0800 (PST) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id ho17sm1713973ejc.111.2021.12.10.09.05.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Dec 2021 09:05:15 -0800 (PST) Date: Fri, 10 Dec 2021 18:05:13 +0100 From: Job Snijders To: Alexander Azimov Cc: Ben Maddison , "sidrops@ietf.org" , Ties de Kock , Nick Hilliard Message-ID: References: <00E18520-A535-4CC8-A287-56FB2F164E14@nist.gov> <5B2CD457-E376-4B8C-B901-202ACC4C465C@ripe.net> <20211208120944.5oq6o2sr6m6xzq42@benm-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-rpkimaxlen-08 - ends 25/October/2021 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2021 17:05:29 -0000 On Fri, Dec 10, 2021 at 07:38:58PM +0300, Alexander Azimov wrote: > > If your neighbors drop invalids, turning off egress ROV doesn't make any > > difference: the update gets dropped on the other end of the wire. > > > > If your neighbors don't drop invalids then this can be done in local > > policy using SLURM, in close to real time. > > > > In either case, this is a red-herring. > > In this scenario, I was supposing that ROV is done on egress and is absent > at the ingress of the neighbor. Sasha, I fail to see what you want to achieve with this discussion - egress ROV is a novelty that almost nobody uses today. All of today's educational outreach efforts focus on ingress ROV. draft-ietf-sidrops-rpkimaxlen can be summarized in just a few sentences: "Configure your ROAs such that they align exactly with your BGP announcements. Adversarial actors can and will use any 'holes' you leave open: if you permit more-specifics but don't announce those more-speciics, someone else might!" If this group really cannot come to consensus on the draft at hand, I suppose the next step simply is to propose to remove the ROA MaxLength functionality entirely from the ecosystem. Eradicate the misfeature. The 'MaxLength' feature seems to cause nothing but confusion, as a result it all to easily leads to a reduction of security posture. Kind regards, Job From nobody Sat Dec 11 05:37:51 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689263A07F1 for ; Sat, 11 Dec 2021 05:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=workonline.africa 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 JwlE7Dh5E1WL for ; Sat, 11 Dec 2021 05:37:43 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70085.outbound.protection.outlook.com [40.107.7.85]) (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 049F53A07EB for ; Sat, 11 Dec 2021 05:37:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NLUNUREPCDxfLdZELY6P2C2wmDl0ltTUgI0KLYv17QK7yPnMEDbdBCk1m/lGzZNNCzoDrlGb12eLF0zos8pTEV4K6l3aFIpxswlkv5DveoUKgOggZ4ZZOL+g7JFpT6Xobu74Yn5idFQPwCf83gAvGlKKIoLbObe39cLLSM3qAcRV2eUTjMZWbaQeqlTXIJ5EmyUgOX/rVFjW3431od4+IoHYyDS2tNohggY+V/Cyg/NXucf0638SYOOaylgfPcbEW1J6BI7e6b2Yxt3iwLuwyssoS+35hoJdbmseBiC/RtqQE2Fh+CyIKOyfBaBOGgkI6lkw0BAGYSm8wU6cfYwu2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=37KjLBFVKq5LOa8XoIaseFJmbFuhJ7YbWlHYM/kZ880=; b=hvv2uT3C1DgDARgPCaZjW1bwLnNykLEIKH2wptrD2YgzgclPi6vH6CiPa7fcbT3BslSMy1FzrFuAV/Xnqa91maPMUeK8VTzAzV9/R1e+tfZhv6nbXrLgKJVt5ZqvaRefkPM7BBoD6Nb6hb/XxaUIiQCSqG4NCyPZidAGk59d+/DAT1s9DM1Bx5JTbT8ATBo1Ru1Q5RedM4ziqrlc9BxsfN7yCK9IAPqr5mj73Ucp/2YIgnuQ6BiFS02glEl6ih7vY9VT/3ugF7jPTYLp1ASgx/zqT9mHtE9rvo/bIaO3vCVp7MO9CPoP4kzbPuvk1gDlJueNaik+JfgCzLj7aXtt0g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=workonline.africa; dmarc=pass action=none header.from=workonline.africa; dkim=pass header.d=workonline.africa; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=workonline.africa; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=37KjLBFVKq5LOa8XoIaseFJmbFuhJ7YbWlHYM/kZ880=; b=duRfivmGGCEbzNOL68sCLCck4W2qct3Be+HD3yGR+E4JQEENH+P3cd7wnafU+hKFPmZgNLN2WY03nQ3gef/9Z3eJRNxmZtZTz/X62ZIy7I8ejIsMqMtlW8kkljzeaYSMTC/GMPyHuqcAraG6lRV7w2Ao8YVLNUIzowZxlKhQIvc= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=workonline.africa; Received: from AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13) by AM7P190MB0757.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:11c::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.13; Sat, 11 Dec 2021 13:37:35 +0000 Received: from AS8P190MB1078.EURP190.PROD.OUTLOOK.COM ([fe80::a079:73c5:8443:3068]) by AS8P190MB1078.EURP190.PROD.OUTLOOK.COM ([fe80::a079:73c5:8443:3068%7]) with mapi id 15.20.4778.016; Sat, 11 Dec 2021 13:37:35 +0000 Date: Sat, 11 Dec 2021 15:37:26 +0200 From: Ben Maddison To: Alexander Azimov Cc: Job Snijders , "sidrops@ietf.org" , Ties de Kock , Nick Hilliard Message-ID: <20211211133726.3tg4qo43cyrrdk2j@benm-laptop> References: <00E18520-A535-4CC8-A287-56FB2F164E14@nist.gov> <5B2CD457-E376-4B8C-B901-202ACC4C465C@ripe.net> <20211208120944.5oq6o2sr6m6xzq42@benm-laptop> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="c5clandeiayqlu2y" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: CTXP275CA0033.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:1::21) To AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6fc8e8f4-cd59-4115-bca3-08d9bcab63a8 X-MS-TrafficTypeDiagnostic: AM7P190MB0757:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: dniX3MXgfXtfQ+e8v9l9Z3+ATExtdvbqJS5z4SBlSV2kNfUkvVyPoQ8GqvPyvfB8d8ilUJ9EHb98RKwfpL0OojUx6hWnXKJdM7aPAg2DZizDUuQ0mhEiuy2/xz85+iL/LOf5zboOwgzWv3JyNClBP1UZTb7TM3iU8wMF64a2FbkeraecmBlhHlsigXESpVEqbuQxlHh6NAs1T7K5UyPwA8EL37umCP/mR0sBJNvK9NEDgl+er62gVTw8Qa+C9wwpGQAqE4/DsPbGW9cPwD+IQj6kK4fhEHDOI0b+H+z8ZFKA72uO8Pt/Y4+A42gSK0YoAwFN1KnjUXyRHfJyD1iZ/oSt9qhufw9XY0/VeQfCH9DteMghwE5FY1o8zUTvAknIjp+IRkJJbsuLQdI7MNzamEypINi3e/bBDsefF5Txlpf/yBRQbsWVO6yfZ+grC2d5nMxlaWqTXaIrd6oUj46+TNgGSPqBlWrcsDsDCQ8ig4o2MWE8IWNo2aJmXnb2NglvfVj1rdtMcnt2Hjl/93lN7IesXi8znKFGSjKc7UXNAPl7lFGn9eyqgvTOZO3PGTqlEuZYBQDppwGyFnC3+sc3xmgQqCqnHaqHQj9KEa2oar38KWGETbaKAimFp0KQBWravEIjraAtBqRakBvIUS5zexqCa9TyxvC5aa5SMnA6LfzFMDSNgYTziAmh4Rx3l1PaKRzgA6FR2XaZCaPuSlNd7Rd4UyIzMeeS9h88e8hJ/6nptHticB76r54fpm/DM5IW X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8P190MB1078.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(7916004)(366004)(376002)(346002)(136003)(39830400003)(396003)(6916009)(4326008)(52116002)(508600001)(44144004)(66946007)(66556008)(66476007)(1076003)(6666004)(26005)(6512007)(38350700002)(38100700002)(316002)(54906003)(9686003)(86362001)(21480400003)(8676002)(5660300002)(33716001)(186003)(2906002)(6486002)(83380400001)(8936002)(6506007)(46492014)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?pgg8cLaaTkbHFl8rgcafYfg6z28t6JXD+6/j728vJK0KGyN5UDmxRga0WHS4?= =?us-ascii?Q?gZV+JDnLPoC+5mXkOHHYizwK1043p0Uq1gbWiKLNUdfiNB45wdjZW2/uSSUr?= =?us-ascii?Q?XbnlY7NCy5rKgId5EiJ1QUphocny4i9DCCRytAzjG/ojuu0NkKVLCmcpixgq?= =?us-ascii?Q?nIr9pBWCs42hQEKfj/Uridh/sOHGX35keHfckiDBH3QQRmvzZpYfNIppzYGJ?= =?us-ascii?Q?Ut9p0LCMkxmfbk+yg52TatnJaefpDEJJXunLP3KMLyagsFe1zCifmEJTxVbB?= =?us-ascii?Q?GxrzSxgkKM7yQW92vAsT82op0ttsV19gF+0IYgmAXpxZEPFrK+w0fKSL68hR?= =?us-ascii?Q?VZGhUtySR0P5kpB1q6wIaVyUCcJP7SNV/xt+kcOSgY4qT32l8r7EgJ6JvJZw?= =?us-ascii?Q?L4akfYx72mYOtLHI3BfVLzd7LaYZKTDJ3J9+IHqg48FHJrMXZzf+QQZzaLoF?= =?us-ascii?Q?BZm21CydMXzIQF7YSe8clFhCOJWqQ6Wcc7gsGKmQO/Cyo9HrjbrsBjQvJAeD?= =?us-ascii?Q?0HVBWkInNzetqwAvv9yg4LdYbmMmNrjuyAbGJOtGthOSzd4JzOUVSmRnGg9t?= =?us-ascii?Q?kzXddrLkFC8hq4I5EcHkD7ibdnCBDN9P381jJJSP6jwtLD+KdhS6PtdMt3Eg?= =?us-ascii?Q?R06ADvsqAlQtVkcQn1JyOiN9Xhxo9JcOOoEBCOkBIGc+emGE0gKv6mfLUbkj?= =?us-ascii?Q?+er4rdXQ/BsxKiCssAGgkNHrae+5WFzaNjEMe/YVZYbG0QOvq09K1WnPhhpO?= =?us-ascii?Q?M8/ywf7KOoVELII3l4slUL0UcS4kPl99ecgflBzCgsoS6fUk/5LVZ2GbePOS?= =?us-ascii?Q?GBrZ/38oMqhuL3EJsmwFXKha3hQ/W3yzcJ9tRhoOERrDZuysbak0bQqNfoWA?= =?us-ascii?Q?XzOKGDS+UzSA+HY+knZfwXU267nKaziZTKSZg2Wb110MnGv87dqMAXXME5AW?= =?us-ascii?Q?Mh9D0nqSFXeJKoa1ha/CV8z6YvCMhmEvSbjSWlFnJKbIgHJ4uM26JE5mh3Lg?= =?us-ascii?Q?5VnxmvqvXwbWm3BrHTVFjRa9TNhbPVFgJGyLnSnGZkQqNKqDcE2y0EiYA5f8?= =?us-ascii?Q?7yT2taS4E5LdXDeVGaPLy1tMJE1O0Xynz8ta0ZIjZv1Tn7usLjlR1RTt8uoE?= =?us-ascii?Q?shX/M9bgEVoGRzCbmnss5sK1bPraE5YYOP1nvHyY0ekx8ANgGag2LNDoio62?= =?us-ascii?Q?qWdFeEMAAna7XlXqPf6XCyPlSpiZX2VE6psI079/D6hx/KGflESDm9Td5kKs?= =?us-ascii?Q?Z/GQOfpw5mfOEdDsaFin4PS8DTZgkHTBJyDlqDd1QhNFwTAyzPFSRr+n3AF5?= =?us-ascii?Q?PxngziWKJEKlP2rfNHXLm55n8skin0gzDqPCikcT+SX2dwULHseWGPGmrnP+?= =?us-ascii?Q?IbqQONO7ABw9/U/qQNe8dmWntwLBYsvLTk54QPPNVwrsw/Lgr9l+uznT53ve?= =?us-ascii?Q?f4D/Ta/WMkeQYVJiO1RNAM1OWYDKA1lRns0fo0PmEvtPeMZC/9Rl1Prp7M7h?= =?us-ascii?Q?JoJrfeTMBK3OxWknoujubac/TWkpK5yLcNEqMjpOoIUub6B9+SyfaGIkiKXW?= =?us-ascii?Q?ly/r74sHaShMWl2jxdIVilhBuIn+dnyvifJas8l5+Rmg81C2Nz5S6qNZTcVd?= =?us-ascii?Q?41ZluoQSDOYnA1oJfIAHnpo=3D?= X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: 6fc8e8f4-cd59-4115-bca3-08d9bcab63a8 X-MS-Exchange-CrossTenant-AuthSource: AS8P190MB1078.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Dec 2021 13:37:35.0036 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: iRR32QTXiFMCG/YTc8TrdxNN++T8BS6HvuGfieSI693FC5vLWLPppDNp5F/jrXYh+xtuvArdE52y3vSeU1FfMA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7P190MB0757 Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-rpkimaxlen-08 - ends 25/October/2021 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2021 13:37:50 -0000 --c5clandeiayqlu2y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Alexander, On 12/10, Alexander Azimov wrote: > > > [...] > > > > > > Let's elaborate what kind of events we are facing at the moment. > > > The majority of hijacks and route leaks are mistakes. We can assume t= hat > > > the difference between accidental and malicious hijacks is absence of > > > forged as path in case of accidental events. > > > So, ROA with ANY prefix length is good enough to limit the blast radi= us > > of > > > accidental hijacks. > > > > Only if the origin AS of the hijack route is that of the hijacker. That > > is not the case for all mistakes (Noction-leaks, for example). > > > > Minimal ROAs are the best current initial line of defense to such > > incidents. > > > I agree with your point about Noction. At the very moment, we don't have > any other technique if forged disaggregated routes are leaked. > Though it is mixing up route leaks and hijack problems, and there might be > more suitable solutions for route leaks in the long term. >=20 > My point and my main concern grow from the fact that Noction-like inciden= ts > don't present all the scope. > The incidents that I witnessed were results of redistribution of static > routes with Invalid origin AS. I hope we can agree that for this kind of > incident the length of ROA doesn't matter. >=20 Yes. We can certainly agree there. However a substantial proportion of the wide scale incidents that I have seen in recent months have been such events. We really don't have a good defense to these other than the ROV length-check. > > > > > Unfortunately ROV deployment isn't at the level when we are no longer > > > affected by accidental hijacks. And the best option is instant prefix > > > deaggregation, if it is possible. > > > And I hope you will agree - the time is precious. > > > > > > Now let's discuss how the recommendations from this document may > > complicate > > > things that already got nasty due to the fact that your address space= was > > > hijacked. > > > > > > *Scenario 1:* > > > Being a proactive and BCP aware autonomous system holder, one may add > > > egress ROV with strict policy to drop Invalid routes with an exceptio= n to > > > blackhole routes. > > > In case of a hijack this good citizen will have to relax it's routing > > > policy/turn off ROV on egress. It is still not that bad, but in huge > > > companies with complicated access rules to devices, it may still take > > time. > > > > > If your neighbors drop invalids, turning off egress ROV doesn't make any > > difference: the update gets dropped on the other end of the wire. > > > > If your neighbors don't drop invalids then this can be done in local > > policy using SLURM, in close to real time. > > > > In either case, this is a red-herring. > > > In this scenario, I was supposing that ROV is done on egress and is absent > at the ingress of the neighbor. > And, yes, it can be done using local policy, but it may take time if this > scenario is not thought out in advance. > I wonder if you want to cite it in your document. I don't see any > references to rfc8893 at the moment. >=20 I'm hesitant to add any more length to an already lengthy document. I kinda think this should be fairly obvious to an educated reader. What do others think here? > > *Scenario 2:* > > [...] > > > I think you missed my point in this scenario. >=20 Yes, Sriram pointed out to me that you were considering competition for path selection inside the intersection of Y and Z's customer cones. I missed that previously. Apologies for making you repeat yourself. Viewed from this perspective, this scenario is simply a variation on the one that lead to us adding section 5.2. In this case the defensive routes are hidden because of differences between local-pref in Y, but the effect is the same as if there is no adjacency between X and Y. I stand by my view that, in the general case, solving for this creates more risk than it removes. But I also appreciate that this general guidance is "general", and isn't necessarily true for your employer, or those with similar topologies... > [...] >=20 > I can imagine that for access providers the list of 'important' targets m= ay > be quite small these days. > But this view can be very different from the content provider sude. Last > time I made this math I had 1000AS to cover 80% of egress traffic and > another 1000 AS to cover 95%. Yes, the same distinction occurred to me. This phenomenon only occurs when the networks that one cares about are not directly adjacent to the hijack victim. Most content networks with which I am familiar have very high external interconnection density, and are usually only one AS away from the other end of a TCP connection. This would make the above much less of a problem, and perhaps explains why other CDN ops people here seem less concerned about it? I wonder if you have looked at how many of those ~2k networks you are directly adjacent to? > I hope you admit that makes 'some' networks care about the customer cones > of their peers. And as far as I know, these networks are primary targets > for Noction-like systems. >=20 > [...] > I hope you reconsider. Let's try to find the golden mean between our > positions. I think that we can resolve this by explicitly noting that the "general" recommendation of section 5.2 will not apply to everyone. Something like (section 5.2): 447,451c447,452 < victim and hijacker filters ROV invalid prefixes, it may be the ca= se < that the existence of a minimal ROA issued by the victim prevents = the < defensive more- specific prefixes being propagated to the networks < topologically close to the attacker, thus hampering the effectiven= ess < of this response. --- > victim and hijacker filters ROV invalid prefixes (or where path > selection policy within intermediate ASs prefers paths learned from > the attack source) it may be the case that the existence of a mini= mal > ROA issued by the victim prevents the defensive more-specific > prefixes being propagated to the networks topologically close to t= he > attacker, thus hampering the effectiveness of this response. 453,455c454,456 < Nevertheless, this document recommends that where possible, network < operators publish minimal ROAs even in the face of this risk. This < is because: --- > Nevertheless, this document recommends that in general, network > operators SHOULD publish minimal ROAs even in the face of this ris= k. > This is because: 468a470,480 >=20 > Some operators, however, especially those that are topologically > distant from traffic sources that they consider "important", MAY > legitimately prioritise the ability to defensively de-aggregate ab= ove > the protection that minimal ROAs afford. Operators making such a > decision SHOULD carefully evaluate (insofar as they are able) the > filtering and path selection behaviour of ASs in their vicinity to > determine the extent to which the aforementioned risks apply to th= eir > situation. Furthermore, operators SHOULD continue to re-evaluate > this decision periodically in the face of continuing deployment of > route origin validation by other ASs. Let me know if this works for you? Cheers, Ben --c5clandeiayqlu2y Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEadkaB2uV5dm5UllaOkYk/rSLaGAFAmG0qZYACgkQOkYk/rSL aGD26hAAtB7/U4eBZKTjKtJSCbNBDXW7dmFcaT+LTgv29BiOrHInb4fzzUa1OJti El849rso+DdxBpvAKV4gFPuMHSDlXkMIq2zyZ09f95Aiq8/htluWKXzfqXCb2/BT y6HSwdKZi03G4MW0JWqfGDlN4iHkCi6u7WclO2ayRyXnCH4/YSN9C3Edf5vWM23O LVryt/rICSEZbQp1Q4lPbcabaBwXs309XLsmdV6zhjSYCtMaEIwuxSet4ft4fEYm hFjoOovSVBx70k6hlff0a1yNFDyFjttmNbXrqeG3Ejs/Ax1GAGLWcztIutYL+f+I LPeGMWZyPD1NDs3L++7e4i4x5x9q4YCe03oQTuSyhvMjbQnLbsm2eZPGtGFvs7ae XvH79hOGbmcOz5KFdkbMnOm3QRKuGtTNpbaxB5uQALW4BpCmLvKqiJtPFJ680y3Z zdaDiPFxXjFNqPq3Hlq8h2dr5rhP5ashIT8PYxGWOcqtd7v5zP3iBvWvcQCopEGh j29G3R+so9KmoJxd8dk+D3xRPEk/OQV7u1/PmhBMwV4InGgOOWD4GhK0rTil3HjI zQJE9yTysLHebuJOUtAylJEuZgDP7QM9r7h+AXUyoUM1Rdp0z38k4Ui2Ha+lL5v5 j2Rw9+e0H2zz+WbmPWU9hWgOLEm5kFv+Ai7W42xhc8R/IaNa/zM= =dkLo -----END PGP SIGNATURE----- --c5clandeiayqlu2y-- From nobody Mon Dec 13 07:37:29 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6DA3A074E for ; Mon, 13 Dec 2021 07:37:27 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=student.utwente.nl 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 BxsioDTxGRGP for ; Mon, 13 Dec 2021 07:37:23 -0800 (PST) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 E8C093A0687 for ; Mon, 13 Dec 2021 07:37:22 -0800 (PST) Received: by mail-ed1-x52f.google.com with SMTP id r11so52725024edd.9 for ; Mon, 13 Dec 2021 07:37:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=student.utwente.nl; s=google; h=from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=dylN3pr4d49sm/AGEtvVGISAGlUk+oNCmzqu2fDIjCY=; b=TrKmIiX/p/9RsOQIy1Q4rQw1TKbCca8K0LV9UB775CasKFO/SAOBAxxSJkyzvLI4rk bwFvYJ+TLPXLXoMZYn+L4bd5LnP5prvNieQlBNz4+GB296cU3Cooc4PeKldxiMU5O9dk 8497IXHxqV1yh2Wprg+EtutWeRu9ix8TZKfQthDMvtyzskKHnLbMANhTmqVEQz1Z1SN3 X6HRD2L7tbMt/gwyfPGpHjIqGvVTvkdUbsNITI12gLV6X0w977wAa3AUR/weZqWlrY4r kl4vSnF51A3NKWJh6G/CVOBIsJXeCGKLBLlUTGNybNJvB0nIbcBsX7ngik2JCY27a8NG ZoOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :thread-index:content-language; bh=dylN3pr4d49sm/AGEtvVGISAGlUk+oNCmzqu2fDIjCY=; b=nETMxSampAc04NMg0I+e4VoBz+daMIdwl4lTme6AG0B0irRPP9OOeBEB5IJrHOR9S4 P4q9Blv6iYvhjJ7I02W/krscEvlRGEEMqMk1stMmlVtfmtxlNJ2jvesspvs+AVWni1QH 9kRv1YS49/ZQmxAb+q2w2iORnyomfYF5sdFRZQi4jixWsSwHF0kOyW1aToMcCHxrZscw K+vMN/JY6DyHozfmvQmRiOMDnH5mzEQaYgTxbh7LzAgcTk10ATV4LuM5BzfY/2Kdq5wr aHkn+XxcVPriewYIZ625UXnp9w6maactKEBI7VAHEf5WTiSd92OeJ0v0f0CdmUzJ5QAi nTXg== X-Gm-Message-State: AOAM530oNb0wvmLHQV9aNxXdc8JpsjAR2d0XnpSLuOXoIQ2xBmR5apNv TheI43CPKuef4FIwhCSaBfENTFOgqaH4fOLLZPgdHbO5DKmY8EVzMPhifLi7FNbHid1UpdVy1QS nq+vMkqb12VYZfIRtVkQbblMDiDugKK9EnYfB2YocGY6qQmeqBc2DQwlIkqrZj+vmxQi3vKgpn0 xT X-Google-Smtp-Source: ABdhPJxjX/R5JldEZFxQ5ugSiNFokeL20nCcE3NccINdy4KlOz8/dFUtdciJ9bB/a1J5jNVHrZgoZw== X-Received: by 2002:a05:6402:b82:: with SMTP id cf2mr65183127edb.40.1639409816357; Mon, 13 Dec 2021 07:36:56 -0800 (PST) Received: from Epsilon (219-190-177-143.ftth.glasoperator.nl. [143.177.190.219]) by smtp.gmail.com with ESMTPSA id 9sm242290ejf.172.2021.12.13.07.36.55 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Dec 2021 07:36:55 -0800 (PST) From: "Koen van Hove" To: "'SIDR Operations WG'" Date: Mon, 13 Dec 2021 16:36:55 +0100 Message-ID: <004b01d7f037$42626090$c72721b0$@student.utwente.nl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01D7F03F.A4287640" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdfwNXAZwoUVOQPiTXuBEeJJiDDGJQ== Content-Language: nl Archived-At: Subject: [Sidrops] draft-kwvanhove-sidrops-rpki-tree-hints-01 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2021 15:37:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004C_01D7F03F.A4287640 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, Based on your feedback I hereby present the second version of the tree hints draft [1]. Russ Housley rightly pointed out to me that whilst additional fields cannot be added to the PKIX certificate profile, non-critical extensions can be added. I believe adding the hints to the certificate directly, rather than using a separate object, reduces operational complexity, might simplify some issues with "what if the limits change" (as that now only happens when the certificates change). I hope it also makes the political problem less troubling. Additionally, I reduced the limits to the two main ones, although others can be added in a similar fashion. Apart from that, the main concept was left unchanged. Koen van Hove [1] https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-tree-hints/ ------=_NextPart_000_004C_01D7F03F.A4287640 Content-Type: text/html; boundary="----=_NextPart_000_002B_01D7ED63.71B03EC0"; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = all,

 

Based on your feedback I hereby present the second version = of the tree hints draft [1].

 

Russ Housley rightly pointed out to = me that whilst additional fields cannot be added to the PKIX certificate = profile, non-critical extensions can be added. I believe adding the = hints to the certificate directly, rather than using a separate object, = reduces operational complexity, might simplify some issues with = “what if the limits change” (as that now only happens when = the certificates change). I hope it also makes the political problem = less troubling. Additionally, I reduced the limits to the two main ones, = although others can be added in a similar fashion. Apart from that, the = main concept was left unchanged.

 

Koen van = Hove

 

[1] https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpk= i-tree-hints/

------=_NextPart_000_004C_01D7F03F.A4287640-- From nobody Mon Dec 13 08:00:45 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193AC3A07D5 for ; Mon, 13 Dec 2021 08:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net 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 U-jBCapkPMGB for ; Mon, 13 Dec 2021 08:00:39 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 42B903A07DB for ; Mon, 13 Dec 2021 08:00:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Cc:Date:Subject:Mime-Version:Content-Type:Message-Id:From ; bh=k/sk3ExFO0P2uCyPSO5wkyFVaooHyBHY6PLWl06BBgw=; b=Bv7cpTlW4inPSvrBJGhzehfU 1iMChsuS6jAkiJ7qMdfCXkiVtKeIIZOxjRdqiYRlIi2LBsFee34K1jumY31uqtHF110keLBYOh27V DZevqHNL3ifoOV3YpE+EPFL5oasWFPrwmI+HYa5/rvdsTLzDgCe5+IBApubgnPT3Aj8FwD0uxck8n hifWUMIBhtmC4SVRU7hNmcGU4fXXru5CdMVfrZ3m+B7PgfUIukw0DrtsVCgCkgP4jzK4kjAa66qrz 73TVXR79CcWKCuqltZRc7944tEi3K9Sdsz/a38maoXwLRvbcyKh5XGpiVaGDiuO4jk7Fh7ov6iDhd lyZoPAanuA==; Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:43054) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mwnkh-000Ac4-Nc; Mon, 13 Dec 2021 17:00:35 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mwnkh-0000YL-Kf; Mon, 13 Dec 2021 17:00:35 +0100 From: Ties de Kock Message-Id: <9F86E690-C065-4438-BAFF-97AE7DBF2D1F@ripe.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_65EAD028-FB08-4921-8DA0-0345FA7A81F0" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Mon, 13 Dec 2021 17:00:35 +0100 In-Reply-To: <004b01d7f037$42626090$c72721b0$@student.utwente.nl> Cc: SIDR Operations WG To: Koen van Hove References: <004b01d7f037$42626090$c72721b0$@student.utwente.nl> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e15df250457ec0edb56ab8c04a465ac278 Archived-At: Subject: Re: [Sidrops] draft-kwvanhove-sidrops-rpki-tree-hints-01 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2021 16:00:44 -0000 --Apple-Mail=_65EAD028-FB08-4921-8DA0-0345FA7A81F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Koen, > On 13 Dec 2021, at 16:36, Koen van Hove = wrote: >=20 > Dear all, > =20 > Based on your feedback I hereby present the second version of the tree = hints draft [1].=20 > =20 > Russ Housley rightly pointed out to me that whilst additional fields = cannot be added to the PKIX certificate profile, non-critical extensions = can be added. I believe adding the hints to the certificate directly, = rather than using a separate object, reduces operational complexity, = might simplify some issues with =E2=80=9Cwhat if the limits change=E2=80=9D= (as that now only happens when the certificates change). I hope it also = makes the political problem less troubling. Additionally, I reduced the = limits to the two main ones, although others can be added in a similar = fashion. Apart from that, the main concept was left unchanged. That is a significant realisation. I think this will need some testing = to see what implementations are intolerant to additional extensions, but that = should be quick --- but if this works, this is much easier to implement, both for = RPs and CAs. This also specifies the exceptions much more naturally :). Kind regards, Ties --- > =20 > Koen van Hove > =20 > [1] = https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-tree-hints/ = _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops = --Apple-Mail=_65EAD028-FB08-4921-8DA0-0345FA7A81F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Koen,

On 13 Dec 2021, at 16:36, Koen = van Hove <k.w.vanhove@student.utwente.nl> wrote:

Dear all,
 
Based on your feedback I hereby present the = second version of the tree hints draft [1]. 
 
Russ Housley rightly pointed out to me that = whilst additional fields cannot be added to the PKIX certificate = profile, non-critical extensions can be added. I believe adding the = hints to the certificate directly, rather than using a separate object, = reduces operational complexity, might simplify some issues with =E2=80=9Cw= hat if the limits change=E2=80=9D (as that now only happens when the = certificates change). I hope it also makes the political problem less = troubling. Additionally, I reduced the limits to the two main ones, = although others can be added in a similar fashion. Apart from that, the = main concept was left = unchanged.

That is a significant realisation. I think = this will need some testing to see
what implementations are = intolerant to additional extensions, but that should be
quick = --- but if this works, this is much easier to implement, both for RPs = and
CAs.

This also = specifies the exceptions much more naturally :).

Kind regards,
Ties

---
 
Koen van Hove
 
[1] https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-t= ree-hints/
_______________________________________________
Sidrops mailing list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

= --Apple-Mail=_65EAD028-FB08-4921-8DA0-0345FA7A81F0-- From nobody Tue Dec 14 13:44:23 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29AF83A0A29 for ; Tue, 14 Dec 2021 13:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net 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 pmQupiQrDIbn for ; Tue, 14 Dec 2021 13:44:20 -0800 (PST) Received: from sonic304-22.consmr.mail.ne1.yahoo.com (sonic304-22.consmr.mail.ne1.yahoo.com [66.163.191.148]) (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 B5E053A0A26 for ; Tue, 14 Dec 2021 13:44:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1639518257; bh=Qn6y4PcFdTvgg7MG8ZfMVISclKCbVWnyD/VSLK5iW9g=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=U2IabCYUo0b4pYRAZdpQZ909dX5rIG/o+e2XLnCIySyotTAwMbOBY+zsvBHHuoii5wKjwmRFA7ELSVec/QwgFMcc9z2R/gecXDrSmvB53ImmFxg4I1vnnFUyCYUVx0luxUGZFiPbrvxTLdcNwz0KV1MRLZVWZwuSDsSLNxUiFNnFD8qU/dS2jiiKc7x6v80DeME44ozYhg/+YGpCnv5olt1pmWry871TAYsZ7J683WM9Jbag5lGxSBjoZV+uw0PRrNBpgprPnuMHAH4PIe7OxaIAtvMIh36NWWhqQXcIyn3Fe67Yx10bowa09R81PQuIS3BoZvicLcbPKEBjzh1SLQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639518257; bh=itvByPczSlYNftOLtF8ohXmXx1qzEKsC0RoFbpwIffi=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=eMbV2RpRANd6fLY40CbMuwUAOOxcuA3Dp0CemDwlAR443QHFvKowryFOeMknF2s+/SsfaQ+dwOymPV465/5m8TddcCv0ETd4jPnGn7c2542RH7pilP+BcHz9hvgzUbhQ+agt5E7mf/TQhmKO1+YjdNkxLbHVa7eS+LlzWyO2zkA64z8qOlGsyY7OfQWZSa5woexRAzEV0N2mBE/tJ74bqoPOoChQ9eB8uslTuM4HNzp+bpP54oGODOnibZWlvzwtu/iYoT5pd5OwO1y76xkoYmeHrkt5ZBPRI3qg4hFhmW2qwFk8Xbtocz8D6zDI6Z2Ikck0kMsaaJ75vITCv7DBcQ== X-YMail-OSG: cExlbIgVM1nquTdl.a9VDGeqFpmylNGGypBZ_6rvpwdDmKSAYFugD2sdyoB36t1 joB61fikgk_VZGoE1_esQDyX7d8Va.vKboZXMZrr7v0ROSJDN8VFjtFjtB8_6ecbwcC1yVc.9W78 QdnscZhuhMHoDDs6ch1yKzTEkhFcDSlEUpFO8N5ve8meGG.HQh3dv0R.vouYFPwc7Tig1z84SdCE H5Pwbwkm53848MW_n99Trdq6fESY0TQng8mAs.6HV3S6UpHcn5h882L8y_daRFEkbkEG5PJ4Hfo5 cpH80McLrVtiVxCVYaURbQaj5G7108Ed62CGSOgMyDZ04zWT6uia6N3n4zWj3jFmiS3kzrmnS1iE oIxTkOzcTO40skydkcLh0G_yxz.2OesijJbhG8k6AYOld6cYhBnd.LMBg_UbuwMYkBlYiOKLzY2z LCD.YLCfc_OEXuM_ObA14p509Te0uqaqgGG3YbaTKqz6ztUIZB4PpYDiXO3Zc3o1EaBZFdVMneam 7aiwWalLn3ki5xc14FDEJq227f14vEmSSJRdHvOFInNbuLZ2o5Cc_4ZIMxnLZ.1Djq.OrbSusneF efZTPXlpd1ERTCkc5xJBfxhd_q5w_cS2ebI5nUcvfQIG.qSiFjsLz7A15nUs16zb7Lwtamx4jVzq NSshZXOnZPUcucTNBJQ6IE6hbs5u308hyMiygVJ.O5y3EerKd_jEVefX_XMQ.DTj2.yPuO.qd6hf 87vFUaVoRVUilQSfd8NqEAt1Lhq4kxtDZzjo6Z0ezO62ibnjUI5LTuovDekY4QyMBhqbfacddPCa 8iDgCuMzkVwSNB_tsSLf5ETvAmUO3mygiptZT_VproIz4qwRa2grNsYuttDk41Uh5M5WE1H3_XVO dkmv3.EZ29E4GUItr1853RRz8Jnc_bwhKIoysmAjTkSugg_Fao.OohlnE7Q634yzvzoDngNDfLiO JJDzxYkswYwdfbBaUGRE0FbpFpX_YVloMAiGZTnEoSvV8IfmwJlHbR_DqNl28rV2U.uog8iR0BuM vBW3ghQS2e_C_HzWkkhrszgG4Dc3pWcqdLBv_XSlGayyJTy.vcxVAG1ZdK7CU0RPtL4rtUVgPJEF OZcTItm.JP.LLO6eSYLyYzn0RknPn99UoMHkrulj3.zFrlg9LkOab3EtqyJRf7Bx9gdDef4AiIx8 QlQQArmdbt0oWYLotiLQoGbqOI5gUBHtlzh.0p6pFipSieRXqDmo1fmo_Hzp51F76GLrbQKYmDOQ bzHgq_xnMXdn1S8g3U8tTKUdqW5q1OteESqTONQH_u5x9TDcmj2t7tZY4gCbRN0eJgNZpoKTCxDr 9iDWZHdHied56j0hxScPIitGRJvCa14.mLEZ2y9fFdaykmYk7Y7NEBL9P_vOPXEjvkFDBVvdHJD1 myf.CGm1Pli3CukezFh3BWHnd2.wUTrcTl9C_SYgQnAwNSfbeWYrlE7PDAuPTorfXONUsyGuxuUU NbKQiTJfl89b98JqmBawSbGSHnjHzbryiXTLLPuITzMuSeVJkfEeTOyJAutNnX0gaDiIAcA6PpWh MoiphP7G3m5XrcICyxmxnimRIlQPAuDRMnXCra2R0iRRq_yuoWhlcL2PM_XZTyR001LkVVfMSODN 0FDARDLD6qZgAePTfgtktfLDOOTm9l3frJPlQM.GQ6B8ZI8y7lToR9sN3q3kgyq_bxXQ55tn6cDS 1X0Csdp9AeVQ22XcuCsRKW3CJ_d.Y00RRhYSo0gPACyIj5lehTOpGensHxirw3IFyMs57Rf594iR A0qRv_f9gaEgNAXzLGYHeWsrXWthIzoBKvKc5twAGh62Ix.pEdX5bXuCnwPR0yYVvTs1nWFFccYh OS8Iqy796FukE9P5_v7LmvCJe6Q8j71ZLGh_wrZZhmjo_kMXh2.OxFyjX6Bb6wbrzxg5YWzVFG4T Ft2OjJRS_yzEt931NUWa5hWYV8QqpeVtYTA_8YFZP.WVrxpYGn63YQkYJekMRBT4piueuWLybQ1O _PbaDsUml.UJ_zzxXNzdEykVD7xJkNLLDtHgkHW4fw6S9gIcB.AMVUflKPXj2wgTAIxbU6oVz.XG d2Mjq7zX3I41v_52X1grgv88vSAamJNotAJdQAJlQ0fHejhvi_gSSaFRIylF9j_3bYPjxUFaBvyl iJ54p8EpwVRgIVg1dylBtxjSV.BKYVTyL3puuWw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ne1.yahoo.com with HTTP; Tue, 14 Dec 2021 21:44:17 +0000 Received: by kubenode538.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6ecca25ca479adf359b6dec8da6a34a8; Tue, 14 Dec 2021 21:44:12 +0000 (UTC) Message-ID: <89f187e8-2c5d-9ead-22b6-31de556221b1@verizon.net> Date: Tue, 14 Dec 2021 16:44:11 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Tim Bruijnzeels , Job Snijders Cc: sidrops@ietf.org, Warren Kumari References: <813d1599-fc9d-18b6-a76c-b550855b1186@verizon.net> <20211130193034.344F62EA0102@minas-ithil.hactrn.net> <8d9b693c-137d-4a76-9fef-65968bb5062e@verizon.net> <2D30298B-EE34-43D2-B2B7-978DE69CC9A5@nlnetlabs.nl> From: Stephen Kent In-Reply-To: <2D30298B-EE34-43D2-B2B7-978DE69CC9A5@nlnetlabs.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: WebService/1.1.19415 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Archived-At: Subject: Re: [Sidrops] AD Review of: draft-ietf-sidrops-6486bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2021 21:44:22 -0000 Tim, > >> I would leave the text as-is, or suggest to change the MAY to MUST: >> >> """ >> If the current time isearlier than thisUpdate, the CA may have made an >> error or the RP’s local notion of time may be in error; the RP MUST >> choose to treat this as a failed fetch and proceed to Section 6.6. >> """ >> > First of all.. my apologies if my concerns were confusing. I did indeed > raise them in response to a question Warren raised about section 6.3. But, > I agree with Job on the above - as far as I can see. Yes, your concerns, as stated we VERY confusing, which the only reason I changed the text in question. I will change the 'MAY" back to "MUST" and publish the revised document. Steve From nobody Wed Dec 15 05:38:33 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B983A05A9 for ; Wed, 15 Dec 2021 05:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lvuedjd4t_E for ; Wed, 15 Dec 2021 05:38:27 -0800 (PST) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 9F35C3A044D for ; Wed, 15 Dec 2021 05:38:27 -0800 (PST) Received: by mail-ed1-x532.google.com with SMTP id z7so13732392edc.11 for ; Wed, 15 Dec 2021 05:38:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:subject:message-id:mime-version:content-disposition; bh=ODyteushkLFQhB3/G8a0Ejge4MV/YY5bjYmHQYveiX4=; b=C+RFylf3xkPWo+QE3MmWsy2g749pC7dTn4nOYuDSkNEvrlNcDD1BNF7QzsljZB4lV9 kecG76JCX3+ODd0rQ7AjU5QHdim/HVzh8bL49+YdX+CZsazho7k30DmdF22jDjN8X9rC HuSyRWI5UujMeeMyOY9LhcKeV7oMUyJ2GDyKw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition; bh=ODyteushkLFQhB3/G8a0Ejge4MV/YY5bjYmHQYveiX4=; b=o1y36u+wzwrQsMceojlvUrmJkFeXYwglAJqeP1IwcbX8yZQn4xHd57RfrFmSLIzAre x7obdr6zQBd7vSTb2zdT9PtpMtE6VBT+PpW1j30oXNDBiOYqf1055Oc3VTV1VBrW415z 4ZVDrQgJDD+Rs2ejgGIqWK9eQG21DTgnVUJ0cd1pmcxqtSGRYqG997agC/NAToEwGgeJ QnGs3fal0B84EmaYpIpeOjvl4Tnx6K/6C56s9b6ejkayiL6KSxg6jBJD5KbGsDil3TLk NTQUAFoprq5/MPvowD01nryWhvJ14YwsZSVEr6TfjKEKItE9jVC8WDc8tiH8ucXXly1v 2BQQ== X-Gm-Message-State: AOAM530Z/RfHVjkW5QUVRTOrHy42+teyPb/S/0nxv1cO9dFFQY7+WRMc deF1yapjmRQFO0a8L3P7jGTsAvRqREfg+0LOB27ecw7w0rTe/tORKNryg4VL29y2kpL9nzfSQuZ HfMModDoPvc6wXVz+Qfe6T3BKG30HS9Us/rLeb1/19dOuUkQxk5FRULI= X-Google-Smtp-Source: ABdhPJxzA53xxmCs9OXj16NQNVb/sV/ADTA3LAZcj3IQaPr0220ObqclZTvXxq8LcjwOGdhbOKlVHg== X-Received: by 2002:a17:906:d94:: with SMTP id m20mr6482012eji.233.1639575503906; Wed, 15 Dec 2021 05:38:23 -0800 (PST) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id b7sm1029217edj.24.2021.12.15.05.38.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Dec 2021 05:38:23 -0800 (PST) Date: Wed, 15 Dec 2021 14:38:22 +0100 From: Job Snijders To: sidrops@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [Sidrops] potential errata for RFC 8182 (RRDP) - serial 0 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2021 13:38:33 -0000 Dear all, I noticed there are some RRDP server implementations which produce non-confirming XML. An example of broken RRDP (redacted) content: The problem is a value of 0 (zero) for the 'serial' attribute in the 'notification' element. According to RFC 8182 section 3.5.1.3, the value 0 in context of the serial is unambiguously invalid: "The serial attribute MUST be an unbounded, unsigned positive integer in decimal format indicating the current version of the repository." https://datatracker.ietf.org/doc/html/rfc8182#section-3.5.1.3 Furthermore, the schema in Section 3.5.4 specifies serial to be a "xsd:positiveInteger", which is described as "The value space of xsd:positiveInteger includes the set of the strictly positive integers (excluding zero), with no restriction of range. Its lexical space allows any number of insignificant leading zeros." (src: http://books.xmlschemata.org/relaxng/ch19-77279.html) With the above in mind, I see two paths forward: path #1: ======== Affected RRDP server implementations recognize this issue, fix the bug (by starting to count from 1 onwards); no RFC errata; no changes to RPs. path #2: ======== An errata is filed on RFC 8182; RPs update their code to take the new errata into consideration (iff the Errata is accepted); no changes to RRDP server implementations. In the errata I'd remove the word 'positive' from section 3.5.1.3, and change serial to be xsd:nonNegativeInteger (http://books.xmlschemata.org/relaxng/ch19-77247.html) to make 0 a legal value. Does the group have any preferences? Kind regards, Job From nobody Wed Dec 15 05:44:42 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C103A0657 for ; Wed, 15 Dec 2021 05:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=workonline.africa 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 u6yqyZGtbxsG for ; Wed, 15 Dec 2021 05:44:36 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10082.outbound.protection.outlook.com [40.107.1.82]) (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 450313A064F for ; Wed, 15 Dec 2021 05:44:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E5ZBh2KlX1J3kiQAloGRxZb8IVpxU0eONdDsR/oGjA2EN3Ey9JCuPSXq/C5736k/oP7CI1IZrHAnJPc3AsTzWiRbSeGVDMgesXsJHmbXCKksx4ps9HyjA8560otFbMnPVuGuITOx1YYU4SULrJzT8QxZRhIMwDvglLS0F4ofkCqeH6W56jc6JSLn1HQnqe5/CuUs9CfBLHl3a71cv/9UqXwTc/9fZ/OfkHSfouMpmabovvwazohfLWAdUIDiGroLQPvjhS0BwJf62eZpPkLyvsr4dIkBuf4vPJh0ahl5PjQw1KgSzd07JT4k7XwP42r+9JGXQSMh1TGYPdimdtW8kA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=N4dNzDSuyJmZkUo5pT0kWZuJjqNWztr0IChb8moXPn0=; b=aRLe2E/vXAWSl+D6mN0vHec6kSxB6nC+FaFNZngNpA24yL3o4GRJBwFk8PuaJofiz224hUy71if53rVRnSJTk8VDEMX9kAJLVYJToQYVbt5rYVcJnMIk4rh39zHDdxehvqO2hsCylHU39ffcsZeyJi5xTXPr8W8A0U5B4Ls+OPSaztkoEDl+kB6vShVroW+Mi4wGORebR62QomXZCajUmD6cWB1Eazvc8i8U76t8HzQV5A4rSsYyFk8FQYnvYlbGiaJYwhbSzJwfGN0cNXlgv0q8DcPs0Ce7mHdKneKgXnWOVWojhlYiHQcQB7S8uaFcM07aiX5EEi/V86ix80E9Iw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=workonline.africa; dmarc=pass action=none header.from=workonline.africa; dkim=pass header.d=workonline.africa; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=workonline.africa; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N4dNzDSuyJmZkUo5pT0kWZuJjqNWztr0IChb8moXPn0=; b=JWslJbiqx8Eq5mKEybO5cbUGoxojP+b4AteBMiFoFWxqr6C9RJxjT5SDJJALI2dhTGqlKll7wqnZrh7WDdsnCp0SWxq35WE/6cTHkq/irRJgH3+WsE8V5jM72geJEhrT/vCEOgZe4od6x07bqM7mj73GXR7IrE9tDF6Vz2vC/lA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=workonline.africa; Received: from AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13) by AM7P190MB0744.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:11d::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.16; Wed, 15 Dec 2021 13:44:32 +0000 Received: from AS8P190MB1078.EURP190.PROD.OUTLOOK.COM ([fe80::a079:73c5:8443:3068]) by AS8P190MB1078.EURP190.PROD.OUTLOOK.COM ([fe80::a079:73c5:8443:3068%7]) with mapi id 15.20.4778.018; Wed, 15 Dec 2021 13:44:31 +0000 Date: Wed, 15 Dec 2021 15:44:24 +0200 From: Ben Maddison To: Job Snijders Cc: sidrops@ietf.org Message-ID: <20211215134424.adrjrlmzwae7purz@benm-laptop> References: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kmfgcu5hhbalfmvx" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: CTXP275CA0013.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100::25) To AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ed09007a-a585-445f-c79d-08d9bfd105e4 X-MS-TrafficTypeDiagnostic: AM7P190MB0744:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6790; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: iSjE4f66V8ah3BX/ZVVwVTbcDlzWI2KDudN3M6m+0XGidLta/8jIhDNFXW+xMMUKoofJvzcGs3IoG2r/SMsB8lgzTnqsfqGZGfmlkYQ/J7kK/K/B0GRamd4HrZ6QSt1RCIgeD9aZwY4HrKtaSoEdVorMtu5VQ2o8K16B6wum6OS7ZNmQ7fJF5CFpDKf//QSQN4zUJtxoaDGHzBDhrgC20BWm0OcNSfpf2UfWMl4iksd/A6UEZja/zhWm51K24m277rjsXUSV48r9JSd2LUVrhuMWoNhEdSw+szdMwy9hOAPXptrGG1xQpUwy9TgvWcPGY9G79RBggjbT1G8ev63W7mDpZ/E0aWrQyY2T6q+W/t4BHimGKIPApbbJMjAmR9OHeXrIlJj9Wdcwj+sANoDPdblo30eZ37liLcWVNfB/72UX6KFqQLLHi6Xb/81Hja7SmSsMmIgJKgYl5C0+uBGqAGXdH6JjPKHfcgtTPHcwKTCDUXRxLpdC4qXdM9qbj0J5A1rMqb91Wvzsrdpn4mJMHGMJUn+rtCqjAxDm9zzyQkAmaAfwtaQBinAWMPrOVpk9Z75ZJx8gfXpGm0jYnqZVd24DrYda//B0i0UGV01UWD++Tmj57OhXPIbLeI+2v722RUoa0AYApWamH84wQ+QF/R5H1FiH4Gos1hoODC6FBISWOigZU2KYr3Y6ShD3TewlRxjHWgGbW3FZ4bgB2MCM5SJdYgDvGruUtlHgW4LQTjN+rxsdKnNYZ7uR3NkDEkTM X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8P190MB1078.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(7916004)(366004)(396003)(376002)(346002)(39830400003)(136003)(26005)(86362001)(83380400001)(66556008)(66476007)(38100700002)(38350700002)(6506007)(6486002)(66946007)(6512007)(9686003)(316002)(4326008)(33716001)(2906002)(8936002)(1076003)(52116002)(6666004)(8676002)(186003)(508600001)(5660300002)(21480400003)(44144004)(46492014)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?oZIAmOcXm8rUJXrbhuqa4bNHBvWk50GKZDFyv2HeqPhWd3+//1Ikl0eX1yMk?= =?us-ascii?Q?a3943j9gWgX+1NJwQ/4TT3tbjdZA+6WUZEFiQYraNZUnqtIyuCMDzqZtzRq8?= =?us-ascii?Q?cAykZ9j13EoNNtsaW0MmSznRACpzfsDB/V2kGg9ECljhPupdutZTDGNNoI41?= =?us-ascii?Q?rXibSYMiA/c/deK5HkhraG28vp5fZ99Mrjdag5x6/dPcqTJeSFk6CyMk2KqU?= =?us-ascii?Q?bU0yebFoC9Dz+JeAs+57SToMswbGlWU7nZ8DjdW1bkp33Rum9ao0pxBerxB4?= =?us-ascii?Q?drUZ6hqfWxUCcov3J7eNmdT3Z/gX5IMwpIT845QFWssAx2UfV1RXPhIf1F3h?= =?us-ascii?Q?9dmxnXPIZ5Wp8c1g4/ELZCmSBOhs1DzJbEVWBP1MCSfulu/6m76U1Po5a9j4?= =?us-ascii?Q?6Z8rkhv0RDrn1soHN0f68Kr8ml0ROtHbfWKNfz04A/eHpLWFFbq2CecvF9nP?= =?us-ascii?Q?/cBvP1KnsIpTrb5EzY2ZVdDgGTOTeBsmGd8tEF7wLdLu7FjPaP6gXfCg+VRB?= =?us-ascii?Q?Cgr0tpGDMOw20Nq0cD1wMX99ECBy5f8jaa7JvkBF65zYACcAPNusWHlbCuZM?= =?us-ascii?Q?Tv+GWASftlC7AGNY+Xn8NCbvNylF/FugDK3HCUtTJHAe3tKToSh/Dx780XwW?= =?us-ascii?Q?9sd0hl9dQEtEcpxjBkXJDa8PbiDqHjsAUk2H4SqfAbs9XYm0w0+BwwduR48Q?= =?us-ascii?Q?KxAFOLaxBXHf+pJ9MItAYV4n8dpVUSJRJLkh9z6v2rn62mA0ZQTmgw0g414A?= =?us-ascii?Q?vNGeAtvlLUfITFSaI8e6+ZeSqi3l38Q2p69u57UJOdTBkughOsU9sytwNVTE?= =?us-ascii?Q?KCCVGCYaanSDtTHhuJNCafqXQukL1YadvsqVDx4lIdSrUCZPqfHZlr4b1sQd?= =?us-ascii?Q?XFK3vrB/Kc9kAcfpnfstCXrsvNvf+ELoSIOebNcvEw5eMoJzeznLc8Nu2Rek?= =?us-ascii?Q?T/jIf6+hgpB0XzTzqZ+JTX6dNaOVU+dtBIOzDt4mt2IGDcD/RKyS0vRtmLJX?= =?us-ascii?Q?/kKxGaodgqQUm7exa//rycwxI/KSXWggY2i+e1eYcmOpitpSm2g9FOZk4VOY?= =?us-ascii?Q?hP7BBZBl/Cas5S6Ru08hmPCWl5pSxIPkKuBLDC5yndjxI7kZ16+HPHXqwyxd?= =?us-ascii?Q?mbNNCIzJMPof+kegsT+C1GiguJflATUOaDxxGTCynstUn1D4LXJOMLb2nAr3?= =?us-ascii?Q?Dj/awKJe5u0kT6GEJzIyQzZVYJ6Binx6KPMi9d6wN1f3r+KXM2GRtfB+CM1m?= =?us-ascii?Q?hcXe6hLjPLRgGtZ5cBTio8yT5NOZ9+BqQGgP9iFgmyVK2xc2FNVt/y+Qkqdw?= =?us-ascii?Q?lLm5wIUZxEgwAdAqu0dTVCP4oWJ9WkTiBkBB0IAAWkBCrdU6JPMro1i1RVa3?= =?us-ascii?Q?L4n1yxWbkThQQxYBIFdgi5ZRIUf0gTLwWol9motv7MaeXy4WiGJNlVjLdCFQ?= =?us-ascii?Q?FsH+BybY4//kkIVn4RDJS/LfcC27aAm743ATfFoWJBnYhcF5Utldz5p+LYoR?= =?us-ascii?Q?rGnXGRARnZLO/xEC8vc/Pt63pvCOmZ0xfngeE2d7yb1HrxIHrBPwtKu9DQwc?= =?us-ascii?Q?S8B9yx2zkYVzdVus1MdjdPTPGPBtZcdpq+P7K7HrsBKrv4JVlQwbbDLjbbOh?= =?us-ascii?Q?SSyPq00+M5S6fudU3evC098=3D?= X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: ed09007a-a585-445f-c79d-08d9bfd105e4 X-MS-Exchange-CrossTenant-AuthSource: AS8P190MB1078.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Dec 2021 13:44:31.8835 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: U3B3xDq2rHsE7GuU+vPmxvlu6vgfVu7ElGAQvurLOSkVioJNF+0xPzSqyXkQSgS4qC5vgoAjC+r/PYKY1AC7aQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7P190MB0744 Archived-At: Subject: Re: [Sidrops] potential errata for RFC 8182 (RRDP) - serial 0 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2021 13:44:41 -0000 --kmfgcu5hhbalfmvx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, On 12/15, Job Snijders wrote: > Dear all, >=20 > [...] >=20 > path #1: > =3D=3D=3D=3D=3D=3D=3D=3D > Affected RRDP server implementations recognize this issue, fix the > bug (by starting to count from 1 onwards); no RFC errata; no changes > to RPs. >=20 I think this option still requires an errata to remove the word "unsigned" from the definition. An integer cannot simultaneously be "unsigned" and "positive". Cheers, Ben --kmfgcu5hhbalfmvx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEadkaB2uV5dm5UllaOkYk/rSLaGAFAmG58TgACgkQOkYk/rSL aGAewBAAh7V+buG9vBZvlx6yQveJgrBKLqH480wRbIcS0giSTrwW+CNumxgnhWrs XCy4p9G8I9TyVP9TG6MeVa7VZnA7YkbV9K3d/bvaV/qPELtkPkwDXEuoNnSt0k7J VzaEEaKcLitNfzXewzK5I2ZbDaAV/wRKWFamQ+rIPlkpHK2hUQ91TV6cby6p1UKp lykG2fBhiQb+I3gkdKU6XeODK1AImaJ8HZc/zfkH0/cPzP2e0HKUDyz9h9FKcQo8 hRJKiyMJDM4Fje5JpmTCnKkF3a9LR3Q2SzQJQeC4updrO9HgIsTQtWao0q0mfrCQ hBY7Wx11L6G0m2/QHq8ksOb2Lkt2cXnz36Mu28W6LYDqAljc57w52XfO/YHnk4MR zi+u2+JR+EwDGrNawQjSJ1SLjG1EvL76zxQ1FeeAVK6X2ZiT71CcI/zemoc0gSC8 l22IMHqkMiF08afXiG6h5/SXg7RdtLiyVIgWm0A3oSpr/pmveTcvDgLD8cXZK7wT Dchji/lB6WC2ZrB+2GALMdkrMpStghvQWuJK21zVEstRvJsbOsN2nNSjK6jKAC3y SDtbKO1iHmHMTYzKLJqR3OVI3uXRX02TuFV/8XYrNYuLb1/Za3e7Ttm3noB90XZ2 L/+EGAhL1ZfIiTF0n9OurLVFGRsP/pv+kqWMCiO6cQnfPWcdD0k= =G2O6 -----END PGP SIGNATURE----- --kmfgcu5hhbalfmvx-- From nobody Wed Dec 15 06:18:51 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B97C3A07AB for ; Wed, 15 Dec 2021 06:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl 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 bXKwg2HsFXR8 for ; Wed, 15 Dec 2021 06:18:44 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:65::8:228]) (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 6FA923A07AF for ; Wed, 15 Dec 2021 06:18:44 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 34A9251; Wed, 15 Dec 2021 14:18:41 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1639577920; bh=dYhKvVczO4s1bZ3Kgu+TT1jEgKv5WvKEg7TxurWzTxw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=ViZ8RV6ZbsLANFnoGwd7ZxBGpZEGsG2MyGeFraUYaXKwZm5DIdM1VXprkgHDf5ZlZ vvOxvkAZvfPj10GrRjzUp5kWhhvzB+vNiryWutn27uK7+LFPC1ZBuPWgyyqarR7SBM 5nFXZumSEZHPxqLAkNpIdtCL4CsR3KYtfwBTMMz+/8xp4eaVco0ZtjC11UkF2uI4Bf 5DS2exljynMtCFIiV9XdHaK4/TbCguLzrpfr62HxfsqF63XP+LXrMrU3VOilLpbyzD mZDUhG+ZvkwSu4fTZq7qYLwRWcG7iV7xit96Z5fk0jD03vSwSZ1e2xTQhRUAlzuzEX 438xWTWFzSMXw== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Tim Bruijnzeels In-Reply-To: Date: Wed, 15 Dec 2021 15:18:38 +0100 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7D6F25BF-13D7-40E8-863F-DDF6EF3560EE@nlnetlabs.nl> References: To: Job Snijders Archived-At: Subject: Re: [Sidrops] potential errata for RFC 8182 (RRDP) - serial 0 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2021 14:18:50 -0000 Hi Job, all, > On 15 Dec 2021, at 14:38, Job Snijders = wrote: >=20 > Dear all, >=20 > I noticed there are some RRDP server implementations which produce > non-confirming XML. An example of broken RRDP (redacted) content: >=20 > > > >=20 > The problem is a value of 0 (zero) for the 'serial' attribute in the > 'notification' element. According to RFC 8182 section 3.5.1.3, the = value > 0 in context of the serial is unambiguously invalid: >=20 > "The serial attribute MUST be an unbounded, unsigned positive > integer in decimal format indicating the current version of the > repository." > https://datatracker.ietf.org/doc/html/rfc8182#section-3.5.1.3 >=20 > Furthermore, the schema in Section 3.5.4 specifies serial to be a > "xsd:positiveInteger", which is described as >=20 > "The value space of xsd:positiveInteger includes the set of the > strictly positive integers (excluding zero), with no restriction of > range. Its lexical space allows any number of insignificant leading > zeros." (src: http://books.xmlschemata.org/relaxng/ch19-77279.html) >=20 > With the above in mind, Just to add to this: Section 3.3.1. Initialization has: ... o After the Snapshot File has been published, the Repository Server MUST publish a new Update Notification File that contains the new session_id, has serial number ONE, has one reference to the Snapshot File that was just published... ... > I see two paths forward: >=20 > path #1: > =3D=3D=3D=3D=3D=3D=3D=3D > Affected RRDP server implementations recognize this issue, fix the > bug (by starting to count from 1 onwards); no RFC errata; no = changes > to RPs. This has my preference. Krill has the same bug. I did not expect that starting the counting at 0 would be harmful, so I overlooked that the specification says that we should start at 1. I guess I replayed things from memory, rather than text in this case. The fix is trivial enough, and I can push one out today. But, it will require that users upgrade - which will happen eventually. If RPs can be forgiving for a while then this path has my preference. If they fall = back to rsync until serial 1 is published then that would be regrettable, but still not result in an enduring issue. > path #2: > =3D=3D=3D=3D=3D=3D=3D=3D > An errata is filed on RFC 8182; RPs update their code to take the=20= > new errata into consideration (iff the Errata is accepted); > no changes to RRDP server implementations. >=20 > In the errata I'd remove the word 'positive' from section 3.5.1.3, = and > change serial to be xsd:nonNegativeInteger > (http://books.xmlschemata.org/relaxng/ch19-77247.html) to make 0 a = legal > value. Less preferred by me at least. I think it will require at least one more change (in section 3.3.1). Also, I think the RFC is actually clear on this, but it's just easy to overlook because one may not expect that 0 is technically not allowed. And having an erratum may not help to improve readability. Kind regards, Tim >=20 > Does the group have any preferences? >=20 > Kind regards, >=20 > Job >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Dec 15 06:23:19 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0843A07C1 for ; Wed, 15 Dec 2021 06:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8SwQ6DeuUyI for ; Wed, 15 Dec 2021 06:23:12 -0800 (PST) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C987C3A07B9 for ; Wed, 15 Dec 2021 06:23:11 -0800 (PST) Received: (qmail 5315 invoked by uid 1000); 15 Dec 2021 14:23:08 -0000 Date: Wed, 15 Dec 2021 15:23:08 +0100 From: Claudio Jeker To: Job Snijders Cc: sidrops@ietf.org Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Sidrops] potential errata for RFC 8182 (RRDP) - serial 0 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2021 14:23:18 -0000 On Wed, Dec 15, 2021 at 02:38:22PM +0100, Job Snijders wrote: > Dear all, > > I noticed there are some RRDP server implementations which produce > non-confirming XML. An example of broken RRDP (redacted) content: > > > > > > The problem is a value of 0 (zero) for the 'serial' attribute in the > 'notification' element. According to RFC 8182 section 3.5.1.3, the value > 0 in context of the serial is unambiguously invalid: > > "The serial attribute MUST be an unbounded, unsigned positive > integer in decimal format indicating the current version of the > repository." > https://datatracker.ietf.org/doc/html/rfc8182#section-3.5.1.3 > > Furthermore, the schema in Section 3.5.4 specifies serial to be a > "xsd:positiveInteger", which is described as > > "The value space of xsd:positiveInteger includes the set of the > strictly positive integers (excluding zero), with no restriction of > range. Its lexical space allows any number of insignificant leading > zeros." (src: http://books.xmlschemata.org/relaxng/ch19-77279.html) > > With the above in mind, I see two paths forward: > > path #1: > ======== > Affected RRDP server implementations recognize this issue, fix the > bug (by starting to count from 1 onwards); no RFC errata; no changes > to RPs. > > path #2: > ======== > An errata is filed on RFC 8182; RPs update their code to take the > new errata into consideration (iff the Errata is accepted); > no changes to RRDP server implementations. > > In the errata I'd remove the word 'positive' from section 3.5.1.3, and > change serial to be xsd:nonNegativeInteger > (http://books.xmlschemata.org/relaxng/ch19-77247.html) to make 0 a legal > value. > > Does the group have any preferences? I prefer if the faulty RRDP software is fixed. Knowing that 0 can not happen can be used by RP software as an invalid serial number and for example ignore all deltas in that case. It is already a pain to work with those serial numbers because they are unbounded. In rpki-client they have to fit in [1..2^63 - 1] if not you get a 2nd chace via rsync. -- :wq Claudio From nobody Wed Dec 15 07:06:37 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BB03A0989 for ; Wed, 15 Dec 2021 07:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net 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 XIYyi5GAqTPl for ; Wed, 15 Dec 2021 07:06:14 -0800 (PST) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 CF5A73A090F for ; Wed, 15 Dec 2021 07:06:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Cc:Date:Subject:Mime-Version:Content-Type:Message-Id:From ; bh=CtZh5YopdVJlzkyV96jXe7hKoZCWfOf76c51a/vA/Po=; b=m7JmcnunO9xhIzSdi3bY5kor wKofwjDHr/89abmxUjuaKwl+lFdTE+uHE8vxxsR7hQ4AOeCvIjLI+ev+7AgjRZIGwYjEyhq4r8P1E VqCmj95wZy/1gM6whenWwK4qHzGZ3+fG/Ggp7L+EkgeE8UcdorOkVip9tVEPoOep1OSW4Kwnt5ES/ Lkh9ucSERoCl+2UCmyyYSFTjMrhe91vTwlH5u0MUCuu9NwmXxc2LpX+Gy9XplDInh2/p+z6IApYaH bR7fJejNqN2GbNtkViuo0jfhZA9RbKWuR8/oSPqn+E5b1AiebvbtnKzIYO1p5i4G9fBWh2e8cKAi+ bIqGLu79TQ==; Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:60686) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mxVr0-00015q-MO; Wed, 15 Dec 2021 16:06:02 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mxVr0-0000Zp-Iy; Wed, 15 Dec 2021 16:06:02 +0100 From: Ties de Kock Message-Id: <6F90B9F6-6940-4CCA-AB1B-7B35712E6D2B@ripe.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_261EB9F4-B269-4445-AB47-DB53B9952914" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Wed, 15 Dec 2021 16:06:02 +0100 In-Reply-To: <7D6F25BF-13D7-40E8-863F-DDF6EF3560EE@nlnetlabs.nl> Cc: Job Snijders , sidrops@ietf.org To: Tim Bruijnzeels References: <7D6F25BF-13D7-40E8-863F-DDF6EF3560EE@nlnetlabs.nl> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e176377dcd61d00b8387f335b81de76640 Archived-At: Subject: Re: [Sidrops] potential errata for RFC 8182 (RRDP) - serial 0 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2021 15:06:35 -0000 --Apple-Mail=_261EB9F4-B269-4445-AB47-DB53B9952914 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Tim, all, > On 15 Dec 2021, at 15:18, Tim Bruijnzeels wrote: >=20 > Hi Job, all, >=20 >> On 15 Dec 2021, at 14:38, Job Snijders = wrote: >>=20 >> Dear all, >>=20 >> I noticed there are some RRDP server implementations which produce >> non-confirming XML. An example of broken RRDP (redacted) content: >>=20 >> >> >> >>=20 >> The problem is a value of 0 (zero) for the 'serial' attribute in the >> 'notification' element. According to RFC 8182 section 3.5.1.3, the = value >> 0 in context of the serial is unambiguously invalid: >>=20 >> "The serial attribute MUST be an unbounded, unsigned positive >> integer in decimal format indicating the current version of the >> repository." >> https://datatracker.ietf.org/doc/html/rfc8182#section-3.5.1.3 >>=20 >> Furthermore, the schema in Section 3.5.4 specifies serial to be a >> "xsd:positiveInteger", which is described as >>=20 >> "The value space of xsd:positiveInteger includes the set of the >> strictly positive integers (excluding zero), with no restriction of >> range. Its lexical space allows any number of insignificant leading >> zeros." (src: http://books.xmlschemata.org/relaxng/ch19-77279.html) >>=20 >> With the above in mind, >=20 > Just to add to this: >=20 > Section 3.3.1. Initialization has: >=20 > ... > o After the Snapshot File has been published, the Repository Server > MUST publish a new Update Notification File that contains the new > session_id, has serial number ONE, has one reference to the > Snapshot File that was just published... > ... I think that is completely unambiguous but very easy to overlook. The = question of whether zero is a positive number (or a natural number) reminders me = of some university classes.. That paragraph you quoted, combined with o The serial attribute MUST be an unbounded, unsigned positive integer in decimal format indicating the current version of the repository. Makes it very clear that a compliant implementation MUST accept = arbitrary precision integers from 1..infinity. Kind regards, Ties >=20 >=20 >> I see two paths forward: >>=20 >> path #1: >> =3D=3D=3D=3D=3D=3D=3D=3D >> Affected RRDP server implementations recognize this issue, fix the >> bug (by starting to count from 1 onwards); no RFC errata; no = changes >> to RPs. >=20 > This has my preference. >=20 > Krill has the same bug. I did not expect that starting the counting > at 0 would be harmful, so I overlooked that the specification says > that we should start at 1. >=20 > I guess I replayed things from memory, rather than text in this case. >=20 > The fix is trivial enough, and I can push one out today. But, it will > require that users upgrade - which will happen eventually. If RPs can = be > forgiving for a while then this path has my preference. If they fall = back > to rsync until serial 1 is published then that would be regrettable, = but > still not result in an enduring issue. >=20 >> path #2: >> =3D=3D=3D=3D=3D=3D=3D=3D >> An errata is filed on RFC 8182; RPs update their code to take the=20= >> new errata into consideration (iff the Errata is accepted); >> no changes to RRDP server implementations. >>=20 >> In the errata I'd remove the word 'positive' from section 3.5.1.3, = and >> change serial to be xsd:nonNegativeInteger >> (http://books.xmlschemata.org/relaxng/ch19-77247.html = ) to make 0 a = legal >> value. >=20 > Less preferred by me at least. I think it will require at least one = more > change (in section 3.3.1). >=20 > Also, I think the RFC is actually clear on this, but it's just easy to > overlook because one may not expect that 0 is technically not allowed. > And having an erratum may not help to improve readability. >=20 > Kind regards, > Tim >=20 >=20 >>=20 >> Does the group have any preferences? >>=20 >> Kind regards, >>=20 >> Job >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops = --Apple-Mail=_261EB9F4-B269-4445-AB47-DB53B9952914 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Tim, all,

On 15 Dec 2021, at 15:18, Tim Bruijnzeels = <tim@nlnetlabs.nl> wrote:

Hi Job, all,

On 15 Dec 2021, at 14:38, Job = Snijders <job=3D40fastly.com@dmarc.ietf.org> wrote:

Dear all,

I = noticed there are some RRDP server implementations which produce
non-confirming XML. An example of broken RRDP (redacted) = content:

  <notification = xmlns=3D"http://www.ripe.net/rpki/rrdp" version=3D"1" = session_id=3D"1" serial=3D"0">
     <snapshot uri=3D"https://rpki/rrdp/1/0/snapshot.xml" hash=3D"redacted" = />
  </notification>

The problem is a value of 0 (zero) for the 'serial' attribute = in the
'notification' element. According to RFC 8182 = section 3.5.1.3, the value
0 in context of the serial is = unambiguously invalid:

  "The = serial attribute MUST be an unbounded, unsigned positive
  integer in decimal format indicating the current = version of the
  repository."
  https://datatracker.ietf.org/doc/html/rfc8182#section-3.5.1.3

Furthermore, the schema in Section 3.5.4 = specifies serial to be a
"xsd:positiveInteger", which is = described as

  "The value space = of xsd:positiveInteger includes the set of the
  strictly positive integers (excluding zero), with = no restriction of
  range. Its lexical space = allows any number of insignificant leading
  zeros." (src: http://books.xmlschemata.org/relaxng/ch19-77279.html)

With the above in mind,

Just to add to this:

Section 3.3.1. Initialization has:

...
  o  After the = Snapshot File has been published, the Repository Server
     MUST= publish a new Update Notification File that contains the new
     session_id, has serial number = ONE, has one reference to the
     Snapshot File that was just = published...
...

I think that = is completely unambiguous but very easy to overlook. The = question
of whether zero is a positive number (or a natural = number) reminders me of some
university = classes..

That paragraph you quoted, = combined with

   o =  The serial attribute MUST be an unbounded, unsigned = positive
      integer in decimal format = indicating the current version of the
      = repository.

Makes it very clear that = a compliant implementation MUST accept arbitrary
precision = integers from 1..infinity.

Kind = regards,
Ties



I see two paths forward:

path #1:
=3D=3D=3D=3D=3D=3D=3D=3D<= br class=3D"">  Affected RRDP server implementations recognize = this issue, fix the
  bug (by starting to count = from 1 onwards); no RFC errata; no changes
  to = RPs.

This has my preference.

Krill has the same bug. I did not expect that starting the = counting
at 0 would be = harmful, so I overlooked that the specification says
that we should start at = 1.

I guess I = replayed things from memory, rather than text in this case.

The fix is trivial enough, and I = can push one out today. But, it will
require that users upgrade - which will happen eventually. If = RPs can be
forgiving for = a while then this path has my preference. If they fall back
to rsync until serial 1 is = published then that would be regrettable, but
still not result in an enduring = issue.

path = #2:
=3D=3D=3D=3D=3D=3D=3D=3D
  An = errata is filed on RFC 8182; RPs update their code to take the 
  new errata into consideration (iff the Errata is = accepted);
  no changes to RRDP server = implementations.

  In the errata = I'd remove the word 'positive' from section 3.5.1.3, and
  change serial to be xsd:nonNegativeInteger
  (http://books.xmlschemata.org/relaxng/ch19-77247.html) to = make 0 a legal
  value.

Less preferred by me at least. I think it will require at = least one more
change (in section 3.3.1).

Also, I think the RFC is actually clear on this, but it's = just easy to
overlook = because one may not expect that 0 is technically not allowed.
And having an erratum may not = help to improve readability.

Kind regards,
Tim



Does the group have = any preferences?

Kind regards,

Job

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

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

= --Apple-Mail=_261EB9F4-B269-4445-AB47-DB53B9952914-- From nobody Wed Dec 15 07:24:33 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894583A0945 for ; Wed, 15 Dec 2021 07:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRp77I_R40Um for ; Wed, 15 Dec 2021 07:24:22 -0800 (PST) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 2AC9E3A0938 for ; Wed, 15 Dec 2021 07:24:22 -0800 (PST) Received: by mail-ed1-x530.google.com with SMTP id x15so77059202edv.1 for ; Wed, 15 Dec 2021 07:24:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Do2ipzcTouBemKe7pTVPoRwHvPy9lzgNgpav9Hrmbn4=; b=ofPBmUV60EL3BmmIpypB+Pj6APkU0vwcx0bjIOLx8xBIDK1VnbwzULdNMYIaIsLZtZ HwcjXJ8ZBMVMp8kNKMOSEHLhegV/vsNAfdRvKfPsUw+njgwJ+c1C97cbFpdsMZwik3gx eS5eKpJaWxC83wdA+QK5iyOcFW/NUjMSOS4IU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Do2ipzcTouBemKe7pTVPoRwHvPy9lzgNgpav9Hrmbn4=; b=TnY51/zt0wKsr9i0CEmet213Lt7+attPMbqg/xJaK6vTPiMaf+3iuSmVgFAl9uqpb2 cGGpiiEz0rDA7KfHZSrmHbQp3J3yLCXijjOHpgf4mZ6aoSJGw24vc5IkYfbSZ01BDnvB W0FqDagXz9TO0wLpKTEjuUy2/crbZMq9A4/WyxBjkF4ThrLy8CL8IUxhABZwCi1T1hCc Mt9wkgqbxrrbTuaZFlrnF8PRd/qmG6SjdlS9jrnGmKy58fG02+TnZBOqE/S2cXfXWOxH 3h9OHRK+TKEigK00eqY2GEWzkGaMqm+WozHVXtMLGsFjSYwEOQCEHA5hHdL29Z5MA1vW aMIg== X-Gm-Message-State: AOAM5308y/knhcFq75i7gIpC3udE44/b2G8PHgUe7lYuHllkifBtJtJ3 QAmtohdPKcLVK8jocq/9lz0XaO8Ps9XBwJYYMYEYcP6e3uojolv3iRHVLA5q2lNHcIH9eKB5V7x yjHa02UOSUR4tj84DiQSdgkEmyn8uz3QMan5AmIaX7HYU7/Z3+fdDOj0= X-Google-Smtp-Source: ABdhPJzhBmbSTXQQcx3TUvtKO+Br3iTvXzRny5W2oDHczmJWsS3c2jpqlLeFq2scjpx0aOo3JIYoZg== X-Received: by 2002:a17:906:c155:: with SMTP id dp21mr11231933ejc.450.1639581852028; Wed, 15 Dec 2021 07:24:12 -0800 (PST) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id j11sm1144866edv.0.2021.12.15.07.24.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Dec 2021 07:24:11 -0800 (PST) Date: Wed, 15 Dec 2021 16:24:10 +0100 From: Job Snijders To: sidrops@ietf.org Message-ID: References: <7D6F25BF-13D7-40E8-863F-DDF6EF3560EE@nlnetlabs.nl> <6F90B9F6-6940-4CCA-AB1B-7B35712E6D2B@ripe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6F90B9F6-6940-4CCA-AB1B-7B35712E6D2B@ripe.net> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] potential errata for RFC 8182 (RRDP) - serial 0 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2021 15:24:28 -0000 On Wed, Dec 15, 2021 at 04:06:02PM +0100, Ties de Kock wrote: > Makes it very clear that a compliant implementation MUST accept > arbitrary precision integers from 1..infinity. Your honor, I object! As I understand the specification of "xsd:positiveInteger", the presence of a decimal point (even when followed only by insignificant zeros) is forbidden. According to W3 docs: positiveInteger is derived from nonNegativeInteger, which is derived from integer, which is derived from decimal - by fixing the value of fractionDigits to be 0. Kind regards, Job From nobody Thu Dec 16 05:57:11 2021 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5593A0EC1; Thu, 16 Dec 2021 05:56:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <163966301590.9602.4950966336948551478@ietfa.amsl.com> Date: Thu, 16 Dec 2021 05:56:55 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-08.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 13:56:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : Manifests for the Resource Public Key Infrastructure (RPKI) Authors : Rob Austein Geoff Huston Stephen Kent Matt Lepinski Filename : draft-ietf-sidrops-6486bis-08.txt Pages : 18 Date : 2021-12-16 Abstract: This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-6486bis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-6486bis-08 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Thu Dec 16 12:13:41 2021 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8F33A11F7; Thu, 16 Dec 2021 12:13:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-sidrops-6486bis@ietf.org, morrowc@ops-netman.net, sidrops-chairs@ietf.org, sidrops@ietf.org, warren@kumari.net Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <163968561528.5705.3344262878453726327@ietfa.amsl.com> Date: Thu, 16 Dec 2021 12:13:35 -0800 Archived-At: Subject: [Sidrops] Last Call: (Manifests for the Resource Public Key Infrastructure (RPKI)) to Proposed Standard X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 20:13:36 -0000 The IESG has received a request from the SIDR Operations WG (sidrops) to consider the following document: - 'Manifests for the Resource Public Key Infrastructure (RPKI)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-12-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc8488: RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation (Informational - Internet Engineering Task Force (IETF)) From nobody Thu Dec 16 19:55:48 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF343A12D1; Thu, 16 Dec 2021 19:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dT7uw-LdmzKN; Thu, 16 Dec 2021 19:55:37 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 DB1163A12E7; Thu, 16 Dec 2021 19:55:35 -0800 (PST) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1BH3tOoO024754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Dec 2021 22:55:30 -0500 Date: Thu, 16 Dec 2021 19:55:23 -0800 From: Benjamin Kaduk To: last-call@ietf.org Cc: draft-ietf-sidrops-6486bis@ietf.org, morrowc@ops-netman.net, sidrops-chairs@ietf.org, sidrops@ietf.org, warren@kumari.net Message-ID: <20211217035523.GF11486@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <163968561528.5705.3344262878453726327@ietfa.amsl.com> Archived-At: Subject: Re: [Sidrops] Last Call: (Manifests for the Resource Public Key Infrastructure (RPKI)) to Proposed Standard X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2021 03:55:40 -0000 This draft is marked with an "Updates:" relationship to RFC 6486 both in the document header and in the shepherd writeup. But the actual contents of the document contain substantial portions of text that are identical to RFC 6486, as would be expected from a "bis" document (per the draft name) that would replace entirely the original RFC; that relationship is typically indicated by an "Obsoletes:" relationship rather than "Updates:". Also, I would recommend including a "changes since RFC 6486" section that motivates why the document is being updated or replaced. -Ben From nobody Thu Dec 16 22:13:32 2021 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE3F3A15A9; Thu, 16 Dec 2021 22:13:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <163972158278.17164.7845548419791447965@ietfa.amsl.com> Date: Thu, 16 Dec 2021 22:13:02 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-08.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2021 06:13:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : RPKI Signed Object for Trust Anchor Key Authors : Carlos Martinez George G. Michaelson Tom Harrison Tim Bruijnzeels Rob Austein Filename : draft-ietf-sidrops-signed-tal-08.txt Pages : 18 Date : 2021-12-16 Abstract: A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in the Resource Public Key Infrastructure (RPKI) to locate and validate a Trust Anchor (TA) Certification Authority (CA) certificate used in RPKI validation. This document defines an RPKI signed object for a Trust Anchor Key (TAK), that can be used by a TA to signal the location(s) of the accompanying CA certificate for the current key to RPs, as well as the successor key and the location(s) of its CA certificate. This object helps to support both planned and unplanned key rolls without impacting RPKI validation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-signed-tal/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-sidrops-signed-tal-08.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-signed-tal-08 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Fri Dec 17 13:08:18 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846DD3A07AE; Fri, 17 Dec 2021 13:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogWTnylg1p2f; Fri, 17 Dec 2021 13:08:09 -0800 (PST) Received: from relay.ops-netman.net (relay.ops-netman.net [192.110.255.59]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B6B3A07AD; Fri, 17 Dec 2021 13:08:07 -0800 (PST) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by relay.ops-netman.net (Postfix) with ESMTPS id 6BC393C2130; Fri, 17 Dec 2021 21:08:06 +0000 (UTC) Received: from mailserver.ops-netman.net.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 3CC94221; Fri, 17 Dec 2021 21:08:05 +0000 (UTC) Date: Fri, 17 Dec 2021 21:08:04 +0000 Message-ID: <87tuf7gcsr.wl-morrowc@ops-netman.net> From: Chris Morrow To: Benjamin Kaduk Cc: last-call@ietf.org, draft-ietf-sidrops-6486bis@ietf.org, morrowc@ops-netman.net, sidrops-chairs@ietf.org, sidrops@ietf.org, warren@kumari.net In-Reply-To: <20211217035523.GF11486@mit.edu> References: <163968561528.5705.3344262878453726327@ietfa.amsl.com> <20211217035523.GF11486@mit.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Last Call: (Manifests for the Resource Public Key Infrastructure (RPKI)) to Proposed Standard X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2021 21:08:12 -0000 ( Clarifying question(s) ) On Fri, 17 Dec 2021 03:55:23 +0000, Benjamin Kaduk wrote: > > This draft is marked with an "Updates:" relationship to RFC 6486 both in > the document header and in the shepherd writeup. But the actual contents > of the document contain substantial portions of text that are identical to > RFC 6486, as would be expected from a "bis" document (per the draft name) > that would replace entirely the original RFC; that relationship is > typically indicated by an "Obsoletes:" relationship rather than "Updates:". It sounds like you are saying; "Hey, you included a ton of 'copy/paste' text in this -bis, stylistically/historically people only put in the -bis the CHANGED text, and whatever is required to link it into the original" I have no idea about this... but does it matter? I mean, won't the -bis just be the original with the 'new' content stitched into it properly? > Also, I would recommend including a "changes since RFC 6486" section that > motivates why the document is being updated or replaced. Ok, this doesn't seem bad :) I think most of the reasoning is stuck in mailing-list discussions like: "Hey, we did what you said, lots of sadness... how about we shave the yak a little differently so ops / theory / practice align better and leave us less balded yaks?" (and lost packets) I think we need to either re-engage the author(s) or pawn this off on the sekret-pen-holder, provided we can provide some linkage text. thanks! -chris From nobody Fri Dec 17 13:11:26 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5CA3A07DF for ; Fri, 17 Dec 2021 13:11:24 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRCx74SaR8sO for ; Fri, 17 Dec 2021 13:11:21 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [IPv6:2001:418:8006::30]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7B03A07D4 for ; Fri, 17 Dec 2021 13:11:21 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-100-88-186.hsd1.ma.comcast.net [73.100.88.186]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id 0D9174E621 for ; Fri, 17 Dec 2021 21:11:17 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 0141D2EA00A5 for ; Fri, 17 Dec 2021 16:11:15 -0500 (EST) Date: Fri, 17 Dec 2021 16:11:15 -0500 From: Rob Austein To: sidrops@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Message-Id: <20211217211116.0141D2EA00A5@minas-ithil.hactrn.net> Archived-At: Subject: Re: [Sidrops] potential errata for RFC 8182 (RRDP) - serial 0 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2021 21:11:25 -0000 Once upon a time the RRDP RelaxNG schema said serial = xsd:nonNegativeInteger Somewhere along the road to publication as RFC 8182 that became serial = xsd:positiveInteger No recollection of why that change was thought necessary or useful. Always fun when a confirming implementation has the specification changed out from underneath it. From nobody Fri Dec 17 13:54:28 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1963A090B for ; Fri, 17 Dec 2021 13:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTBQLBxj3odx for ; Fri, 17 Dec 2021 13:54:19 -0800 (PST) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 6DC203A08FA for ; Fri, 17 Dec 2021 13:54:19 -0800 (PST) Received: by mail-ed1-x531.google.com with SMTP id z7so12861595edc.11 for ; Fri, 17 Dec 2021 13:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=OSZwu/51HNwwEgFj1jlf5fyooEnYANiTFpaCGRoPPGc=; b=t4CcBFoJFp5cDxrscxttkfSq2k4IL7Wq+5Mmw9mcBK3lcXFK6N33jCqqbUQnR5WpyP oM5UJFroCuRriD50hKRmuWxYXTaiCrUDw1LFeltsdSLAke2nlOmUVT8PapFxn++de4Fo mhUH73G7dsd768mcrnu0nqYjamOgygzVYXKxs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=OSZwu/51HNwwEgFj1jlf5fyooEnYANiTFpaCGRoPPGc=; b=tyt57ljxzfMNhmzUWRp2ImM+iFnqPYirdtVO67C61nuUAHLEiYguYQnGcwDGI0W1rK vKIr2+1qSpTzUjDTyvsj9gjMh3GNcNcf/TFqA3zs3yG0bh+VvZPU8UbyJgoxBD5HKeG6 1oN/pmLZXRIr0wgG9LiU6soDzpDQ2RpaxLAwI7vOyuFOVIzJPWL0UCLOq41938PbwWwU K9tb/VOGhWTgrzOKuq69010a8tf9kxR9RieEVXmnJel7sfuVWa7O5c/NrVuzpchDfT1L Lcu5HozLMGP/t3/BkY/g26Q6VRKuKAuf24MzuQtcZHHKxUJkRt8UtNPm9yvVlx57ZS38 fEJg== X-Gm-Message-State: AOAM532unEZYHtAFYgLAVXpYv8u9gNh8/N4I1leVozgnamwLBKhowVv5 lMFlbSUyxAJCpOHWA+AB7xI2ww== X-Google-Smtp-Source: ABdhPJxZ78VVQm+sKny7nLlec2fAfzph22xOzAaHmNkyUxReu8XioXBNoRJbXNt+mxdjQkVmo5Kfkg== X-Received: by 2002:a17:907:2d9f:: with SMTP id gt31mr3973119ejc.353.1639778056811; Fri, 17 Dec 2021 13:54:16 -0800 (PST) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id o12sm440791edz.71.2021.12.17.13.54.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Dec 2021 13:54:16 -0800 (PST) Date: Fri, 17 Dec 2021 22:54:14 +0100 From: Job Snijders To: Chris Morrow Cc: Benjamin Kaduk , sidrops-chairs@ietf.org, sidrops@ietf.org, last-call@ietf.org, warren@kumari.net, draft-ietf-sidrops-6486bis@ietf.org Message-ID: References: <163968561528.5705.3344262878453726327@ietfa.amsl.com> <20211217035523.GF11486@mit.edu> <87tuf7gcsr.wl-morrowc@ops-netman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87tuf7gcsr.wl-morrowc@ops-netman.net> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] [Last-Call] Last Call: (Manifests for the Resource Public Key Infrastructure (RPKI)) to Proposed Standard X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2021 21:54:24 -0000 Hi, On Fri, Dec 17, 2021 at 09:08:04PM +0000, Chris Morrow wrote: > ( Clarifying question(s) ) > > On Fri, 17 Dec 2021 03:55:23 +0000, > Benjamin Kaduk wrote: > > > > This draft is marked with an "Updates:" relationship to RFC 6486 both in > > the document header and in the shepherd writeup. But the actual contents > > of the document contain substantial portions of text that are identical to > > RFC 6486, as would be expected from a "bis" document (per the draft name) > > that would replace entirely the original RFC; that relationship is > > typically indicated by an "Obsoletes:" relationship rather than "Updates:". > > It sounds like you are saying; > > "Hey, you included a ton of 'copy/paste' text in this -bis, > stylistically/historically people only put in the -bis the CHANGED > text, and whatever is required to link it into the original" > > I have no idea about this... but does it matter? I mean, won't the > -bis just be the original with the 'new' content stitched into it > properly? I understand Benjamin's message to more be a matter of publication procedure: draft-ietf-sidrops-6486bis is a complete specification, to me it makes sense to change the XML header to something along the lines of: > > Also, I would recommend including a "changes since RFC 6486" section > > that motivates why the document is being updated or replaced. > > Ok, this doesn't seem bad :) I think most of the reasoning is stuck in > mailing-list discussions like: "Hey, we did what you said, lots of > sadness... how about we shave the yak a little differently so ops / > theory / practice align better and leave us less balded yaks?" (and > lost packets) > > I think we need to either re-engage the author(s) or pawn this off > on the sekret-pen-holder, provided we can provide some linkage text. If 6486 is to be obsoleted, Benjamin's suggestion to add a section "chanes since" makes sense and should be added. I can take a stab at some draft text if there are no other volunteers. Chris - can you check with authors to avoid duplicate work? Kind regards, Job From nobody Fri Dec 17 13:55:06 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4273A0912; Fri, 17 Dec 2021 13:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBiycwGOD0wT; Fri, 17 Dec 2021 13:54:50 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 E94953A090F; Fri, 17 Dec 2021 13:54:49 -0800 (PST) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1BHLsge4018162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Dec 2021 16:54:47 -0500 Date: Fri, 17 Dec 2021 13:54:42 -0800 From: Benjamin Kaduk To: Chris Morrow Cc: last-call@ietf.org, draft-ietf-sidrops-6486bis@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, warren@kumari.net Message-ID: <20211217215442.GH11486@mit.edu> References: <163968561528.5705.3344262878453726327@ietfa.amsl.com> <20211217035523.GF11486@mit.edu> <87tuf7gcsr.wl-morrowc@ops-netman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87tuf7gcsr.wl-morrowc@ops-netman.net> Archived-At: Subject: Re: [Sidrops] Last Call: (Manifests for the Resource Public Key Infrastructure (RPKI)) to Proposed Standard X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2021 21:55:02 -0000 On Fri, Dec 17, 2021 at 09:08:04PM +0000, Chris Morrow wrote: > ( Clarifying question(s) ) > > On Fri, 17 Dec 2021 03:55:23 +0000, > Benjamin Kaduk wrote: > > > > This draft is marked with an "Updates:" relationship to RFC 6486 both in > > the document header and in the shepherd writeup. But the actual contents > > of the document contain substantial portions of text that are identical to > > RFC 6486, as would be expected from a "bis" document (per the draft name) > > that would replace entirely the original RFC; that relationship is > > typically indicated by an "Obsoletes:" relationship rather than "Updates:". > > It sounds like you are saying; > > "Hey, you included a ton of 'copy/paste' text in this -bis, > stylistically/historically people only put in the -bis the CHANGED > text, and whatever is required to link it into the original" > > I have no idea about this... but does it matter? I mean, won't the > -bis just be the original with the 'new' content stitched into it > properly? It sounds like my point got muddled (perhaps unsurprising, as I was writing it in a hurry...) Basically, when I see a "bis" document, I expect that it's going to be a "complete replacement" or "totally new version" of the original, with some changes based on experience gained since the original. Sometimes it will also be progressing on the maturity level front as well (experimental->Proposed Standard, or Proposed Standard->Internet Standard), though not always. In this case I'm used to seeing basically all the original content remain in the "bis" version (except for things intentionally being changed), perhaps modulo IANA considerations that create new registries. That type of document is typically also going to be marked as obsoleting the original, since you're expected to just read the new one and the original would only be of historical interest. The "updates" relationship (while admittedly much less well defined than the "obsoletes" one, see discussion around draft-kuehlewind-update-tag), is intrinsically of the form "the original stays around and the new document is just adding stuff or making changes". In that case, the expectation is that someone will read both documents, and so the new document just describes the changes being made, and doesn't repeat much text from the original. I would summarize my point here as being "I think this document should have an 'obsoletes' relationship to 6486, not an 'updates' one". (I'm happy to be proven wrong, as I didn't actually read the contents in much detail.) > > Also, I would recommend including a "changes since RFC 6486" section that > > motivates why the document is being updated or replaced. > > Ok, this doesn't seem bad :) I think most of the reasoning is stuck in > mailing-list discussions like: "Hey, we did what you said, lots of > sadness... how about we shave the yak a little differently so ops / > theory / practice align better and leave us less balded yaks?" (and > lost packets) An excellent reason to do a "bis" document, then! :) > I think we need to either re-engage the author(s) or pawn this off > on the sekret-pen-holder, provided we can provide some linkage text. The most generic/boilerplate text one might see would be along the lines of "the specification was updated in light of deployment experience to avoid problematic cases and streamline implementation". Thanks, Ben From nobody Fri Dec 17 14:06:26 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9783A0902 for ; Fri, 17 Dec 2021 14:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net 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 dG2qkZ3OiYCV for ; Fri, 17 Dec 2021 14:06:19 -0800 (PST) Received: from sonic304-22.consmr.mail.ne1.yahoo.com (sonic304-22.consmr.mail.ne1.yahoo.com [66.163.191.148]) (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 24AA63A0926 for ; Fri, 17 Dec 2021 14:06:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1639778778; bh=Ymqu+epLdygUCs0NPY8oZ9x+tH5EEktb9v2fTdo0INg=; h=Date:Subject:To:References:Cc:From:In-Reply-To:From:Subject:Reply-To; b=HVP+S9fR457xq2Z7vd5sJ2dISUkinlgWcAB6RLVI/4I8PSbw5MqqyiXzPYRO1RqoIWnRoAiWAiTPx+ucsqI10uutj1wBOLiLXqrAKPrVfM9BNVVzzN17HNQG5PW46Ujhp/AoZ26Gduo7GC6+3obKQi/VEoRzREW82BrYhTlqqaEYjYF7GLIryl7jFxag7/4V2VNmJYC91oVH/G9kEP8mxRtYD4qCiQfsiD6iIGOcWDlXPbZhMiB3zC38Rt6mxyBOfyeNsQuDD/vq3O+jZojXf01iJsJB/lH4P8Vqs5ngFoUeMBbO+pwvCeLN+XmPzo0pmMkm6DQnNTr5MBtpwl8CHA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639778778; bh=iUIf+HR5tKpM9gawz1KvjL6kLn9mn4uJhJd9Qbibb3X=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=soZCIRMY3xTQx/IkxgHPzfCBUNEdsi53Ymh75ieqHcvuByyILuYhtuE7mmT9ihwLEJov+A6Iu+M+RFcUbdHld/C6v3bh5gIQyMZ+FjDaJAZW9xjPGmFqu9WDhDKAd+1PwzuNhxHkRmSMF307r/Uy9eTaebsM2cUMXApS59J/j+kXBqXBjnPV2UreaLsvWAQdAyY58LTOZC5d6geGHPIXNrK7NBDIoOfKxF/+l+Gzu2IIbtFKPPfdT0WZsxKhzIqx/3i3bxX8sF+MYLPmpEa2O0/JhR4nHeAUetVKBdA1by5uX5toKqjwboM8mYEjZeXtZE9AE6Us/jDK4eu9A7fSPw== X-YMail-OSG: 0UW5o_8VM1ml3uiFwJPUfPzIoYOc7aZ1TcChbVBoNRs_IOjyi_7gxEPLFy1CVvo l28Oc2hMUt1W5tXs.hpIk6.gRPJJTS38sJC3n8cJkwAliMuQ.L36vwldSK.GCYnMsZMwRJRah7qS Pd6MgQWQy8q6Ic7iOLdtgSG.yi3CrF8bYX7NGZK.2SDUelo4CScytQSFHKa4eep9GXR1FZ3VqV.. G44DHuC8ytk4vCzXkIj5KhMhcxIppLRsVMCErtaihiRglBB9e9ZbeFb33SRyCd8SXJR84Je_Ne_u MevsY66fXn0rYSydeWg3CMRWWZabKUb7s6v7Z3zl4hQgF2789XOR446uZg7ZpsUrOV7s3maacse0 ZghWhMBIVeae4X2Oy47HvWofs6ZKkY.m9XmZctpIKebJCg82OMCwwErofJUOu4bICqYuTlhV9ZpA uf_PFwlc3tXiFj3sq7v6wELzlYePuIN5HAm1veSiPU5qfFC_3oHz3xmvN80lLgs24ZwsH.ARtECF Xc5a1zSX1s75USvd1CKTFpJGhXvhV2FrN1wutQN4XHPTkLgHggN9u2gZHRNvLtHm1KGeHQyOGOMr WllDYY0SymTBx2DZcZTUalUUfpJ7GRmVLpef.L8ba7PO3DPEWkLjLd2ouHk3k4UkBL9Sozt1rqGe lIQiODBgpke_gUxzkKPC3P2CLusqcf1EEt2V8zwD5tCQpB95WblFkmoffXr.ja9LT6Rgw7S4C7CL 5xY5Tym3Fk4Cwuwd9tADxjbY6C3Y6jr3ibhyIJlx_1pxcAfGhdhRf1_Lk0HDWtK9eOUaK3CIYoZq 1.qeCbEYpf9s5m4MsFYv7K7aNYpYXs0NaR2aDCpUq5ZbQ36lrIaQT5Kk9LDm0tKPZOHydCrQZDle XB3n3n_ErEE9gmEOvNmrSW.1.27FZe_5cQ6gdhoBXQn5jTj6KWEBPzEPnc_rI5RBi4DCSnHHcNpB TnsTw7hlLFC4BG.obOjN3u.zIYl1oQfmBNE3vIO_05ew8X3_o9QfLIFXh9IjfSqQ7W5AKCG1gRQU kYuxUk.5LZrfYu7NC2FoxGyNbP0y..qBOhoucy.VWfURXjAdrywOuyeLdbLThy.5o2SMjyp.9_kT QL69kEIe8YRg9PMYOvsuXqmKTmIP6aMOjdDKIeJdUfXLIinQNL7WBK.MQKX4VSLyQqi0Rw6y0mzo ruT6hyWccPOY5YsXblQ_to9o3QxpKtzol.Bdrn5X0AzG2sRnkbqhX4svHGICKGxTPxWge61icsV7 gVFJv7OoGkfazDuaqGNVoPbyvtu4jgZhdZcILjf0QPTgVjcTMHb_vD9jS2j7ecQjKAvVyl_IQSuW qwxEJFzze6wYoxp2Om4SayqRIBew5IkH08NyMx9jtrDvbjPm3RA5aicK3qkomUA9d_DpmYqUetef LE8agH62RFusYCPShEdAOWQur1liVB7tnUkYDO8aj8DaV1yTEF85CQLdxXGn7DkhVesqakpxsHGX c6AeS2q00JgSvN3WMbUca1jfCHVn9SJ77jUZyrpwDwckgIjIuHvyz2liiKgom5r91dJLsyMM2iM7 32QtasY8WTJEymnqSyi0YgfjWZ1SpU36SKltAnCGeY48g8H2SWIFMRqG4yVkoVVIOIIuTI7pYoTG JeG0OXqQU3h9b86JJMevxxj5Ol6V0Rvd0vllQjzwGJV7QQLB5ZcBNM.kX2gfjY_IXm_Eg.3Tv2bS q36MhCXXoE8L0IcOH5c7OBnZnb0q8RbBmdaoByQOXolQ.buf392zTMT9FwrvBCR.tIIro3G4lyKM BJplOuxCXuJN.ugwdJ_c9rVYK0dRwxXI58uEtbSqrg27qnYCEUu4zJ5OtBAKXxqbeE8IW5Vf57Tb hmPtZJhsvjS7fN9DmZEkyC8flZ44nynKwhZTIEDQuPMHtQmt1kZYCGIkIf7MdzQn0pY7eLo0YHVA E5au5Udyhnp3ZbGuZy9S2tzQE.YGwVeI9kqy48jILubHKwNr0WM8_LHdsd5P6v542di4gjeR5ByB yWmR4wwlTCI9ANwLX_8zhH9xHoFak2wKAkl0LO8RtWMrNVeFXtsyfDrvoyn4Uck0.6CeeYryPkpW nUvfCDRTlOGECgZfbNhafgK1sOhV0ez6jOSBPIenbIY0rPj9UGvINNpTsZtcuIdmsuZHfmwa1la4 Mk14ZRBCrUbPpQsnAXq7P3cR5MwuMyA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ne1.yahoo.com with HTTP; Fri, 17 Dec 2021 22:06:18 +0000 Received: by kubenode520.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 04d79121141a0d36f9259962cb77263a; Fri, 17 Dec 2021 22:06:13 +0000 (UTC) Message-ID: <6ea123ca-8fe3-bbf8-8cbe-2f46db72907b@verizon.net> Date: Fri, 17 Dec 2021 17:06:12 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Benjamin Kaduk References: <163968561528.5705.3344262878453726327@ietfa.amsl.com> <20211217035523.GF11486@mit.edu> <87tuf7gcsr.wl-morrowc@ops-netman.net> <20211217215442.GH11486@mit.edu> Cc: "sidrops@ietf.org" , Job Snijders From: Stephen Kent In-Reply-To: <20211217215442.GH11486@mit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.19498 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Archived-At: Subject: Re: [Sidrops] Last Call: (Manifests for the Resource Public Key Infrastructure (RPKI)) to Proposed Standard X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2021 22:06:24 -0000 Benjamin, I agree with your reasoning. I believe this should be labelled as "Obsoletes" vs. "Updates". I also agree that we should have a list of the differences from 6486, which probably can be generated via a diff plus some editing. If Job wants to take on that task, fine with me! Steve From nobody Tue Dec 21 07:02:44 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5ADB3A0DC9 for ; Tue, 21 Dec 2021 07:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 hmQLU-zZaIaa for ; Tue, 21 Dec 2021 07:02:37 -0800 (PST) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl0gcc02on2070d.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d05::70d]) (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 249053A0DD7 for ; Tue, 21 Dec 2021 07:02:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DWl1XJ7GAWZR2ypmgxF2AyAzHI2lUkANDupNko455jHvXWQjOtCLvhl0/U+HYhV8l+biia2/MHr6DzfDf1SEsTEtfqekYxUvVlwb78VFQXHdbJgfKt87ruxrPcGN9srr5bQS7vlaBFmLRGS4Q1b/Z/9GtXfFUL9ZEPBBPvoPuIzG4Y1UwPygX0XP/BPF/IlY67usPtkExSwujFAs1aZTsOxRuQ5sKLpVXpweSQxbRa5QwLuT/m9fFGhx9GRN/TxmLf4eTGv9mXFSCieAOi3h3yz2/jZNi7Bo4NrsQ0kssjIotoSTn823IuQH99y3p86iHoTT4UP9+NOT4GEy3lZzBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ebiskAdcIF1MC84po5HKdfnopIHLAFJ2Y/H5YP1ry+A=; b=dF6HZuGXFdNg6CbyEaGb3BPzuhjiqlTlgR0MoQiWcH4+Gt4ZspwDrj01NXvr8OwpjYV/7ohHokPb5LobYa1Htdd/yMcTXU9+RaVgxw+J6jIIhkE1TUKozReJukInpoMCCZECIAVnYTzCPG06yy5ZpA/oxoepLu8XsZk2K+K1nyPbPrfn9oIJewNpYIZKA1mMWhelKOijRFtrGTB8EM7GHn8KU+gaiPTrzQjbW2yNpuhLCo0PkXVeWyLOe9Nfg29T+qp1YlGv6uBz6GyO4j30fxpd+STC6e2RBRkAldMlpkp5bjnG3OZCKxwv0/Dkl712wBu0tu5rilKADCgKCq93xw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ebiskAdcIF1MC84po5HKdfnopIHLAFJ2Y/H5YP1ry+A=; b=llmdwOvLJRsUR5nKTEVaIgQeBroECv+pi3X7g7LXlEoCvMPbg0NvQT8HMtM3GRHZcSZhVskCab5QEm3IY9aqO7nHvtCnoK/LyTWiAfXTv8AQxpWSrYeAi12SXSe1aeEpX74sedP8iv5KCyKmPV2+2iGV/4zZFs7OYIQvusKVNfg= Received: from SA1PR09MB8142.namprd09.prod.outlook.com (2603:10b6:806:171::8) by SA1PR09MB7438.namprd09.prod.outlook.com (2603:10b6:806:17a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4801.15; Tue, 21 Dec 2021 15:02:31 +0000 Received: from SA1PR09MB8142.namprd09.prod.outlook.com ([fe80::717a:2702:70fb:6225]) by SA1PR09MB8142.namprd09.prod.outlook.com ([fe80::717a:2702:70fb:6225%4]) with mapi id 15.20.4801.020; Tue, 21 Dec 2021 15:02:30 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "sidrops@ietf.org" Thread-Topic: new ASPA-based AS path verification algorithms implemented in NIST BGP-SRx Thread-Index: Adf2AEh2j2cZJJpeRBaB0tOWBPfkHAAeARpQAAA+T6A= Date: Tue, 21 Dec 2021 15:02:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nist.gov; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 513118d2-1166-4dea-a8d0-08d9c492e95f x-ms-traffictypediagnostic: SA1PR09MB7438:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4714; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pBVDiNzNKMsA1bokp6z1w6LhN4Hj7VOASURjZplo9p0mu/5DbcOqvMHGoYfKfKbuAcsnxFfr+v4UQ9vvwNWj/u4TAZwv2o2ow1+eBUHlkHiU/4vxPP81nzm+x3bBk+E2Au2gwEzWhqvLeGQCq5rXLwAcnxbUOOIlOUUrITHSLFnmlwnJJeruosI2ARzSl6n3VSq9cnMqrOp/0FPzEx0nGkGxWs3x7Rm2zPl5oIOXpBN17DCP1QICa7ml+8wkMUFaeRXGArD3Jr46j2c0ywRC9jNdR6trfnYj/mXdyx3wDyVOiZEFtTUKLeFxZ9SnwiO+Lz6BU8XVZgZwLQD4/Typo5RkmIC4SiTSu6+jM8LNTURtw1d8YuET3AGQiT3mbEBiUYb2sk6aI/zVOKm5GTFGi2K9g6mpO0q1kg0r5Y/9TcRal4Y3xOKsAUs58bR8eBzd9m3tWbdO3ic6ImHtd/80WEA6PjDA5QSXm4FPnriVw+2rnfJ8GW56LCa84ufdtigMLWflVLU6U+uUtEvnYNrv6nynbLQreyEABko0BUBRMWiKzHq8LXARxmRjcwQ2O5A4LEZiIQtdiyZbBvOFtq9UZ9kNbYlLhJuOJa21Nyc/7K5JBV8gIEdXiXkPvOFwcseNjK1qFa3c19U9VVqeq7I6KCkk76EpRTdpFEIxnqsupYh6w9AWRMtDpkBemhmGTpfyrK+ULeKrud7d1fg0sWefIwIRsDypGmraQwKa8FQnZs5GvyOxhW9Y3nIkc/hlav204/dt8eC+aJ7bU7GprOpzTt/iCMOCi4F+38vdtrJFKIg= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA1PR09MB8142.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(6916009)(186003)(86362001)(71200400001)(55016003)(38100700002)(82960400001)(7696005)(8936002)(122000001)(26005)(33656002)(52536014)(15650500001)(966005)(316002)(508600001)(83380400001)(5660300002)(2940100002)(2906002)(38070700005)(66446008)(6506007)(66476007)(64756008)(8676002)(66556008)(76116006)(9686003)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ZFFaeFBWYU9oTGZ6UW1BSlJOYitZb2M5WWVMeEIvcE01VFl0UXkxb1VVcFNS?= =?utf-8?B?UlFIVUw3TFI1QTRGNEREeUdoZWhrY3puT2QyQjhKaTNZNmpoZVU2K2tnSWhp?= =?utf-8?B?NndwQVU0ejNZdEo3OTluWjBXRTNTWkx3N1hPaWRuT1YvUENURmVRQmorK1RV?= =?utf-8?B?V25qSms0dUxvK0ZDcjMzYm9kK1hsdCtVUVZQMFI0cTJTZDdRV0hieHI4VGQv?= =?utf-8?B?RHo0V3dxM0pGQVJzRTlNc3JZSmZEanhwOFhlN0tUTFBBSkhPRC8raFU4NEZ2?= =?utf-8?B?UEFZZU9icVZoTUtGTEwwU0l3bURwN3dmNGpoVmxvVzI0RFk2TzdMWTJpZXZ0?= =?utf-8?B?S24vdTBGdzR4OEcxYTFyT3pEaldZN09kWnpRVFhLS1NmeEtRRVlFWTRIMnpt?= =?utf-8?B?eWxCQ1pKSjhVS3BtL05JUkVVWkF1eUkxWk1KWFd0ODNkc3o3N3RLa21oVkNk?= =?utf-8?B?QkM3WXcwMjhhd3V4dW5uZUFXZktBM2luSGtwVkw4bExKV3NmdWxJMzNyWnI3?= =?utf-8?B?MEF1c2o4bXRCTVB4TTg2ZUcvQWlSUHZGZFZMT1FOK09xZ2FYa2V2SDl3NzV2?= =?utf-8?B?WWp4MUc3eExQcGhqamJPMHhCUm9ITGlzb2xsc1UzNEV6RVpOUzBkL1Z4aEhN?= =?utf-8?B?ZUlwQ0FsNUpDZzZwVzQzMWEzSXdtcStkZ3pMUS9MMms0TWgxZksvN0tyMk1j?= =?utf-8?B?WmxWRFhZRmVTcWUyVk5GM3hnMDJlelJQdDhUSVAzd2tXUGtMcDkraGt0dEdl?= =?utf-8?B?OERHSlNaUVpoZElya3NsUVZiblRmQjR3a3lpYzJNemFVMUU1MnBYMGkrY1Y0?= =?utf-8?B?NHI2STZZRHoyaEtKbTM2VUhPNWdEajZidVFNd1R6Y1kyOFdmSWVuLzFidmNj?= =?utf-8?B?eDZxRDFpM25oSUNRRWQ5NHhxNUlsMXNSOGI1TGIrN1NNc0FlT3RMa0RKUDdU?= =?utf-8?B?aWd4dWc2MlVwbWFZZU5Tcm1Jb1BvTHZNVkRrWGZYUFJBd1p1RFhsdmQ5cHph?= =?utf-8?B?WWNiUmc4cmRXMmRQS0l6Tlg4TWRHWHNmN3huWnk5amdpRFBSNWZBd2hEMUpa?= =?utf-8?B?MHlJVFBCRU9HSG9mN2RTakFYNkUzNE9wTGJiQWk0RnRyd05KVEIza1J3UjNz?= =?utf-8?B?aDJkTEVRTU9VT2V4RlpMVnpPMTVwaWZzWTlOYTVJSzY4ZlR1RWpIaEZxNHdl?= =?utf-8?B?ZEZza1c1RThCbTJSQXNYbWNsZHJTM01UMllnTk1peEpjcnAyMEhCNnVoVFB4?= =?utf-8?B?NFArY1oyYTRYYWFzVFBnZk1CVXNSZnhvVzgwWTgySVEwSS84cWFxalhUODBK?= =?utf-8?B?Y25uaXo1a3hBQW9JWXAvd0owUVhDUjQ3a0RrWkNiQWNKdGZ5K1U1VHQwb1c4?= =?utf-8?B?b2pWN3h3b1UxRmJSVnRzTE1nenIyVy93NW5BcFNyWVJublBXNTVSU25yQ1ZH?= =?utf-8?B?dy9IVFk0dFU1K1BwSjNVT1NsOFFyQzExcHgvTU4vWVhveG1rYkQ0b3IxOU95?= =?utf-8?B?enFub0pMNjJncXBrZjQyNzgrYTFwaGpXRVZ6TVdvK2NVeFVyd2VsUCtmdmhR?= =?utf-8?B?SWcveDBKaEN2RWQ4NlJXZy9lZXBKZVVTK2NPdWU2MHk2YVpzRmEwTVBFSFdp?= =?utf-8?B?S0xmUWVPZG93c2ovdStUalAvOGVlQlFZaUpyS01hc3h4eWpEb1FaOFV6Vk1G?= =?utf-8?B?dWZnbnl5S0tjcFJGVkQ1L2JsUUN5dmp0ZTNqenVzMVlwVDNFRW8wdGdWV0lk?= =?utf-8?Q?10qKz6DFIv68ZgbpR8=3D?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA1PR09MB8142.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 513118d2-1166-4dea-a8d0-08d9c492e95f X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2021 15:02:30.7859 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR09MB7438 Archived-At: Subject: [Sidrops] new ASPA-based AS path verification algorithms implemented in NIST BGP-SRx X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2021 15:02:42 -0000 Rm9yIGZvbGtzIHVzaW5nIHRoZSBOSVNUIEJHUC1TUnggdGVzdCBleGFtcGxlcyAoaHR0cHM6Ly9n aXRodWIuY29tL3VzbmlzdGdvdi9OSVNULUJHUC1TUngvYmxvYi9tYXN0ZXIvZXhhbXBsZXMvZXhh bXBsZS1kZW1vLWFzcGEtbmV3L1JFQURNRSApIHRvIHRlc3QgdGhlaXIgaW1wbGVtZW50YXRpb24g YW5kIGNvbXBhcmluZyBhZ2FpbnN0IHRoZSBCR1AtU1J4IGltcGxlbWVudGF0aW9uIG9mIEFTUEEs IHdlIHByb3ZpZGUgYmVsb3cgdGhlIGRlc2NyaXB0aW9ucyBvZiB0aGUgbmV3IChjb3JyZWN0ZWQg cGVyIFsxXSkgcGF0aCB2ZXJpZmljYXRpb24gKGkuZS4sIHJvdXRlLWxlYWsgZGV0ZWN0aW9uKSBh bGdvcml0aG1zIHRoYXQgd2XigJl2ZSB1c2VkIChpbiBCR1AtU1J4KS4gQ29tbWVudHMvdXNlciBl eHBlcmllbmNlIGZlZWRiYWNrIGlzIHdlbGNvbWUuIA0KDQpJ4oCZdmUgYWxzbyBzaGFyZWQgdGhl IHRleHQgKGFsZ29yaXRobXMgYmVsb3cpIHdpdGggQWxleGFuZGVyIGZvciB0aGUgYW50aWNpcGF0 ZWQgQVNQQSB2ZXJpZmljYXRpb24gZHJhZnQgLTA5LiBUaGUgdXBkYXRlZCBhbGdvcml0aG1zIGFs c28gaW5jbHVkZSBzb21lIGVzc2VudGlhbCBzcGVjaWFsIChvciBjb3JuZXIpIGNhc2VzIHRoYXQg d2VyZSBub3QgY29uc2lkZXJlZCBiZWZvcmUgaW4gdGhlIGRyYWZ0Lg0KIA0KTmV3IHVwc3RyZWFt IEFTIHBhdGggdmVyaWZpY2F0aW9uIGFsZ29yaXRobSAod2hlbiBVUERBVEUgaXMgcmVjZWl2ZWQg ZnJvbSBhIGxhdGVyYWwgcGVlciwgY3VzdG9tZXIsIG9yIG5vbi10cmFuc3BhcmVudC1SUyBjbGll bnQpOg0KDQoxLiBJZiB0aGVyZSBpcyBhbiBBU19TRVQgcHJlc2VudCBpbiB0aGUgQVNfUEFUSCwg dGhlbiBzZXQgQVNfU0VUX0ZsYWcgPSAxLCBlbHNlIHNldCBBU19TRVRfRmxhZyA9IDAuDQogDQoy LiBJZiB0aGVyZSBpcyBub3QgYW4gQVNfU0VRVUVOQ0UgcHJlc2VudCogYnV0IG9ubHkgYW4gQVNf U0VULCB0aGVuIHRoZSBwcm9jZWR1cmUgaGFsdHMgd2l0aCB0aGUgb3V0Y29tZSDigJxVbnZlcmlm aWFibGXigJ0uIEVsc2UsIGNvbnRpbnVlLg0KDQozLiBDb2xsYXBzZSBwcmVwZW5kcyBpbiB0aGUg QVNfU0VRVUVOQ0UocykgaW4gdGhlIEFTX1BBVEggKGkuZS4sIGtlZXAgb25seSB0aGUgdW5pcXVl IEFTIG51bWJlcnMpLiBMZXQgdGhlIHJlc3VsdGluZyBvcmRlcmVkIHNlcXVlbmNlIGJlIHJlcHJl c2VudGVkIGJ5IHtBUygxKSwgQVMoMiksIOKApiwgQVMoTi0xKSwgQVMoTil9LCB3aGVyZSBBUygx KSBpcyB0aGUgZmlyc3QtYWRkZWQgQVMgaW4gdGhlIEFTX1NFUVVFTkNFIGFuZCBBUyhOKSBpcyB0 aGUgbGFzdC1hZGRlZCBhbmQgbmVpZ2hib3IgdG8gdGhlIHJlY2VpdmluZy92YWxpZGF0aW5nIEFT Lg0KICANCjQuIElmIE4gPSAxLCB0aGVuIGp1bXAgdG8gU3RlcCA4LiBFbHNlLCBjb250aW51ZS4N Cg0KNS4gQXQgdGhpcyBzdGVwLCBOIOKJpSAyLiBGb3IgMiDiiaQgaSDiiaQgTiwgaWYgdGhlcmUg aXMgYW4gaSBmb3Igd2hpY2ggQVMoaSkgaXMgYXR0ZXN0ZWQg4oCcbm90IFByb3ZpZGVy4oCdIGJ5 IGl0cyBsZWZ0IG5laWdoYm9yIEFTKGktMSksIHRoZW4gdGhlIHByb2NlZHVyZSBoYWx0cyB3aXRo IHRoZSBvdXRjb21lIOKAnEludmFsaWTigJ0uIEVsc2UsIGNvbnRpbnVlLg0KDQo2LiBGb3IgMSDi iaQgaSDiiaQgTi0xLCBpZiB0aGVyZSBpcyBhbiBpIGZvciB3aGljaCBBUyhpKSBoYXMgbm8gQVNQ QSwgdGhlbiBjb250aW51ZSB0byB0aGUgbmV4dCBzdGVwLiBFbHNlLCBqdW1wIHRvIFN0ZXAgOC4N CiANCjcuIElmIEFTX1NFVF9GbGFnID0gMCwgdGhlbiB0aGUgcHJvY2VkdXJlIGhhbHRzIHdpdGgg dGhlIG91dGNvbWUg4oCcVW5rbm93buKAnS4gRWxzZSAoaS5lLiwgQVNfU0VUX0ZsYWcgPSAxKSwg dGhlIHByb2NlZHVyZSBoYWx0cyB3aXRoIG91dGNvbWUg4oCcVW52ZXJpZmlhYmxl4oCdLg0KIA0K OC4gSWYgQVNfU0VUX0ZsYWcgPSAwLCB0aGVuIHRoZSBwcm9jZWR1cmUgaGFsdHMgd2l0aCB0aGUg b3V0Y29tZSDigJxWYWxpZOKAnS4gRWxzZSAoaS5lLiwgQVNfU0VUX0ZsYWcgPSAxKSwgdGhlIHBy b2NlZHVyZSBoYWx0cyB3aXRoIG91dGNvbWUg4oCcVW52ZXJpZmlhYmxl4oCdLg0KDQoqICBOb3Rl OiBTaW5jZSBBU19QQVRIIGlzIGEgbWFuZGF0b3J5IGF0dHJpYnV0ZSBpbiBlQkdQLCBpdCBtdXN0 IGhhdmUgYW4gQVNfU0VRVUVOQ0UsIG9yIEFTX1NFVCwgb3IgYm90aC4gDQouLi4uLi7igIMNCg0K TmV3IGRvd25zdHJlYW0gQVMgcGF0aCB2ZXJpZmljYXRpb24gYWxnb3JpdGhtICh3aGVuIFVQREFU RSBpcyByZWNlaXZlZCBmcm9tIGEgdHJhbnNpdCBwcm92aWRlciBvciBub24tdHJhbnNwYXJlbnQg UlMpOg0KDQoxLiBJZiB0aGVyZSBpcyBhbiBBU19TRVQgcHJlc2VudCBpbiB0aGUgQVNfUEFUSCwg dGhlbiBzZXQgQVNfU0VUX0ZsYWcgPSAxLCBlbHNlIHNldCBBU19TRVRfRmxhZyA9IDAuIA0KDQoy LiBJZiB0aGVyZSBpcyBub3QgYW4gQVNfU0VRVUVOQ0UgcHJlc2VudCBidXQgb25seSBhbiBBU19T RVQsIHRoZW4gdGhlIHByb2NlZHVyZSBoYWx0cyB3aXRoIHRoZSBvdXRjb21lIOKAnFVudmVyaWZp YWJsZeKAnS4gRWxzZSwgY29udGludWUuDQoNCjMuIENvbGxhcHNlIHByZXBlbmRzIGluIHRoZSBB U19TRVFVRU5DRShzKSBpbiB0aGUgQVNfUEFUSCAoaS5lLiwga2VlcCBvbmx5IHRoZSB1bmlxdWUg QVMgbnVtYmVycykuIExldCB0aGUgcmVzdWx0aW5nIG9yZGVyZWQgc2VxdWVuY2UgYmUgcmVwcmVz ZW50ZWQgYnkge0FTKDEpLCBBUygyKSwg4oCmLCBBUyhOLTEpLCBBUyhOKX0sIHdoZXJlIEFTKDEp IGlzIHRoZSBmaXJzdC1hZGRlZCBBUyBpbiB0aGUgQVNfU0VRVUVOQ0UgYW5kIEFTKE4pIGlzIHRo ZSBsYXN0LWFkZGVkIGFuZCBuZWlnaGJvciB0byB0aGUgcmVjZWl2aW5nL3ZhbGlkYXRpbmcgQVMu IA0KIA0KNC4gSWYgTiDiiaQgMiwgdGhlbiBqdW1wIHRvIFN0ZXAgMTEuIEVsc2UsIGNvbnRpbnVl Lg0KDQo1LiBBdCB0aGlzIHN0ZXAsIE4g4omlIDMuIEZvciAyIOKJpCBpIOKJpCBOLCBkZXRlcm1p bmUgdGhlIHNtYWxsZXN0IGkgZm9yIHdoaWNoIEFTKGkpIGlzIGF0dGVzdGVkIOKAnG5vdCBQcm92 aWRlcuKAnSBieSBpdHMgbGVmdCBuZWlnaGJvciBBUyhpLTEpLiBEZW5vdGUgc3VjaCBpIGFzIGlf bWluLiBJZiBpX21pbiBkb2VzIG5vdCBleGlzdCwgdGhlbiBzZXQgaV9taW4gPSBOKzEuIEZvciAx IOKJpCBqIOKJpCBOLTEsIGRldGVybWluZSB0aGUgbGFyZ2VzdCBqIGZvciB3aGljaCBBUyhqKSBp cyBhdHRlc3RlZCDigJxub3QgUHJvdmlkZXLigJ0gYnkgaXRzIHJpZ2h0IG5laWdoYm9yIEFTKGor MSkuIERlbm90ZSBzdWNoIGogYXMgal9tYXguIElmIGpfbWF4IGRvZXMgbm90IGV4aXN0LCB0aGVu IHNldCBqX21heCA9IDAuICBJZiBpX21pbiDiiaQgal9tYXgsIHRoZW4gdGhlIHByb2NlZHVyZSBo YWx0cyB3aXRoIHRoZSBvdXRjb21lIOKAnEludmFsaWTigJ0uIEVsc2UsIGNvbnRpbnVlIHRvIFN0 ZXAgNi4NCg0KNi4gVXAgcmFtcDogRm9yIDIg4omkIGkg4omkIE4sIGRldGVybWluZSB0aGUgbGFy Z2VzdCBpIChjYWxsIGl0IEspIHN1Y2ggdGhhdCBBUyhpKSBpcyBhdHRlc3RlZCBQcm92aWRlciBi eSBpdHMgbGVmdCBuZWlnaGJvciBBUyhpLTEpIGZvciBlYWNoIGkg4omkIEsuIElmIHN1Y2ggSyBk b2VzIG5vdCBleGlzdCwgdGhlbiBzZXQgSyA9IDEuDQoNCjcuIElmIEsg4omlIE4tMSwgdGhlbiBq dW1wIHRvIFN0ZXAgMTEuIEVsc2UsIGNvbnRpbnVlLg0KDQo4LiBEb3duIHJhbXA6IEZvciAxIOKJ pCBqIOKJpCBOLTEsIGRldGVybWluZSB0aGUgc21hbGxlc3QgaiAoY2FsbCBpdCBMKSBzdWNoIHRo YXQgQVMoaikgaXMgYXR0ZXN0ZWQgUHJvdmlkZXIgYnkgaXRzIHJpZ2h0IG5laWdoYm9yIEFTKGor MSkgZm9yIGVhY2ggaiDiiaUgTC4gSWYgbm8gc3VjaCBMIGV4aXN0cywgdGhlbiBzZXQgTCA9IE4u DQoNCjkuIElmIEwtSyDiiaQgMSwgdGhlbiBqdW1wIHRvIFN0ZXAgMTEuIEVsc2UgKGkuZS4sIEwt SyDiiaUgMiksIGNvbnRpbnVlLg0KDQoxMC4gSWYgQVNfU0VUX0ZsYWcgPSAwLCB0aGVuIHRoZSBw cm9jZWR1cmUgaGFsdHMgd2l0aCB0aGUgb3V0Y29tZSDigJxVbmtub3du4oCdLiBFbHNlIChpLmUu LCBBU19TRVRfRmxhZyA9IDEpLCB0aGUgcHJvY2VkdXJlIGhhbHRzIHdpdGggb3V0Y29tZSDigJxV bnZlcmlmaWFibGXigJ0uIA0KDQoxMS4gSWYgQVNfU0VUX0ZsYWcgPSAwLCB0aGVuIHRoZSBwcm9j ZWR1cmUgaGFsdHMgd2l0aCB0aGUgb3V0Y29tZSDigJxWYWxpZOKAnS4gRWxzZSAoaS5lLiwgQVNf U0VUX0ZsYWcgPSAxKSwgdGhlIHByb2NlZHVyZSBoYWx0cyB3aXRoIG91dGNvbWUg4oCcVW52ZXJp ZmlhYmxl4oCdLg0K4oCm4oCmDQoNCihUaGFua3MgdG8gT2xpdmVyIEJvcmNoZXJ0IGFuZCBLeWVo d2FuIExlZSB3aG8gcmVjZW50bHkgZW5jb2RlZCB0aGUgYWJvdmUgYWxnb3JpdGhtcyBpbiB0aGUg QVNQQSBpbXBsZW1lbnRhdGlvbiBhbmQgdGVzdGluZyBpbiBOSVNUIEJHUC1TUnguIEluY2x1ZGVk IGFyZSB0ZXN0IGNhc2VzIHdoZXJlIHRoZSBhYm92ZSBkb3duc3RyZWFtIGFsZ29yaXRobSB5aWVs ZHMgdGhlIGNvcnJlY3QgdmVyaWZpY2F0aW9uIHJlc3VsdHMgd2hpbGUgdGhlIHNhbWUgaW4gZHJh ZnQgdmVyc2lvbiAtMDggd2lsbCB5aWVsZCBpbmNvcnJlY3QgcmVzdWx0cy4pDQoNClJlZ2FyZHMs DQpTcmlyYW0NCg0KWzFdICBLLiBTcmlyYW0gYW5kIEouIEhlaXR6LCAiT24gdGhlIEFjY3VyYWN5 IG9mIEFsZ29yaXRobXMgZm9yIEFTUEEgQmFzZWQgUm91dGUgTGVhayBEZXRlY3Rpb24sIiBJRVRG IFNJRFJPUFMgTWVldGluZywgTWFyY2ggMjAyMS4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9tZWV0aW5nLzExMC9tYXRlcmlhbHMvc2xpZGVzLTExMC1zaWRyb3BzLXNyaXJhbS1hc3BhLWFs Zy1hY2N1cmFjeS0wMQ0K From nobody Tue Dec 21 12:30:31 2021 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A273A12F5; Tue, 21 Dec 2021 12:30:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <164011861762.4812.13738627542601322478@ietfa.amsl.com> Date: Tue, 21 Dec 2021 12:30:17 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-09.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2021 20:30:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : Manifests for the Resource Public Key Infrastructure (RPKI) Authors : Rob Austein Geoff Huston Stephen Kent Matt Lepinski Filename : draft-ietf-sidrops-6486bis-09.txt Pages : 19 Date : 2021-12-20 Abstract: This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. This document obsoletes RFC 6486. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-6486bis-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-6486bis-09 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Wed Dec 22 03:16:29 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630213A0826 for ; Wed, 22 Dec 2021 03:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9FfEI2gvdMN for ; Wed, 22 Dec 2021 03:16:21 -0800 (PST) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 9D0603A0827 for ; Wed, 22 Dec 2021 03:16:19 -0800 (PST) Received: by mail-ed1-x535.google.com with SMTP id f5so7246621edq.6 for ; Wed, 22 Dec 2021 03:16:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=vj+yGt0mz9XjEvs+6LWj566blDAlEsQx255EyNYjL+4=; b=OkFHG/nM4839iD9LPNHr55/MJNo9cTclJRqSVQmSvoChcdGBFrA2t85oM650KHXHNu DcwFKck8KAxEbVS9qwbi08woFvp1XnRbv6I09uRdL01ysz1Pm0iA+Xifl7wAM6xmQULd AoWH5nXXVC/b5jeuy7Zad5CLJ94IXf8Q0CVJs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=vj+yGt0mz9XjEvs+6LWj566blDAlEsQx255EyNYjL+4=; b=13soc1lb8wDcQz9Cramo9hd3z+QLao1vjkw0rJsMYXcY3cYmE4p0kcEbxT2wJvFebL dTiPCWpyDS8+Qgf7ZQel+uRvsFnvWkkEFKwUzhDSK6d1atfr/GLrLaQhgONsJ7PmouNE dj/abVezGO7r+pGP3U+MqxyWc13nizdQkPvaqWzgePQSy0aY2MGmEr6rGHfqayvoLr22 OVCUSLiCWDMQVmy2tlhvOA0aKtWxBteDthP3LUS3ol4Fm0hhmYknXohdWdRCklnai8zA Q2hYjCpBl2R8YwV6J1PYa3okVXrZ+95b1iAqbly+BxA+KvKum2t2XC3bq5GCStRvpJ73 TyBA== X-Gm-Message-State: AOAM531zqoSkFSvGzrZOdBK3VFTHs2mWeQPhxi90vRxJuBWCIQLgZGfW nKgxNcnE5jCYAp4BliM3QCrE0A== X-Google-Smtp-Source: ABdhPJzqsdPLWVqj74d5LXjfzMIKS0DyO5OwWiNtrXYvHZh+p4xUWwGupqDJONJ2RuKtha9nMm6mSw== X-Received: by 2002:a17:907:9488:: with SMTP id dm8mr2033006ejc.571.1640171773001; Wed, 22 Dec 2021 03:16:13 -0800 (PST) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id 8sm645308ejb.9.2021.12.22.03.16.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Dec 2021 03:16:12 -0800 (PST) Date: Wed, 22 Dec 2021 12:16:11 +0100 From: Job Snijders To: Benjamin Kaduk Cc: last-call@ietf.org, morrowc@ops-netman.net, sidrops-chairs@ietf.org, sidrops@ietf.org, warren@kumari.net, draft-ietf-sidrops-6486bis@ietf.org Message-ID: References: <163968561528.5705.3344262878453726327@ietfa.amsl.com> <20211217035523.GF11486@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211217035523.GF11486@mit.edu> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] [Last-Call] Last Call: (Manifests for the Resource Public Key Infrastructure (RPKI)) to Proposed Standard X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2021 11:16:28 -0000 On Thu, Dec 16, 2021 at 07:55:23PM -0800, Benjamin Kaduk wrote: > Also, I would recommend including a "changes since RFC 6486" section that > motivates why the document is being updated or replaced. This has been added. A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-6486bis-09 Kind regards, Job From nobody Wed Dec 22 08:50:20 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88903A00AF for ; Wed, 22 Dec 2021 06:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JVRXm_Y3qmG for ; Wed, 22 Dec 2021 06:48:36 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A743A005F for ; Wed, 22 Dec 2021 06:48:36 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.12.54]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id 1BMEm8CP000477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Dec 2021 06:48:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1640184500; x=1640270900; i=@elandsys.com; bh=P2oT2iPwh/fmXFzOLxi9/tMKmVTsAnRQF7S4zBsAja0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=y90L0794s/VbFO2q29IWGnlHDmv2h+FVTWQBymx7h+M3rrIilywfj1WObn+NxBdi6 oNHexrh9ONiTBnhocbw0pmAy78Jv+jhiFdsqqlGanBc+j2kKDp3dys7MQnIxFVzXwn zfOb20jrXyulDMmsc770X+ofc0xsbrdGvdhCFVfU= Message-Id: <6.2.5.6.2.20211222063851.0be759b8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 Dec 2021 06:47:27 -0800 To: Job Snijders From: S Moonesamy Cc: Benjamin Kaduk , sidrops@ietf.org In-Reply-To: References: <163968561528.5705.3344262878453726327@ietfa.amsl.com> <20211217035523.GF11486@mit.edu> <87tuf7gcsr.wl-morrowc@ops-netman.net> <20211217215442.GH11486@mit.edu> <6.2.5.6.2.20211220151713.1873e4e0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: X-Mailman-Approved-At: Wed, 22 Dec 2021 08:50:17 -0800 Subject: Re: [Sidrops] [Last-Call] Last Call: (Manifests for the Resource Public Key Infrastructure (RPKI)) to Proposed Standard X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2021 14:48:42 -0000 Hi Job, At 03:14 AM 22-12-2021, Job Snijders wrote: >The -09 version proposes to obsolete 6486. > >There is an htmlized version available at: >https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-6486bis-09 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-6486bis-09 Thank you for following up on the comment. Regards, S. Moonesamy From nobody Wed Dec 22 09:02:28 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B25A3A0A24 for ; Wed, 22 Dec 2021 09:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzvIw0DL52UM for ; Wed, 22 Dec 2021 09:02:21 -0800 (PST) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 B7A2F3A0969 for ; Wed, 22 Dec 2021 09:02:21 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id f138so2892582qke.10 for ; Wed, 22 Dec 2021 09:02:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Oba5qQT2Bc3WRI5LhKKI7DKlFtcEi4TPYrU/BwcRrQA=; b=RaGM0xH+0wK8ixOx4OIjECmJfDBIl6usrqzEDllUIrweptBTtqrtqNe9petXREyrL4 LQzdArQ3X0wPUxKQZrKgfA3WCWmo1uApyaI6BqReQQRdObAGW74jfB46jknGNUH1T9IQ 1wk2iRPbvfG88iGJbWIzynzXG3St/j/vOeA0/5Rd7GQoMoNZSzSR6CwxNFzpOHO5Nmtb ChD2iK2ozE8nFLHbWy+pFMx6Cns9z9eyCOshUpjd3e+8kJPv7KhpWbu1O7Ylo8NNNhGS E44XLy9HMo9Pp/SZJeRMkcJz3YTXc+XErVKWGWOxMu7nSGIs1eLXljLeqk7KO2xbDVe5 a/2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Oba5qQT2Bc3WRI5LhKKI7DKlFtcEi4TPYrU/BwcRrQA=; b=jPWT/O8wU/UWD8fy+9N6Lt/GWFrkHuq9j3xhwrJMZIDqyTV1Pb/gN9PXxhYLdc96in dqw47x/uW+jRul8mpCQ70tfygBYIMf83MGRCAMBuOz9ZD4iCaylRtovTKQeKIHOdP89Q 3oPFaR+iBgzrnKYf0HhOm5ZS6xmQnC4H9UvNctmyPgfJt4l1nSTjjJSDX8uE8RsuIp0e 4TWGsDIwLrJ9qIB9bXhKwep4vx4ceExAc7SYYHXeANNwMv5g6YiDQnRHTVOaL0difeCB Rug1aBJWJePWc/t5FfRoS5SI8YlAugRR7A9uEKqKKsq9HyvZ6hQo8P7/GPiV2zXFr4L3 x0qw== X-Gm-Message-State: AOAM531zUBg5YRVGwPEN1WWV+8NSjh9uqG9tTuP9ISbyjlX1RIvWZZmV qkcweAkaoObJGeU71e5FsuHc8WtInbNL0HVSo/cncyxTokE= X-Google-Smtp-Source: ABdhPJwCfTw/UPJiCpofUwkx/53akrJKbdQYbTEgYJnnnkZ0E7ormau8UTarcwRTL31zmiBt6mGRn2nzcSqDitXPhLs= X-Received: by 2002:a05:620a:4548:: with SMTP id u8mr2719882qkp.614.1640192539740; Wed, 22 Dec 2021 09:02:19 -0800 (PST) MIME-Version: 1.0 References: <163968561528.5705.3344262878453726327@ietfa.amsl.com> <20211217035523.GF11486@mit.edu> <87tuf7gcsr.wl-morrowc@ops-netman.net> <20211217215442.GH11486@mit.edu> <6.2.5.6.2.20211220151713.1873e4e0@elandnews.com> <6.2.5.6.2.20211222063851.0be759b8@elandnews.com> In-Reply-To: <6.2.5.6.2.20211222063851.0be759b8@elandnews.com> From: Christopher Morrow Date: Wed, 22 Dec 2021 12:02:06 -0500 Message-ID: To: S Moonesamy Cc: Job Snijders , SIDR Operations WG , Benjamin Kaduk Content-Type: multipart/alternative; boundary="000000000000b1cd7205d3bf15e6" Archived-At: Subject: Re: [Sidrops] [Last-Call] Last Call: (Manifests for the Resource Public Key Infrastructure (RPKI)) to Proposed Standard X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2021 17:02:27 -0000 --000000000000b1cd7205d3bf15e6 Content-Type: text/plain; charset="UTF-8" thanks Stephen and Job (and probably sekret-editor-in-chef?) and thanks Benjamin for the clarification :) On Wed, Dec 22, 2021 at 11:50 AM S Moonesamy wrote: > Hi Job, > At 03:14 AM 22-12-2021, Job Snijders wrote: > >The -09 version proposes to obsolete 6486. > > > >There is an htmlized version available at: > >https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-6486bis-09 > > > >A diff from the previous version is available at: > >https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-6486bis-09 > > Thank you for following up on the comment. > > Regards, > S. Moonesamy > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --000000000000b1cd7205d3bf15e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
thanks Stephen and Job (and probably sekret-editor-in-chef= ?)
and thanks Benjamin for the clarification :)

On Wed, Dec 22, 20= 21 at 11:50 AM S Moonesamy <sm= +ietf@elandsys.com> wrote:
Hi Job,
At 03:14 AM 22-12-2021, Job Snijders wrote:
>The -09 version proposes to obsolete 6486.
>
>There is an htmlized version available at:
>https://datatracker.ietf.org/= doc/html/draft-ietf-sidrops-6486bis-09
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?ur= l2=3Ddraft-ietf-sidrops-6486bis-09

Thank you for following up on the comment.

Regards,
S. Moonesamy

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops
--000000000000b1cd7205d3bf15e6-- From nobody Wed Dec 22 09:19:00 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B9E3A0AA4; Wed, 22 Dec 2021 09:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8QcGhYhqzHF; Wed, 22 Dec 2021 09:18:54 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 5C06E3A0AA6; Wed, 22 Dec 2021 09:18:54 -0800 (PST) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1BMHIgpS021213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Dec 2021 12:18:48 -0500 Date: Wed, 22 Dec 2021 09:18:42 -0800 From: Benjamin Kaduk To: Job Snijders Cc: morrowc@ops-netman.net, sidrops-chairs@ietf.org, sidrops@ietf.org, warren@kumari.net, draft-ietf-sidrops-6486bis@ietf.org Message-ID: <20211222171842.GR11486@mit.edu> References: <163968561528.5705.3344262878453726327@ietfa.amsl.com> <20211217035523.GF11486@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Sidrops] [Last-Call] Last Call: (Manifests for the Resource Public Key Infrastructure (RPKI)) to Proposed Standard X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2021 17:18:59 -0000 On Wed, Dec 22, 2021 at 12:16:11PM +0100, Job Snijders wrote: > On Thu, Dec 16, 2021 at 07:55:23PM -0800, Benjamin Kaduk wrote: > > Also, I would recommend including a "changes since RFC 6486" section that > > motivates why the document is being updated or replaced. > > This has been added. > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-6486bis-09 Thanks! -Ben From nobody Wed Dec 22 17:34:19 2021 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11DF53A0EFF; Wed, 22 Dec 2021 17:34:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <164022324901.20808.2191946379061791503@ietfa.amsl.com> Date: Wed, 22 Dec 2021 17:34:09 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-8210bis-05.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2021 01:34:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2 Authors : Randy Bush Rob Austein Filename : draft-ietf-sidrops-8210bis-05.txt Pages : 38 Date : 2021-12-22 Abstract: In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 2 of the RPKI-Router protocol. RFC 6810 describes version 0, and RFC 8210 describes version 1. This document updates RFC 8210. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-8210bis/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-8210bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-8210bis-05 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Sun Dec 26 05:51:17 2021 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9E13A1279; Sun, 26 Dec 2021 05:51:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: nathalie@ripe.net, sidrops-chairs@ietf.org, sidrops@ietf.org, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164052667423.27313.6789268436594632651@ietfa.amsl.com> Date: Sun, 26 Dec 2021 05:51:14 -0800 Archived-At: Subject: [Sidrops] sidrops - New Meeting Session Request for IETF 113 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2021 13:51:16 -0000 A new meeting session request has just been submitted by Nathalie Trenaman, a Secretary of the sidrops working group. --------------------------------------------------------- Working Group Name: SIDR Operations Area Name: Operations and Management Area Session Requester: Nathalie Trenaman Number of Sessions: 1 Length of Session(s): unspecified Number of Attendees: 70 Conflicts to Avoid: Chair conflict: grow idr opsawg Technology overlap: opsarea opsec People who must be present: Keyur Patel Chris Morrow Warren "Ace" Kumari Resources Requested: Special Requests: ---------------------------------------------------------