From nobody Wed May 1 11:36:03 2019 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 394FC120108; Wed, 1 May 2019 11:35:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-sidrops-lta-use-cases@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <155673575623.1018.2628095868041430703.idtracker@ietfa.amsl.com> Date: Wed, 01 May 2019 11:35:56 -0700 Archived-At: Subject: [Sidrops] Roman Danyliw's Discuss on draft-ietf-sidrops-lta-use-cases-06: (with DISCUSS and COMMENT) 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: Wed, 01 May 2019 18:35:56 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-sidrops-lta-use-cases-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I had a few questions about use case #3. (1) I want to discuss what I see as a dissonance between use case #3 (Section 4, “Alice is responsible for the trusted routing for a large organization …”) and the Security Considerations. It appears that use case #3 is explicitly describing an on-path attack per RFC3552. Is use case #3 a use case or an attack against RPKI? There seems to me to be an analog between use case #3 and the TLS/web MitM discussions where the consensus was not to standardize these features despite their existence. In what way do you see RPKI as different? (2) Thanks for the additional background in in [1]. More to clarity along the lines of Mirja’s DISCUSS, I’m trying to unpack the use case #3 text in Section 4. Original Text: “Alice is responsible for the trusted routing for a large organization, commercial or geo-political, in which management requests to redirect their competitors' prefixes to socially acceptable data.” If Alice is “(us|china|uk|justabouteverybody)” per [1], who is the “management” in the context of a government? Furthermore, “competitor’s” is confusing to me because it seems odd to characterize the networks of objectionable content as competitors to other governments. I would have read this text as “Alice is a network operator who has been directed to inspect and redirect select prefixes to …”. [1] https://mailarchive.ietf.org/arch/msg/sidrops/qGulOfrDPxXgMC9HLJWpXYeBOi4 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few editorial nits: (1) Section 3. Editorial Nit. s/There are critical uses of the RPKI where a local administrative and/or routing domain, e.g. an end-user site, a particular ISP or content provider, an organization, a geo-political region, ... may wish to have a specialized view of the RPK./ There are critical uses of the RPKI where a local administrative and/or routing domain (e.g., an end-user site, a particular ISP or content provider, an organization, a geo-political region) may wish to have a specialized view of the RPK./ (2) Section 4. Editorial Nit. s/(LIR, PI holder, …)/(e.g., LIR, PI holder)/ From nobody Wed May 1 13:58:22 2019 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 2C54A120094; Wed, 1 May 2019 13:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 50cb5qehv9lQ; Wed, 1 May 2019 13:58:12 -0700 (PDT) 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 3577B120021; Wed, 1 May 2019 13:58:12 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1hLwIr-0007WC-Cf; Wed, 01 May 2019 20:58:09 +0000 Date: Wed, 01 May 2019 13:58:08 -0700 Message-ID: From: Randy Bush To: Roman Danyliw Cc: The IESG , SIDR Operations WG In-Reply-To: <155673575623.1018.2628095868041430703.idtracker@ietfa.amsl.com> References: <155673575623.1018.2628095868041430703.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 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] Roman Danyliw's Discuss on draft-ietf-sidrops-lta-use-cases-06: (with DISCUSS and COMMENT) 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 May 2019 20:58:14 -0000 > (1) I want to discuss what I see as a dissonance between use case #3 > (Section 4, $B!H(BAlice is responsible for the trusted routing for a large > organization $B!D!I(B) and the Security Considerations. It appears that > use case #3 is explicitly describing an on-path attack per RFC3552. > Is use case #3 a use case or an attack against RPKI? it is using the rpki to facilitate an attack on the internet within a local scope. in a sense, all three use cases describe 'attacks' on the rpki. they are all about having divergent local views of the rpki content. like many tools, they have applications good and bad. > There seems to me to be an analog between use case #3 and the TLS/web > MitM discussions where the consensus was not to standardize these > features despite their existence. In what way do you see RPKI as > different? well, it's not a transport/network layer, so the monkey can not find a middle :). but it definitely is an attack. note that this draft does not describe mechanisms, only use cases. but, as i said in response to mirja, i have sympathy for the position and am willing to go either way. but this use case is, and will likely continue to be, the dominant use for tree modification a la slurm. > (2) Thanks for the additional background in in [1]. More to clarity > along the lines of Mirja$B!G(Bs DISCUSS, I$B!G(Bm trying to unpack the use case > #3 text in Section 4. > > Original Text: $B!H(BAlice is responsible for the trusted routing for a large > organization, commercial or geo-political, in which management requests to > redirect their competitors' prefixes to socially acceptable data.$B!I(B > > If Alice is $B!H(B(us|china|uk|justabouteverybody)$B!I(B per [1], who is the > $B!H(Bmanagement$B!I(B in the context of a government? different cultures have different organizational relationships between political decision making and internet operations. anybody here understand the mechanisms by which the USG shuts down a thousand web sites? we read in the press about various cultures doing this stuff all the time, and it is pretty complex. > Furthermore, $B!H(Bcompetitor$B!G(Bs$B!I(B is confusing to me because it seems odd to > characterize the networks of objectionable content as competitors to > other governments. I would have read this text as $B!H(BAlice is a network > operator who has been directed to inspect and redirect select prefixes > to $B!D!I(B. glad to have a different term which conveys the intent. we have always been at war with eastasia. btw, the use case which is most interesting to operators is that of carol, the 'dutch court attack.' while carol or a third party can easily construct a slurm patch, how is that distributed, authenticated, and how do third parties decide whether to apply it? > A few editorial nits: thanks. as it is now within 24 of your telechat, i will hold back on a new draft. randy From nobody Wed May 1 18:41:14 2019 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 A93DE120149; Wed, 1 May 2019 18:41:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-sidrops-lta-use-cases@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155676126468.2640.12123560027176038171.idtracker@ietfa.amsl.com> Date: Wed, 01 May 2019 18:41:04 -0700 Archived-At: Subject: [Sidrops] Benjamin Kaduk's Discuss on draft-ietf-sidrops-lta-use-cases-06: (with DISCUSS and COMMENT) 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, 02 May 2019 01:41:05 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-sidrops-lta-use-cases-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have strong misgivings about publishing this document in its current form. The review comment on its predecessor in sidr, "it is written like af able, not an RFC" really sticks with me, and while the style plays a role in my misgivings, I think there are some substantive concerns in play as well. I agree with Roman that there is strong qualitative overlap with situations like TLS MiTM, akin to a violation of the end-to-end principle. I also agree with Mirja that "re-routing to acceptable content" is questionable, and smacks of endorsing censorship. (And yes, I know that one person's censorship is another's parental controls.) My main concern, though, seems to be that this document presents a narrow slice of a broad issue, and does not lay clear the technical facts of the broader situation. Specifically, it lays out some examples where some parties may believe that it is desired to inject additional local information into a local view of the RPKI (or, roughly equivalently, to suppress such information). There are important details about what the two "local"s mean, who is authorized to impose such additional information, etc., but I think it is possible to write a useful document that does not reach a clearn answer on any of those questions. To be useful, though, we need to consider the consequences of having the capability to perform such local injection. There is new attack surface that must be protected from network attack, and a need for permissions/consent (contractual or otherwise) for the systems that are affected by the local view of the RPKI to trust the party/parties that are injecting the local view. Furthermore, there is a sizeable chance that the technical solutions to resolve these use cases will be technically unconstrained, allowing for the "local view" to fully override any and all of the RPKI, so the risk of granting such consent is potentially quite sizeable. I'm also a little concerned about the level of review that this document received; the responsible AD had to send it back to the WG once due to lack of evidence for consensus (https://mailarchive.ietf.org/arch/msg/sidrops/5IBDpQZdsqJeYrxIsSI37c8QxRw), and I did not see a great deal of additional feedback after that. (Perhaps I was looking in the wrong place?) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Abstract The phrasing "needs to" is very strong and implies that there is an absolute judgment that can be made as to the validity of the operation, when my impression is that the topic remains rather controversial. The wording "will want to" used in the Introduction seems to be more accurate. (The word "critical" in "critical circumstances", present in both Abstract and Introduction, is also prone to criticisms of hyperbolism.) Section 1 This document attempts to lay out a few of those use cases. It is not intended to be authoritative, complete, or to become a standard. It is informative laying out a few critical examples to help frame the issues. I appreciate that this document does not intend to be authoritative or complete. But to say that it is "help[ing] frame the issues" borders on irresponsible -- it presents *a* framing in which these use cases are cast favorably, but (per the Discuss point) does not include in that framing some significant points that cause the use cases to be cast less favorably. Section 4 Carol, a resource holder (Local Internet Registry (LIR), Provider Independent address space (PI) holder, ...), operates outside of the country in which her Regional Internet Registry (RIR) is based. Is "legal jurisdiction" more on topic than "country", for the purposes of this example? Someone convinces the RIR's local court to force the RIR to remove or modify some or all of Carol's certificates, ROAs, etc. or the resources they represent, and the operational community wants to retain the ability to route to Carol's network(s). [...] It seems unlikely to me that this is a matter on which the operational community would achieve full consensus. Perhaps "a subset of" is appropriate? Alice is responsible for the trusted routing for a large organization, commercial or geo-political, in which management requests routing engineering to redirect their competitors' prefixes to socially acceptable data. [...] Both "competitors' prefixes" and "socially acceptable" have been mentioned already as potentially problematic phrasing, IIRC, but I will mention them again. (Also, I don't really understand what "geo-political organization" is intended to mean, but maybe that's just as well.) Section 5 One wants to reproduce only as much of the Global RPKI as needed. Replicating more than is needed would amplify tracking and maintenance. The text would probably benefit from a bit more about what is being tracked and by whom. (I assume it is not users being tracked by a surveilance state, though I can't quite exclude that possibility given just the text at hand.) One can not reissue down from the root trust anchor at the IANA or from the RIRs' certificates because one does not have the private keys required. So one has to create a new trust anchor which, for ease of use, will contain the new/modified certificates and ROAs as well as the unmodified remainder of the Global RPKI. I'm not really sure what sense "trust anchor" is being used in, here. It does not seem to match up with the one described in Section 2.4 of RFC 6480, for example. Because Alice, Bob, and Carol want to be able to archive, reproduce, and send to other operators the data necessary to reproduce their modified view of the global RPKI, there will need to be a formally defined set of data which is input to a well-defined process to take an existing Global RPKI tree and produce the desired modified re- anchored tree. This feels very incompletely described. (Yes, I know, "not intended to be complete". But there's a level of incompleteness that seems to not be worth publishing, and we may be close to it.) I also don't have a great sense of whether there's supposed to be a single "re-anchored tree" or a forest of trees, and whether the full global RPKI tree is a subtree of this re-anchored tree, or a replacement/copied version is present therein. Simplified Local Internet Number Resource Management with the RPKI (SLURM), [RFC8416], addresses many, but not all, of these issues and approaches. This document was originally a gating requirements document for SLURM and other approaches. The phrasing of this last sentence feels very unusual to me for an archival document. Section 6 "patching of trust" seems like a phrase without a clear meaning. Though, a large part of that is probably because "trust" itself is so hard to nail down... Modification 'recipes' may lack authentication. E.g., if modifications to the tree are passed around a la SLURM files, see [RFC8416], what was object security becomes, at best, transport security, or authentication by other trust domains such as PGP. Expounding on this with a couple more sentences would probably be worth the effort. From nobody Wed May 1 18:58:24 2019 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 0B6191202AC; Wed, 1 May 2019 18:58:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-sidrops-lta-use-cases@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <155676230303.2891.9061769370182049689.idtracker@ietfa.amsl.com> Date: Wed, 01 May 2019 18:58:23 -0700 Archived-At: Subject: [Sidrops] Alissa Cooper's Discuss on draft-ietf-sidrops-lta-use-cases-06: (with DISCUSS and COMMENT) 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, 02 May 2019 01:58:23 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-sidrops-lta-use-cases-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I do not believe we should publish this document with the term "socially acceptable data," because it endorses others' determinations of what is socially acceptable in a blanket fashion. I would recommend "other resources." ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support the DISCUSS ballots of Roman and Mirja and Benjamin's first three DISCUSS points. From nobody Thu May 2 06:52:05 2019 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 32C6D120103; Thu, 2 May 2019 06:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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=nostrum.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 eBoa8SnsOvvh; Thu, 2 May 2019 06:52:02 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A781C120372; Thu, 2 May 2019 06:52:02 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x42DpvIA091924 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 2 May 2019 08:51:58 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1556805122; bh=k5mhRrFMT2/VH74PFl4nZeufL3aKpR9H5dW66I44P5s=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=F/axvkMCswnJ3KCE+qBsis6qe+IJ3UwOE2i0xTVrR6J1SoBKsM8v9XQrP74DYVKIY g6cFEY0QTUAa8Ypb6qnkrJGKwsb7EtSDLzyoOSFZL7TaPFy8KwWbzzqFMwjDDS3FFT BpSuEayGppWkeCLQFOoCb3b0eCTUgrugBEAsew9Q= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Tim Bruijnzeels Cc: morrowc@ops-netman.net, sidrops-chairs@ietf.org, sidrops@ietf.org, draft-ietf-sidrops-https-tal@ietf.org, The IESG References: <155491689193.9336.11988651941770388340.idtracker@ietfa.amsl.com> <06A75E77-16DA-4391-91A0-7A0A53AFB66F@nlnetlabs.nl> From: Adam Roach Message-ID: Date: Thu, 2 May 2019 08:51:52 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <06A75E77-16DA-4391-91A0-7A0A53AFB66F@nlnetlabs.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Sidrops] Adam Roach's Yes on draft-ietf-sidrops-https-tal-07: (with COMMENT) 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 May 2019 13:52:04 -0000 My apologies for the slow response here -- somehow I missed this message back when you sent it. Reply inline. On 4/16/19 7:47 AM, Tim Bruijnzeels wrote: > Hi Adam, all, > >> On 10 Apr 2019, at 19:21, Adam Roach via Datatracker wrote: >> >> Adam Roach has entered the following ballot position for >> draft-ietf-sidrops-https-tal-07: Yes >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-sidrops-https-tal/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thanks to everyone who worked on this document. >> >> --------------------------------------------------------------------------- >> >> I find it curious and somewhat problematic that there is not a section, >> equivalent to the existing section 4, that deals with RSYNC considerations. In >> particular, the attack described in the first paragraph of section 4 appears >> to be unavoidable when the TAL contains an RSYNC URI. Minimally, this document >> should draw attention to that fact, at least in the Security Considerations >> section. Ideally, it would deprecate -- or at least discourage -- the use of >> RSYNC URIs for this reason. > Good point. > > How about if we change the name of section 4 from "HTTPS Considerations" to "URI Scheme Considerations" > > And start off with: > > Please note that the RSYNC protocol provides neither transport security nor any means by which the Relying Party can validate that they are connected to the proper host. There it is RECOMMENDED that HTTPS is used as the preferred scheme. > > And change: > Note that a Man in the Middle (MITM) cannot produce a CA certificate > that would be considered valid according to the process described in > Section 3. However, a MITM attack can be performed to prevent the > Relying Party from learning about an updated CA certificate. Because > of this, Relying Parties MUST do TLS certificate and host name > validation when they fetch a CA certificate using an HTTPS URI on a > TAL. > > To: > > Relying Parties MUST do TLS certificate and host name validation when > they fetch a CA certificate using an HTTPS URI on a TAL. Note that, > although a Man in the Middle (MITM) cannot produce a CA certificate > that would be considered valid according to the process described in > Section 3, this attack can prevent that the Relying Party learns about > an updated CA certificate. Thanks! These changes address the issue. /a From nobody Thu May 2 18:04:17 2019 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 3B2011200EA; Thu, 2 May 2019 18:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 IPtc2-3tEHz3; Thu, 2 May 2019 18:04:06 -0700 (PDT) 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 BD5DE12004D; Thu, 2 May 2019 18:04:05 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x4313xYa021697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 2 May 2019 21:04:01 -0400 Date: Thu, 2 May 2019 20:03:58 -0500 From: Benjamin Kaduk To: Tim Bruijnzeels Cc: The IESG , morrowc@ops-netman.net, sidrops-chairs@ietf.org, sidrops@ietf.org, draft-ietf-sidrops-https-tal@ietf.org Message-ID: <20190503010358.GL59871@kduck.mit.edu> References: <155486682558.19696.15312172563014424742.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-https-tal-07: (with COMMENT) 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 May 2019 01:04:09 -0000 (just one note inline) On Tue, Apr 30, 2019 at 10:36:16AM +0200, Tim Bruijnzeels wrote: > Hi Benjamin, > > My apologies. While updating -07 based on the review comments I found that I overlooked your response. > > See response in-line, I am including these in the -08 that will follow shortly. > > > On 10 Apr 2019, at 05:27, Benjamin Kaduk via Datatracker wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-sidrops-https-tal-07: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-sidrops-https-tal/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thank you for keeping the diff from RFC 7730 tidy! > > > > Abstract > > > > their CA certificate. In particular it allows TAs to change the set > > of Internet Number Resources included in the RFC3779 extension of > > their certificate. > > > > Neither "Internet Number" nor "Number Resources" appears in RFC 3779 that I > > can see. (On a quick skim, I'm still not sure if we mean AS number or IP > > address/prefix.) > > > > ack, clarified. > > > > Section 2.1 > > > > the trust anchor per se. In the RPKI, certificates contain > > extensions that represent Internet Number Resources (INRs) [RFC3779]. > > > > good point, I am used to this term so I took it for granted. Now clarified. > > > > (As above, I don't see INRs mentioned in RFC 3779.) > > > > Since comments are new in this rev of TAL, do we want to caution consumers > > that implementations may not necessarily support comments yet? > > I added the following section: > > 1.2. Changes from RFC7730 > > The TAL format defined in this document differs from the definition in [RFC7730] in that: > > • it allows for the use of the HTTPS scheme in URIs; and > • it allows for the inclusion of an optional comment section. > > Note that current Relying Parties may not support this new format yet. Therefore it is RECOMMENDED that a Trust Anchor operator maintains a [RFC7730] TAL file for a time as well until they are satisfied that RP tooling has been updated. > > > > > > Section 2.3 > > > > The trust anchor MUST contain a stable key. This key MUST NOT change > > when the certificate is reissued due to changes in the INR > > extension(s), when the certificate is renewed prior to expiration, or > > for any reason other than a key change. > > > > (This seems a bit tautological...) > > > > If an entity wishes to withdraw a self-signed CA certificate as a > > putative trust anchor, for any reason, including key rollover, the > > entity MUST remove the object from the location referenced in the > > TAL. > > > > Certain classes of attacker could continue to publish the last-known > > certificate as a trust anchor and prevent this withdrawl from taking > > effect; we should probably cover that in the security considerations. > > > > see below 2.4, or am I missing another point here? > > > Section 2.4 > > > > We say that it's RECOMMENDED to have different domains (so as to get > > different IP addresses) but this example shows only a single domain. > > > > Section 4 > > > > Note that a Man in the Middle (MITM) cannot produce a CA certificate > > that would be considered valid according to the process described in > > Section 3. [...] > > > > I think the key part is that the attacker cannot produce a *new* CA > > certificate that differs from a legitimate one, but they can MITM the HTTPS > > connection and present a legitimate (but potentially stale) CA certificate. > > We have this (slightly re-worded text) in the Security section: > > Note that, although a Man in the Middle (MITM) cannot produce a CA > certificate that would be considered valid according to the process > described in Section 3, this attack can prevent that the Relying Party > learns about an updated CA certificate. I think (but am only about 80% sure) that we want "updated or removed" here. So add it if it makes sense to you, and if not, don't worry about it. Thanks, Ben > This does not go on to clarify the consequences of such possible attacks, but I believe this is sufficient warning to implementers. > > > > > > o DNS names in Repository Server certificates SHOULD NOT contain the > > wildcard character "*". > > > > Would a Relying Party ever reject the HTTPS connection (and thus, the > > delivered TA) if a wildcard certificate is presented for the HTTPS > > connection? > > This is most likely controlled by the HTTPS client library used by the RP software. In some cases it may not be possible to tweak the behaviour. Therefore I think the SHOULD NOT is the right level. > > > > > > Section 5 > > > > This TAL does not directly provide a list of resources covered by the > > referenced self-signed CA certificate. Instead, the RP is referred > > to the trust anchor itself and the INR extension(s) within this > > certificate. This provides necessary operational flexibility, but it > > also allows the certificate issuer to claim to be authoritative for > > any resource. Relying parties should either have great confidence in > > the issuers of such certificates that they are configuring as trust > > anchors, or they should issue their own self-signed certificate as a > > trust anchor and, in doing so, impose constraints on the subordinate > > certificates. > > > > Are there any external databases that a RP could consult to affect the > > decision of whether to believe that a TA should actually be claiming the > > indicated resource(s)? (It would be a bit silly, given that this is the > > RPKI already, but still...) > > I think this is out of scope for this document. But the RIRs do publish their stats here on the NRO website: > https://www.nro.net/about/rirs/statistics/ > > > > > > > > > > > _______________________________________________ > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops > From nobody Thu May 2 19:15:05 2019 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 B7F4B120261; Thu, 2 May 2019 19:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORD4R0WyGJZW; Thu, 2 May 2019 19:14:55 -0700 (PDT) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 145F912019B; Thu, 2 May 2019 19:14:55 -0700 (PDT) Received: by mail-vk1-xa36.google.com with SMTP id l17so1025594vke.7; Thu, 02 May 2019 19:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MJHV9bhRCOWjZqrp+Xpbx7HSdbA+pPSCAeGT8fHpsc4=; b=gUu+rRdScLBgzhSqM0d1eERJafgWmlcXDKGDWJg6nm431xi+j7e7isw6TyCL+SOKPT OXLicjYFmNJLKzVasWnVeAiMSGWW5MDBBu1NX9Ew30vo52+1bBGzUF10G4zo/C5iwJwA 0nxML12q3ciCsfI3CNZuP4RN2eE7EWBiM6klMzjgQEqVBUWYsfRdEPXWb+EizjS4ZH1W omdkdvJw1Gexf1gAm+zYOb9pL58ldp3HJQRfsfeGhKuItHna6/s9e19GuL0zGlyjeq2/ xJk8FUuAooL5KaqNLueg+ngZ3KboywiQtln3t1xx8SSaxeYfY4kODPcewHqdYLGJ81WX ozAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MJHV9bhRCOWjZqrp+Xpbx7HSdbA+pPSCAeGT8fHpsc4=; b=m/Dlbld/sTi+lQ5QCJQmrAtOqCjOzltR9LKjfJnAgyugmOWkjjTZj4YAhd9Z7AaZ8S uchjXsT4oNOmyr0FEZf7lYOd+VTE0ktMwmWxdPKkWaxJOxqVahwrhVYMTJmzu+nnn5bS afcHT7VgTWih7Pu0JucHWogJHPrQ8tWUDBCHtn+MgRhBTHbUnHoMIw1gQcNuTaqASLoc a0mDoOzNufYT14HfI5pWlRXeqtirziMlrSdKJzqBGyZ/n03emiPgPUQBI/aT+TXl6FOc jlQdvT1uXvR3LVdLPSDhcP5G/FQl9fw5OxxFbUs7qlKLR1il6K0fIUF0axpBm8YU5/KZ K9tg== X-Gm-Message-State: APjAAAXiUgJTL9EWVyuFWSg5eVAocbF96Bvo82YEI56wsBaTXoF8FqPf 1UyD9RZO7LfYseBGEF9VFf3Y3V/ViI8vgeDc++i0Fg== X-Google-Smtp-Source: APXvYqwhzos71pZBikP9YNah0Pycq4GDPyc3IIKcq3aS72/uB0VzpcDdQeuEZhaXEfCWQGsf07bwg4TuxRKQ5llhmbQ= X-Received: by 2002:a1f:141:: with SMTP id 62mr124606vkb.58.1556849693706; Thu, 02 May 2019 19:14:53 -0700 (PDT) MIME-Version: 1.0 References: <87bm3euruw.wl%morrowc@ops-netman.net> <74a8c64a-f0bd-0659-972e-2b79993986e2@gmail.com> In-Reply-To: <74a8c64a-f0bd-0659-972e-2b79993986e2@gmail.com> From: Christopher Morrow Date: Thu, 2 May 2019 22:14:42 -0400 Message-ID: To: SIDR Operations WG Cc: Chris Morrow , SIDROps Chairs , sidrops-ads@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] WG Adoption call draft-azimov-sidrops-aspa-verification 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 May 2019 02:15:04 -0000 Howdy folks! It's past 2/28, please note that the draft had some good conversation and I support for adoption. Let's have the authors resubmit with the correct naming and move forward with wg disucssion/etc. thanks! -chris On Tue, Feb 19, 2019 at 10:25 AM Andrei Robachevsky wrote: > > Chris Morrow wrote on 14/02/2019 19:50: > > > > Hi Folks, > > > > > > > > The authors have requested SIDROPS working group adoption call of > > > > https://tools.ietf.org/html/draft-azimov-sidrops-aspa-verification-01 > > > > https://datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-profile/. > > > > > > > > Please send your comments to the list. This adoption call will conclude on Feb 28 2019. > > I support adoption of the draft. Promise a review. > > Regards, > > Andrei > > > > > > > > > Regards, > > > > Chris & Keyur > > > > _______________________________________________ > > 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 From nobody Fri May 3 00:23:47 2019 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 19B8312006B; Fri, 3 May 2019 00:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 3ukycu6xT_ka; Fri, 3 May 2019 00:23:44 -0700 (PDT) Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [185.49.140.10]) (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 952D6120044; Fri, 3 May 2019 00:23:43 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:c2:9a30:b88f:6115] (unknown [IPv6:2001:981:4b52:1:c2:9a30:b88f:6115]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 2944A201C0; Fri, 3 May 2019 09:23:41 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1556868221; bh=+fajtRcslZ4+kz3iZBV4HBbR78/uguZ1T7HZV7qXYjw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=UpQQY2neCq5nftweZXAGrGTraz4pZ78l0r3Bdz2n9gAbYpUferrLEOv33XTCpqIjR ZKxc0QvXBQDQUmCbTdPAlUVpnC52gsfEXTQPVwy9yh4ehTuXYwxyZM9lVJlLarErG+ ORwnMyZaROW2Q3jLPolSrqhSr7bPphUtzqizyBfs= Content-Type: multipart/alternative; boundary="Apple-Mail=_EE527C0F-B2DE-4413-B635-1C27E7A8832D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Tim Bruijnzeels In-Reply-To: <20190503010358.GL59871@kduck.mit.edu> Date: Fri, 3 May 2019 09:23:37 +0200 Cc: The IESG , Chris Morrow , sidrops-chairs@ietf.org, sidrops@ietf.org, draft-ietf-sidrops-https-tal@ietf.org Message-Id: References: <155486682558.19696.15312172563014424742.idtracker@ietfa.amsl.com> <20190503010358.GL59871@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-https-tal-07: (with COMMENT) 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 May 2019 07:23:46 -0000 --Apple-Mail=_EE527C0F-B2DE-4413-B635-1C27E7A8832D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Ben, > On 3 May 2019, at 03:03, Benjamin Kaduk wrote: >=20 >> Note that, although a Man in the Middle (MITM) cannot produce a CA >> certificate that would be considered valid according to the process >> described in Section 3, this attack can prevent that the Relying = Party >> learns about an updated CA certificate. >=20 > I think (but am only about 80% sure) that we want "updated or removed" > here. So add it if it makes sense to you, and if not, don't worry = about > it. I don't think "removed" applies here. If the TA intended to no longer = publish a certificate for a key, that would imply that they are trying = to do a key roll. Key rolls are not covered by this document. There is another document that talks about TA key rolls - using a signed = object, with TAL like content: https://tools.ietf.org/html/draft-ietf-sidrops-signed-tal-02 This draft is currently expired, but as co-author I plan to do an update = at least in time for IETF105. I was postponing the update because I had = hoped to do some proof of concept implementation first. Thanks Tim >=20 > Thanks, >=20 > Ben --Apple-Mail=_EE527C0F-B2DE-4413-B635-1C27E7A8832D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Ben,

On 3 May 2019, at 03:03, Benjamin Kaduk = <kaduk@mit.edu> = wrote:

Note = that, although a Man in the Middle (MITM) cannot produce a CA
certificate that would be considered valid according to the = process
described in Section 3, this attack can prevent = that the Relying Party
learns about an updated CA = certificate.

I think (but am only about 80% sure) that we want "updated or = removed"
here. =  So add it if it makes sense to you, and if not, don't worry = about
it.

I = don't think "removed" applies here. If the TA intended to no longer = publish a certificate for a key, that would imply that they are trying = to do a key roll. Key rolls are not covered by this = document.

There is another document = that talks about TA key rolls - using a signed object, with TAL like = content:









Thanks,

Ben

= --Apple-Mail=_EE527C0F-B2DE-4413-B635-1C27E7A8832D-- From nobody Mon May 6 09:35:48 2019 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 5D49F12021B; Mon, 6 May 2019 09:35:29 -0700 (PDT) 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: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Cc: morrowc@ops-netman.net, The IESG , sidrops@ietf.org, sidrops-chairs@ietf.org, Chris Morrow , draft-ietf-sidrops-https-tal@ietf.org, warren@kumari.net, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155716052937.27677.2249361625134023083.idtracker@ietfa.amsl.com> Date: Mon, 06 May 2019 09:35:29 -0700 Archived-At: Subject: [Sidrops] Protocol Action: 'Resource Public Key Infrastructure (RPKI) Trust Anchor Locator' to Proposed Standard (draft-ietf-sidrops-https-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: Mon, 06 May 2019 16:35:33 -0000 The IESG has approved the following document: - 'Resource Public Key Infrastructure (RPKI) Trust Anchor Locator' (draft-ietf-sidrops-https-tal-08.txt) as Proposed Standard This document is the product of the SIDR Operations Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-https-tal/ Technical Summary This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). TALs allow Relying Parties in the RPKI to download the current Trust Anchor (TA) CA certificate from one or more locations, and verify that the key of this self-signed certificate matches the key on the TAL. Thus, Relying Parties can be configured with TA keys, but allow these TAs to change the content of their CA certificate. In particular it allows TAs to change the set of Internet Number Resources included in the RFC3779 extension of their certificate. This document obsoletes the previous definition of Trust Anchor Locators in RFC 7730 by adding support for HTTPS URIs. Working Group Summary Nothing in the WG that was overly noteworthy, good discussion and back/forth on changes. Document Quality This document obsoletes an existing implementation replacing it with new implementations. Personnel Shepherd: Chris Morrow - morrowc@ops-netman.net AD: Warren Kumari - warren@kumari.net From nobody Mon May 6 13:10:15 2019 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 DD4DB12013E; Mon, 6 May 2019 13:09:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <155717338189.27537.3549752090005278157.idtracker@ietfa.amsl.com> Date: Mon, 06 May 2019 13:09:41 -0700 Archived-At: Subject: [Sidrops] Roman Danyliw's No Objection on draft-ietf-sidrops-rtr-keying-05: (with COMMENT) 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: Mon, 06 May 2019 20:09:52 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-sidrops-rtr-keying-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for making the updates in -04 and -05 to address ekr’s DISCUSSes. A few additional items: (1) Typos: ** Section 5.2.1. s/operators's/operators'/ ** Appendix B. s/pubic/public/ (2) Section 10 PKI-relying protocols, of which BGPsec is one, have many issues to consider - so many, in fact, entire books have been written to address them; so listing all PKI-related security considerations is neither useful nor helpful. It seems odd to say there is a large body of knowledge of relevant issues that won’t be discussed/cited/referenced here. (2) Appendix B. The n00b Guide to BGPsec Key Management It seems derogatory to refer to a section as being for “n00bs”. I would recommend alternative language. From nobody Thu May 9 06:44:59 2019 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 589FF12003E for ; Thu, 9 May 2019 06:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 kbpmqoPxa_Vg for ; Thu, 9 May 2019 06:44:56 -0700 (PDT) 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 639CE1200B8 for ; Thu, 9 May 2019 06:44:56 -0700 (PDT) Received: from [193.0.23.13] (helo=bufobufo.ripe.net) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hOjLz-0007N0-31 for sidrops@ietf.org; Thu, 09 May 2019 15:44:55 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::af5]) by bufobufo.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hOjLz-0003l5-1E for sidrops@ietf.org; Thu, 09 May 2019 15:44:55 +0200 From: Thiago da Cruz Content-Type: multipart/alternative; boundary="Apple-Mail=_086F4550-CB08-44E7-84EC-169C4974731A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Message-Id: <773981F0-CC8E-404C-8F5F-E9CEA55CF8D1@ripe.net> Date: Thu, 9 May 2019 15:44:54 +0200 To: sidrops@ietf.org X-Mailer: Apple Mail (2.3445.104.8) X-ACL-Warn: Delaying message X-RIPE-Signature: bc54d195b0c1bc98e39bfcde448d5b41551c73d1341f5df53164a538e2632ef9 Archived-At: Subject: [Sidrops] RPKI Planned Downtime 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 May 2019 13:44:59 -0000 --Apple-Mail=_086F4550-CB08-44E7-84EC-169C4974731A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear colleagues, We=E2=80=99ll be running an upgrade on our infrastructure on Monday, 13 = May from 10:30 (UTC+2).=20 =20 During the time it takes to carry out the upgrade, the RSYNC and RRDP = repositories will be accessible, but the up down protocol, the RPKI user = interface on my.ripe.net , and REST API will be = unavailable. We expect the upgrade to take no longer than an hour. We apologise in = advance for any inconvenience that might be caused by this. = https://www.ripe.net/support/service-announcements/rpki-planned-downtime-1= / = Kind regards, Thiago da Cruz RIPE NCC= --Apple-Mail=_086F4550-CB08-44E7-84EC-169C4974731A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear colleagues,

We=E2=80=99ll be running an upgrade on our = infrastructure on Monday, 13 May from 10:30 (UTC+2). 
 
During the time it takes to carry out = the upgrade, the RSYNC and RRDP repositories will be accessible, but the = up down protocol, the RPKI user interface on my.ripe.net, and REST API = will be unavailable.

We expect the upgrade = to take no longer than an hour. We apologise in advance for any = inconvenience that might be caused by this.

https://www.ripe.net/support/service-announcements/rpki-planned= -downtime-1/

Kind regards,
Thiago da Cruz
RIPE NCC
= --Apple-Mail=_086F4550-CB08-44E7-84EC-169C4974731A-- From nobody Mon May 13 10:54:48 2019 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 1F9881200B5 for ; Mon, 13 May 2019 10:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] 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 QPE0-UEK2i_F for ; Mon, 13 May 2019 10:54:43 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700070.outbound.protection.outlook.com [40.107.70.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FBDC120021 for ; Mon, 13 May 2019 10:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KqByb3WRc1e0QyML0quEu1WrKpImnckL6SN+JyUGz1w=; b=JWcnREVkA5NvyZt6j1VBsGOLvD5vkxng4fwVVlfs9CGvAyDq84rlbwCi/zywwLpWWWCNG81Q091Ne3gMSjV8CARThGKQkN8jfPt6ate1fR2pQnzTEAKimBatfCDStw7B1yhuyj4xwHwbLD9hxG40y/IAa59bIquIofibjBvOc3Y= Received: from BYAPR18MB2856.namprd18.prod.outlook.com (20.179.58.82) by BYAPR18MB2968.namprd18.prod.outlook.com (20.179.59.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.20; Mon, 13 May 2019 17:54:38 +0000 Received: from BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::f855:74f:9e5f:d010]) by BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::f855:74f:9e5f:d010%6]) with mapi id 15.20.1878.024; Mon, 13 May 2019 17:54:38 +0000 From: Keyur Patel To: "sidrops@ietf.org" Thread-Topic: IETF 104 SIDROPS Meeting Minutes Thread-Index: AQHVCbTuFwhpf/S030iDc/RJPyWqXA== Date: Mon, 13 May 2019 17:54:38 +0000 Message-ID: <29A62D35-94A6-4764-B76E-27914F5BA7EA@arrcus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-originating-ip: [70.234.233.188] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f37a66b4-7103-4321-c429-08d6d7cc118e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR18MB2968; x-ms-traffictypediagnostic: BYAPR18MB2968: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0036736630 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(366004)(346002)(376002)(39830400003)(199004)(189003)(6436002)(14444005)(2351001)(7736002)(71200400001)(71190400001)(83716004)(5024004)(2906002)(66066001)(6306002)(102836004)(68736007)(54896002)(3846002)(508600001)(6116002)(256004)(1730700003)(81156014)(8676002)(5640700003)(6512007)(6506007)(81166006)(486006)(476003)(8936002)(6486002)(86362001)(14454004)(66574012)(25786009)(186003)(36756003)(99286004)(5660300002)(73956011)(26005)(33656002)(53936002)(2501003)(6916009)(66946007)(66556008)(82746002)(66476007)(2616005)(64756008)(66446008)(316002)(76116006); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2968; H:BYAPR18MB2856.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 2vAsS/bZBiNFxrnH39mVmWurqD+OHSHyDHVbxGOQ8+3Jl144I5JJDgsdZSKOyGZdvvKrIHc86y/67MDfNPVQBvR0BoVeVUizG/Uqx7HKAIlElbS0hSSkhZoRr3jyGVwl2+vj9ZPPNTtg4PYj05/w/jqUdkG3/tZ/JiMWEWktALN8+kh4FQ/kCL+keJ45f6StXUCNJGH68455ERvNCmO/IhST/4v3F0+ZqgKN7RbM8C3rtqmlvxprymYBG38VXZcg49/Dle0ir6BhzKUqnWgHUErpdTV+h0I0fw/tjr3b3vhMlQZa25/B8SAnqOOCuC18QE3FDLqsC8bgF0IXpnYzBPgd31Q2BsUHzer22Yrp5sl6SRSKiGb1BBvyPWBWR9e+nYamqPii7oorKduBDKzBrLqaqB6LtVeeZnGepOSHo9w= Content-Type: multipart/alternative; boundary="_000_29A62D3594A64764B76E27914F5BA7EAarrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-Network-Message-Id: f37a66b4-7103-4321-c429-08d6d7cc118e X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2019 17:54:38.5614 (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-Transport-CrossTenantHeadersStamped: BYAPR18MB2968 Archived-At: Subject: [Sidrops] IETF 104 SIDROPS Meeting Minutes 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 May 2019 17:54:47 -0000 --_000_29A62D3594A64764B76E27914F5BA7EAarrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9sa3MsDQoNCkF0dGFjaGVkIGFyZSB0aGUgbWVldGluZyBtaW51dGVzIGZvciB0aGUgU0lEUk9Q UyBtZWV0aW5nIGF0IElFVEYgMTA0IGluIFByYWd1ZS4NCkFwb2xvZ2llcyBmb3IgdGhlIGRlbGF5 IGluIHNlbmRpbmcgb3V0IHRoZSBtZWV0aW5nIG1pbnV0ZXMuDQoNCkJlc3QgUmVnYXJkcywNCktl eXVyDQoNCiBNZWV0aW5nIE1pbnV0ZXMgZnJvbSBQcmFndWUgSUVURi0xMDQNCg0KDQotMSkgUmFu ZHkgQnVzaCAtLSBkcmFmdC15bWJrLXNpZHJvcHMtb3Ytc2lnbmFsLTAyLnR4dA0KDQotSW4gYmFu ZCBtYXJraW5nIHdpdGggZXh0ZW5kZWQgY29tbXVuaXR5Og0KU3JpcmFtIEsuIChOaXN0KTogRXZh bHVhdG9yIGRvZXMgdmFsaWRhdGlvbiBvciByb3V0ZXIgZG9lcyB0aGUgdmFsaWRhdGlvbj8NClJh bmR5IEJ1c2g6IEV2YWx1YXRvciBvbmx5Lg0KU3JpcmFtIEsuOiBFdmFsdWF0b3IgbG9zdCBpdHMg cnBraSBjb25uZWN0aW9uLi4gaG93IGRvZXMgaXQgc2lnbmFsIHJvdXRlcj8NClJhbmR5IEJ1c2g6 IERyYWZ0IGRvZXMgbm90IGNvdmVyIGl0Lg0KU3JpcmFtIEsuOiBTaG91bGQgd2UgY292ZXIgdGhl IHVzZSBjYXNlIGluIHRoZSBkcmFmdD8NClJhbmR5IEJ1c2g6IE1heWJlLg0KDQoNCjIpIERhbmll bCBLb3BwIC0tIGRyYWZ0LWlldGYtc2lkcm9wcy1yb3V0ZS1zZXJ2ZXItcnBraS1saWdodC0wMi50 eHQNCg0KLSBJbiBkb21haW4gb2YgSVhQIG5ldHdvcmsgd2hlcmUgUk9BIHZhbGlkYXRpb24gcmVz dWx0cyBpcyBmb3J3YXJkZWQgZnJvbSBSUyB0byBpdHMgcGVlcnMuDQotIEludHJvZHVjZSBhIHRy YW5zaXRpdmUgZm91ci1vY3RldCBBUyBzcGVjaWZpYyBFeHRlbmRlZCBDb21tdW5pdHkuDQpKYWtv YiBIZWl6OiBUaHJlZSB2YWxpZGF0aW9uIHN0YXRlcyBhcmUgZGVmaW5lZCBhbmQgdGhlcmUgc2hv dWxkIGJlIHRoZSBmb3VydGggc3RhdGUgKFZhbGlkYXRpb24gbm90IGRvbmUpLg0KRGFuaWVsIEtv cHA6IEl0IGlzIG1pc3NpbmcgaW4gdGhlIGRyYWZ0Lg0KUnVlZGlnZXIgVm9sazogV2h5IG5vdCBo YXZlIHlvdXIgY3VzdG9tZXJzIGRvIGl0PyBFeHRlbmRlZCBjb21tdW5pdHkgd2FzIGNob3NlbiBi ZWNhdXNlIGxhcmdlIGNvbW11bml0aWVzIHdhcyBtaXNzaW5nLiBBc2tpbmcgZm9yIHJvdXRlcnMg dG8gaW1wbGVtZW50IGl0IGFuZCBpbXBsZW1lbnRhdGlvbiBjeWNsZXMgYXJlIGxvbmcgYmVmb3Jl IGl0IGdvZXMgaW4gcHJvZHVjdGlvbi4gU3VnZ2VzdCB1c2luZyBsYXJnZSBjb21tdW5pdHk/DQpE YW5pZWwgS29wcDogSGFwcHkgdG8gYWRvcHQgTGFyZ2UgY29tbXVuaXR5Lg0KUmFuZHkgQnVzaDog QWdyZWUgd2l0aCBSdWVkaWdlciBWb2xrLiBTdWdnZXN0IHVzaW5nIExhcmdlIGNvbW11bml0eSBh bmQgc2FtZSBjb21tdW5pdHkgZGVmaW5pdGlvbi4NCkRvdWcgTTogSVhQIGNvdWxkIG9mZmVyIHRo aXMgYXMgc2VydmljZT8NCkRhbmllbCBLb3BwOiBZZXMuDQpEb3VnaCBNOiBtYWtlcyBzZW5zZS4N CkpvYiBTbmlkZXJzOiBXaGF0IGlzIGxhY2tpbmcgaW4gdGhlIGRyYWZ0IGlzIHNlY3VyZSBieSBk ZWZhdWx0IGFwcHJvYWNoLiBTdWdnZXN0IGFiYW5kb25pbmcgdGhlIGRyYWZ0LiBTaG91bGQgbm90 IGJlIHByb3BhZ2F0aW5nIHZhbGlkYXRpb24gc3RhdGUgb24gRWJncC4NCkRhbmllbCBLb3BwOiBE byBub3QgYWdyZWUuDQpKb2IgU25pZGVyczogU2hvdWxkIG5vdCBwcm9wYWdhdGUgaW52YWxpZHMu IFRoaXMgbWFrZXMgaXQgaW5zZWN1cmUuDQpSYW5keSBCdXNoOiBUcmFkZS1vZmYgaXMgd2hldGhl ciB5b3UgYWN0IGZvciBJWFAgbWVtYmVyIG9yIHlvdSBnaXZlIElYUCBtZW1iZXIgbW9yZSBpbmZv cm1hdGlvbi4gUXVlc3Rpb24gZnJvbSBJWFAgbWVtYmVycyBwb3YgaXMgYXJlIHlvdSBvdXRzb3Vy Y2luZyB5b3VyIHNlY3VyaXR5Lg0KRG91ZyBNOiBEbyBub3QgYWdyZWUgd2l0aCBvdXRzb3VyY2lu ZyBzZWN1cml0eS4NCkFsZXhhbmRlciBBemltb3Y6IFlvdSBkbyBoYXZlIGZpbHRlcmluZy4gV2h5 IGRvbid0IHlvdSB1c2UgbWFya2luZyBhbmQgd2h5IGFzayBmb3IgZmxleGliaWxpdHk/IFdoYXRz IHRoZSBkaWZmZXJlbmNlPw0KRGFuaWVsIEtvcHA6IFdvdWxkIGxpa2UgdG8gc3RhbmRhcmRpemUg dXNpbmcgYSBjb21tdW5pdHkgZm9yIGV2ZXJ5b25lLg0KUnVkaWdoZXIgVm9sazogQ29uc2lkZXIg c2lnbmFsaW5nIGZvciBndXlzIHdobyBzZW50IHlvdSBpbnZhbGlkIHN0dWZmPw0KS2V5dXIgUGF0 ZWw6IEFueSBmbGF2b3Igb3Igc29sdXRpb24gZGVwbG95ZWQgdG9kYXk/DQpEYW5pZWwgS29wcDog RHJvcHBpbmcgZm9yIGRlZmF1bHQuIFRhZ2dpbmcgaXMgbm90IGRvbmUuDQoNCg0KMykgUnVlZGln ZXIgVm9sayAtLSBkcmFmdC15bWJrLXNpZHJvcHMtb3YtZWdyZXNzLTAwLnR4dA0KDQpSYW5keSBC dXNoOiBXaGF0ZXZlciBSRkMgb3JpZ2luIGNsYXJpZmljYXRpb25zIGJlY2FtZSBpcyBpbmNvbnZl bmllbnQ/IFdlIGRvIGhhdmUgU05NUCBNSUJzIGZvciBkcm9wcGVkIGFubm91bmNlbWVudHM/DQpS dWVkaWdlciBWb2xrOiBOb3QgaW50ZXJlc3RlZCBpbiBTTk1QIHN0YXRzLg0KUmFuZHkgQnVzaDog VGFnZ2luZyBhbm5vdW5jZW1lbnRzIHdpdGggZGlmZmVyZW50IG9yaWdpbi1hcyB0byBkaWZmZXJl bnQgcGVlcnM/DQpSdWVkaWdlciBWb2xrOiBJdCB3b3VsZCBmYWxsIHVuZGVyIHdlaXJkIHBvbGlj eSBwcmltaXRpdmVzLg0KUmFuZHkgQnVzaDogTXkgcG9pbnQgaXMgdGhlIGhhY2sgeW91IHdhbnQg aXMgdG8gcHV0IGEgY2hlY2sgYXQgdGhlIGVuZCBvZiBleHBvcnQgcG9saWN5IHNvIEkgZG9uJ3Qg aGF2ZSB0byBkdXBsaWNhdGUgaXQuDQpSdWVkaWdlciBWb2xrOiBXZSBhcmUgaW4gYWdyZWVtZW50 Lg0KSm9obiBTY3VkZGVyOiBTaW5jZSB5b3VyIHRlbGxpbmcgaW1wbGVtZW50b3JzIGhvdyB0byBp bXBsZW1lbnQgYSBzdGFuZGFyZCBtYWtlIGl0IHN0YW5kYXJkcyBiYXNlZC4NCkFuZHJldyBEcmF5 OiBQbGVhc2UgYXNrIHRoZSBpbXBsZW1lbnRvcnMgdG8gc2hvdyB3aGF0IGlzIGV4YWN0bHkgYmVp bmcgZHJvcHBlZC4gQW5vdGhlciBjb21tZW50IEkgaGF2ZSB0byBlbmFibGUgcG9saWNpZXMgcGVy IHBlZXIuDQpSYW5keSBCdXNoOiAiZG8gTk9UIGRvIFJPQXMgZm9yIHJvdXRlcyBOT1QgbWVhbnQg Zm9yIERGWiIgaXMgZm9yIEFTMCBwZWVycyBvbmx5Lg0KUnVlZGlnZXIgVm9sazogWW91IHNlZW0g dG8gdGhpbmsgQVMwIGlzIHNwZWNpYWwuDQpSYW5keSBCdXNoOiBMZXRzIGRpZmZlcmVudGlhdGUg QVMwIGluIHBhdGggdmVyc3VzIFJPQS4NClJ1ZWRpZ2VyIFZvbGs6IEFncmVlLg0KSm9obiBTY3Vk ZGVyOiBUaGUgc2xpZGUgaXMgY29tcGxldGVseSB1bnJlbGF0ZWQgdG8gdGhlIHByZXNlbnRhdGlv bi4NClJ1ZWRpZ2VyIFZvbGs6IFllcy4NCkpvaG4gU2N1ZGRlcjogTGFzdCBzbGlkZSBpcyBpbnRl cmVzdGluZyBhbmQgdGhvdWdodCBwcm92b2tpbmcuDQpKb2IgU25pZGVyczogVGhlcmUgbWF5IGJl IGV4cGxhbmF0aW9ucyBhcyB0byB3aHkgeW91IGFyZSBzZWVpbmcgdW53YW50ZWQgQVNlcywgQ3Vz dG9tZXJzIG1ha2UgUk9BcyB3aXRoIHByaXZhdGUgQVNlcyBhcyB0YWdzLCB0eXBvcywgZXRjLg0K UnVlZGlnZXI6IE9ubHkgd2hlbiBzb21lb25lIHByZXNlbnRzIHRoZW4gYW5kIG9ubHkgdGhlbiBp dCBnZXRzIGZpeGVkLg0KSmVmZiBIdXN0b246IElmIHlvdSByZWFsbHkgd2FudGVkIHRvIHVuZGVy c3RhbmQgdmFsaWRpdHkgb2YgUk9BIHdoeSBkb24ndCB5b3Ugc2lnbiB3aXRoIEFTLg0KUnVlZGln ZXIgVm9sazogQXJlIHlvdSBzdWdnZXN0aW5nIHdlIG1pbWljIHdoZXJlIEFkZHJlc3MgYW5kIEFT IG11c3QgYmUgc2lnbmVkLiBXaGF0IEkgc3VnZ2VzdCBpcyBzaW1wbGUgYW5kIHN0cmFpZ2h0Zm9y d2FyZC4NCkRvdWcgTS4gV2h5IGlzIHRoaXMgc3R1ZmYgYXBwZWFyaW5nIGluIGdsb2JhbCBSUEtJ LiBJcyB0aGlzIGlnbm9yYW5jZT8NClJ1ZWRpZ2VyIFZvbGs6IFR5cG9zLCBmb2xrcyBub3QgYWRo ZXJpbmcgdG8gZ3VpZGVsaW5lcyBhbmQgZm9sa3Mgbm90IGtub3dpbmcgd2hhdCB0aGV5IGFyZSBk b2luZy4NCkRvdWcgTS4gY29uY2VybmVkIHRoYXQgb25lIG9mZiB2YWxpZGF0b3JzIG1pZ2h0IGNs ZWFuIHRoaXMgdXAgYnV0IHRoZSBwcm9ibGVtcyBtYXkgbm90IGJlIHNvbHZlZD8NClJ1ZGVnZXIg Vm9sazogU3VnZ2VzdCBhIEJDUC4NCg0KNCkgU3JpcmFtIEsuIOKAkyBSUEtJL1JPViBkYXRhIGFu YWx5c2lzIHdpdGggZGV0YWlsIGNoYXJhY3Rlcml6YXRpb24gb2YgSW52YWxpZCByb3V0ZXMNCg0K QW5kcmV5IFIuOiBIb3cgZG9lcyBpdCB3b3JrPyBXaGF0IGlzIHRoZSBxdWVyeSBtZWNoYW5pc20/ DQpTcmlyYW06IFdlIGNhbiBnaXZlIHlvdSBhIGdsb2JhbCB2aWV3IG9yIGEgdmlldyBwZXIgQVMu IERvbid0IHRoaW5rIGl0IGlzIHJlYWR5IGJ1dCBjYW4gZmFjaWxpdGF0ZSB0aGF0Lg0KDQo1KSBH ZW9yZ2UgTWljaGVsc29uIOKAkyBSUEtJIFZhbGlkYXRpb24gUmVjb25zaWRlcmVkDQoNClJvYiBB dXN0ZWluOiBEb24ndCBhZ3JlZSB3aXRoIHRoZSBjaGVjayBhdCBldmVyeSBsZXZlbC4NCkRpIE1h OiBXZSBkb27igJl0IHVzZSBPSUQgYnV0IHdlIHVzZSBhbGdvcml0aG0uIFdlIGNhbiBzd2l0Y2gg dG8gbmV3IHZhbGlkYXRpb24uDQpHZXJvZ2UgTS4gQ29vbC4NCg0KNikgR2VvcmdlIE1pY2hlbHNv biDigJMgUmVzb3VyY2UgVGFnIEF0dGVzdGF0aW9uDQoNCkpvYiBTbmlkZXJzOiBXb3VsZCBsaWtl IHRvIHNlZSB0aGlzIG1vdmUgZm9yd2FyZC4NCg0KNykgT2xpdmVyIEJvcmNoZXJ0IOKAkyBkcmFm dC1ib3JjaGVydC1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmctMDAudHh0DQoNClByZXNlbnRl ZCBCR1BTZWMgVmFsaWRhdGlvbiBTdGF0ZSBTaWduYWxpbmcuDQoNCg== --_000_29A62D3594A64764B76E27914F5BA7EAarrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <4B819F76320BD24181A63D795515A62E@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmgyDQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1s aW5rOiJIZWFkaW5nIDIgQ2hhciI7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjE4LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1z cGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5IVE1M UHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhlYWRpbmcyQ2hh cg0KCXttc28tc3R5bGUtbmFtZToiSGVhZGluZyAyIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDIiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i IzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJs YWNrIj5Gb2xrcyw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPkF0dGFjaGVkIGFyZSB0aGUgbWVldGluZyBt aW51dGVzIGZvciB0aGUgU0lEUk9QUyBtZWV0aW5nIGF0IElFVEYgMTA0IGluIFByYWd1ZS48L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFj ayI+QXBvbG9naWVzIGZvciB0aGUgZGVsYXkgaW4gc2VuZGluZyBvdXQgdGhlIG1lZXRpbmcgbWlu dXRlcy48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPkJlc3QgUmVnYXJkcyw8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+S2V5dXI8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6YmxhY2siPiZuYnNwOzxiPk1lZXRpbmcgTWludXRlcyBmcm9tIFByYWd1ZSBJRVRGLTEw NDwvYj48L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij4tMSkgUmFuZHkgQnVzaCAtLSBkcmFmdC15bWJrLXNpZHJvcHMtb3Ytc2lnbmFsLTAyLnR4dDwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOmJsYWNrIj4tSW4gYmFuZCBtYXJraW5nIHdpdGggZXh0ZW5kZWQgY29tbXVu aXR5Ojwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOmJsYWNrIj5TcmlyYW0gSy4gKE5pc3QpOiBFdmFsdWF0b3IgZG9lcyB2YWxpZGF0aW9uIG9y IHJvdXRlciBkb2VzIHRoZSB2YWxpZGF0aW9uPzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5SYW5keSBCdXNoOiBFdmFsdWF0b3Ig b25seS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjpibGFjayI+U3JpcmFtIEsuOiBFdmFsdWF0b3IgbG9zdCBpdHMgcnBraSBjb25uZWN0aW9u Li4gaG93IGRvZXMgaXQgc2lnbmFsIHJvdXRlcj88L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+UmFuZHkgQnVzaDogRHJhZnQgZG9l cyBub3QgY292ZXIgaXQuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Y29sb3I6YmxhY2siPlNyaXJhbSBLLjogU2hvdWxkIHdlIGNvdmVyIHRoZSB1c2Ug Y2FzZSBpbiB0aGUgZHJhZnQ/PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPlJhbmR5IEJ1c2g6IE1heWJlLjwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+MikgRGFuaWVsIEtvcHAgLS0gZHJhZnQt aWV0Zi1zaWRyb3BzLXJvdXRlLXNlcnZlci1ycGtpLWxpZ2h0LTAyLnR4dDwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OmJsYWNrIj4tIEluIGRvbWFpbiBvZiBJWFAgbmV0d29yayB3aGVyZSBST0EgdmFsaWRhdGlvbiBy ZXN1bHRzIGlzIGZvcndhcmRlZCBmcm9tIFJTIHRvIGl0cyBwZWVycy48L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+LSBJbnRyb2R1 Y2UgYSB0cmFuc2l0aXZlIGZvdXItb2N0ZXQgQVMgc3BlY2lmaWMgRXh0ZW5kZWQgQ29tbXVuaXR5 Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OmJsYWNrIj5KYWtvYiBIZWl6OiBUaHJlZSB2YWxpZGF0aW9uIHN0YXRlcyBhcmUgZGVmaW5lZCBh bmQgdGhlcmUgc2hvdWxkIGJlIHRoZSBmb3VydGggc3RhdGUgKFZhbGlkYXRpb24gbm90IGRvbmUp Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OmJsYWNrIj5EYW5pZWwgS29wcDogSXQgaXMgbWlzc2luZyBpbiB0aGUgZHJhZnQuPC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPlJ1 ZWRpZ2VyIFZvbGs6IFdoeSBub3QgaGF2ZSB5b3VyIGN1c3RvbWVycyBkbyBpdD8gRXh0ZW5kZWQg Y29tbXVuaXR5IHdhcyBjaG9zZW4gYmVjYXVzZSBsYXJnZSBjb21tdW5pdGllcyB3YXMgbWlzc2lu Zy4gQXNraW5nIGZvciByb3V0ZXJzIHRvIGltcGxlbWVudCBpdCBhbmQgaW1wbGVtZW50YXRpb24g Y3ljbGVzIGFyZSBsb25nIGJlZm9yZQ0KIGl0IGdvZXMgaW4gcHJvZHVjdGlvbi4gU3VnZ2VzdCB1 c2luZyBsYXJnZSBjb21tdW5pdHk/PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPkRhbmllbCBLb3BwOiBIYXBweSB0byBhZG9wdCBM YXJnZSBjb21tdW5pdHkuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Y29sb3I6YmxhY2siPlJhbmR5IEJ1c2g6IEFncmVlIHdpdGggUnVlZGlnZXIgVm9s ay4gU3VnZ2VzdCB1c2luZyBMYXJnZSBjb21tdW5pdHkgYW5kIHNhbWUgY29tbXVuaXR5IGRlZmlu aXRpb24uPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6YmxhY2siPkRvdWcgTTogSVhQIGNvdWxkIG9mZmVyIHRoaXMgYXMgc2VydmljZT88L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFj ayI+RGFuaWVsIEtvcHA6IFllcy48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+RG91Z2ggTTogbWFrZXMgc2Vuc2UuJm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6Ymxh Y2siPkpvYiBTbmlkZXJzOiBXaGF0IGlzIGxhY2tpbmcgaW4gdGhlIGRyYWZ0IGlzIHNlY3VyZSBi eSBkZWZhdWx0IGFwcHJvYWNoLiBTdWdnZXN0IGFiYW5kb25pbmcgdGhlIGRyYWZ0LiBTaG91bGQg bm90IGJlIHByb3BhZ2F0aW5nIHZhbGlkYXRpb24gc3RhdGUgb24gRWJncC48L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+RGFuaWVs IEtvcHA6IERvIG5vdCBhZ3JlZS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Sm9iIFNuaWRlcnM6IFNob3VsZCBub3QgcHJvcGFn YXRlIGludmFsaWRzLiBUaGlzIG1ha2VzIGl0IGluc2VjdXJlLjwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5SYW5keSBCdXNoOiBU cmFkZS1vZmYgaXMgd2hldGhlciB5b3UgYWN0IGZvciBJWFAgbWVtYmVyIG9yIHlvdSBnaXZlIElY UCBtZW1iZXIgbW9yZSBpbmZvcm1hdGlvbi4gUXVlc3Rpb24gZnJvbSBJWFAgbWVtYmVycyBwb3Yg aXMgYXJlIHlvdSBvdXRzb3VyY2luZyB5b3VyIHNlY3VyaXR5Ljwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5Eb3VnIE06IERvIG5v dCBhZ3JlZSB3aXRoIG91dHNvdXJjaW5nIHNlY3VyaXR5Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5BbGV4YW5kZXIgQXppbW92 OiBZb3UgZG8gaGF2ZSBmaWx0ZXJpbmcuIFdoeSBkb24ndCB5b3UgdXNlIG1hcmtpbmcgYW5kIHdo eSBhc2sgZm9yIGZsZXhpYmlsaXR5PyBXaGF0cyB0aGUgZGlmZmVyZW5jZT88L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+RGFuaWVs IEtvcHA6IFdvdWxkIGxpa2UgdG8gc3RhbmRhcmRpemUgdXNpbmcgYSBjb21tdW5pdHkgZm9yIGV2 ZXJ5b25lLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOmJsYWNrIj5SdWRpZ2hlciBWb2xrOiBDb25zaWRlciBzaWduYWxpbmcgZm9yIGd1eXMg d2hvIHNlbnQgeW91IGludmFsaWQgc3R1ZmY/PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPktleXVyIFBhdGVsOiBBbnkgZmxhdm9y IG9yIHNvbHV0aW9uIGRlcGxveWVkIHRvZGF5Pzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5EYW5pZWwgS29wcDogRHJvcHBpbmcg Zm9yIGRlZmF1bHQuIFRhZ2dpbmcgaXMgbm90IGRvbmUuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4zKSBSdWVkaWdlciBWb2xrIC0tIGRyYWZ0LXltYmstc2lk cm9wcy1vdi1lZ3Jlc3MtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6YmxhY2siPlJhbmR5IEJ1c2g6IFdoYXRldmVyIFJGQyBvcmlnaW4gY2xhcmlmaWNhdGlvbnMg YmVjYW1lIGlzIGluY29udmVuaWVudD8gV2UgZG8gaGF2ZSBTTk1QIE1JQnMgZm9yIGRyb3BwZWQg YW5ub3VuY2VtZW50cz88L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtjb2xvcjpibGFjayI+UnVlZGlnZXIgVm9sazogTm90IGludGVyZXN0ZWQgaW4gU05N UCBzdGF0cy48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjpibGFjayI+UmFuZHkgQnVzaDogVGFnZ2luZyBhbm5vdW5jZW1lbnRzIHdpdGggZGlm ZmVyZW50IG9yaWdpbi1hcyB0byBkaWZmZXJlbnQgcGVlcnM/PC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPlJ1ZWRpZ2VyIFZvbGs6 IEl0IHdvdWxkIGZhbGwgdW5kZXIgd2VpcmQgcG9saWN5IHByaW1pdGl2ZXMuPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPlJhbmR5 IEJ1c2g6IE15IHBvaW50IGlzIHRoZSBoYWNrIHlvdSB3YW50IGlzIHRvIHB1dCBhIGNoZWNrIGF0 IHRoZSBlbmQgb2YgZXhwb3J0IHBvbGljeSBzbyBJIGRvbid0IGhhdmUgdG8gZHVwbGljYXRlIGl0 Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OmJsYWNrIj5SdWVkaWdlciBWb2xrOiBXZSBhcmUgaW4gYWdyZWVtZW50Ljwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5Kb2huIFNj dWRkZXI6IFNpbmNlIHlvdXIgdGVsbGluZyBpbXBsZW1lbnRvcnMgaG93IHRvIGltcGxlbWVudCBh IHN0YW5kYXJkIG1ha2UgaXQgc3RhbmRhcmRzIGJhc2VkLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5BbmRyZXcgRHJheTogUGxl YXNlIGFzayB0aGUgaW1wbGVtZW50b3JzIHRvIHNob3cgd2hhdCBpcyBleGFjdGx5IGJlaW5nIGRy b3BwZWQuIEFub3RoZXIgY29tbWVudCBJIGhhdmUgdG8gZW5hYmxlIHBvbGljaWVzIHBlciBwZWVy Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OmJsYWNrIj5SYW5keSBCdXNoOiAmcXVvdDtkbyBOT1QgZG8gUk9BcyBmb3Igcm91dGVzIE5PVCBt ZWFudCBmb3IgREZaJnF1b3Q7IGlzIGZvciBBUzAgcGVlcnMgb25seS48L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+UnVlZGlnZXIg Vm9sazogWW91IHNlZW0gdG8gdGhpbmsgQVMwIGlzIHNwZWNpYWwuPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPlJhbmR5IEJ1c2g6 IExldHMgZGlmZmVyZW50aWF0ZSBBUzAgaW4gcGF0aCB2ZXJzdXMgUk9BLjwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5SdWVkaWdl ciBWb2xrOiBBZ3JlZS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtjb2xvcjpibGFjayI+Sm9obiBTY3VkZGVyOiBUaGUgc2xpZGUgaXMgY29tcGxldGVs eSB1bnJlbGF0ZWQgdG8gdGhlIHByZXNlbnRhdGlvbi48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+UnVlZGlnZXIgVm9sazogWWVz Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OmJsYWNrIj5Kb2huIFNjdWRkZXI6IExhc3Qgc2xpZGUgaXMgaW50ZXJlc3RpbmcgYW5kIHRob3Vn aHQgcHJvdm9raW5nLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOmJsYWNrIj5Kb2IgU25pZGVyczogVGhlcmUgbWF5IGJlIGV4cGxhbmF0aW9u cyBhcyB0byB3aHkgeW91IGFyZSBzZWVpbmcgdW53YW50ZWQgQVNlcywgQ3VzdG9tZXJzIG1ha2Ug Uk9BcyB3aXRoIHByaXZhdGUgQVNlcyBhcyB0YWdzLCB0eXBvcywgZXRjLjwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5SdWVkaWdl cjogT25seSB3aGVuIHNvbWVvbmUgcHJlc2VudHMgdGhlbiBhbmQgb25seSB0aGVuIGl0IGdldHMg Zml4ZWQuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6YmxhY2siPkplZmYgSHVzdG9uOiBJZiB5b3UgcmVhbGx5IHdhbnRlZCB0byB1bmRlcnN0 YW5kIHZhbGlkaXR5IG9mIFJPQSB3aHkgZG9uJ3QgeW91IHNpZ24gd2l0aCBBUy48L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+UnVl ZGlnZXIgVm9sazogQXJlIHlvdSBzdWdnZXN0aW5nIHdlIG1pbWljIHdoZXJlIEFkZHJlc3MgYW5k IEFTIG11c3QgYmUgc2lnbmVkLiBXaGF0IEkgc3VnZ2VzdCBpcyBzaW1wbGUgYW5kIHN0cmFpZ2h0 Zm9yd2FyZC48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjpibGFjayI+RG91ZyBNLiBXaHkgaXMgdGhpcyBzdHVmZiBhcHBlYXJpbmcgaW4gZ2xv YmFsIFJQS0kuIElzIHRoaXMgaWdub3JhbmNlPzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5SdWVkaWdlciBWb2xrOiBUeXBvcywg Zm9sa3Mgbm90IGFkaGVyaW5nIHRvIGd1aWRlbGluZXMgYW5kIGZvbGtzIG5vdCBrbm93aW5nIHdo YXQgdGhleSBhcmUgZG9pbmcuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPkRvdWcgTS4gY29uY2VybmVkIHRoYXQgb25lIG9mZiB2 YWxpZGF0b3JzIG1pZ2h0IGNsZWFuIHRoaXMgdXAgYnV0IHRoZSBwcm9ibGVtcyBtYXkgbm90IGJl IHNvbHZlZD88L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjpibGFjayI+UnVkZWdlciBWb2xrOiBTdWdnZXN0IGEgQkNQLjwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpi bGFjayI+NCkgU3JpcmFtIEsuIOKAkyBSUEtJL1JPViBkYXRhIGFuYWx5c2lzIHdpdGggZGV0YWls IGNoYXJhY3Rlcml6YXRpb24gb2YgSW52YWxpZCByb3V0ZXM8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPkFu ZHJleSBSLjogSG93IGRvZXMgaXQgd29yaz8gV2hhdCBpcyB0aGUgcXVlcnkgbWVjaGFuaXNtPzwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJs YWNrIj5TcmlyYW06IFdlIGNhbiBnaXZlIHlvdSBhIGdsb2JhbCB2aWV3IG9yIGEgdmlldyBwZXIg QVMuIERvbid0IHRoaW5rIGl0IGlzIHJlYWR5IGJ1dCBjYW4gZmFjaWxpdGF0ZSB0aGF0Ljwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjpibGFjayI+NSkgR2VvcmdlIE1pY2hlbHNvbiDigJMgUlBLSSBWYWxpZGF0aW9uIFJl Y29uc2lkZXJlZDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Um9iIEF1c3RlaW46IERvbid0IGFncmVlIHdp dGggdGhlIGNoZWNrIGF0IGV2ZXJ5IGxldmVsLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5EaSBNYTogV2UgZG9u4oCZdCB1c2Ug T0lEIGJ1dCB3ZSB1c2UgYWxnb3JpdGhtLiBXZSBjYW4gc3dpdGNoIHRvIG5ldyB2YWxpZGF0aW9u Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OmJsYWNrIj5HZXJvZ2UgTS4gQ29vbC48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPjYpIEdlb3JnZSBNaWNo ZWxzb24g4oCTIFJlc291cmNlIFRhZyBBdHRlc3RhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtjb2xvcjpibGFjayI+Sm9iIFNuaWRlcnM6IFdvdWxkIGxpa2UgdG8gc2VlIHRoaXMg bW92ZSBmb3J3YXJkLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8aDIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDox NS43NXB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo3LjlwdDttYXJnaW4tbGVmdDow aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2s7Zm9udC13ZWln aHQ6bm9ybWFsIj43KSBPbGl2ZXIgQm9yY2hlcnQg4oCTIGRyYWZ0LWJvcmNoZXJ0LWJncHNlYy12 YWxpZGF0aW9uLXNpZ25hbGluZy0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L2gyPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOmJsYWNrIj5QcmVzZW50ZWQgQkdQU2VjIFZhbGlkYXRpb24gU3RhdGUgU2lnbmFsaW5n Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_29A62D3594A64764B76E27914F5BA7EAarrcuscom_-- From nobody Tue May 14 18:29:44 2019 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 C4E3412004E; Tue, 14 May 2019 18:29:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: sidrops-chairs@ietf.org, keyur@arrcus.com, sidrops@ietf.org, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155788378273.30210.16633881796896245126.idtracker@ietfa.amsl.com> Date: Tue, 14 May 2019 18:29:42 -0700 Archived-At: Subject: [Sidrops] sidrops - New Meeting Session Request for IETF 105 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: Wed, 15 May 2019 01:29:43 -0000 A new meeting session request has just been submitted by Keyur Patel, a Chair of the sidrops working group. --------------------------------------------------------- Working Group Name: SIDR Operations Area Name: Operations and Management Area Session Requester: Keyur Patel Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 62 Conflicts to Avoid: First Priority: IDR, GROW, LSVR, RTGWG, LSR, MPLS, PIM, SPRING 6man People who must be present: Keyur Patel Chris Morrow Warren "Ace" Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue May 14 18:55:17 2019 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 98EF3120088; Tue, 14 May 2019 18:55:15 -0700 (PDT) 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: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <155788531553.30142.11886031563955612950@ietfa.amsl.com> Date: Tue, 14 May 2019 18:55:15 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rtr-keying-06.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: Wed, 15 May 2019 01:55:16 -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 : Router Keying for BGPsec Authors : Randy Bush Sean Turner Keyur Patel Filename : draft-ietf-sidrops-rtr-keying-06.txt Pages : 19 Date : 2019-05-14 Abstract: BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the global Resource Public Key Infrastructure, enabling verification of BGPsec messages. This document describes two methods of generating the public-private key-pairs: router-driven and operator-driven. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-rtr-keying-06 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rtr-keying-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rtr-keying-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 16 14:51:32 2019 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 999F8120303; Thu, 16 May 2019 14:51:18 -0700 (PDT) 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: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Cc: morrowc@ops-netman.net, The IESG , sidrops@ietf.org, draft-ietf-sidrops-rtr-keying@ietf.org, sidrops-chairs@ietf.org, Chris Morrow , warren@kumari.net, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155804347861.19810.7639110584865753496.idtracker@ietfa.amsl.com> Date: Thu, 16 May 2019 14:51:18 -0700 Archived-At: Subject: [Sidrops] Protocol Action: 'Router Keying for BGPsec' to Proposed Standard (draft-ietf-sidrops-rtr-keying-06.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 May 2019 21:51:19 -0000 The IESG has approved the following document: - 'Router Keying for BGPsec' (draft-ietf-sidrops-rtr-keying-06.txt) as Proposed Standard This document is the product of the SIDR Operations Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ Technical Summary BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the global Resource Public Key Infrastructure, enabling verification of BGPsec messages. This document describes two methods of generating the public-private key-pairs: router-driven and operator-driven. Working Group Summary This document started out in the SIDR Working Group (in 2012), and was successfully WGLCed there (2017-04-05). It took some time to address comments, and the document was moved from SIDR (under Alvaro) to SIDROPS when the SIDR WG was shut down (2018-09-06). The consensus in SIDR was good, in SIDROPS there've been no objections. Document Quality The document is well written and easily read. Personnel Chris Morrow is DS Warren Kumari is RAD! From nobody Fri May 17 10:15:08 2019 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 C65D612027A; Fri, 17 May 2019 10:15:06 -0700 (PDT) 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: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <155811330675.26368.7037535825426235603@ietfa.amsl.com> Date: Fri, 17 May 2019 10:15:06 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-verification-00.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 May 2019 17:15:07 -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 : Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization Authors : Alexander Azimov Eugene Bogomazov Randy Bush Keyur Patel Job Snijders Filename : draft-ietf-sidrops-aspa-verification-00.txt Pages : 9 Date : 2019-05-17 Abstract: This document defines the semantics of an Autonomous System Provider Authorization object in the Resource Public Key Infrastructure to verify the AS_PATH attribute of routes advertised in the Border Gateway Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-00 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 17 10:15:37 2019 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 2D4A71203AA; Fri, 17 May 2019 10:15:25 -0700 (PDT) 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: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <155811332511.26509.4846139237460142094@ietfa.amsl.com> Date: Fri, 17 May 2019 10:15:25 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-profile-00.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 May 2019 17:15:29 -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 : A Profile for Autonomous System Provider Authorization Authors : Alexander Azimov Eugene Uskov Randy Bush Keyur Patel Job Snijders Russ Housley Filename : draft-ietf-sidrops-aspa-profile-00.txt Pages : 9 Date : 2019-05-17 Abstract: This document defines a standard profile for Autonomous System Provider Authorization in the Resource Public Key Infrastructure. An Autonomous System Provider Authorization is a digitally signed object that provides a means of verifying that a Customer Autonomous System holder has authorized a Provider Autonomous System to be its upstream provider and for the Provider to send prefixes received from the Customer Autonomous System in all directions including providers and peers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-profile/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-aspa-profile-00 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-profile-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/