From nobody Fri May 1 01:23:01 2020 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 1DA703A0A8A for ; Fri, 1 May 2020 01:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6g8OrTTAi3Lp for ; Fri, 1 May 2020 01:22:58 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A04B33A0A89 for ; Fri, 1 May 2020 01:22:58 -0700 (PDT) Received: from bufobufo.ripe.net ([193.0.23.13]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jUQwi-0005Hx-Vf for sidrops@ietf.org; Fri, 01 May 2020 10:22:56 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::f7f]) by bufobufo.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jUQwi-0002q6-TE for sidrops@ietf.org; Fri, 01 May 2020 10:22:56 +0200 From: Nathalie Trenaman Content-Type: multipart/alternative; boundary="Apple-Mail=_2D2BBC49-E2BD-43DE-A87E-0F00823DBB17" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <49B38F20-63F3-46EB-8B12-9C475524D17F@ripe.net> Date: Fri, 1 May 2020 10:22:56 +0200 To: SIDR Operations WG X-Mailer: Apple Mail (2.3608.80.23.2.2) X-ACL-Warn: Delaying message X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92af64fc86f05223e9cced25cca64c4c2a9 Archived-At: Subject: [Sidrops] Minutes, slides and recording from interim meeting 28 April 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, 01 May 2020 08:23:00 -0000 --Apple-Mail=_2D2BBC49-E2BD-43DE-A87E-0F00823DBB17 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, We have published the slides and minutes from the interim meeting last = Tuesday here: = https://datatracker.ietf.org/meeting/interim-2020-sidrops-01/session/sidro= ps = We have also published the recording from WebEx on YouTube: https://www.youtube.com/watch?v=3Db39ubLjomlw&feature=3Dyoutu.be. = Cheers, Nathalie --Apple-Mail=_2D2BBC49-E2BD-43DE-A87E-0F00823DBB17 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi all,

We have published the slides and minutes from the interim meeting last Tuesday here:

We have also published the recording from WebEx on YouTube:

Cheers,
Nathalie


--Apple-Mail=_2D2BBC49-E2BD-43DE-A87E-0F00823DBB17-- From nobody Sat May 2 11:39:50 2020 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 C8D7E3A17C4 for ; Sat, 2 May 2020 11:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnQE3lbFvwxT for ; Sat, 2 May 2020 11:39:44 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 6581D3A17C6 for ; Sat, 2 May 2020 11:39:44 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id t3so1477599otp.3 for ; Sat, 02 May 2020 11:39:44 -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=4iz1sirMI8MHsrhFYBD5LPfSHDOcHpJPZOSsSKmaCVc=; b=OXljyg3sG9QVGqC60P/GgT9lCdF8KhDwIMhoMkr8MeRB4ZXB06zhKDN/7ayHtonbNX wrS/wpNPC54k9H2pCiKcSpmfuUjD/31YVhD9eWqCWeh3WLd1fkz/LgxlG7EqBRXtgiYC LsCfnxSYZkoWEE4ktK2V0IUyRjkg94FoHvu+RcJ8a9V/KTSB6wIVJ5eSRo+CfWdzCZs1 AOCvBLbo6SiPA3nXf4q9MQeZcVag23KX6wwWQ3lrph/MJhlVtjQ4V3eEKvaVtkqqDXhD vWB3l704ARpUQ2sKkrSISN2H7tKRWzoUyMV4ggfteQHBbGKulYeo/LDWvf2zvzkhuKKS XK5w== 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=4iz1sirMI8MHsrhFYBD5LPfSHDOcHpJPZOSsSKmaCVc=; b=rcBqIJBBn/237tDQh83uJWdMOa8AlEAjjsnmNUZy8aWQCpFt1uxQJexjE6DRzPUdxP vJnQZzHN0+/iCZNX5VNrjCnuCyMlR5/H15DOgBXUVU7bSPQRU6JVly4QPcYtbRPCDg7k 0II+akWkJ7aaPucCjwPYJ98UZMBjGTbnRGbAu85KT1oDUuEiXgJTjpzeuFH5bq+/rb3D jzjm3zH68rkR18os2q43W4uoWMi4utPTUyRFsFqWUpZ6dbax+m3MysE7vG1KYyOoOKTP VGxWnRherXJcDS0a5zDkxv9VPzaYabC2JM69QN+zJV5xAWAwhWqaPkrxZCem9C477BPQ J6CQ== X-Gm-Message-State: AGi0PuZMPHpcT33/rg42J6lyqhWkIlOxbg0NDgNvtdaSfwbYnz9tInAu LWZuxPc9CNWBbIgt7f7TIJRhOb2XBLuLjK65Gm4= X-Google-Smtp-Source: APiQypLRHa3g4wHhp0kt8B0RPCX23oROUWdTwfbnVoSGD18bUM1UQzd3/3zKWkSOX+2GrD1N6lmWhlnTLsMOzAaLqw4= X-Received: by 2002:a05:6830:1e43:: with SMTP id e3mr8647397otj.248.1588444783187; Sat, 02 May 2020 11:39:43 -0700 (PDT) MIME-Version: 1.0 References: <87pnbrspdr.wl-morrowc@ops-netman.net> <24232.24434.41224.396200@oz.mt.att.com> <12F90135-5597-490B-947F-F588C2ED3B48@nlnetlabs.nl> In-Reply-To: <12F90135-5597-490B-947F-F588C2ED3B48@nlnetlabs.nl> From: Alexander Azimov Date: Sat, 2 May 2020 21:39:31 +0300 Message-ID: To: Tim Bruijnzeels Cc: Job Snijders , Jay Borkenhagen , SIDR Operations WG Content-Type: multipart/alternative; boundary="0000000000000c18af05a4ae9fcf" Archived-At: Subject: Re: [Sidrops] ASPA duplicates X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2020 18:39:48 -0000 --0000000000000c18af05a4ae9fcf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you all for comments. First of all, I'd like to address the reasons for that change at the side of RTR. And the comparison with ROA is important. The RTR documents don't say that "you MUST apply diff after receiving EOD", instead it is applied incrementally. So, the race in the updates for selected address space may invalidate the correct routes. One may say that finally, all data will become consistent and the router will make a proper marking. Unfortunately, it's not true for two reasons: - You never know when all data will arrive, there may be every kind of network issues between cache and router (and it's TCP after all); - Even if all updates finally arrives some routing software will keep the result of original verification. I'm not sure how it is covered with RFC, but I know that such implementations exist. As a result, we may end with hard to debug prefix propagation issues. These race conditions are partially addressed in the RFC8210bis by adding order to the ROA updates - from more specific to less specific routes. It solves the problem with less specifics, but issues for prefixes that have multiple records may still exist. In the ASPA, we are trying to prevent race conditions from happening. And the easiest way is to guarantee the atomicity of updates for each key-value pair. In our cases - to pack all ASPA records for the selected customer AS into one PDU. I hope this will make clear the motivation why ASPA PDU is different from what we have now for ROA. Btw, I will vote to update ROA too (and the update of RTR is a good time for such change, there is no requirement for compatibility between versions). The way new ASPA records are issued and the way they are received by RTR (rsync?) is another place for race conditions. And it seems native to guarantee consistency the same way - making a single ASPA object, thus preventing possible misconfigurations. Now the question - what should be done if RTR cache receives multiple RTR records for ASPA? Let's discuss possible scenarios: - There is misfunction at the level of RPKI software that issued records= ; If we face a bug in the hosting RPKI software it should be gracefully processed, without effect on operations. - Tim's example with administrative domain splitting; The administrative domain splitting in RPKI doesn't seem to be a good idea, it significantly increases chances to get in the state with a partial set of customer-providers pairs with hardly predictable outcomes. - Transfer between RIRs. And the last seems to be on the same board - such semistate isn't safe, and one should keep one record at any point in time. Keeping in mind that the absence of ASPA record is less dangerous then inconsistent state my thinking is that if RPKI cache receives multiple ASPA records for selected customers AS it should ignore all of them. IMO looks like a fair good compromise: prevent race conditions and also do not have an effect on operations if something goes wrong. =D1=81=D1=80, 29 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 15:26, Tim Bruijnz= eels : > Hi, > > > On 28 Apr 2020, at 19:03, Job Snijders wrote: > > > > On Tue, Apr 28, 2020, at 18:53, Jay Borkenhagen wrote: > >> The current ASPA Verification draft: > >> > >> https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-04 > >> > >> .... says in Section 3 "For a selected Customer AS MAY exist only > >> single ASPA object." > >> > >> I concur that an ASPA object should list every authorized upstream ASN > >> to avoid possible race conditions, and as such it makes sense for only > >> a single ASPA object to exist at any point in time. > >> > >> But how is that uniqueness to be ensured? What should RPs do if > >> multiple validated ASPA objects are ever found to exist? > > > > Good question. What should it do? > > In my mind it's good to that CAs can create a single ASPA object for a > customer ASN they hold for all their provider(*) ASNs. > > But, I think it may be better to cover that CAs SHOULD (or even MUST if > you will) combine all provider ASNs on a single ASPA objects as a separat= e > BCP, and leave a bit more flexibility in the profile and validation draft= s. > This makes it easier to change things, should we find that we need to > change our minds on what is best. > > I don't think that RPs have to check whether the CA did indeed use a > single ASPA object for a customer ASN. I think it should just validate al= l > ASPA objects it finds, and build a list Verified Asn Relations alternate acronym here>. Furthermore, I think that 8210bis should then > specify that the RP (cache) MUST exclude duplicates when sending these > relations to routers. > > And veering a bit further into that document, I am not sure why those > updates should be sent as a single PDU containing all current provider > ASNs. I think it make sense to do the same as with ROAs where > 'announcement' (add) or 'withdraw' VRPs (excluding duplicates) are sent > over RTR. I read the comment about race conditions, but I don't see how > this is an issue when such PDUs are sent as a typical exchange (section > 8.2) between a Cache Response and End of Data PDUs. > > *) relations as defined in draft, not necessarily the business relation. > > > I expect such duplicates *will* exist if ASPA were to be deployed for > real: in cases where an ASN is transferred from one RIR to another RIR an= d > one wishes to make before break. > > Well in that case one would expect objects for the same customer ASN in > different parts of the RPKI tree. > > But a similar issue could also come up if a parent issues the same ASN to > multiple children. Which could be a working model if a large operation > operates the same ASN globally, but has different teams managing it. In > that case an organisation could chooses to run a delegated CA and issue > certificates to child CAs in use by those teams. (I am not sure how likel= y > this is, you have much more operational insight than I do, but it's > definitely possible under the standards). > > In those cases any of those CAs can issue valid ASPA objects, and they > should be combined as above. > > Furthermore, the security considerations (section 8) of the AS path > verification draft can use some additional words to warn that this also > means that any ASPA issuer can potentially invalidate other users of the > same ASN if they exist. > > Maybe the idea of multiple parties operating the same ASN is ludicrous, > but then I think it would be good to have words that discourage delegatin= g > the same ASN to multiple CAs, and similarly, discourage issuing ASPA for > customer ASNs that are also delegated. > > Note that this issue is somewhat similar to ROAs for prefixes which are > also (partially) delegated, or received by multiple organisations. > > > > > > > > Kind regards, > > > > Job > > > > _______________________________________________ > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --=20 Best regards, Alexander Azimov --0000000000000c18af05a4ae9fcf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you all for comments.

First of al= l, I'd like to address the reasons for that change at the side of RTR.<= /div>

And the comparison with ROA is important. The RTR = documents don't say that "you MUST apply diff after receiving EOD&= quot;, instead it is applied incrementally. So, the race in the updates for= selected address space may invalidate the correct routes. One may say that= finally, all data will become consistent and the router will make a proper= marking. Unfortunately, it's not true for two reasons:
    <= li>You never know when all data will arrive, there may be every kind of net= work issues between cache and router (and it's TCP after all);
  • = Even if all updates finally arrives some routing software will keep the res= ult of original verification. I'm not sure how it is covered with RFC, = but I know that such=C2=A0implementations exist.
As a result,= we may end with hard to debug prefix propagation issues. These race condit= ions are partially addressed in the RFC8210bis by adding order to the ROA u= pdates - from more specific to less specific routes. It solves the problem = with less specifics, but issues for prefixes that have multiple records may= still exist.

In the ASPA, we are trying to = prevent race conditions from happening. And the easiest way is to guarantee= the atomicity of updates for each key-value pair. In our cases - to pack a= ll ASPA records for the selected customer AS into one PDU. I hope this will= make clear the motivation why ASPA PDU is different from what we have now = for ROA. Btw, I will vote to update ROA too (and the update of RTR is a goo= d time for such change, there is no requirement for compatibility between v= ersions).

The way new ASPA records are issued and = the way they are received by RTR (rsync?) is another place for race conditi= ons. And it seems native to guarantee consistency the same way - making a s= ingle ASPA object,=C2=A0thus preventing possible misconfigurations.

Now the question - what should be done if RTR cache recei= ves multiple RTR records for ASPA? Let's discuss possible scenarios:
  • There is misfunction=C2=A0at the level of RPKI software tha= t issued records;
If we face a bug in the hosting RPKI softwa= re it should be gracefully processed, without effect on operations.
  • Tim's example with administrative domain splitting;
=
The administrative domain splitting in RPKI doesn't seem to be a g= ood idea, it significantly increases chances to get in the state with a par= tial set of customer-providers pairs with hardly predictable outcomes.=C2= =A0=C2=A0
  • Transfer between RIRs.
And the las= t seems to be on the same board - such semistate isn't safe, and one sh= ould keep one record at any point in=C2=A0time.

Keeping in mind that the absence of ASPA record is less dangerous then in= consistent state my thinking is that if RPKI cache receives multiple ASPA r= ecords for selected customers AS it should ignore all of them. IMO looks li= ke a fair good compromise: prevent race conditions and also do not have an= =C2=A0effect on operations if something goes wrong.

=D1=81=D1=80, 29 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 15:26, Tim = Bruijnzeels <tim@nlnetlabs.nl>= ;:
Hi,

> On 28 Apr 2020, at 19:03, Job Snijders <job@sobornost.net> wrote:
>
> On Tue, Apr 28, 2020, at 18:53, Jay Borkenhagen wrote:
>> The current ASPA Verification draft:
>>
>> https://tools.ietf.org/h= tml/draft-ietf-sidrops-aspa-verification-04
>>
>> .... says in Section 3 "For a selected Customer AS MAY exist = only
>> single ASPA object."
>>
>> I concur that an ASPA object should list every authorized upstream= ASN
>> to avoid possible race conditions, and as such it makes sense for = only
>> a single ASPA object to exist at any point in time.
>>
>> But how is that uniqueness to be ensured?=C2=A0 What should RPs do= if
>> multiple validated ASPA objects are ever found to exist?
>
> Good question. What should it do?

In my mind it's good to that CAs can create a single ASPA object for a = customer ASN they hold for all their provider(*) ASNs.

But, I think it may be better to cover that CAs SHOULD (or even MUST if you= will) combine all provider ASNs on a single ASPA objects as a separate BCP= , and leave a bit more flexibility in the profile and validation drafts. Th= is makes it easier to change things, should we find that we need to change = our minds on what is best.

I don't think that RPs have to check whether the CA did indeed use a si= ngle ASPA object for a customer ASN. I think it should just validate all AS= PA objects it finds, and build a list Verified Asn Relations <or insert = alternate acronym here>. Furthermore, I think that=C2=A0 8210bis should = then specify that the RP (cache) MUST exclude duplicates when sending these= relations to routers.

And veering a bit further into that document, I am not sure why those updat= es should be sent as a single PDU containing all current provider ASNs. I t= hink it make sense to do the same as with ROAs where 'announcement'= (add) or 'withdraw' VRPs (excluding duplicates) are sent over RTR.= I read the comment about race conditions, but I don't see how this is = an issue when such PDUs are sent as a typical exchange (section 8.2) betwee= n a Cache Response and End of Data PDUs.

*) relations as defined in draft, not necessarily the business relation.
> I expect such duplicates *will* exist if ASPA were to be deployed for = real: in cases where an ASN is transferred from one RIR to another RIR and = one wishes to make before break.

Well in that case one would expect objects for the same customer ASN in dif= ferent parts of the RPKI tree.

But a similar issue could also come up if a parent issues the same ASN to m= ultiple children. Which could be a working model if a large operation opera= tes the same ASN globally, but has different teams managing it. In that cas= e an organisation could chooses to run a delegated CA and issue certificate= s to child CAs in use by those teams. (I am not sure how likely this is, yo= u have much more operational insight than I do, but it's definitely pos= sible under the standards).

In those cases any of those CAs can issue valid ASPA objects, and they shou= ld be combined as above.

Furthermore, the security considerations (section 8) of the AS path verific= ation draft can use some additional words to warn that this also means that= any ASPA issuer can potentially invalidate other users of the same ASN if = they exist.

Maybe the idea of multiple parties operating the same ASN is ludicrous, but= then I think it would be good to have words that discourage delegating the= same ASN to multiple CAs, and similarly, discourage issuing ASPA for custo= mer ASNs that are also delegated.

Note that this issue is somewhat similar to ROAs for prefixes which are als= o (partially) delegated, or received by multiple organisations.




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


--
Best regards,
Alexander Azi= mov
--0000000000000c18af05a4ae9fcf-- From nobody Sat May 2 12:01:57 2020 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 E3C3E3A17F7 for ; Sat, 2 May 2020 12:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GE1EGtMUkpVd for ; Sat, 2 May 2020 12:01:53 -0700 (PDT) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (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 3C14D3A17F6 for ; Sat, 2 May 2020 12:01:53 -0700 (PDT) Received: by mail-yb1-xb36.google.com with SMTP id o198so6809138ybg.10 for ; Sat, 02 May 2020 12:01:53 -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=9FJemeQstTsnqZJx8Fh8aW7Lpj4CZxaA6lALVz2WhB4=; b=o3ClUHdED1DGrs0j7IAOnw6fQBfk5tfsKF3LtMWaaYW0KXKPQjc8hIITO+vbqT+KYY +BTcX8oy2atnsnenb7fPoOlcBIyjkWsZoqxfuetL76PT2Q4abCCkfuPsMm1QDge52Hu+ s56rlfernCe01/anLCBB1KfnyKEn59oydo85KQVC1RplGlXbx+IPtnhhGxb/J3FgAKmf uiJaBUMa7abO/bI5swk0RPJgFAlKj/BpY8fgR9jfriNoHy7OvPhKJhH1mHxtctLzk4EV w75Jp57t/PqmlTS7Eeyv0QCQ/F5/K68nkU7F/lxa3yndjliRKwytF2UfGhB23E7riGwJ KLPg== 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=9FJemeQstTsnqZJx8Fh8aW7Lpj4CZxaA6lALVz2WhB4=; b=djUPti1mBroig885kY6DDPBqqNRkauXeGLXHXFlEaVyb0T8MNKfJqJS255YB3Uv6EE VKYYo/oIOo0qyq4tAe5AQHX7zk8gWGxEfbSUcB85iOqpyxCR1Q4sWi/aeZ3NSlJy51Rp xhce1Elw4UZHR2T1KbIOS+JaqTAsF/MjUY8iENZzPz626aL8sT/bhmZCosYsEl3i2zjJ M6c8xKybdl4akAisgyzhRDvJPcvxb7HeThnt98VwOQvr9OexEHMy5hJJVi+Ub4oemiq2 M4oeKoCpAK7jyyUcaZ3K5CDLelPP7ykZQD5Ho/4ggnwgWZ1rXuVzIuM4f0hzeTSptHGL 4N/w== X-Gm-Message-State: AGi0PuYYOGSNFS9jF52UT3lRzVtmJZ8XhpQeCX9qgSi4PwH7sT7ukl9e tJL+JPUVT1oSIi7CHsNGXyUVl1bvKuVCmc8eomqYZ9/H X-Google-Smtp-Source: APiQypLVFyEHFbachIp2R3i5d0DA8/5BGpv83+tBsDAtDys+BNz0jRgPooKzprl0dgOqEjp4r8OpPW/M7GFgeQ5XPvQ= X-Received: by 2002:a05:6830:1e43:: with SMTP id e3mr8678329otj.248.1588445678709; Sat, 02 May 2020 11:54:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alexander Azimov Date: Sat, 2 May 2020 21:54:27 +0300 Message-ID: To: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" Cc: "rv@nic.dtag.de" , SIDR Operations WG Content-Type: multipart/related; boundary="0000000000006d448305a4aed48e" Archived-At: Subject: Re: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2020 19:01:55 -0000 --0000000000006d448305a4aed48e Content-Type: multipart/alternative; boundary="0000000000006d448105a4aed48d" --0000000000006d448105a4aed48d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yunan, Let say that that AS1 is the originator of the prefix, and has created ASPA records. Since AS2 is a peer it will not be included in the list of providers. The AS2 isn't creating any records + making the leak and AS3 is performing ASPA verification procedure. The 5.1 says: When a route is received from a customer, a literal peer, or by a RS at an IX, each pair (AS(I-1), AS(I)) MUST belong to customer-provider or sibling relationship In our case, AS3 needs to check that AS1 -> AS2 belongs to c2p pairs. It will check the existence of ASPA record for AS1 - it is present, then it will check the presence of AS2 in the list - it will not be there, thus making the path invalid. Let me know if you have further questions. =D1=81=D1=80, 29 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 05:21, Guyunan (Yu= nan Gu, IP Technology Research Dept. NW) : > Hi Alex and Ruediger, > > > > To continue our discussion at the meeting, let=E2=80=99s use the example = you > provided yesterday. Both lateral peering between AS1=E2=80=94AS2, and AS2= =E2=80=94AS3. > > > > First question, does AS1 or AS2 sign any ASPA object for this pair and > how? I see description for Sibling relation representation in Section 7, > but haven=E2=80=99t been able to find any for P2P. > > > > Second question, if yes to the above question, how does AS 3 use any of > the ASPA object(s) to detect the leak? And if no, how to detect the leak > anyway? > > > > Thanks. > > > > Yunan > > > > [image: 10.1.1.0/24] > [image: AS 1] [image: AS 2,AS 3] > > > --=20 Best regards, Alexander Azimov --0000000000006d448105a4aed48d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Yunan,

Let say that that AS1 is= the originator of the prefix, and has created ASPA records. Since AS2 is a= peer it will not be included in the list of providers. The AS2 isn't c= reating any records=C2=A0+ making the leak and AS3 is performing ASPA verif= ication procedure.
The 5.1 says:

   When a route is received fr=
om a customer, a literal peer, or by a RS
   at an IX, each pair (AS(I-1), AS(I)) MUST belong to customer-provider
   or sibling relationship

In our case, AS3 needs to check that AS1 -> AS2 belongs to =
c2p pairs. It will check the existence of ASPA record for AS1 - it is prese=
nt, then it will check the presence of AS2 in the list - it will not be the=
re, thus making the path invalid.

Let me know =
if you have further questions.

=D1=81=D1=80, 29 =D0=B0=D0=BF=D1=80. 20=
20 =D0=B3. =D0=B2 05:21, Guyunan (Yunan Gu, IP Technology Research Dept. NW=
) <guyunan@huawei.com>:
=












Hi Alex and Ruediger, 


=C2=A0


To continue our discussion at the meeting, let=E2=80=
=99s use the example you provided yesterday. Both lateral peering between A=
S1=E2=80=94AS2, and AS2=E2=80=94AS3.



=C2=A0


First question, does AS1 or AS2 sign any ASPA object=
 for this pair and how?=C2=A0 I see description for Sibling relation repres=
entation in Section 7, but haven=E2=80=99t been able to find any for P2P.



=C2=A0


Second question, if yes to the above question, how d=
oes AS 3 use any of the ASPA object(s) to detect the leak? And if no, how t=
o detect the leak anyway?



=C2=A0


Thanks.


=C2=A0


Yunan


=C2=A0



















3D"10.1.1.0/24"











3D"AS

3D"AS










=C2=A0









-- 
Best regards,
Alexander Azi=
mov


--0000000000006d448105a4aed48d--

--0000000000006d448305a4aed48e
Content-Type: image/png; name="image009.png"
Content-Disposition: inline; filename="image009.png"
Content-Transfer-Encoding: base64
Content-ID: <171d6b57e9dbdbb391>
X-Attachment-Id: 171d6b57e9dbdbb391

iVBORw0KGgoAAAANSUhEUgAAAGgAAAAlCAYAAACu2qwTAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO
xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAGBSURBVGje
7ZftjcMgDIYZofPw66bxHMkGbJAtWIZhXEgvKR+GouiqQu99JVdt6tjgBxyiGBpS27b9rOuqFEoB
QBAAARAEQBAAAdD4sqRYG/fNgBwbrVhpw+k0LZMPpw4jezHOVd+e/MFH88nH0tPfm3iLM6xV7zg/
DMgZ7SeimUhnA34U8Lky89+9ca76duYPQM4YHlYU78iT3vKIQ0RzAEqKFg94X2XEtlqMzjhXfbvy
/xbbtndg/P+eM1ywswOSJrC3j6xo7wLUk1+CWECOd1DUDmcHJBbvVUH+EFBP/nM3NFpk/H9ymACg
dwPKDgfFBlTtjvAVLe6Tz6BX+RtjKeAc15RkdchjAyoesOkpyhkSJyYVvdc39Wvlr58oJThcWwAz
7CBxZcWrVLpe6e9ynF5f8kfk7F2nlr/Wao/3m9p8ZgQ0o9qHg3H1TwCV7zYABAEQAEEABAEQAEEA
BEAoBQBBAARAEABBAARAEAABEDQUoPAFNp4ty3LbAYUP2Lh2B6WaqndH7933AAAAAElFTkSuQmCC
--0000000000006d448305a4aed48e
Content-Type: image/png; name="image010.png"
Content-Disposition: inline; filename="image010.png"
Content-Transfer-Encoding: base64
Content-ID: <171d6b57e9d1f3c04f2>
X-Attachment-Id: 171d6b57e9d1f3c04f2

iVBORw0KGgoAAAANSUhEUgAAAIoAAABACAYAAADF9O+2AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO
xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAauSURBVHja
7Z1LTBtnEMc59phjjzn2mGOPfUB4OGAgIU0ITShKKxRFVcCY9bKlNeUR1zxlaghgXkkToYZGcmkp
SoUoitpUFSpVK6uHSImiiKQlosYhFBSQvvq/sO16uzY29ppd71j6R8iPFeH77cw3882Ms5qamrK0
Fud0vlwtuCvL6r1fW7nBxexa38brNT4G5TuurRY0XA/KlcuNh6TXc+uGn+Iz5Y7e8Yu8q9jlcr2U
jt+ZFCnNLvx+Y1teBe/pK7D77ufYRv4udN5aK+2cZyd67rLTV35lZ4YCcelU38/iZ4rds8zSOLH6
Ro1vG+BUcR0OTmg5QotoQFBgOc7wvYPhxdyyCBNBq+tbdrL3p7ihiFcAp6hlejuPu7qaY/OFqoQu
O1kaA4AiAXLUPhqyXr69VT74W8rhiGpx+n9hRR9/uR52UX8RMDoF5SABiQZMts33rLKhx+V0Og/R
AusAlGre/a4eAFEK+x9r6/RGnn1kuaax7TVa5AMCBXdqGdc/U+j8YlVPgKhZGERQ5xo8HbTQaQbF
JrS8ml8/slTaPvdCr4AoVdz61Vqhfeh3uEla8DSAgjsTOQ+Eq0aBRFKZ50eWZx9dudjoKqJF1xCU
Cv7TvuLmqVWjAaLcuxz74MafBItGoFQKnlajQyIJeypLw3Xa5KYalPNC14XCjyZXMgESuWWx8Fef
UFY3RaDARFuEGxkFiTwisnBjS4LTeZggSAIUmGaYaD2Hv0nDEt6UW7jRhxQN7RMUpMCRDsddl6mQ
SCrtvMNKuCtzBMI+QHmb7/VY277ZyHRIJOHwEifdBEMCoNicLa/kc+MrmexylHrLu8AK6kce0mFi
AqCgzgNH+GaBRJ69pVR/nKBcENxnCxs/D5oNEim/kmsfC1IUFAco+XW+JZhhM4IiWhX3LEO5JUER
AxTxsM9xLSOyr8kk4lDLQnuVGKCc43u6rW0zW2YGhSKgOEBB3akZ8iZ751XmGToFCAwVUJCFRYGP
2SGRNrXZtuENcj8qoJzk+m+WtH9nekgkoa0EPUgEhwIU9N1o0VJhVKHFBP1IBIcCFHTtJdKQtW9N
LrPHwWXGq702G2J4PF68t/d18N4Hj+j8J92goPNO+zv1HvMHmQoM0vMh5pV+jgaT7BrR35O8UDaJ
GluCQwEK+nzTYk3CMPgXNyMXefd5bxzX8D5gbGE2wHjlNTSoVUEUSHAo9yhpiHjExYW7EMHYZP5J
OSg7ACR0LQ1BgdAcbzYQTnsDh98bWDgUFRTs8tPhdnZg2PlZ7n5gKRJxJ+kA5Wjd2JrZzn3C/+/K
8sFAsGIo4FQDJquwyb+eDrfjlW9GlQu9a1ni2dASKNqBIvsbPAnrUgQoSFtr7nZUHqruRox+ZK7p
gEDBBt9sSTcFKKIiQMHoCO1AecQWWJSHaoi78/5YexatQREPB2t9GyaBI+bfIgKUN2uHNzUDRbQQ
KlHN7vP+xVCk9dCBRUHyEUlIs21m97QoGHqjVemjuFGNZTkW/9ubxHRJ8k2v/KEBMMe7v0fC7a7p
QfEFRiNAMXvBEhUwKUAJA4JQ+X9RD9LVSFsTJLuHgs1Tm1W8+5Lp8igDgSNqgPwLSrXgOnXsw5vP
CJIdYTAhNYWpgIIwEDUYZmrRiCZ0IKATgcBQAQX/UE0K1aLEBQrqRLVOvOldsKg5tuHnNCQwBihm
6jemOpQkQIHQKYeOObOCglN0GrATByiwKvn24T+MOKMtaWvSPvcCky4JiDhAMeteBWc7GARIIXEC
oEBmS8Bh2jVGoxMMCYKCOwsTqc2QVzHrAWBKQIGqhA7e2uwPZTIkOxMiP3uKvmsCYZ+giFEQ7+ku
aZ3KyP0KIKGZsykCRczY8gP+0k9m1zMNFIxExWhUAiBFoECljoH54x3zhpl9v5fgUuFaafFTDAry
K6WOoR9OdN0xPCxwpXCptPAagALh/AOnqtbmqedGjIbEadXCBEGiNSiS3uG7mhApGKkiDqUDSKjR
gJw0ggIhnLTUD98vcc/q3hXh7AqWkLKuBwCK5IpOOry38PWyehyZASuCmXQ0EvSAQZGEL6xGZlMv
wODoAYDAilAiTUeg6AUYAIJGNpxTESA6BkUJDO7qosu3mZbQoP8GFfMY2wFA6Pt3DASKfMN71tHj
BjToRESVP2pyk6mgQ6SFsVkIczGWAk1aaKvA/H5aSIOCotz4oiUEBdwYUINFhptARRlU1DK9XdQ2
w+TChAXpdUwWwGfQqIbZahTmZigoaoKbQNkhVMV1OCodnU65zvOuaul1mk9vYlBIxtM/WRyVHTC6
Ub8AAAAASUVORK5CYII=
--0000000000006d448305a4aed48e
Content-Type: image/png; name="image011.png"
Content-Disposition: inline; filename="image011.png"
Content-Transfer-Encoding: base64
Content-ID: <171d6b57e9d201d7d03>
X-Attachment-Id: 171d6b57e9d201d7d03

iVBORw0KGgoAAAANSUhEUgAAANcAAABFCAYAAADZ03P9AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO
xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAt/SURBVHja
7V1dcBPXFfZjH/uYxzzmMY95TFsI/pfsJBSHP9dDGSbDdAAj765VJ3ItbEU1xmOPANmSfyi0TEM8
o9AAMeMhDNOmaUidFFR3hikkkyGkJkQ2f2YwM9v9VlqzklerlbR3tas9nvlm7NWPpbv3u+ec75x7
bk1vb28Na3CBwAt7/KEtm7lj73u4sfmNnbHln+2PiUAd/4el+u5TKTVquRNLyuObDsbv4jVv8aPT
e4WQNxAI/NSKz0wglAtmb7y/p//VHfxwuN4Xu7mxc+Jx4zvv32/5/SfiG8OfiluOfSluHU8awpaj
/5Rf4w3PiQ09p5d+cSD+pMk3vtDBDfKd/uArdBMJriAXrEp793Bow4HYCixQ88CsuHn0H4aJZBRv
jvxdbA6eewarByvY4R/yhUKhn9ANJVQdueD2bRVGxzZ2xh96Dp1baTv+L9MJldeySVaw+XcfPtrQ
GbsPYpPbSKgKcimkes03uewZmF19a+yaZaTKBQgNYm/yTaSIZARHk2uPEP61HUilR7Lf9PTX0k2u
XiDmRmyvRmcg+JJjyQWLsJmPzDQFPliyE6m0SNbgP53aLoyOUDzmXKSV5nD7m12Rj6AaI57XU5o3
cdPL+ZRmq+dB0StFQ1f8Zkt47qldSZULT//5FU9X7JqdVjSCPuBxbBNGjipKc1Ng5kHr4cuyalxM
PJ+rNP98f+wZyAalmfMHX7YNuTr8g0JD98m7v4xcdQSpctXFem7q+7f94R00ee1roRC/SwRYhcfh
CV1kojSDbFCakUtlrTQbetJOYeSIpy+xbGc30Iib2NTz59Qu/9DbNJntA38g8CLctkrE74rSLLmP
P7IQwQo+AZOx6d0z95xKKjVw4xp/+8f/7e0JNdPErrAYIbnpqNh57eDUA7htlVy4QTJFBIP1hBVl
Tq5qIpaaYHBvqbqjcviVMNRbx03fQ8WO3bwbWM9a3+Q9M5TmvA9gdccq72RXUFdJFE7csSKoJWTH
VS3c8U89fWcfOkFp3spH4uXEY5oXkS9o6D61WI3EUitJjfz01/D5aeJbowDWc5N3Xj/yV8fMEW//
x48bu2I3SlWa110AUxHgFVNc61TgRmMlpcnPFsg1whI4cU5BsYQLW4rSrDkQyA1VO7EUQEEkiZ4d
NgvRhNPnEzy4UpTmdQoOWFrN7qCWUgRLTVUc5gMpnJZDZ1NuVZqz/kD2Gkk2txBrrYpjYHYVEiwR
wjy0+0cOefvOLlWf0nxqEZpEUeSCawTT5zZiKYNWx5/4gdRDc1CNKZxSlOa1X+oOxm47sbTJLKB2
DcWhRI7y4IZFGgRDOV0hFTEda/mDr6DC2K3EUqzXhs74CsVe5eWxILe7QWlG+IQwqiC5dgrDRzz9
F1bdTC5ZOQzMPMD2BiJKicogH5lx0o6J8ufLB0vY16hLLlQHu2G1obwXO7jR+wFnan0Ti/kKfuVq
DGwyczuxFGD/kFmFm24BXGlUMrDYImJ3eN+7+LSNj5zUJBcqk+1WQFlRU9+beLRLCO0h0hgHCnFR
L+jWOYO9YVrqYQ12e7pxxckHLDRYcIg0xuH2sCKf0lyDngSWtEI7syh+l1oUBa3H5pZF/Hw3f0P/
PYw+j7EKRHgOFOTKFeQuV5rRVjA39qpBXwH2H+CGmEiJGsRQri+LEeV3TQJ+K14Vc3/wGvM/K3J9
yPkRcQwqhBRW5FWaa9AtxxKrJZEhMf8kmzyZ65GS3k8Ur86xWYXQx4GIY0zIQG7QTbWoxXg8NVYo
hQJIdevbDCmeiIkzZZKEIbkA9KOnpqKFgcM1cAYAxeraSnMNzJkVLmGaCOnf1a5h5FbGy8sXj+WN
vdi4hXrqDyEbLdzxS62HrzgqXpcXeVauYd/ZJx1CeN9zcvUmHlnhEkbUXzJ3oDKWyJhYkY6/WIoa
nr4PH249/uUXbWP/vgRI145tG08GFGyPJ2u3j197FWiLJl3bi8OaelST4nWZVErszmZhlhvt8KPT
a+RirfTILqHGj6ZLJ68uKrcx30AzXH1ky8WfWmmPfNKqEEi6tk9NLoV0GeLNZ70+dv2W+vG28etH
soiZec8MMW1nHduiX70kf24Dnw2xKfN4i0m8rjfHSkduhU8NXCB2g6Ol8ok65jn9fO1YyhpiAWiF
XPLkjCRfVBOoADEXSifmV0w6CGc+s/x58P93R6/mjT0RmzozXmdDLuSLkTdeIxfTAcoXG2WuJ+aX
s7+kjuWSY7Ni4rISgcY16DFeKauRQ0xeIZb0+4AuMaW/cx4fUL2WN0rMtuiCN1s9TcKz2af1XLYL
M4N4PUNIViEF8sXIG6vzXMxMu/zl9SzU/PNYS9ddPLP+eUWLIGVIqk6AHjFhgbKIJ1nIfMTUIK2C
ebyv+n8yTx6bFa/nzh+GizTyxsq2JddvksyFGzdNIr5aI2UsOakzPgtqq8daaTY3XrdGEEMHYaVd
n3VyqkPg6T+/ulMY6nOrAphxI7PGZFvs+p9yrRZ7cpkZrxv1qEwmFyUCs4GKFTcfN6SyXHcQt+2O
JvNuv2FagGBWvC65hIk56+IutRhGJSw6ao8ryTWe3CehfXf0vwXbHWCVZnUvTIvXtSwgI6uVK4ZR
8aXaJQx+tNIhDPVQ9YUxWFP07RzgHLgm3/hCFrlo20AatAuZ9nGZKYatVTe7pT98tUnwlQRttM3x
fEIXRRw3m0UuYGf3yKD30F8euHVgcGYuDqUm0hQRnwmjY3K3YiKW5hzK2ptT54t/j6DMfeb8CmrC
LhFhigP1u3wOuTqjM3Zf3fcya7DcGHtBJd3km0rROV12roy3P3Ir4teRy9I9OnYZFMkVhktMRCkN
SLgj8e52ciHnl3tAw7rBglqGk9XdkPfCilvfNfENtbAuHbD4LPNdTkC+Ym/NAevwDwqevsRyNQ9I
scfBEPIDuR3keFyrEvZfWEVLeEPkSpv76jm4TAt0oiQJG6ZYLZ2W1rqDtoU/erolNPu42gak+d2Z
H3f5Bw8QMcyD2w5hWFukdQ5jKDxoQjTR+t7co2oZDFhjWGUihLlw0/FBCgoVHhgaOC839tnrg5cd
vyp5+z9+DGtMZGADrOBYyd2SwsH54Xo7KAwNGtS0Vj56GSKHE1VEJPgQYxGxSNwwT8Q4v7JdGB3R
G4uiBg4qIs4OdlLSEDe6rmtqkcQL66T5Rn7662qu9Hlj6MrTVn78b4VSOMX71v7gy8gNOSF4xeqC
lZSqL6wnWAM3dbsa4y/EWV5u/HMjudGSBg9vDHUIhYp2rIrGACBjXshsExgKHNIijFPvLTlBxyJg
rjdx8f8YbXVe1gCiAhjbDuxCMoVUUHAoOWyP/FdD98m71VDtAze3rmvidjFnCJgyiGsk859OYYJb
/cVRC4kkJpHKftjbE2oGwZxc3ItOug3c5DfFhhemDiSq6jHB0Syyuf+CyFI1whduDp57hoYyKDbG
KkmT2cYWrCt+02lJZlhcHEeLFtWl7FBn5m+384cDEBPQ0RfdpVCSX46ChJUPOz3hgqJ3A75wBzfI
u7lTk5MAdwpxOlIiTojDMFdhcXHec6nf2ZJBRfs27HVB5TBaT8HaIDYCYH1g5dTAUSzK46i4xmuw
bwhbqOGCUhW7c4GUCFIjlQgfDFfxSBYW8VW53lBl3ATJ2iA2AmB9YOXUwBlHyuMko1enVI/wAYun
nUiGDmhY+GFhzTj8kG42oWLA4gmSQYyq1AZdxFUIWeAhocWgmWEG3WSCLQQPiFIQwmA9rKjuQOoI
+7DkjcFSyMLCQ6KbS7ANIITBeiA2h3uG2BuqsBl5MlSLoK8g+tujPyVSR9jgyLJPJd1Ugj2tmeSe
IfaGKoxjrpBDVQQvuHGI1QC1lYM1Uq43D8ymBbLguWewiGhgioade/zhdqsav9KNJDgCyKEqghfc
OMRqgKJAA7BGyvUd/HBYFse4Qb5Sh8fTjSMQGOH/gyyQiJxRDxgAAAAASUVORK5CYII=
--0000000000006d448305a4aed48e--


From nobody Sat May  2 14:02:38 2020
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 A95483A00D4 for ; Sat,  2 May 2020 14:02:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.487
X-Spam-Level: 
X-Spam-Status: No, score=0.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, MISSING_MIMEOLE=1.899, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9F_TFpwTGgbi for ; Sat,  2 May 2020 14:02:34 -0700 (PDT)
Received: from yudhisthira.itb.ac.id (yudhisthira.itb.ac.id [167.205.1.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A34F3A00D3 for ; Sat,  2 May 2020 14:02:33 -0700 (PDT)
X-ASG-Debug-ID: 1588453347-0ef5d76b17209f170001-0d23Qc
Received: from mx6.itb.ac.id (mx6.itb.ac.id [167.205.23.26]) by yudhisthira.itb.ac.id with ESMTP id TuNWefy9OXmfsDjT; Sun, 03 May 2020 04:02:27 +0700 (WIB)
X-Barracuda-Envelope-From: rifqyhakimi@stei.itb.ac.id
X-Barracuda-Effective-Source-IP: mx6.itb.ac.id[167.205.23.26]
X-Barracuda-Apparent-Source-IP: 167.205.23.26
Received: from [192.168.1.2] (unknown [202.151.12.191]) (Authenticated sender: rifqyhakimi@itb.ac.id) by mx6.itb.ac.id (Postfix) with ESMTPSA id 49F1ll1sKLz23yS; Sun,  3 May 2020 04:02:27 +0700 (WIB)
Date: Sun, 03 May 2020 04:02:24 +0700
Message-ID: <64da0db8-9f23-4ce4-b870-b99066e50eb6@email.android.com>
X-ASG-Orig-Subj: Re: [Sidrops] ASPA duplicates
X-Android-Message-ID: <64da0db8-9f23-4ce4-b870-b99066e50eb6@email.android.com>
In-Reply-To: 
From: rifqyhakimi@stei.itb.ac.id
To: Alexander Azimov 
Cc: Tim Bruijnzeels , Job Snijders , Jay Borkenhagen , SIDR Operations WG 
Importance: Normal
X-Priority: 3
X-MSMail-Priority: Normal
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
X-Barracuda-Connect: mx6.itb.ac.id[167.205.23.26]
X-Barracuda-Start-Time: 1588453347
X-Barracuda-URL: https://167.205.1.122:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at itb.ac.id
X-Barracuda-Scan-Msg-Size: 9072
X-Barracuda-BRTS-Status: 1
X-Barracuda-Bayes: SPAM GLOBAL 0.9998 1.0000 4.3405
X-Barracuda-Spam-Score: 4.34
X-Barracuda-Spam-Status: No, SCORE=4.34 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE, MIME_HTML_ONLY,  MISSING_MIMEOLE, NO_REAL_NAME
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.81583 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 MIME_HTML_ONLY         BODY: Message only has text/html MIME parts 0.00 NO_REAL_NAME           From: does not include a real name 0.00 HTML_MESSAGE           BODY: HTML included in message 0.00 MISSING_MIMEOLE        Message has X-MSMail-Priority, but no X-MimeOLE
Archived-At: 
Subject: Re: [Sidrops] ASPA duplicates
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 02 May 2020 21:02:37 -0000

PGRpdiBkaXI9J2F1dG8nPk1tYiZuYnNwOyZuYnNwOzxicj48YnI+PGRpdiBkYXRhLXNtYXJ0bWFp
bD0iZ21haWxfc2lnbmF0dXJlIj5TZW50IGZyb20gQW5kcm9pZCBkZXZpY2U8L2Rpdj48L2Rpdj48
ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiAz
IE1heSAyMDIwIDAxOjM5LCBBbGV4YW5kZXIgQXppbW92ICZsdDthLmUuYXppbW92QGdtYWlsLmNv
bSZndDsgd3JvdGU6PGJyIHR5cGU9ImF0dHJpYnV0aW9uIiAvPjxibG9ja3F1b3RlIGNsYXNzPSJx
dW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlk
O3BhZGRpbmctbGVmdDoxZXgiPjxkaXYgZGlyPSJsdHIiPlRoYW5rIHlvdSBhbGwgZm9yIGNvbW1l
bnRzLjxkaXY+PGJyIC8+PC9kaXY+PGRpdj5GaXJzdCBvZiBhbGwsIEkmIzM5O2QgbGlrZSB0byBh
ZGRyZXNzIHRoZSByZWFzb25zIGZvciB0aGF0IGNoYW5nZSBhdCB0aGUgc2lkZSBvZiBSVFIuPC9k
aXY+PGRpdj48YnIgLz48L2Rpdj48ZGl2PkFuZCB0aGUgY29tcGFyaXNvbiB3aXRoIFJPQSBpcyBp
bXBvcnRhbnQuIFRoZSBSVFIgZG9jdW1lbnRzIGRvbiYjMzk7dCBzYXkgdGhhdCAmIzM0O3lvdSBN
VVNUIGFwcGx5IGRpZmYgYWZ0ZXIgcmVjZWl2aW5nIEVPRCYjMzQ7LCBpbnN0ZWFkIGl0IGlzIGFw
cGxpZWQgaW5jcmVtZW50YWxseS4gU28sIHRoZSByYWNlIGluIHRoZSB1cGRhdGVzIGZvciBzZWxl
Y3RlZCBhZGRyZXNzIHNwYWNlIG1heSBpbnZhbGlkYXRlIHRoZSBjb3JyZWN0IHJvdXRlcy4gT25l
IG1heSBzYXkgdGhhdCBmaW5hbGx5LCBhbGwgZGF0YSB3aWxsIGJlY29tZSBjb25zaXN0ZW50IGFu
ZCB0aGUgcm91dGVyIHdpbGwgbWFrZSBhIHByb3BlciBtYXJraW5nLiBVbmZvcnR1bmF0ZWx5LCBp
dCYjMzk7cyBub3QgdHJ1ZSBmb3IgdHdvIHJlYXNvbnM6PC9kaXY+PGRpdj48dWw+PGxpPllvdSBu
ZXZlciBrbm93IHdoZW4gYWxsIGRhdGEgd2lsbCBhcnJpdmUsIHRoZXJlIG1heSBiZSBldmVyeSBr
aW5kIG9mIG5ldHdvcmsgaXNzdWVzIGJldHdlZW4gY2FjaGUgYW5kIHJvdXRlciAoYW5kIGl0JiMz
OTtzIFRDUCBhZnRlciBhbGwpOzwvbGk+PGxpPkV2ZW4gaWYgYWxsIHVwZGF0ZXMgZmluYWxseSBh
cnJpdmVzIHNvbWUgcm91dGluZyBzb2Z0d2FyZSB3aWxsIGtlZXAgdGhlIHJlc3VsdCBvZiBvcmln
aW5hbCB2ZXJpZmljYXRpb24uIEkmIzM5O20gbm90IHN1cmUgaG93IGl0IGlzIGNvdmVyZWQgd2l0
aCBSRkMsIGJ1dCBJIGtub3cgdGhhdCBzdWNowqBpbXBsZW1lbnRhdGlvbnMgZXhpc3QuPC9saT48
L3VsPjxkaXY+QXMgYSByZXN1bHQsIHdlIG1heSBlbmQgd2l0aCBoYXJkIHRvIGRlYnVnIHByZWZp
eCBwcm9wYWdhdGlvbiBpc3N1ZXMuIFRoZXNlIHJhY2UgY29uZGl0aW9ucyBhcmUgcGFydGlhbGx5
IGFkZHJlc3NlZCBpbiB0aGUgUkZDODIxMGJpcyBieSBhZGRpbmcgb3JkZXIgdG8gdGhlIFJPQSB1
cGRhdGVzIC0gZnJvbSBtb3JlIHNwZWNpZmljIHRvIGxlc3Mgc3BlY2lmaWMgcm91dGVzLiBJdCBz
b2x2ZXMgdGhlIHByb2JsZW0gd2l0aCBsZXNzIHNwZWNpZmljcywgYnV0IGlzc3VlcyBmb3IgcHJl
Zml4ZXMgdGhhdCBoYXZlIG11bHRpcGxlIHJlY29yZHMgbWF5IHN0aWxsIGV4aXN0LjwvZGl2Pjwv
ZGl2PjxkaXY+PGJyIC8+PC9kaXY+PGRpdj5JbiB0aGUgQVNQQSwgd2UgYXJlIHRyeWluZyB0byBw
cmV2ZW50IHJhY2UgY29uZGl0aW9ucyBmcm9tIGhhcHBlbmluZy4gQW5kIHRoZSBlYXNpZXN0IHdh
eSBpcyB0byBndWFyYW50ZWUgdGhlIGF0b21pY2l0eSBvZiB1cGRhdGVzIGZvciBlYWNoIGtleS12
YWx1ZSBwYWlyLiBJbiBvdXIgY2FzZXMgLSB0byBwYWNrIGFsbCBBU1BBIHJlY29yZHMgZm9yIHRo
ZSBzZWxlY3RlZCBjdXN0b21lciBBUyBpbnRvIG9uZSBQRFUuIEkgaG9wZSB0aGlzIHdpbGwgbWFr
ZSBjbGVhciB0aGUgbW90aXZhdGlvbiB3aHkgQVNQQSBQRFUgaXMgZGlmZmVyZW50IGZyb20gd2hh
dCB3ZSBoYXZlIG5vdyBmb3IgUk9BLiBCdHcsIEkgd2lsbCB2b3RlIHRvIHVwZGF0ZSBST0EgdG9v
IChhbmQgdGhlIHVwZGF0ZSBvZiBSVFIgaXMgYSBnb29kIHRpbWUgZm9yIHN1Y2ggY2hhbmdlLCB0
aGVyZSBpcyBubyByZXF1aXJlbWVudCBmb3IgY29tcGF0aWJpbGl0eSBiZXR3ZWVuIHZlcnNpb25z
KS48L2Rpdj48ZGl2PjxiciAvPjwvZGl2PjxkaXY+VGhlIHdheSBuZXcgQVNQQSByZWNvcmRzIGFy
ZSBpc3N1ZWQgYW5kIHRoZSB3YXkgdGhleSBhcmUgcmVjZWl2ZWQgYnkgUlRSIChyc3luYz8pIGlz
IGFub3RoZXIgcGxhY2UgZm9yIHJhY2UgY29uZGl0aW9ucy4gQW5kIGl0IHNlZW1zIG5hdGl2ZSB0
byBndWFyYW50ZWUgY29uc2lzdGVuY3kgdGhlIHNhbWUgd2F5IC0gbWFraW5nIGEgc2luZ2xlIEFT
UEEgb2JqZWN0LMKgdGh1cyBwcmV2ZW50aW5nIHBvc3NpYmxlIG1pc2NvbmZpZ3VyYXRpb25zLjwv
ZGl2PjxkaXY+PGJyIC8+PC9kaXY+PGRpdj5Ob3cgdGhlIHF1ZXN0aW9uIC0gd2hhdCBzaG91bGQg
YmUgZG9uZSBpZiBSVFIgY2FjaGUgcmVjZWl2ZXMgbXVsdGlwbGUgUlRSIHJlY29yZHMgZm9yIEFT
UEE/IExldCYjMzk7cyBkaXNjdXNzIHBvc3NpYmxlIHNjZW5hcmlvczo8L2Rpdj48ZGl2Pjx1bD48
bGk+VGhlcmUgaXMgbWlzZnVuY3Rpb27CoGF0IHRoZSBsZXZlbCBvZiBSUEtJIHNvZnR3YXJlIHRo
YXQgaXNzdWVkIHJlY29yZHM7PC9saT48L3VsPjxkaXY+SWYgd2UgZmFjZSBhIGJ1ZyBpbiB0aGUg
aG9zdGluZyBSUEtJIHNvZnR3YXJlIGl0IHNob3VsZCBiZSBncmFjZWZ1bGx5IHByb2Nlc3NlZCwg
d2l0aG91dCBlZmZlY3Qgb24gb3BlcmF0aW9ucy48YnIgLz48L2Rpdj48dWw+PGxpPlRpbSYjMzk7
cyBleGFtcGxlIHdpdGggYWRtaW5pc3RyYXRpdmUgZG9tYWluIHNwbGl0dGluZzs8L2xpPjwvdWw+
PGRpdj5UaGUgYWRtaW5pc3RyYXRpdmUgZG9tYWluIHNwbGl0dGluZyBpbiBSUEtJIGRvZXNuJiMz
OTt0IHNlZW0gdG8gYmUgYSBnb29kIGlkZWEsIGl0IHNpZ25pZmljYW50bHkgaW5jcmVhc2VzIGNo
YW5jZXMgdG8gZ2V0IGluIHRoZSBzdGF0ZSB3aXRoIGEgcGFydGlhbCBzZXQgb2YgY3VzdG9tZXIt
cHJvdmlkZXJzIHBhaXJzIHdpdGggaGFyZGx5IHByZWRpY3RhYmxlIG91dGNvbWVzLsKgwqA8YnIg
Lz48L2Rpdj48dWw+PGxpPlRyYW5zZmVyIGJldHdlZW4gUklScy48L2xpPjwvdWw+PGRpdj5BbmQg
dGhlIGxhc3Qgc2VlbXMgdG8gYmUgb24gdGhlIHNhbWUgYm9hcmQgLSBzdWNoIHNlbWlzdGF0ZSBp
c24mIzM5O3Qgc2FmZSwgYW5kIG9uZSBzaG91bGQga2VlcCBvbmUgcmVjb3JkIGF0IGFueSBwb2lu
dCBpbsKgdGltZS48YnIgLz48L2Rpdj48ZGl2PjxiciAvPjwvZGl2PjxkaXY+S2VlcGluZyBpbiBt
aW5kIHRoYXQgdGhlIGFic2VuY2Ugb2YgQVNQQSByZWNvcmQgaXMgbGVzcyBkYW5nZXJvdXMgdGhl
biBpbmNvbnNpc3RlbnQgc3RhdGUgbXkgdGhpbmtpbmcgaXMgdGhhdCBpZiBSUEtJIGNhY2hlIHJl
Y2VpdmVzIG11bHRpcGxlIEFTUEEgcmVjb3JkcyBmb3Igc2VsZWN0ZWQgY3VzdG9tZXJzIEFTIGl0
IHNob3VsZCBpZ25vcmUgYWxsIG9mIHRoZW0uIElNTyBsb29rcyBsaWtlIGEgZmFpciBnb29kIGNv
bXByb21pc2U6IHByZXZlbnQgcmFjZSBjb25kaXRpb25zIGFuZCBhbHNvIGRvIG5vdCBoYXZlIGFu
wqBlZmZlY3Qgb24gb3BlcmF0aW9ucyBpZiBzb21ldGhpbmcgZ29lcyB3cm9uZy48YnIgLz48L2Rp
dj48L2Rpdj48ZGl2PjxiciAvPjwvZGl2PjwvZGl2PjxiciAvPjxkaXYgY2xhc3M9ImVsaWRlZC10
ZXh0Ij48ZGl2IGRpcj0ibHRyIj7RgdGALCAyOSDQsNC/0YAuIDIwMjAg0LMuINCyIDE1OjI2LCBU
aW0gQnJ1aWpuemVlbHMgJmx0OzxhIGhyZWY9Im1haWx0bzp0aW0mIzY0O25sbmV0bGFicy5ubCI+
dGltJiM2NDtubG5ldGxhYnMubmw8L2E+Jmd0Ozo8YnIgLz48L2Rpdj48YmxvY2txdW90ZSBzdHls
ZT0ibWFyZ2luOjBweCAwcHggMHB4IDAgMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigg
MjA0ICwgMjA0ICwgMjA0ICk7cGFkZGluZy1sZWZ0OjFleCI+SGksPGJyIC8+DQo8YnIgLz4NCiZn
dDsgT24gMjggQXByIDIwMjAsIGF0IDE5OjAzLCBKb2IgU25pamRlcnMgJmx0OzxhIGhyZWY9Im1h
aWx0bzpqb2ImIzY0O3NvYm9ybm9zdC5uZXQiPmpvYiYjNjQ7c29ib3Jub3N0Lm5ldDwvYT4mZ3Q7
IHdyb3RlOjxiciAvPg0KJmd0OyA8YnIgLz4NCiZndDsgT24gVHVlLCBBcHIgMjgsIDIwMjAsIGF0
IDE4OjUzLCBKYXkgQm9ya2VuaGFnZW4gd3JvdGU6PGJyIC8+DQomZ3Q7Jmd0OyBUaGUgY3VycmVu
dCBBU1BBIFZlcmlmaWNhdGlvbiBkcmFmdDo8YnIgLz4NCiZndDsmZ3Q7IDxiciAvPg0KJmd0OyZn
dDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2lkcm9w
cy1hc3BhLXZlcmlmaWNhdGlvbi0wNCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LWlldGYtc2lkcm9wcy1hc3BhLXZlcmlmaWNhdGlvbi0wNDwvYT48YnIgLz4NCiZndDsmZ3Q7IDxi
ciAvPg0KJmd0OyZndDsgLi4uLiBzYXlzIGluIFNlY3Rpb24gMyAmIzM0O0ZvciBhIHNlbGVjdGVk
IEN1c3RvbWVyIEFTIE1BWSBleGlzdCBvbmx5PGJyIC8+DQomZ3Q7Jmd0OyBzaW5nbGUgQVNQQSBv
YmplY3QuJiMzNDs8YnIgLz4NCiZndDsmZ3Q7IDxiciAvPg0KJmd0OyZndDsgSSBjb25jdXIgdGhh
dCBhbiBBU1BBIG9iamVjdCBzaG91bGQgbGlzdCBldmVyeSBhdXRob3JpemVkIHVwc3RyZWFtIEFT
TjxiciAvPg0KJmd0OyZndDsgdG8gYXZvaWQgcG9zc2libGUgcmFjZSBjb25kaXRpb25zLCBhbmQg
YXMgc3VjaCBpdCBtYWtlcyBzZW5zZSBmb3Igb25seTxiciAvPg0KJmd0OyZndDsgYSBzaW5nbGUg
QVNQQSBvYmplY3QgdG8gZXhpc3QgYXQgYW55IHBvaW50IGluIHRpbWUuPGJyIC8+DQomZ3Q7Jmd0
OyA8YnIgLz4NCiZndDsmZ3Q7IEJ1dCBob3cgaXMgdGhhdCB1bmlxdWVuZXNzIHRvIGJlIGVuc3Vy
ZWQ/wqAgV2hhdCBzaG91bGQgUlBzIGRvIGlmPGJyIC8+DQomZ3Q7Jmd0OyBtdWx0aXBsZSB2YWxp
ZGF0ZWQgQVNQQSBvYmplY3RzIGFyZSBldmVyIGZvdW5kIHRvIGV4aXN0PzxiciAvPg0KJmd0OyA8
YnIgLz4NCiZndDsgR29vZCBxdWVzdGlvbi4gV2hhdCBzaG91bGQgaXQgZG8/PGJyIC8+DQo8YnIg
Lz4NCkluIG15IG1pbmQgaXQmIzM5O3MgZ29vZCB0byB0aGF0IENBcyBjYW4gY3JlYXRlIGEgc2lu
Z2xlIEFTUEEgb2JqZWN0IGZvciBhIGN1c3RvbWVyIEFTTiB0aGV5IGhvbGQgZm9yIGFsbCB0aGVp
ciBwcm92aWRlcigqKSBBU05zLjxiciAvPg0KPGJyIC8+DQpCdXQsIEkgdGhpbmsgaXQgbWF5IGJl
IGJldHRlciB0byBjb3ZlciB0aGF0IENBcyBTSE9VTEQgKG9yIGV2ZW4gTVVTVCBpZiB5b3Ugd2ls
bCkgY29tYmluZSBhbGwgcHJvdmlkZXIgQVNOcyBvbiBhIHNpbmdsZSBBU1BBIG9iamVjdHMgYXMg
YSBzZXBhcmF0ZSBCQ1AsIGFuZCBsZWF2ZSBhIGJpdCBtb3JlIGZsZXhpYmlsaXR5IGluIHRoZSBw
cm9maWxlIGFuZCB2YWxpZGF0aW9uIGRyYWZ0cy4gVGhpcyBtYWtlcyBpdCBlYXNpZXIgdG8gY2hh
bmdlIHRoaW5ncywgc2hvdWxkIHdlIGZpbmQgdGhhdCB3ZSBuZWVkIHRvIGNoYW5nZSBvdXIgbWlu
ZHMgb24gd2hhdCBpcyBiZXN0LjxiciAvPg0KPGJyIC8+DQpJIGRvbiYjMzk7dCB0aGluayB0aGF0
IFJQcyBoYXZlIHRvIGNoZWNrIHdoZXRoZXIgdGhlIENBIGRpZCBpbmRlZWQgdXNlIGEgc2luZ2xl
IEFTUEEgb2JqZWN0IGZvciBhIGN1c3RvbWVyIEFTTi4gSSB0aGluayBpdCBzaG91bGQganVzdCB2
YWxpZGF0ZSBhbGwgQVNQQSBvYmplY3RzIGl0IGZpbmRzLCBhbmQgYnVpbGQgYSBsaXN0IFZlcmlm
aWVkIEFzbiBSZWxhdGlvbnMgJmx0O29yIGluc2VydCBhbHRlcm5hdGUgYWNyb255bSBoZXJlJmd0
Oy4gRnVydGhlcm1vcmUsIEkgdGhpbmsgdGhhdMKgIDgyMTBiaXMgc2hvdWxkIHRoZW4gc3BlY2lm
eSB0aGF0IHRoZSBSUCAoY2FjaGUpIE1VU1QgZXhjbHVkZSBkdXBsaWNhdGVzIHdoZW4gc2VuZGlu
ZyB0aGVzZSByZWxhdGlvbnMgdG8gcm91dGVycy48YnIgLz4NCjxiciAvPg0KQW5kIHZlZXJpbmcg
YSBiaXQgZnVydGhlciBpbnRvIHRoYXQgZG9jdW1lbnQsIEkgYW0gbm90IHN1cmUgd2h5IHRob3Nl
IHVwZGF0ZXMgc2hvdWxkIGJlIHNlbnQgYXMgYSBzaW5nbGUgUERVIGNvbnRhaW5pbmcgYWxsIGN1
cnJlbnQgcHJvdmlkZXIgQVNOcy4gSSB0aGluayBpdCBtYWtlIHNlbnNlIHRvIGRvIHRoZSBzYW1l
IGFzIHdpdGggUk9BcyB3aGVyZSAmIzM5O2Fubm91bmNlbWVudCYjMzk7IChhZGQpIG9yICYjMzk7
d2l0aGRyYXcmIzM5OyBWUlBzIChleGNsdWRpbmcgZHVwbGljYXRlcykgYXJlIHNlbnQgb3ZlciBS
VFIuIEkgcmVhZCB0aGUgY29tbWVudCBhYm91dCByYWNlIGNvbmRpdGlvbnMsIGJ1dCBJIGRvbiYj
Mzk7dCBzZWUgaG93IHRoaXMgaXMgYW4gaXNzdWUgd2hlbiBzdWNoIFBEVXMgYXJlIHNlbnQgYXMg
YSB0eXBpY2FsIGV4Y2hhbmdlIChzZWN0aW9uIDguMikgYmV0d2VlbiBhIENhY2hlIFJlc3BvbnNl
IGFuZCBFbmQgb2YgRGF0YSBQRFVzLjxiciAvPg0KPGJyIC8+DQoqKSByZWxhdGlvbnMgYXMgZGVm
aW5lZCBpbiBkcmFmdCwgbm90IG5lY2Vzc2FyaWx5IHRoZSBidXNpbmVzcyByZWxhdGlvbi48YnIg
Lz4NCjxiciAvPg0KJmd0OyBJIGV4cGVjdCBzdWNoIGR1cGxpY2F0ZXMgKndpbGwqIGV4aXN0IGlm
IEFTUEEgd2VyZSB0byBiZSBkZXBsb3llZCBmb3IgcmVhbDogaW4gY2FzZXMgd2hlcmUgYW4gQVNO
IGlzIHRyYW5zZmVycmVkIGZyb20gb25lIFJJUiB0byBhbm90aGVyIFJJUiBhbmQgb25lIHdpc2hl
cyB0byBtYWtlIGJlZm9yZSBicmVhay48YnIgLz4NCjxiciAvPg0KV2VsbCBpbiB0aGF0IGNhc2Ug
b25lIHdvdWxkIGV4cGVjdCBvYmplY3RzIGZvciB0aGUgc2FtZSBjdXN0b21lciBBU04gaW4gZGlm
ZmVyZW50IHBhcnRzIG9mIHRoZSBSUEtJIHRyZWUuPGJyIC8+DQo8YnIgLz4NCkJ1dCBhIHNpbWls
YXIgaXNzdWUgY291bGQgYWxzbyBjb21lIHVwIGlmIGEgcGFyZW50IGlzc3VlcyB0aGUgc2FtZSBB
U04gdG8gbXVsdGlwbGUgY2hpbGRyZW4uIFdoaWNoIGNvdWxkIGJlIGEgd29ya2luZyBtb2RlbCBp
ZiBhIGxhcmdlIG9wZXJhdGlvbiBvcGVyYXRlcyB0aGUgc2FtZSBBU04gZ2xvYmFsbHksIGJ1dCBo
YXMgZGlmZmVyZW50IHRlYW1zIG1hbmFnaW5nIGl0LiBJbiB0aGF0IGNhc2UgYW4gb3JnYW5pc2F0
aW9uIGNvdWxkIGNob29zZXMgdG8gcnVuIGEgZGVsZWdhdGVkIENBIGFuZCBpc3N1ZSBjZXJ0aWZp
Y2F0ZXMgdG8gY2hpbGQgQ0FzIGluIHVzZSBieSB0aG9zZSB0ZWFtcy4gKEkgYW0gbm90IHN1cmUg
aG93IGxpa2VseSB0aGlzIGlzLCB5b3UgaGF2ZSBtdWNoIG1vcmUgb3BlcmF0aW9uYWwgaW5zaWdo
dCB0aGFuIEkgZG8sIGJ1dCBpdCYjMzk7cyBkZWZpbml0ZWx5IHBvc3NpYmxlIHVuZGVyIHRoZSBz
dGFuZGFyZHMpLjxiciAvPg0KPGJyIC8+DQpJbiB0aG9zZSBjYXNlcyBhbnkgb2YgdGhvc2UgQ0Fz
IGNhbiBpc3N1ZSB2YWxpZCBBU1BBIG9iamVjdHMsIGFuZCB0aGV5IHNob3VsZCBiZSBjb21iaW5l
ZCBhcyBhYm92ZS48YnIgLz4NCjxiciAvPg0KRnVydGhlcm1vcmUsIHRoZSBzZWN1cml0eSBjb25z
aWRlcmF0aW9ucyAoc2VjdGlvbiA4KSBvZiB0aGUgQVMgcGF0aCB2ZXJpZmljYXRpb24gZHJhZnQg
Y2FuIHVzZSBzb21lIGFkZGl0aW9uYWwgd29yZHMgdG8gd2FybiB0aGF0IHRoaXMgYWxzbyBtZWFu
cyB0aGF0IGFueSBBU1BBIGlzc3VlciBjYW4gcG90ZW50aWFsbHkgaW52YWxpZGF0ZSBvdGhlciB1
c2VycyBvZiB0aGUgc2FtZSBBU04gaWYgdGhleSBleGlzdC48YnIgLz4NCjxiciAvPg0KTWF5YmUg
dGhlIGlkZWEgb2YgbXVsdGlwbGUgcGFydGllcyBvcGVyYXRpbmcgdGhlIHNhbWUgQVNOIGlzIGx1
ZGljcm91cywgYnV0IHRoZW4gSSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUgd29yZHMg
dGhhdCBkaXNjb3VyYWdlIGRlbGVnYXRpbmcgdGhlIHNhbWUgQVNOIHRvIG11bHRpcGxlIENBcywg
YW5kIHNpbWlsYXJseSwgZGlzY291cmFnZSBpc3N1aW5nIEFTUEEgZm9yIGN1c3RvbWVyIEFTTnMg
dGhhdCBhcmUgYWxzbyBkZWxlZ2F0ZWQuPGJyIC8+DQo8YnIgLz4NCk5vdGUgdGhhdCB0aGlzIGlz
c3VlIGlzIHNvbWV3aGF0IHNpbWlsYXIgdG8gUk9BcyBmb3IgcHJlZml4ZXMgd2hpY2ggYXJlIGFs
c28gKHBhcnRpYWxseSkgZGVsZWdhdGVkLCBvciByZWNlaXZlZCBieSBtdWx0aXBsZSBvcmdhbmlz
YXRpb25zLjxiciAvPg0KPGJyIC8+DQo8YnIgLz4NCjxiciAvPg0KPGJyIC8+DQomZ3Q7IDxiciAv
Pg0KJmd0OyBLaW5kIHJlZ2FyZHMsPGJyIC8+DQomZ3Q7IDxiciAvPg0KJmd0OyBKb2I8YnIgLz4N
CiZndDsgPGJyIC8+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPGJyIC8+DQomZ3Q7IFNpZHJvcHMgbWFpbGluZyBsaXN0PGJyIC8+DQomZ3Q7IDxh
IGhyZWY9Im1haWx0bzpTaWRyb3BzJiM2NDtpZXRmLm9yZyI+U2lkcm9wcyYjNjQ7aWV0Zi5vcmc8
L2E+PGJyIC8+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vc2lkcm9wcyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRy
b3BzPC9hPjxiciAvPg0KPGJyIC8+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXzxiciAvPg0KU2lkcm9wcyBtYWlsaW5nIGxpc3Q8YnIgLz4NCjxhIGhyZWY9
Im1haWx0bzpTaWRyb3BzJiM2NDtpZXRmLm9yZyI+U2lkcm9wcyYjNjQ7aWV0Zi5vcmc8L2E+PGJy
IC8+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpZHJv
cHMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lkcm9wczwvYT48YnIg
Lz4NCjwvYmxvY2txdW90ZT48L2Rpdj48YnIgY2xlYXI9ImFsbCIgLz48ZGl2PjxiciAvPjwvZGl2
Pi0tIDxiciAvPjxkaXYgZGlyPSJsdHIiPjxkaXYgZGlyPSJsdHIiPkJlc3QgcmVnYXJkcyw8ZGl2
PkFsZXhhbmRlciBBemltb3Y8L2Rpdj48L2Rpdj48L2Rpdj4NCjwvYmxvY2txdW90ZT48L2Rpdj48
YnI+PC9kaXY+


From nobody Sun May  3 12:02:10 2020
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 3719B3A114C for ; Sun,  3 May 2020 12:02:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level: 
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6GsKmRCf1at for ; Sun,  3 May 2020 12:02:07 -0700 (PDT)
Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (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 CA0C93A115A for ; Sun,  3 May 2020 12:02:06 -0700 (PDT)
Received: by mail-wm1-f43.google.com with SMTP id z6so6320376wml.2 for ; Sun, 03 May 2020 12:02:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition; bh=BwkYOBT80H25E1hevbz8BqtQYNExsAwC7YosuZMkO/o=; b=Oi73ldg/Yg9PLeeNQ0l4HFaaeAnNkaISYMjDMyJPwW+9KtwQPxRFmwvBBVn8gIi6mi a7qKlwy9K26sH81ZhRgHy6j/MsDqdgIgXlMMmM1jBQXormwUk/mKQ4Nvd49SRXH3aiA6 m2/gsXr2iXJLD7bnVMGISWgl/5UDzpF2E8y35niZSNv73G2qHcZlPI5OOd1GGlYuyZNN awL77iVnLajUm5Fn4G/jZhZ7xBrLwwPkhCqfj4zPfokVmHl/U5ugyYQsEGuML4xlq284 us1OWU4yyFHoBf3YdFsUDXkP82vAPxklbDDxybhGu4Gbp1Xv1wNJUJ4K4YuOyZg3WgLl aqBg==
X-Gm-Message-State: AGi0Pubvxt0jfBnkKcpj+rZZt75XwRSUKA4KRIJp/S25uWL/30622twJ Kzpd5iz6paBHJHPOUvAS/J8KVUtQ2mo=
X-Google-Smtp-Source: APiQypI7nVJnYqo7GRRBeKo7kPCHL1dO8rMfEOz2zq0HyeKPWhqMFi2iaKjC1p0cWkcRjmSAi5w0bA==
X-Received: by 2002:a7b:c7d2:: with SMTP id z18mr10945380wmk.72.1588532524161;  Sun, 03 May 2020 12:02:04 -0700 (PDT)
Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id e2sm15017114wrv.89.2020.05.03.12.02.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 May 2020 12:02:03 -0700 (PDT)
Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 1b78dfee; Sun, 3 May 2020 19:02:02 +0000 (UTC)
Date: Sun, 3 May 2020 19:02:02 +0000
From: Job Snijders 
To: sidrops@ietf.org
Message-ID: <20200503190202.GD57581@vurt.meerval.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: 
Subject: [Sidrops] About the use of manifests (follow-up from Apr Interim meeting)
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: Sun, 03 May 2020 19:02:08 -0000

Dear all,

At the last virtual interim meeting I heard several people suggestion
that "Section 6" needs stronger language. Unfortunately the webex audi
cut in and out so I didn't exactly catch section 6 of what RFC you were
talking about, so I hope I got the right one.

https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-manifest-validation/

Collaboration via email or github, I'm happy to convert received contributions
into the XML: https://github.com/job/draft-sidrops-manifest-validation/

Kind regards,

Job


From nobody Sun May  3 12:56:28 2020
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 67AB73A11BF for ; Sun,  3 May 2020 12:56:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.599
X-Spam-Level: 
X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tz7v4ygX-EOt for ; Sun,  3 May 2020 12:56:26 -0700 (PDT)
Received: from sonic317-26.consmr.mail.bf2.yahoo.com (sonic317-26.consmr.mail.bf2.yahoo.com [74.6.129.81]) (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 35D213A11C1 for ; Sun,  3 May 2020 12:56:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1588535785; bh=WDnTB7hJN6nmJbd22h4Ks569593DNdb2JOuhx+Fh4JI=;  h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=lnT36qcWeDxwuopjjuLqDQC8fP7etDyxbC4GYWhU4OAeUhGGmawn8S66uGeLAAjKlJkHyn/VLLV4dgp1/poNmVdJPSXhhwGovHIRTeu5wB9yqpyS5Ynt+npAWnYpmMokuyZqtYgreSbXWpLe7+w7I6ckwZpPawZh02Ik5TkZ2ZRdJXFzX5KpPg3SZ6a5mIwawX6bc/V8JkgcZJTus6PYJpJicwMrSYt7+KMhV52N1A81jMLXq01HhCsPa0THPV2+eND9Ekn1vJEH7m4T1rxp091sVGb9p2MKgaT5TK5ArzjiTYNXRFWbVkNBSEEX2MXVxJhFzU34zhQuXZ21521jWg==
X-YMail-OSG: vtZSYUgVM1lEOegK7i9sgJk2fu2JaIWu1t9bWGiSC_f6JPc5IKuJ6HrPW9yYR.I U7sPuTmSF8WJm.hX8v8JTIThjeoZHY8.F9uKv7sij0okI1Ahc0T07BSyEgY2XCy64IhirNfjriK6 YDnGxiwBB4oqq9hDEN.qIIm4msovTK_LiwLpZHLromOtfSSjQ_8tS5mRMDrfw5pcGu9fHOtBxYRP zOtYs6LtkhMn1Jzu2Fknc0.zp.8vHDSdsuDX6sBdtEbX3VBUNaWV5JUDnwDcNXdlJd.3zUkBAVwQ bBH_.koCKV9qswrD19mIj09x0uXf.SND8ToBNZxy21PBOlKvAwKA.gao9n_eaMA6yRRa_cJQZ9UN sZB5iqsejsGYKNdsa_T1VjPdjjmnlEoICU3FitsllFdXQWvqq5wGAAx.RsJNJrNEijvcojrPgVag ZtbuCnlPq43zOZrxIfh4I2ZPdalkRVNdmuGnk2cfPuthAIOwmJRRe_RevhTstzmZE9mx.ItddT4r La7L9OjkavVz50JS1Rf0AZCsm_yGdzn.DfDEImuhKIys9nAyJm_4eUQGCMoOxPZfvOH0XbZ9e7v_ q8rfL.0ECci3y2A_X0I2wNPUzoSPdygAQoKkUg9ikM9NVQGrZRkci.7Iu.C7wnZ7cYKXz542b3ht ggZnVjnEQfrTj40XHPzbOSm314X0RVhjcoWBxt_3hsogrtA.V7yq8FdHlP..k9Fx1sB.CPJLfRex T1PxO8eHBDCe556wUibMo0UBuYninVfbF4elnzBWkv0yNJhUJcZ6uBYvQGFtQ.s1ea_6vnBjrNaz RQocLYlS.pCB7QRiPPQFiM1gMF04u_gBMF9od3yQTfZpJNJLv6iSnHOjdh6psheD.y8GZaoCr0Vr .t3sWL1JVdVoAzP6WPCcV.dfrXOAPuY.UKmkt3YT2OwjNXYseP3BubvipFVgyqFcOsEOw28CBz2k CluyUmZlDIkAX_VLbQyJYLUp.Ydca1SAalz5fMii0_QzRXYAy6AeXBF7J1fKASFiSrnwn3oAYvHS 7b8atZznlX8r.bSIOcYxhbX1JfA2FYd38o7V8XbVAuHLknr.XVTcrL9r9Z91R3cZTFWOHkZ.j.XE i9f03_.bQoQyNjsmf8se70iGyIzec.rRRv0rYJSGixXKkg_aSQV0Gkc94tdRrwCptHRBfAzXxlmc fDGukovpMywLhDFABXv6xi25dSJvd0EKb8YRfP45mDTSZb4uJ00HHY3vfQ5LUxIvcOfX0KgMd1Yp r7zOhPOAYgmdmqjrmGqOZwFcQv4trKKCVHn.Iec4aZE7PCxChO5omv_gyn8eTQ0b_ZAmTH9sN0Z1 OszyaAABY_AIemXMI4seBTqZWHT2wC6ZqucF_eTKuKQJoOxYmdGpLtrpoW.Jb024kFPp3JfFjTjr 4KMvgPHx38wni3Cl0.wP0Wi8Oci3qQh46D3AGsM2ITji1raTeOswOhQJv
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Sun, 3 May 2020 19:56:25 +0000
Received: by smtp411.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1be2d75311af4204cf4e5fe7443ba179;  Sun, 03 May 2020 19:56:23 +0000 (UTC)
To: sidrops@ietf.org
References: <20200503190202.GD57581@vurt.meerval.net>
From: Stephen Kent 
Message-ID: <60c43db2-030e-723e-177c-13cc14758c64@verizon.net>
Date: Sun, 3 May 2020 15:56:22 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200503190202.GD57581@vurt.meerval.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] About the use of manifests (follow-up from Apr Interim meeting)
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: Sun, 03 May 2020 19:56:27 -0000

Job,

Yes, Section 6 of RFC 6486.

I believe that most of the changes will arise in 6.2, 6.3, 6.4, 6.5, and 
6.6.

I'll submit some proposed edits next week.

Steve


From nobody Sun May  3 13:01:18 2020
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 60FE63A11BF for ; Sun,  3 May 2020 13:01:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-642V292CEM for ; Sun,  3 May 2020 13:01:16 -0700 (PDT)
Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) (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 0EE513A040B for ; Sun,  3 May 2020 13:01:15 -0700 (PDT)
Received: by mail-wr1-f47.google.com with SMTP id d17so18388821wrg.11 for ; Sun, 03 May 2020 13:01:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=rD/IBqI8TL3NJrjBhCPhazMd/6Fbry4q6pOUzSY2RHY=; b=h2G49AKh3BUsOz6XdY6z0P/jwfZ74RQyFy+1hKoeHA+suYWNv15x1c8OCRW05dhree QOovYTsZSt5gNH9PJun3bpk4VoZ5jeeIL7FtZQshvf7Bq8GPDcB+9y01/oIM5AjCNEA2 5KghT6IxMbfRCVhvZ/+pm422wVGJl0hiuSHeyHbqPALLu47adUuoeGC+TYfy6+HBQ7N/ fBqfM1QO/Mqy4SWxahjMGhrQiLHPAAmhhWkn5aDm6Pl8t0jBG+UiUkfamvUKhue+QbYu mVjgpHRSOJt/td1scBLcXoVkktZIab73GmQRT7nvRl1qqE7/iB4zPKQdtoVVmY1KH85B K4Ww==
X-Gm-Message-State: AGi0PuYl9sgjSiqe51nTbvBXhqeCar/sDP8zJIb2n3DU0rjLoraix7uW HmqpXKLuoZmrPK0rwD1YU6eytMYom8M=
X-Google-Smtp-Source: APiQypK8CdYKN9/P4T4FXrHoNwqHj4CeVa6bEqDvtrxrDzO7T3S4yXiEl7Ds95Pl4k7AAo2imAFPXg==
X-Received: by 2002:adf:82ac:: with SMTP id 41mr13053861wrc.110.1588536073899;  Sun, 03 May 2020 13:01:13 -0700 (PDT)
Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id m188sm10254963wme.47.2020.05.03.13.01.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 May 2020 13:01:13 -0700 (PDT)
Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id b1f3eeec; Sun, 3 May 2020 20:01:12 +0000 (UTC)
Date: Sun, 3 May 2020 20:01:12 +0000
From: Job Snijders 
To: Stephen Kent 
Cc: sidrops@ietf.org
Message-ID: <20200503200112.GI57581@vurt.meerval.net>
References: <20200503190202.GD57581@vurt.meerval.net> <60c43db2-030e-723e-177c-13cc14758c64@verizon.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <60c43db2-030e-723e-177c-13cc14758c64@verizon.net>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: 
Subject: Re: [Sidrops] About the use of manifests (follow-up from Apr Interim meeting)
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: Sun, 03 May 2020 20:01:17 -0000

On Sun, May 03, 2020 at 03:56:22PM -0400, Stephen Kent wrote:
> Yes, Section 6 of RFC 6486.
> 
> I believe that most of the changes will arise in 6.2, 6.3, 6.4, 6.5, and
> 6.6.

The current draft (draft-spaghetti-sidrops-rpki-manifest-validation-00)
replaces Section 6 entirely. I don't know if that aligns with IETF
etiquette and it has to be done paragraph by paragraph, but I hope this
helps clarify our thinking.

> I'll submit some proposed edits next week.

Thank you! Edits welcome in unix patch format, in natural language in
email, whatever is easiest.

Kind regards,

Job


From nobody Mon May  4 01:21:32 2020
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 6C48C3A011F; Mon,  4 May 2020 01:21:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMgxcmevKJfx; Mon,  4 May 2020 01:21:29 -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 1575C3A0112; Mon,  4 May 2020 01:21:29 -0700 (PDT)
Received: from bufobufo.ripe.net ([193.0.23.13]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jVWLv-00080N-Nk; Mon, 04 May 2020 10:21:27 +0200
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::522]) by bufobufo.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jVWLv-0003A4-Km; Mon, 04 May 2020 10:21:27 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Nathalie Trenaman 
In-Reply-To: <29748EA5-6016-4E6D-9261-A069F7431390@nlnetlabs.nl>
Date: Mon, 4 May 2020 10:21:26 +0200
Cc: SIDROps Chairs , SIDR Operations WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: <265E2A85-0A83-4909-8A6A-C8FB7E48E6AF@ripe.net>
References: <29748EA5-6016-4E6D-9261-A069F7431390@nlnetlabs.nl>
To: Tim Bruijnzeels 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-ACL-Warn: Delaying message
X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92ae8f048f8e556d1b484e3448d5c3894b2
Archived-At: 
Subject: Re: [Sidrops] Adopt draft-sidrops-bruijnzeels-deprecate-rsync?
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, 04 May 2020 08:21:30 -0000

I support this.

Thanks,
Nathalie=20

> Op 29 apr. 2020, om 15:18 heeft Tim Bruijnzeels  het =
volgende geschreven:
>=20
> Dear co-chairs, WG,
>=20
> As mentioned yesterday I would like ask the chairs to do a call for =
adoption on:
> =
https://datatracker.ietf.org/doc/draft-sidrops-bruijnzeels-deprecate-rsync=
/
>=20
> I am also more than happy to discuss the content, and adapt following =
discussion, but maybe this is better done if adopted :)
>=20
> Thanks
> Tim


From nobody Mon May  4 03:22:37 2020
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 E346B3A0789 for ; Mon,  4 May 2020 03:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksE-vC7tzYYc for ; Mon,  4 May 2020 03:22:34 -0700 (PDT)
Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B8D63A0787 for ; Mon,  4 May 2020 03:22:34 -0700 (PDT)
Received: from bufobufo.ripe.net ([193.0.23.13]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jVYF7-0003MY-9w for sidrops@ietf.org; Mon, 04 May 2020 12:22:33 +0200
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::5d8]) by bufobufo.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jVYF7-00016F-79 for sidrops@ietf.org; Mon, 04 May 2020 12:22:33 +0200
From: Nathalie Trenaman 
Content-Type: multipart/alternative; boundary="Apple-Mail=_36717FF4-2EE5-4994-97C7-1F806FC8DC57"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: 
Date: Mon, 4 May 2020 12:22:33 +0200
To: SIDR Operations WG 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-ACL-Warn: Delaying message
X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a793387a82ca3fc6e48be02e88da762d2
Archived-At: 
Subject: [Sidrops] New on RIPE Labs: Lessons Learned on Improving RPKI
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, 04 May 2020 10:22:36 -0000

--Apple-Mail=_36717FF4-2EE5-4994-97C7-1F806FC8DC57
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Dear colleagues,

In the light of our recent RPKI outages, I wrote a RIPE Labs article on =
what exactly happened, what we did to fix things and what we learned =
along the way.=20
Transparency and trust are very important and I look forward to your =
comments and questions.=20
=
https://labs.ripe.net/Members/nathalie_nathalie/lessons-learned-on-improvi=
ng-rpki =


Kind regards,
Nathalie Trenaman
RIPE NCC


--Apple-Mail=_36717FF4-2EE5-4994-97C7-1F806FC8DC57
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

Dear colleagues,

In the light of our recent RPKI outages, I wrote a RIPE Labs article on what exactly happened, what we did to fix things and what we learned along the way. 
Transparency and trust are very important and I look forward to your comments and questions. 

Kind regards,
Nathalie Trenaman
RIPE NCC


--Apple-Mail=_36717FF4-2EE5-4994-97C7-1F806FC8DC57--


From nobody Mon May  4 05:07:11 2020
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 36A8A3A083D for ; Mon,  4 May 2020 05:07:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjSTosZuZbkU for ; Mon,  4 May 2020 05:07:09 -0700 (PDT)
Received: from sonic312-20.consmr.mail.bf2.yahoo.com (sonic312-20.consmr.mail.bf2.yahoo.com [74.6.128.82]) (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 1B8FD3A083B for ; Mon,  4 May 2020 05:07:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1588594028; bh=x1IP5uJtuBQXjT6FTdqEJLNn8qz2sEKVM11VFeUH8x0=;  h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject;  b=Y4/Y+d6vDIOn2jOKqVJEdRZNHxqluvRZ/oAD9aHCqCawNpdIMd5cjh3CAYM32Zb5B2OQHSy8v0tyjCki/9QEXkA6ewUXCvBbihE1nbtP9bJhxshp87hD/7pym4eiRnrgJNrKHEx/jqwIV49+lUB1RE/Omn/xmN82z1cxMt5Pp1bCuROWP2/wwWM6wLtG8smudKDlTqEC27VufTdlFQzuQ+J/2yaqDKgzfbFtiLsUJ5+TkkIoNUDZzLWuejbYPYNrGx9da9wltzcGERzihsviDe5Dg8FA5S7+/0Z9bDUsF8uLhhDeUY/vPH/CeI4FlwoJqWghXQp6kb5pZrUbtL9hVQ==
X-YMail-OSG: UXbr2HIVM1lvR_cjkSpYrdbBwnL_JhgGA6ksmMwsTOnIHVJ49nvdhpgTv4qi8VJ HyzAu9RdG9UidcixQwvqafyPBf_pfAmGSjqofM1BvReVWPh60HR8G_OVrQ9BpG9rD23TyW0GjQFP Ub74RE44tj8lztjKccmukDLz7pk9M5Y3TbWFAqqRwqMvwCC52SxcP830w.Km4bD3ln3veR4Z.98Q Dw6kt1AQvOeIWuvMtfbiYmLAYDTxwVOjRNcogQcRScWWZfTMn6VkNkq_da2rxWwX1pFiUfpxBKa2 6sfAwqPCRZEnUOdq13hu9il53Egv8xx_FS4e84spvh0LjXcVMNguFHgSXxheH0g_ICYhFQlZqwcD IwEuYata.3b0zIgdN.ibQ.u9UtNixjm0n6hZvH618G3LGaVR_oEAlXBglVdkJrwWXhqW.LxnoeLe uKw7bq7CMjHc5Odo7jimLFtlG_UXiuBjpbD662eqKygDzbEfEPKuRPc6mlRXAmmjH__AePR0sc2X txt3QTmlK3CrQzh_qTTUp8NRV7jwI8NRCGbd1y1Opww80Uc35rGEcYuhSyLXUQhXYVaux60Ngh43 P8WXGCbBkmmPh5aDzGep_tqv4ZwREj1WwLerbDNShuDsZjMMHi1sWTA4AtKGq.a03y5KVBMZKoFp fsnYkTzK_XXrYSl9of81ZtN5YknMtXsDV1A_oYfOLrzsFAOJK7tIXEsfFv0Hh7Hkqp5EvzSEH4iC nc4vQ8KlnDeZ.7Gb64aqO8lEyf_4HgcAQ4oEwung.LRs8OaT2VibIO6ECc.D.Y_UkB3d7cMM_E01 1_hTng.p4fRls6xr7NDF4dKKltZX0yrsuusASq._dJJ3ud41urEyfvtvvNATyat4XlmbytBW_Oen fc1VyrnfiyLTKIgQG0TOSu75WGjdPs1Midx7PjOG3fgZpm76UuQMPvvb1I3TJAmyGtZ6J66i03kw 4ruT8PEvg4df_JAdi5RARxOJ9M1BcaQSbqwyzJ.BJ9gj1VOeAIZzOnfptYbxSbjIyD_7wCaV0EiI AS1obexJb7HOE6rMq2PaWfQ._l7pLty8ZHogMeegAv9mhPhtRN48Tu54gItjBWkyhthlw8ibxj8I 9B1QM9RWsbe0sil_cixLAYrJjoaPQR4mCddQgwNy0jNVyTff3XMg_g3usiMnzdhwbqsPiVX7gNfR SyXB5NgCOsTbHYXGBIG6HuUhi3L5RUzvrl9KttOqVqWEHRm.DHQt1wpbAXZRKP.2ZcWHCx1QxIBl km6V8X1CDWdRCJEntD_uVPEnz3V7sjeU4pb_MOYXI4p_4tNU7T9QHk5zWKy769YxuGK21B3B4lgZ 4Gp4Uorh2QY4.K5BaOvUThTdJ5qrbfElj_p27mf.PaEAz0EiSuse8gDne4PfbHhHzhEGxvypUSvC qUj7DVVZS.smbKnU43HUw5HXjSL.OJKcnwA--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Mon, 4 May 2020 12:07:08 +0000
Received: by smtp413.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c74842441af2dae960e852d0c2853424;  Mon, 04 May 2020 12:07:05 +0000 (UTC)
To: Job Snijders 
Cc: sidrops@ietf.org
References: <20200503190202.GD57581@vurt.meerval.net> <60c43db2-030e-723e-177c-13cc14758c64@verizon.net> <20200503200112.GI57581@vurt.meerval.net>
From: Stephen Kent 
Message-ID: <2d3b8f2f-2872-3652-56d9-6f23f8eb56fa@verizon.net>
Date: Mon, 4 May 2020 08:07:04 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200503200112.GI57581@vurt.meerval.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] About the use of manifests (follow-up from Apr Interim meeting)
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, 04 May 2020 12:07:10 -0000

Job,
> On Sun, May 03, 2020 at 03:56:22PM -0400, Stephen Kent wrote:
>> Yes, Section 6 of RFC 6486.
>>
>> I believe that most of the changes will arise in 6.2, 6.3, 6.4, 6.5, and
>> 6.6.
> The current draft (draft-spaghetti-sidrops-rpki-manifest-validation-00)
> replaces Section 6 entirely. I don't know if that aligns with IETF
> etiquette and it has to be done paragraph by paragraph, but I hope this
> helps clarify our thinking.

I'll see what my co-authors think, but I'm more of an angle hair past 
guy myself :-)

I think most of 6.1 is OK and I plan to reuse most of it in the rev. The 
ambiguity arises in the discussion of what an RP SHOULD/MUST do when an 
object is missing or in error, which is what the latter parts of Section 
6 address.

Steve


From nobody Mon May  4 05:07:16 2020
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 69FAC3A083B for ; Mon,  4 May 2020 05:07:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9ZvnYnlqyyi for ; Mon,  4 May 2020 05:07:09 -0700 (PDT)
Received: from sonic312-20.consmr.mail.bf2.yahoo.com (sonic312-20.consmr.mail.bf2.yahoo.com [74.6.128.82]) (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 EF2A43A083A for ; Mon,  4 May 2020 05:07:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1588594028; bh=x1IP5uJtuBQXjT6FTdqEJLNn8qz2sEKVM11VFeUH8x0=;  h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject;  b=Y4/Y+d6vDIOn2jOKqVJEdRZNHxqluvRZ/oAD9aHCqCawNpdIMd5cjh3CAYM32Zb5B2OQHSy8v0tyjCki/9QEXkA6ewUXCvBbihE1nbtP9bJhxshp87hD/7pym4eiRnrgJNrKHEx/jqwIV49+lUB1RE/Omn/xmN82z1cxMt5Pp1bCuROWP2/wwWM6wLtG8smudKDlTqEC27VufTdlFQzuQ+J/2yaqDKgzfbFtiLsUJ5+TkkIoNUDZzLWuejbYPYNrGx9da9wltzcGERzihsviDe5Dg8FA5S7+/0Z9bDUsF8uLhhDeUY/vPH/CeI4FlwoJqWghXQp6kb5pZrUbtL9hVQ==
X-YMail-OSG: UXbr2HIVM1lvR_cjkSpYrdbBwnL_JhgGA6ksmMwsTOnIHVJ49nvdhpgTv4qi8VJ HyzAu9RdG9UidcixQwvqafyPBf_pfAmGSjqofM1BvReVWPh60HR8G_OVrQ9BpG9rD23TyW0GjQFP Ub74RE44tj8lztjKccmukDLz7pk9M5Y3TbWFAqqRwqMvwCC52SxcP830w.Km4bD3ln3veR4Z.98Q Dw6kt1AQvOeIWuvMtfbiYmLAYDTxwVOjRNcogQcRScWWZfTMn6VkNkq_da2rxWwX1pFiUfpxBKa2 6sfAwqPCRZEnUOdq13hu9il53Egv8xx_FS4e84spvh0LjXcVMNguFHgSXxheH0g_ICYhFQlZqwcD IwEuYata.3b0zIgdN.ibQ.u9UtNixjm0n6hZvH618G3LGaVR_oEAlXBglVdkJrwWXhqW.LxnoeLe uKw7bq7CMjHc5Odo7jimLFtlG_UXiuBjpbD662eqKygDzbEfEPKuRPc6mlRXAmmjH__AePR0sc2X txt3QTmlK3CrQzh_qTTUp8NRV7jwI8NRCGbd1y1Opww80Uc35rGEcYuhSyLXUQhXYVaux60Ngh43 P8WXGCbBkmmPh5aDzGep_tqv4ZwREj1WwLerbDNShuDsZjMMHi1sWTA4AtKGq.a03y5KVBMZKoFp fsnYkTzK_XXrYSl9of81ZtN5YknMtXsDV1A_oYfOLrzsFAOJK7tIXEsfFv0Hh7Hkqp5EvzSEH4iC nc4vQ8KlnDeZ.7Gb64aqO8lEyf_4HgcAQ4oEwung.LRs8OaT2VibIO6ECc.D.Y_UkB3d7cMM_E01 1_hTng.p4fRls6xr7NDF4dKKltZX0yrsuusASq._dJJ3ud41urEyfvtvvNATyat4XlmbytBW_Oen fc1VyrnfiyLTKIgQG0TOSu75WGjdPs1Midx7PjOG3fgZpm76UuQMPvvb1I3TJAmyGtZ6J66i03kw 4ruT8PEvg4df_JAdi5RARxOJ9M1BcaQSbqwyzJ.BJ9gj1VOeAIZzOnfptYbxSbjIyD_7wCaV0EiI AS1obexJb7HOE6rMq2PaWfQ._l7pLty8ZHogMeegAv9mhPhtRN48Tu54gItjBWkyhthlw8ibxj8I 9B1QM9RWsbe0sil_cixLAYrJjoaPQR4mCddQgwNy0jNVyTff3XMg_g3usiMnzdhwbqsPiVX7gNfR SyXB5NgCOsTbHYXGBIG6HuUhi3L5RUzvrl9KttOqVqWEHRm.DHQt1wpbAXZRKP.2ZcWHCx1QxIBl km6V8X1CDWdRCJEntD_uVPEnz3V7sjeU4pb_MOYXI4p_4tNU7T9QHk5zWKy769YxuGK21B3B4lgZ 4Gp4Uorh2QY4.K5BaOvUThTdJ5qrbfElj_p27mf.PaEAz0EiSuse8gDne4PfbHhHzhEGxvypUSvC qUj7DVVZS.smbKnU43HUw5HXjSL.OJKcnwA--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Mon, 4 May 2020 12:07:08 +0000
Received: by smtp413.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c74842441af2dae960e852d0c2853424;  Mon, 04 May 2020 12:07:05 +0000 (UTC)
To: Job Snijders 
Cc: sidrops@ietf.org
References: <20200503190202.GD57581@vurt.meerval.net> <60c43db2-030e-723e-177c-13cc14758c64@verizon.net> <20200503200112.GI57581@vurt.meerval.net>
From: Stephen Kent 
Message-ID: <2d3b8f2f-2872-3652-56d9-6f23f8eb56fa@verizon.net>
Date: Mon, 4 May 2020 08:07:04 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200503200112.GI57581@vurt.meerval.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] About the use of manifests (follow-up from Apr Interim meeting)
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, 04 May 2020 12:07:11 -0000

Job,
> On Sun, May 03, 2020 at 03:56:22PM -0400, Stephen Kent wrote:
>> Yes, Section 6 of RFC 6486.
>>
>> I believe that most of the changes will arise in 6.2, 6.3, 6.4, 6.5, and
>> 6.6.
> The current draft (draft-spaghetti-sidrops-rpki-manifest-validation-00)
> replaces Section 6 entirely. I don't know if that aligns with IETF
> etiquette and it has to be done paragraph by paragraph, but I hope this
> helps clarify our thinking.

I'll see what my co-authors think, but I'm more of an angle hair past 
guy myself :-)

I think most of 6.1 is OK and I plan to reuse most of it in the rev. The 
ambiguity arises in the discussion of what an RP SHOULD/MUST do when an 
object is missing or in error, which is what the latter parts of Section 
6 address.

Steve


From nobody Mon May  4 05:45:47 2020
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 83F5C3A084A for ; Mon,  4 May 2020 05:45:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vagTZ8KWJaMf for ; Mon,  4 May 2020 05:45:44 -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 462DC3A0849 for ; Mon,  4 May 2020 05:45:44 -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 1jVaTe-0004He-QJ for sidrops@ietf.org; Mon, 04 May 2020 12:45:42 +0000
Date: Mon, 04 May 2020 05:45:42 -0700
Message-ID: 
From: Randy Bush 
To: SIDR Operations WG 
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: [Sidrops] request adoption of draft-ymbk-sidrops-rpki-rov-timing
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, 04 May 2020 12:45:46 -0000

hi chairs

i would ike to ask for wg adoption of draft-ymbk-sidrops-rpki-rov-timing

thanks

randy


From nobody Mon May  4 06:09:58 2020
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 103FB3A0879 for ; Mon,  4 May 2020 06:09:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.099
X-Spam-Level: 
X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 gpeXfDePOL8i for ; Mon,  4 May 2020 06:09:55 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.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 459233A0876 for ; Mon,  4 May 2020 06:09:55 -0700 (PDT)
Received: from [IPv6:2001:981:4b52:1:915b:7bc5:cb13:7ced] (unknown [IPv6:2001:981:4b52:1:915b:7bc5:cb13:7ced]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 56B312879C; Mon,  4 May 2020 15:09:53 +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=1588597793; bh=NcArCaLwbe1T5JEOBoJwjV6jHqDvieIk2KacsPyU1ew=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=twCfHFa8h5hj1xoXO1Q1W6WsaXhaHR+P6Br32d+UkIHpkEWlEt4bTFmK4ApXIzH9S EasryeWa1lfyQEwMb0aWJNSmpLGxtPrGe6wTQ6Pah8+p9VulCXWwf9UAdN1LtR+Ha+ +vU6Bt7/6dzGzFFmFdMvuZusGLTHEjXukR4JdTU8=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Tim Bruijnzeels 
In-Reply-To: 
Date: Mon, 4 May 2020 15:09:53 +0200
Cc: Job Snijders , Jay Borkenhagen , SIDR Operations WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: <0BC5FAFC-A5A3-4B67-82C1-C1BE90335C95@nlnetlabs.nl>
References: <87pnbrspdr.wl-morrowc@ops-netman.net> <24232.24434.41224.396200@oz.mt.att.com>  <12F90135-5597-490B-947F-F588C2ED3B48@nlnetlabs.nl> 
To: Alexander Azimov 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [Sidrops] ASPA duplicates
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, 04 May 2020 13:09:57 -0000

Hi,

> On 2 May 2020, at 20:39, Alexander Azimov  =
wrote:
>=20
> Thank you all for comments.
>=20
> First of all, I'd like to address the reasons for that change at the =
side of RTR.
>=20
> And the comparison with ROA is important. The RTR documents don't say =
that "you MUST apply diff after receiving EOD", instead it is applied =
incrementally. So, the race in the updates for selected address space =
may invalidate the correct routes. One may say that finally, all data =
will become consistent and the router will make a proper marking. =
Unfortunately, it's not true for two reasons:
> 	=E2=80=A2 You never know when all data will arrive, there may be =
every kind of network issues between cache and router (and it's TCP =
after all);
> 	=E2=80=A2 Even if all updates finally arrives some routing =
software will keep the result of original verification. I'm not sure how =
it is covered with RFC, but I know that such implementations exist.
> As a result, we may end with hard to debug prefix propagation issues. =
These race conditions are partially addressed in the RFC8210bis by =
adding order to the ROA updates - from more specific to less specific =
routes. It solves the problem with less specifics, but issues for =
prefixes that have multiple records may still exist.
>=20
> In the ASPA, we are trying to prevent race conditions from happening. =
And the easiest way is to guarantee the atomicity of updates for each =
key-value pair. In our cases - to pack all ASPA records for the selected =
customer AS into one PDU. I hope this will make clear the motivation why =
ASPA PDU is different from what we have now for ROA. Btw, I will vote to =
update ROA too (and the update of RTR is a good time for such change, =
there is no requirement for compatibility between versions).
>=20
> The way new ASPA records are issued and the way they are received by =
RTR (rsync?) is another place for race conditions. And it seems native =
to guarantee consistency the same way - making a single ASPA object, =
thus preventing possible misconfigurations.

Ok, understood. Makes sense now.

> Now the question - what should be done if RTR cache receives multiple =
RTR records for ASPA? Let's discuss possible scenarios:
> 	=E2=80=A2 There is misfunction at the level of RPKI software =
that issued records;
> If we face a bug in the hosting RPKI software it should be gracefully =
processed, without effect on operations.
> 	=E2=80=A2 Tim's example with administrative domain splitting;
> The administrative domain splitting in RPKI doesn't seem to be a good =
idea, it significantly increases chances to get in the state with a =
partial set of customer-providers pairs with hardly predictable =
outcomes. =20
> 	=E2=80=A2 Transfer between RIRs.
> And the last seems to be on the same board - such semistate isn't =
safe, and one should keep one record at any point in time.
>=20
> Keeping in mind that the absence of ASPA record is less dangerous then =
inconsistent state my thinking is that if RPKI cache receives multiple =
ASPA records for selected customers AS it should ignore all of them. IMO =
looks like a fair good compromise: prevent race conditions and also do =
not have an effect on operations if something goes wrong.

This might not be easy for existing RPs - with ROAs the thought has also =
been that they are cumulative. Now you would need to keep much more =
state, and even check between all configured TAs - which until now could =
just be processed in parallel.

I understand your reasoning, but I think this warrants at least some =
normative wording in the document and discussion in the security =
section. And most importantly I am curious to learn what RP software =
implementers think (nowadays I do the CA side, which is much easier in =
this context).

Tim


>=20
>=20
> =D1=81=D1=80, 29 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 15:26, Tim =
Bruijnzeels :
> Hi,
>=20
> > On 28 Apr 2020, at 19:03, Job Snijders  wrote:
> >=20
> > On Tue, Apr 28, 2020, at 18:53, Jay Borkenhagen wrote:
> >> The current ASPA Verification draft:
> >>=20
> >> https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-04
> >>=20
> >> .... says in Section 3 "For a selected Customer AS MAY exist only
> >> single ASPA object."
> >>=20
> >> I concur that an ASPA object should list every authorized upstream =
ASN
> >> to avoid possible race conditions, and as such it makes sense for =
only
> >> a single ASPA object to exist at any point in time.
> >>=20
> >> But how is that uniqueness to be ensured?  What should RPs do if
> >> multiple validated ASPA objects are ever found to exist?
> >=20
> > Good question. What should it do?
>=20
> In my mind it's good to that CAs can create a single ASPA object for a =
customer ASN they hold for all their provider(*) ASNs.
>=20
> But, I think it may be better to cover that CAs SHOULD (or even MUST =
if you will) combine all provider ASNs on a single ASPA objects as a =
separate BCP, and leave a bit more flexibility in the profile and =
validation drafts. This makes it easier to change things, should we find =
that we need to change our minds on what is best.
>=20
> I don't think that RPs have to check whether the CA did indeed use a =
single ASPA object for a customer ASN. I think it should just validate =
all ASPA objects it finds, and build a list Verified Asn Relations . Furthermore, I think that  8210bis =
should then specify that the RP (cache) MUST exclude duplicates when =
sending these relations to routers.
>=20
> And veering a bit further into that document, I am not sure why those =
updates should be sent as a single PDU containing all current provider =
ASNs. I think it make sense to do the same as with ROAs where =
'announcement' (add) or 'withdraw' VRPs (excluding duplicates) are sent =
over RTR. I read the comment about race conditions, but I don't see how =
this is an issue when such PDUs are sent as a typical exchange (section =
8.2) between a Cache Response and End of Data PDUs.
>=20
> *) relations as defined in draft, not necessarily the business =
relation.
>=20
> > I expect such duplicates *will* exist if ASPA were to be deployed =
for real: in cases where an ASN is transferred from one RIR to another =
RIR and one wishes to make before break.
>=20
> Well in that case one would expect objects for the same customer ASN =
in different parts of the RPKI tree.
>=20
> But a similar issue could also come up if a parent issues the same ASN =
to multiple children. Which could be a working model if a large =
operation operates the same ASN globally, but has different teams =
managing it. In that case an organisation could chooses to run a =
delegated CA and issue certificates to child CAs in use by those teams. =
(I am not sure how likely this is, you have much more operational =
insight than I do, but it's definitely possible under the standards).
>=20
> In those cases any of those CAs can issue valid ASPA objects, and they =
should be combined as above.
>=20
> Furthermore, the security considerations (section 8) of the AS path =
verification draft can use some additional words to warn that this also =
means that any ASPA issuer can potentially invalidate other users of the =
same ASN if they exist.
>=20
> Maybe the idea of multiple parties operating the same ASN is =
ludicrous, but then I think it would be good to have words that =
discourage delegating the same ASN to multiple CAs, and similarly, =
discourage issuing ASPA for customer ASNs that are also delegated.
>=20
> Note that this issue is somewhat similar to ROAs for prefixes which =
are also (partially) delegated, or received by multiple organisations.
>=20
>=20
>=20
>=20
> >=20
> > Kind regards,
> >=20
> > Job
> >=20
> > _______________________________________________
> > Sidrops mailing list
> > Sidrops@ietf.org
> > https://www.ietf.org/mailman/listinfo/sidrops
>=20
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
>=20
>=20
> --=20
> Best regards,
> Alexander Azimov


From nobody Mon May  4 06:39:46 2020
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 86F373A08AB for ; Mon,  4 May 2020 06:39:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4d50XrZ-PksF for ; Mon,  4 May 2020 06:39:36 -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 696A73A08A6 for ; Mon,  4 May 2020 06:39:36 -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 1jVbJm-0004U1-KL; Mon, 04 May 2020 13:39:34 +0000
Date: Mon, 04 May 2020 06:39:34 -0700
Message-ID: 
From: Randy Bush 
To: Tim Bruijnzeels 
Cc: SIDR Operations WG 
In-Reply-To: <0BC5FAFC-A5A3-4B67-82C1-C1BE90335C95@nlnetlabs.nl>
References: <87pnbrspdr.wl-morrowc@ops-netman.net> <24232.24434.41224.396200@oz.mt.att.com>  <12F90135-5597-490B-947F-F588C2ED3B48@nlnetlabs.nl>  <0BC5FAFC-A5A3-4B67-82C1-C1BE90335C95@nlnetlabs.nl>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [Sidrops] ASPA duplicates
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, 04 May 2020 13:39:44 -0000

> This might not be easy for existing RPs - with ROAs the thought has
> also been that they are cumulative. Now you would need to keep much
> more state, and even check between all configured TAs - which until
> now could just be processed in parallel.
> 
> I understand your reasoning, but I think this warrants at least some
> normative wording in the document and discussion in the security
> section. And most importantly I am curious to learn what RP software
> implementers think (nowadays I do the CA side, which is much easier in
> this context).

from draft-ietf-sidrops-8210bis

11.  ROA PDU Race Minimization

   When a cache is sending ROA PDUs to the router, especially during an
   initial full load, two undesirable race conditions are possible:

   Break Before Make:  For some prefix P, an AS may announce two (or
      more) ROAs because they are in the process of changing what
      provider AS is announcing P.  This is is a case of "make before
      break."  If a cache is feeding a router and sends the one not yet
      in service a significant time before sending the one currently in
      service, then BGP data could be marked invalid during the
      interval.  To minimize that interval, the cache SHOULD announce
      all ROAs for the same prefix as close to sequentially as possible.

   Shorter Prefix First:  If an AS has issued a ROA for P0, and another
      AS (likely their customer) has issued a ROA for P1 which is a sub-
      prefix of P0, a router which receives the ROA for P0 before that
      for P1 is likely to mark a BGP prefix P1 invalid.  Therefore, the
      cache SHOULD announce the sub-prefix P1 before the covering prefix
      P0.

randy


From nobody Mon May  4 08:31:38 2020
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 119023A0AD9 for ; Mon,  4 May 2020 08:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRo7hyOPgSED for ; Mon,  4 May 2020 08:31:34 -0700 (PDT)
Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (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 0688A3A0AE9 for ; Mon,  4 May 2020 08:31:34 -0700 (PDT)
Received: by mail-qv1-xf36.google.com with SMTP id h6so8516605qvz.8 for ; Mon, 04 May 2020 08:31:33 -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=TijDHJgSuIlz4k7BIcwdRBLgl27Hhb6o0T5iKhcRbhQ=; b=NUhptYZvFw8UMk/WrfhaTXXVzFcJNJgipSiNsqXFswDlYjFlORkWPDfFZJlmXZAik7 fWNqfJhaC02cQQfDziszpB1fY/wrqCtXqfmGzOQ1R9PRQKb/L9nhkfyBWnc9l/E4TmNs lPIgLXs1uSLOw+meMKRpg05LjSFtUQwmN43AogUc/K1ebxpMSZaHgeuO1uIGhA4oQ4k7 X9suJW0shr986kecgx1dEONvcVQzE0I+qf4702CQUDYh+O8R2iampxZ4pV6PiWkfDzhy 64u/EyGArwchGipLb6Qg9sLIlXzrmv2ye/1L1iLUuKdPtvkcj+U83kxQKeF+nU/0NybJ Fbyg==
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=TijDHJgSuIlz4k7BIcwdRBLgl27Hhb6o0T5iKhcRbhQ=; b=rDNMSkh5FDQ4pKMJ/mqPJ9DEG0jBwLp+GwiiJrGN0xpc29F93t38jjcxTYQc8xrnCf IkWxH5Jal8ZqQWx6oImY2vb9jBZgo2bo0dP67s5oVofEaIVcfB6hIhZK26r751DI47T+ sGcBNxPhbbRI2fS0VW2y26viAagjgG/SYoj7lg/PKb+t8fYVT5CpSTbWN1snM2Q00PGv I39+ahpyaCVEsq8jSON7f9guZCMfh0T0sBSwqEQAt1ii1HqjYwIT1cfgaNh3fG7Upm/r 0eB37/Fa+7xXgzJcDzfG50fjHmYe/WaVUSxuUSVboY2Bj1u9OUehjuMrLSOjdH0Ai12C fvVw==
X-Gm-Message-State: AGi0PuYVGE7y5bhx8LdNOHY4dfOTaqxT4y7T1w7G74xlp7oOMc2DOCYx 6DehTFszEc1ezoNgPezDMuzK4GHAL2FSSAcXkIM=
X-Google-Smtp-Source: APiQypI9cWkcdkoTWGL9n1mXoHTKqtTNQRvCvejuGIfcaFbUtqNi+dy/KHPoFcxIA0pvall/P5+quVRf20I3079ZdWY=
X-Received: by 2002:ad4:5a06:: with SMTP id ei6mr17131145qvb.70.1588606292820;  Mon, 04 May 2020 08:31:32 -0700 (PDT)
MIME-Version: 1.0
References: <20200503190202.GD57581@vurt.meerval.net> <60c43db2-030e-723e-177c-13cc14758c64@verizon.net> <20200503200112.GI57581@vurt.meerval.net> <2d3b8f2f-2872-3652-56d9-6f23f8eb56fa@verizon.net>
In-Reply-To: <2d3b8f2f-2872-3652-56d9-6f23f8eb56fa@verizon.net>
From: Christopher Morrow 
Date: Mon, 4 May 2020 11:31:21 -0400
Message-ID: 
To: Stephen Kent 
Cc: Job Snijders , SIDR Operations WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [Sidrops] About the use of manifests (follow-up from Apr Interim meeting)
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, 04 May 2020 15:31:36 -0000

On Mon, May 4, 2020 at 8:07 AM Stephen Kent
 wrote:
>
> Job,
> > On Sun, May 03, 2020 at 03:56:22PM -0400, Stephen Kent wrote:
> >> Yes, Section 6 of RFC 6486.
> >>
> >> I believe that most of the changes will arise in 6.2, 6.3, 6.4, 6.5, and
> >> 6.6.
> > The current draft (draft-spaghetti-sidrops-rpki-manifest-validation-00)
> > replaces Section 6 entirely. I don't know if that aligns with IETF
> > etiquette and it has to be done paragraph by paragraph, but I hope this
> > helps clarify our thinking.
>
> I'll see what my co-authors think, but I'm more of an angle hair past
> guy myself :-)

did you mean 'angel hair pasta' ? :) (which I agree, far better than
that gross fat worm pasta... but...)

>
> I think most of 6.1 is OK and I plan to reuse most of it in the rev. The
> ambiguity arises in the discussion of what an RP SHOULD/MUST do when an
> object is missing or in error, which is what the latter parts of Section
> 6 address.

i think this was the meat of the previous discussion:
  "originally we left a lot of wiggle room, because "

and today/now:
  "uhm, leaving this much wiggle room was ... oops! folk would REALLY
like to understand
   the tradeoffs in a succinct manner (that does not require phd in
pkix) and some better
   guidelines on what they should set as default behavior that
can/will set a base security/safety
   level for their deployment."

which I think is the goal of job's draft? I understood from previous
email conversations on
the WG list that the previous author set was happy to suggest
improvements but had no time/$$
for the full edit job?

Is there now time/$$ for the editoring to happen?
(maybe I'm confused, which totally could be the case)

-chris
(off reading current draft:
https://tools.ietf.org/id/draft-spaghetti-sidrops-rpki-manifest-validation-00.txt)
>
> Steve
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops


From nobody Mon May  4 08:37:00 2020
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 5E39C3A0AFE; Mon,  4 May 2020 08:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZymW6DAQBu1; Mon,  4 May 2020 08:36:57 -0700 (PDT)
Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A48433A0AFD; Mon,  4 May 2020 08:36:55 -0700 (PDT)
Received: from bufobufo.ripe.net ([193.0.23.13]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jVd9K-0000tK-8d; Mon, 04 May 2020 17:36:54 +0200
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::445]) by bufobufo.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jVd9K-0006VR-4i; Mon, 04 May 2020 17:36:54 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Oleg Muravskiy 
In-Reply-To: <29748EA5-6016-4E6D-9261-A069F7431390@nlnetlabs.nl>
Date: Mon, 4 May 2020 17:36:53 +0200
Cc: SIDROps Chairs , SIDR Operations WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: <7CF309AA-0B5F-4FE8-80E8-5E041CA21CF1@ripe.net>
References: <29748EA5-6016-4E6D-9261-A069F7431390@nlnetlabs.nl>
To: Tim Bruijnzeels 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-ACL-Warn: Delaying message
X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b74efb6c87ba35a001c9416db0caeb38daa
Archived-At: 
Subject: Re: [Sidrops] Adopt draft-sidrops-bruijnzeels-deprecate-rsync?
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, 04 May 2020 15:36:58 -0000

On 29 Apr 2020, at 15:18, Tim Bruijnzeels  wrote:
>=20
> Dear co-chairs, WG,
>=20
> As mentioned yesterday I would like ask the chairs to do a call for =
adoption on:
> =
https://datatracker.ietf.org/doc/draft-sidrops-bruijnzeels-deprecate-rsync=
/
>=20
> I am also more than happy to discuss the content, and adapt following =
discussion, but maybe this is better done if adopted :)

Support


Oleg=


From nobody Mon May  4 09:03:36 2020
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 A3D843A0B4A for ; Mon,  4 May 2020 09:03:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6T27vaYqmOa for ; Mon,  4 May 2020 09:03:33 -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 BA1F03A0B35 for ; Mon,  4 May 2020 09:03:33 -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 1jVdZ4-00051H-59; Mon, 04 May 2020 16:03:30 +0000
Date: Mon, 04 May 2020 09:03:28 -0700
Message-ID: 
From: Randy Bush 
To: Christopher Morrow 
Cc: Stephen Kent , SIDR Operations WG 
In-Reply-To: 
References: <20200503190202.GD57581@vurt.meerval.net> <60c43db2-030e-723e-177c-13cc14758c64@verizon.net> <20200503200112.GI57581@vurt.meerval.net> <2d3b8f2f-2872-3652-56d9-6f23f8eb56fa@verizon.net> 
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [Sidrops] About the use of manifests (follow-up from Apr Interim meeting)
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, 04 May 2020 16:03:35 -0000

as we do with RFCbis documents, i believe a significant group of the
original authors will be working on the update.

randy


From nobody Mon May  4 09:41:40 2020
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 CE12C3A0CDD for ; Mon,  4 May 2020 09:41:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNfaGuIYO7vt for ; Mon,  4 May 2020 09:41:36 -0700 (PDT)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 A9A843A0CD8 for ; Mon,  4 May 2020 09:41:36 -0700 (PDT)
Received: by mail-qk1-x730.google.com with SMTP id t3so184800qkg.1 for ; Mon, 04 May 2020 09:41:36 -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=Hjcu8JYFZMWJEU7E9xBL4REqcpv4NRgQ9AdhSxVjaT0=; b=GNoVyeJuZeZc6eiF7XvF2bbbLncus9r/UiiLb0JuJJhfB+whBBxbmClUfqc/Grv+Pi DUdEfjMaFVeVXOtzBCK2QESSuBwGgxZuWyef4r9OzUSJKo94jJn0u+UfwU4lJG3MzULR 45AJg6enH2spMGSMB2XVCHbAV1cbFneRQZtAvtqyqafKT11uhsGumwHBEE/ekTu8XW6J 5Y/CK8eQXpXEfdmqCGUG8QzyQWR25FH4ukfMjjPvuuttriR21m6ZMclI+Gk8SIkubDtj MS3/DsnibNeKOuouCjoa2qLb38FAsbQRp8RojW1TRgCrHnrz0B30ocmOknOUgSrLyB6I fqSA==
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=Hjcu8JYFZMWJEU7E9xBL4REqcpv4NRgQ9AdhSxVjaT0=; b=slnbISGoGB2kKoP1IHOoCAippTYIGaJWqFVKnMEoEKrf9s0kH39v5FwcWzzNyEe6YE RHCRAbT6x/rZRRPH3j5RWRkxYwEjV4oY+a7TAG89DEc8NMaCdcPB7s60l0Z+MEHfas57 ITBBjDZPGXM7lEHe+8rfSKRS705njQ/GCFqgi79xCi6xebqo4Z/hybkWPwiZkHeQNMWg YrtODNWzPM/4JNKagQm/FbcmIKnL+qYRAidzkga+8oJiiJzzZ14KcPKuimC8i0G9fts/ JO4ySam8fd0uvylGs8XX9kdNXFa1PdNbnck03CIoU0FQ+4kv2x+F6PVoZmdg5fBFsf8G pImA==
X-Gm-Message-State: AGi0PubAY8g1pPEpRazBu1f7L1kve+LmPNVMWTrq5zWwP5xHNBtk9dW4 cV+mFyWR/TDhwkimJDT7bhZEljQdLqURzvx+ZGzvnbXq
X-Google-Smtp-Source: APiQypIAD7JUE4Pp6kvjWvWZZXONqubNtfmTriJu26UoUpjPQuMfHTrpgM1gsqsBHr0czLKUBKaqIooe4d0OEfLvlPc=
X-Received: by 2002:a05:620a:13fb:: with SMTP id h27mr32359qkl.79.1588610495565;  Mon, 04 May 2020 09:41:35 -0700 (PDT)
MIME-Version: 1.0
References: <20200503190202.GD57581@vurt.meerval.net> <60c43db2-030e-723e-177c-13cc14758c64@verizon.net> <20200503200112.GI57581@vurt.meerval.net> <2d3b8f2f-2872-3652-56d9-6f23f8eb56fa@verizon.net>  
In-Reply-To: 
From: Christopher Morrow 
Date: Mon, 4 May 2020 12:41:24 -0400
Message-ID: 
To: Randy Bush 
Cc: Stephen Kent ,  SIDR Operations WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [Sidrops] About the use of manifests (follow-up from Apr Interim meeting)
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, 04 May 2020 16:41:38 -0000

On Mon, May 4, 2020 at 12:03 PM Randy Bush  wrote:
>
> as we do with RFCbis documents, i believe a significant group of the
> original authors will be working on the update.

ok, that's definitely not the impression I got from the previous
emails... and I think from the interim meeting discussion.
(which is why I am/was confused)


From nobody Mon May  4 10:13:55 2020
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 8DFA83A0DB2; Mon,  4 May 2020 10:13:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUY2e1KmDtZQ; Mon,  4 May 2020 10:13:50 -0700 (PDT)
Received: from smtp.afrinic.net (smtp.afrinic.net [IPv6:2001:43f8:90:606::169]) (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 43D293A0DBB; Mon,  4 May 2020 10:13:25 -0700 (PDT)
Received: from [209.85.221.178] (port=40309 helo=mail-vk1-f178.google.com) by smtp.afrinic.net with esmtpsa (UNKNOWN:AES128-GCM-SHA256:128) (Exim 4.72) (envelope-from ) id 1jVeeZ-0000rB-AQ; Mon, 04 May 2020 17:13:15 +0000
Received: by mail-vk1-f178.google.com with SMTP id p139so1047756vkd.7; Mon, 04 May 2020 10:13:15 -0700 (PDT)
X-Gm-Message-State: AGi0PuZXXpkIwXDjBwailM84IXU9g7ZywZtq2vRJpczELl8on1Hwbbf9 AAhB+//4VdDk+p1Rp4Bxrj2xPKX8vVuYtZqupBM=
X-Google-Smtp-Source: APiQypJEDTmEp331SBGUkSI2U+ezNwL3BpeMihssaB7mfMQ9NPzA/NyPKLkH0B5sU8X+3ogeV5cD7mRLEq/IWmKelVU=
X-Received: by 2002:a1f:a6d2:: with SMTP id p201mr312673vke.7.1588612392620; Mon, 04 May 2020 10:13:12 -0700 (PDT)
MIME-Version: 1.0
References: <29748EA5-6016-4E6D-9261-A069F7431390@nlnetlabs.nl>
In-Reply-To: <29748EA5-6016-4E6D-9261-A069F7431390@nlnetlabs.nl>
From: Amreesh Phokeer 
Date: Mon, 4 May 2020 21:12:36 +0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Tim Bruijnzeels 
Cc: SIDROps Chairs , SIDR Operations WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [Sidrops] Adopt draft-sidrops-bruijnzeels-deprecate-rsync?
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, 04 May 2020 17:13:54 -0000

I would like to see this adopted.

Thanks,
Amreesh

On Wed, Apr 29, 2020 at 5:19 PM Tim Bruijnzeels  wrote:
>
> Dear co-chairs, WG,
>
> As mentioned yesterday I would like ask the chairs to do a call for adoption on:
> https://datatracker.ietf.org/doc/draft-sidrops-bruijnzeels-deprecate-rsync/
>
> I am also more than happy to discuss the content, and adapt following discussion, but maybe this is better done if adopted :)
>
> Thanks
> Tim
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops



-- 
Amreesh Phokeer


From nobody Mon May  4 13:06:56 2020
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 CB9393A0FD3 for ; Mon,  4 May 2020 13:06:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uzduFXrIAUZ for ; Mon,  4 May 2020 13:06:41 -0700 (PDT)
Received: from sonic310-14.consmr.mail.bf2.yahoo.com (sonic310-14.consmr.mail.bf2.yahoo.com [74.6.135.124]) (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 07CD33A0FDB for ; Mon,  4 May 2020 13:06:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1588622798; bh=IKCst57KSZCRJhBIdZpmfNYa2GDZaxvOtfPU5g6zCLs=;  h=From:Subject:To:References:Date:In-Reply-To:From:Subject; b=n89+3+l2d4UScZ8uVT5moLjI2WIOUqHdMeT7d+0RyrH3Wr3W8mkOXxVoF1QqujDPrki/gFiis2u5r6FowLjRymFQN4fwmfqqpnrrlzCLUKfmM08l77TrAmEqdz34YbmpxmVG47pjBzPMI5/cWd6P3+QjaaFT8QMggJ10UPdQvF8BPrNcEtG9wIAe909PWkdffJPzZXOF4xgGvuDm7jxpJq4gkernTl9lbP0djUDWbfXD8a6GbqNvUcxIIbxkqRKqBoqXz0RvrC5Pzjit7j3JaRcteLypa9VyZaBsXZSzqp3SGn065NyBsMiiZkN4Y6/REwYwO2NcOvJLX2ZjFNuR4g==
X-YMail-OSG: 6NOLPzwVM1kXUK.kyTYNm_DoUTpg8KDOJC0_JTbv7bWmRaoktvHWb_WE0kbgRtC vI9NKbsS6O_Z54j.JI1QfBLvRp79DfLSA99KT5ODxUeIg6H9SPNJXRu484R7d2Ul2uXHvCsGJ47f Ceb9tnr7hN0sTywtr9InZjFUMFBU.aJ9s9CQxoQdhY4lYwZPrCUI21a9TkVOsPhSQnMHH0XXMaYy zKcTvySZ6X6Px74RcWjL6DhhkXgm01wrtY13V328LhUVnKE5abu0ZekTVLTArZJ864Vo72BwURwN IrM3uAtmn5iYpCUJVov1gf69yxtH4d8hRFQbsrLcCTt2JTnvSca1ZkZtqZlrVenDzp3KVF7Jrx2_ 8iduaMxzj1D8awxSEcMgvey.2qrvPKbR_eycFvL78tbKhrhRUBCdOHq3CO2_bYHhNNPQ7xyZyOMH vRsnK2M875Cw90ornMXz36t36An3VwLo2YOuBz5e_cM1QX7Bx3uaVoGz4P5bw8k.OylNlI9dRm3_ WN_Gv7nK3rrwJ0cC.95CuUZ3nMuWLax5LLSttEwIXYCaOWWP7TVGQAkU.uupQp3X4dAfe1qdg1oy Z1B7FD65GOcjEvTQfrs2q.fRS4ulb2RKVXkMmWSByoDllr17ixCqIhQZ02SXpDb0rgr3priNt3ZG pe52sBi0tzicG9_Fvw1ALQjDacuqZZ.r0xrZMp5Sjt64Xb.PtCG_RLr9C3VGQ0QOv2Z1x5ESVMrM 6oo3wIgrZfMAk.3WFZwzGHPA1Zwk_KjNqErJ7fuW2p8Jc.3ccPBZW8Y7SqPherFnWGMgKrzHKKIY pcnM0ORs1udGV5bUHl2Rt9RaRbJxRFKx7OkhrWon1npaIPl6nNX14CvO4dQaDhgBf5FdfGBFMc7w ObLxHDfbWyd9k0ilrBCOpcnoqT7yafq3d2Qg9OeWc_a6fkmrm2yheN3tWipIK4QKS2nNwFY48Q4w 4Y4ytJCe0mG9S1eUgnCjhCu3ZdZ4gy1gZKjShHXw74hBQwI2cSY9T5lMOWyS0MI.J0dZ1WN5WtZg LW0Yhv1Omx48qkWslWq.CZN8pA8JZOClOz34.FWJ6zZMuePXxldDnq6VZJ76MSyOdU9Nvch30E7x eIcaBpw_IaOtGcsjmXAUhqIhawN6qhaOGIdUyUIudEeUgsezAq4OvSBgTvO5nC_5u7vudwkfx5kA Op6gFNP9YGT4ky3HmgvL2wUBdonkVgx9KC44RcFul3qcUhzT_7fx3nQU0G8A7ADuza39y0K2m1rT oHYVn_CR5O0nyU0W9PpZ1zwMxlWg8kbjEHtyzXwBoHbFagX4ELZBNS_tEkqOMlNtKZablidWhj8q HN3EHGIfhEArg1tJ_fn5mpwQiEjJj45pij.rIK1_v4a.0BGrY3QfjaVEQ8fSNGqe4bC9BjL91uOR L53.RS7lw6JHoFAQDnRt9SQ--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Mon, 4 May 2020 20:06:38 +0000
Received: by smtp426.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a41ae961c75f025a89460c102710139f;  Mon, 04 May 2020 20:06:33 +0000 (UTC)
From: Stephen Kent 
To: sidrops@ietf.org
References: <20200503190202.GD57581@vurt.meerval.net> <60c43db2-030e-723e-177c-13cc14758c64@verizon.net> <20200503200112.GI57581@vurt.meerval.net> <2d3b8f2f-2872-3652-56d9-6f23f8eb56fa@verizon.net> 
Message-ID: <9d77bc6f-7eb0-474e-9f6b-48f9e5fca8d5@verizon.net>
Date: Mon, 4 May 2020 16:06:32 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] About the use of manifests (follow-up from Apr Interim meeting)
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, 04 May 2020 20:06:43 -0000

Chris,
> did you mean 'angel hair pasta' ? :) (which I agree, far better than
> that gross fat worm pasta... but...)
yes, angel hair, unless I was thinking about elbow macaroni, with sharp 
angles
> i think this was the meat of the previous discussion:
>    "originally we left a lot of wiggle room, because "
agreed.
> and today/now:
>    "uhm, leaving this much wiggle room was ... oops! folk would REALLY
> like to understand
>     the tradeoffs in a succinct manner (that does not require phd in
> pkix) and some better
>     guidelines on what they should set as default behavior that
> can/will set a base security/safety
>     level for their deployment."
>
> which I think is the goal of job's draft? I understood from previous
> email conversations on
> the WG list that the previous author set was happy to suggest
> improvements but had no time/$$
> for the full edit job?
I will offer edited text for section 6 later today.

Steve


From nobody Mon May  4 13:09:51 2020
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 3A4903A0FD3 for ; Mon,  4 May 2020 13:09:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nx1lCdVCADaw for ; Mon,  4 May 2020 13:09:46 -0700 (PDT)
Received: from sonic316-12.consmr.mail.bf2.yahoo.com (sonic316-12.consmr.mail.bf2.yahoo.com [74.6.130.122]) (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 4B5043A0FDC for ; Mon,  4 May 2020 13:08:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1588622929; bh=L+G5Uasg94MjYj0+SauPPQtdGZf15NLG2xVOWr25NhU=;  h=To:From:Subject:Date:References:From:Subject; b=BHkyNvYP4sbGfjTUpilDKSNSpfbxQuP+c6l8KOSBRegeNudpXghV5zYetHwrII7gSXSgKFcG7Ssa+bk4Sm0RUc3qZCQm5DWE+I5ZXC83MNP0uE9sLBzgFNJ8RV6G8q+7DwzZBVfJj+Ba1eIT1/XEAsS6X4rzlgUGQXfL+BiA+pajBSNCiSF50YcDnEeHV2iZRzZ22BTp5fBIqmIlQRd5nkxC+pwvNtDakhVCPcQ5R2igHNppIDvXtTUOZ/r2V31+F8mtujXjroDbjK3MWVYhSt7y0x9e8yEgo71Jx0G6V76WMF0Qm7dN480XfE+mw9f5OpRKD+NlZYWDHU87iP8fuQ==
X-YMail-OSG: 8w3gElYVM1kGUvD3vOOHMgvs4nh79aoXUwPkwqcQdZVH1TXQOPxLj3bQWSAvhIj IQPHPJfmWzeN9UyO6yExI4DEENPw1ncDVhXgTDXAthDz9Z6XKc3K2jfRQktTAbhnf0e40ZEUgKg. nIkOVFh59mgGhJf5iZkQlMwM0nEHKWCJ4_Xo2XJrTLPb2FglxkICK4hrr5fbzWanK2ttwIDDmLOy fyqabh1M4XN_UXzL16eeTICVyoJBZjz1b2Mm75C6E2ZYuUA8oPb4ENvCR7bQL4ay6onViU8gPcPV D0esEMWNpXpcAOcX5KTlSyPBIk5Krhxh_mhk71GBPsBUU0H0rTb6xGBLgR48x.TAOnm3uv7niP9t 6hKiOj2Mi1wmnF_OxTCl_d0mytACnWosVca_ZlL.XgR0OdTf_HXI_QENP3z71fuamsptegbVPWwD GfCZukqk6UTEGfol3OGFs6byTyuTYSO35k9XhNhAzZ2l3X1YKdIKTd3rwEJ9HAmiB1nim.7vYZ4r tF.pRXOrbciodWGdMDUq1wGIjjtvRzF6TxOfpuxk7Zx8RIYAcp46teG1F20JBo.kv21Sw2vNQwlz g6fJn.pMCsJbK_0VtsXjmPbLRkf2PBRHa8Ynw0Td1Bzb4ZYK_0dDK0.5m4ZPjyYRrr_R0WsOli8_ qsoJrQkdj1NHAQX_cXMXgs2wAT6uGaV71vF0GwYUdoGFbrcvQ1KZ_hef0Jqolgapvm6jDboPLC8J KdVOaoLzq.hiEjlYnIp.sMb8o.4hlA3wsKdOO204pf2JFTC6_ijqvCXA1v_SAxUmqaSfLLh2Lvm7 rnItnHg1c5E96Gx7AsFf1RQ1iC4440XynQ61_cJlsAocblUd4a.8kc6W7iDllc0VKDOB1CjJRKVb Zy4MECTAkCcIS0xe148bBFzG84pwdEicYAA2atd4tR5xKsecw9JzUBc95q1CVOIBQ3nZMfdI8SqB nLGfGvzfE_PgYBIsTvIy99hTQeaf4jUmnUgmzWB2btT_dqhhDes825QBA14x0_1wKMvWpkiThhpa QVP7NMWSnQuM9o9XWIyS9LIwDue_OcSUlUqoihpqvgLt3FZMr6UrMDHL9Gp2Q.gmlZ3MTnGldYb. Z4sVR_o8smjlqwKHCIzQQHVEChDV6Mfm7J0VyYHWtY_rVBE8n6BfOiN3F5f5gdchUrI7OBFtYJL4 zFh2OnA2x3NhLI8WIcSuJSBywqTy43vdm58KkcZIJifw8t_d3.ceqP00sCgssq86MMcfJTbRV8fB ACNLqn2Sdigo229fyDWurpePmmx2LSTH7L5UtM8knP2sEK_TJB9pl0d9Mvn.tYZ4AZFH9bKjpTdF vXbf0cfkRJZ6zTMdOE9U9EvBBrb7HamVvKF7Gb7pyS87B.OdFBlRvq64IGHExML3Klpp6S3a41SH W0LkIi.55uD6tV4MBLNkfPbDljE805mqcTts5ZdxlaBCKW2odE6P6nGwv0XE-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Mon, 4 May 2020 20:08:49 +0000
Received: by smtp402.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 206a63d32eeede4cfd229ae50b27af5d;  Mon, 04 May 2020 20:08:44 +0000 (UTC)
To: "sidrops@ietf.org" 
From: Stephen Kent 
Message-ID: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net>
Date: Mon, 4 May 2020 16:08:43 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------9F93DCCA5CD5453651086D8A"
Content-Language: en-US
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net>
X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: [Sidrops] proposed, revised text for Section 6
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, 04 May 2020 20:09:50 -0000

This is a multi-part message in MIME format.
--------------9F93DCCA5CD5453651086D8A
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

To get the discussion going, I generated the following text for Section 
6. I deleted anything that was not definitive (e.g., deferred to local 
policy) and removed the warning message suggested text (I assume RP 
software developers can write their own messages, but we can add this 
back if folks feel it's useful.

I also added a paragraph about the manifest/CRL circular relationship.

In all cases I adopted the approach George suggested, i.e., if there's 
an error indicating that one or more signed objects may be missing (or 
not current), ignore ALL data associated with the CA instance at the pub 
point and DO NOT rely on cached data.

Comments welcome, as usual.

All new text is in red.

Steve

-----



6.1. Determining Manifest State & Object Acceptance

For a given publication point, and given CA instance, an RP MUST perform

the following tests to determine the manifest state of the publication

point. (Note that, during CA key rollover [RFC6489], signed objects for

two or more different CA instances will appear at the same publication

point. The tests described below are to be performed for a specified CA

instance, i.e., a the manifest’s EE certificate was issued by that CA.)

1. Select the CA's current manifest (the "current" manifest is the

manifest issued by this CA having the highest manifestNumber among

all valid manifests (as defined in Section 4.4).

If the publication point does not contain a valid manifest, proceed

as described in Section 6.2. (Lacking a valid manifest, the following

tests cannot be performed.)

2. Check that the current time (translated to UTC) is between

thisUpdate and nextUpdate.

If the current time does not lie within this interval,proceed

as described in Section 6.4.

3. Acquire all objects at the publication point associated with this

CA instance, i.e., the CRL and each object containing an EE

certificate issued by the CA. If there are files listed in a manifest

that do not appear at the publication point, then proceed as

described Section 6.5.

4. Verify that the listed hash value of every file listed in the

manifest matches the value obtained by hashing the file at the

publication point.

If the computed hash value of a file listed on the manifest does

not match the hash value contained in the manifest, then proceed

as described in Section 6.6.

5. If a current manifest contains entries for objects that are not

within the scope of the manifest, then the out-of-scope entries

MUST be disregarded in the context of this manifest.If there

is no other current manifest that describes these objects within

that other manifest's scope, then see Section 6.2.

Note that there is a “chicken and egg” relationship between the

manifest and the CRL for a given CA instance. If the EE certificate

for the manifest is revoked, the CA or publication point manager has

made an error. In this case all signed objects associated with the CA

instance MUST be ignored. Similarly, if the CRL for the CA instance

is not listed on a valid, current manifest, all signed objects

associated with the CA instance MUST be ignored, because the CRL is

missing.

6.2.Missing Manifests

The absence of a current manifest at a publication point could occur

due to an error by the publisher or due to (malicious or accidental)

deletion or corruption of all valid manifests.

When no valid manifest is available, there is no protection against

attacks that delete signed objects or replay old versions of signed

objects. To guard against the adverse impact of processing an

incomplete set of signed objects, an RP MUST treat all signed objects

associated with the missing manifest as invalid. (These objects are

all issued by the same instance of a CA.) RP software MUST issue a

warning when there is no current manifest for a CA instance.

An RP may have access to a local cache containing a previously

issued manifest that is still valid. It is RECOMMENDED that the RP

not make use of this data, to ensure consistent a consistent outcome

in when a manifest is missing.

6.3.Invalid Manifests

The presence of an invalid manifest at a publication point could

occur due to an error by the publisher or due to (malicious or

accidental) corruption of a valid manifest.An invalid manifest MUST

never be used, even if the manifestNumber of the invalid manifest is

greater than that of other (valid) manifests.

If there is no valid, current manifest available at the publication

point for the CA instance, an RP MUST treat the signed objects at the

publication point as indicated above in Section 6.2. A warning MUST

be issued when an invalid manifest is encountered.

6.4.Stale Manifests

A manifest is considered stale if the current time is after the

nextUpdate time for the manifest.This could be due to publisher

failure to promptly publish a new manifest, or due to (malicious or

accidental) corruption or suppression of a more recent manifest.

All signed objects at the publication point issued by the entity that

has published the stale manifest, and all descendant signed objects

that are validated using a certificate issued by the entity that has

published the stale manifest at this publication point, MUST be

treated at invalid and a warning MUST be issued.

The primary risk in using such signed objects is that a newer

manifest exists that, if present, would indicate that certain objects

have been removed or replaced.(For example, the new manifest might

show the existence of a newer CRL and the removal of one or more

revoked certificates).Thus, the use of objects from a stale

manifest may cause an RP to incorrectly treat invalid objects as

valid.The risk is that the CRL covered by the stale manifest has

been superseded, and thus an RP will improperly treat a revoked

certificate as valid.

6.5.Mismatch between Manifest and Publication Point

If there exist valid signed objects associated with a CA instance and

they do not appear in any current, valid manifest for this CA instance,

these objects MUST be ignored by an RP, and a warning MUST be issued.

If there are files listed on the manifest that do not appear in

the repository, then these objects have been improperly deleted from

repository (via malice or accident).A primary purpose of manifests is

to detect such deletions.Therefore, in this case, an RP MUST ignore

all signed objects associated with this CA instance.

6.6.Hash Values Not Matching Manifests

A file appearing on a manifest with an incorrect hash value could

occur because of publisher error, but it also may indicate that an

attack has occurred, e.g., one in which an older version of an object

has been substituted for a newer version of the object. In this case

an RP cannot know the content of the missing object, and thus all

signed objects associated with this instance of the CA MUST be ignored

by the RP, and a warning MUST be issued.


--------------9F93DCCA5CD5453651086D8A
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    
To get the discussion going, I generated the
        following text for Section 6. I deleted anything that was not
        definitive (e.g., deferred to local policy) and removed the
        warning message suggested text (I assume RP software developers
        can write their own messages, but we can add this back if folks
        feel it's useful.

    
I also added a paragraph about the
        manifest/CRL circular relationship.

    
In all cases I adopted the approach George
        suggested, i.e., if there's an error indicating that one or more
        signed objects may be missing (or not current), ignore ALL data
        associated with the CA instance at the pub point and DO NOT rely
        on cached data.

      

    
Comments welcome, as usual.

    
All new text is in red.

      

    
Steve

    
-----

      

    


      

    


      
      

    
6.1. Determining Manifest State &
        Object Acceptance

    
 

    
   For
      a given
      publication point, and given CA instance,
      an RP MUST
      perform 

    
   the
      following tests
      to determine the manifest state of the publication

    
   point.
      (Note that, during CA key rollover
        [RFC6489], signed objects
        for

    
  
        two or more different CA instances will appear at the
        same publication 

    
  
        point. The tests described below are to be performed for
        a specified CA

    
  
        instance, i.e., a the manifest’s EE certificate was
        issued by that CA.)

    
 

    
   1.
      Select the CA's current manifest
      (the
      "current" manifest is the 

    
       manifest
      issued by this CA  having
      the highest
      manifestNumber among 

    
       all
      valid
      manifests (as defined in Section 4.4).

    
 

    
      If
      the
      publication point does not contain a valid manifest, proceed

    
      as described in Section
        6.2. (Lacking
      a valid manifest, the following 

    
      tests
      cannot be
      performed.)

    
 

    
   2.
      Check that
      the current time (translated to UTC) is between

    
      thisUpdate
      and nextUpdate.

    
 

    
      If
      the
      current time does not lie within this interval,
        proceed 

    
      as described in Section
        6.4.

    
 

    
 

    
  3.
      Acquire all objects at the publication
        point associated with
        this 

    
     CA instance, i.e., the
        CRL and each object
        containing an EE 

    
     certificate issued by
        the CA. If there are
        files listed in a manifest 

    
     that do not  appear at the publication
        point, then proceed as
      

    
     described  Section 6.5.

    
 

    
 

    
   4.
      Verify that
      the listed hash value of every file listed in the

    
      manifest
      matches the value obtained by hashing the file at the

    
      publication
      point.

    
 

    
      If
      the
      computed hash value of a file listed on the manifest does

    
      not
      match the
      hash value contained in the manifest, then proceed

    
      as described in
      Section 6.6.

    
 

    
   5.
      If a current
      manifest contains entries for objects that are not

    
      within
      the
      scope of the manifest, then the out-of-scope entries

    
      MUST be disregarded in the context of
      this
      manifest.  If there

    
      is
      no other
      current manifest that describes these objects within

    
      that
      other
      manifest's scope, then see Section 6.2.

    
 

    
 

    
  
        Note that there is a “chicken and egg” relationship
        between the 

    
  
        manifest and the CRL for a given CA instance. If the EE
        certificate 

    
  
        for the manifest is revoked, the CA or publication point
        manager has

    
  
        made an error. In this case all signed objects associated
        with the CA 

    
  
        instance MUST be ignored. Similarly, if the CRL for the
        CA instance

    
  
        is not listed on a valid, current manifest, all signed
        objects 

    
  
        associated with the CA instance MUST be ignored, because
        the CRL is

    
  
        missing.

    
 

    
 

    
6.2.  Missing
      Manifests

    
 

    
   The
      absence of a
      current manifest at a publication point could occur

    
   due
      to an error
      by the publisher or due to (malicious or accidental)

    
   deletion
      or
      corruption of all valid manifests. 

    
 

    
   When
      no valid
      manifest is available, there is no protection against

    
   attacks
      that
      delete signed objects or replay old versions of signed

    
   objects.
      To guard against the adverse impact of
        processing an 

    
  
        incomplete set of signed objects, an RP MUST treat all
        signed objects

    
 
         associated with
        the missing
        manifest as invalid. (These objects are 

    
  
        all issued by the same instance of a CA.) RP software
        MUST issue a

    
  
        warning when there is no current manifest for a CA
        instance.

    
 

    
  
        An RP may have access to a local cache containing a
        previously 

    
  
        issued manifest that is still valid. It is RECOMMENDED
        that the RP

    
  
        not make use of this data, to ensure consistent a
        consistent outcome

    
  
        in when a manifest is missing. 

    
 

    
6.3.  Invalid
      Manifests

    
 

    
   The
      presence of
      an invalid manifest at a publication point could

    
   occur
      due to an
      error by the publisher or due to (malicious or

    
   accidental)
      corruption of a valid manifest.  An
      invalid manifest MUST

    
   never
      be used,
      even if the manifestNumber of the invalid manifest is

    
   greater
      than
      that of other (valid) manifests.

    
 

    
  
        If there is no valid, current manifest available at the
        publication 

    
  
        point for the CA instance, an RP MUST treat the signed
        objects at the

    
  
        publication point as indicated above in Section 6.2. A
        warning MUST 

    
  
        be issued when an invalid manifest is encountered.

    
 

    
6.4.  Stale
      Manifests

    
 

    
   A
      manifest is
      considered stale if the current time is after the

    
   nextUpdate
      time
      for the manifest.  This
      could be due to
      publisher

    
   failure
      to
      promptly publish a new manifest, or due to (malicious or

    
   accidental)
      corruption or suppression of a more recent manifest.

    
 

    
   All
      signed
      objects at the publication point issued by the entity that

    
   has
      published
      the stale manifest, and all descendant signed objects

    
   that
      are
      validated using a certificate issued by the entity that has

    
   published
      the
      stale manifest at this publication point, MUST be

    
   treated at invalid and a warning MUST be
        issued.

    
 

    
   The
      primary risk
      in using such signed objects is that a newer

    
   manifest
      exists
      that, if present, would indicate that certain objects

    
   have
      been
      removed or replaced.  (For
      example, the
      new manifest might

    
   show
      the
      existence of a newer CRL and the removal of one or more

    
   revoked
      certificates).  Thus, the
      use of objects
      from a stale

    
   manifest
      may
      cause an RP to incorrectly treat invalid objects as

    
   valid.  The risk is that the CRL
      covered by the stale
      manifest has

    
   been
      superseded,
      and thus an RP will improperly treat a revoked

    
   certificate
      as
      valid. 

    
 

    
 

    
6.5.  Mismatch
      between Manifest and Publication Point

    
 

    
   If
      there exist
      valid signed objects associated with a CA
        instance
      and

    
   they do not appear in any current, valid
        manifest for this CA
        instance,

    
  
        these objects MUST be ignored by an RP, and a warning
        MUST be issued.

    
 

    
   If there are files listed on the manifest that
        do not appear
        in

    
  
        the repository, then these objects have been improperly
        deleted from

    
  
        repository (via malice or accident). 
        A primary purpose of manifests is 

    
  
        to detect such deletions. 
        Therefore, in this case, an RP MUST ignore 

    
  
        all signed objects associated with this CA instance.

    
 

    
6.6.  Hash
      Values
      Not Matching Manifests

    
 

    
   A
      file appearing
      on a manifest with an incorrect hash value could

    
   occur
      because of
      publisher error, but it also may indicate that an

    
   attack
      has occurred,
      e.g., one in which an older version of an
        object

    
  
        has been substituted for a newer version of the object.
        In this case

    
  
        an RP cannot know the content of the missing object, and
        thus all

    
  
        signed objects associated with this instance of the CA
        MUST be ignored 

    
  
        by the RP, and a warning MUST be issued.

    
 

    
 

    
 

    

        

  


--------------9F93DCCA5CD5453651086D8A--


From nobody Mon May  4 13:37:13 2020
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 4FB8B3A1026 for ; Mon,  4 May 2020 13:37:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czsmrfrPkFTS for ; Mon,  4 May 2020 13:37:08 -0700 (PDT)
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 10C073A1020 for ; Mon,  4 May 2020 13:37:08 -0700 (PDT)
Received: by mail-qt1-x833.google.com with SMTP id x12so147597qts.9 for ; Mon, 04 May 2020 13:37:08 -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=pn3ZY4FpkwY1NPbakVA0a+NdLoNPcsl6BTW0nwgmZWU=; b=Ge36v2swmTOGQZAx1H39e5HfP8VcCvR6TeinDC/nLz20wzEORgtQ6/sy+vwOVzPuTg PiWWBRMU7xDS3IqejAuuc9U67oLuMX0cgSNhMujdnlsrqQyU6HqRokHJHkkfJQOYFhNf l9EpJC6m+YN+RlOml3Q7nFL7Ztlv/h/auRoocFxaqJWLSV5RAMgcp81mTp8lXDtVmZU5 aCm0EN2/O6PE91NivwcUzD9FoliH1UJqqM/LSNBpaNhA2F1YyJPggo2UDwH9CuKC549r e0xI5DDRTQeT4s+i00+KqUp7Fy9ylaZzpI/6mQP0ia5L13gxw78uZUAlRNOvDlujA1ky x/8g==
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=pn3ZY4FpkwY1NPbakVA0a+NdLoNPcsl6BTW0nwgmZWU=; b=F9og+6y+/SQ/zFOLyUrsOkAI/fm/e9Uq5h4a2bcSoXEyjyHjQmFrTlXmYFKn/O+6zl p3ddpvBMftg5gkxo+k9xER7281Xj12JzeFiWNXt7ZfRodj0iVth0E5IhpXGQOppgJ2Pe 8ewfC2XmTiVM+qBP1lCnsqAEPCFDc5EpETfHBkg41NxNsBHx46gHO/Xch7GxcjEmEQKY VEHBb8oY/o3+vf6Z7zyIsFamLFudu9FTgEUGdQ9CCgYNOd2qeDzFmCnRhG3YTSXJchUI L7MVWbYmJX7RYPb8zJtUAHlJjSffppQ3eU7cseBpfGuEF3nxTehA8wBs2dk94CZ3acR3 7dIQ==
X-Gm-Message-State: AGi0PuY5dgr5e06446bQNmmYblbn1oqEPPnNo0gYnEKyFQiqBzXwvZ16 2+SmO33bbtRy5xmUbIEAccnys3Jzhk+ZR/f9Wmk=
X-Google-Smtp-Source: APiQypIv7xDcgZi9CMIht4ZfV1mmurTyDLp90HYjd3KVCi9ZOqJ2EPvfOYceJERG3nJ1Skq5RzEs+vBwHH2maDO8hkY=
X-Received: by 2002:ac8:7b45:: with SMTP id m5mr1098819qtu.336.1588624626785;  Mon, 04 May 2020 13:37:06 -0700 (PDT)
MIME-Version: 1.0
References: <20200503190202.GD57581@vurt.meerval.net> <60c43db2-030e-723e-177c-13cc14758c64@verizon.net> <20200503200112.GI57581@vurt.meerval.net> <2d3b8f2f-2872-3652-56d9-6f23f8eb56fa@verizon.net>  <9d77bc6f-7eb0-474e-9f6b-48f9e5fca8d5@verizon.net>
In-Reply-To: <9d77bc6f-7eb0-474e-9f6b-48f9e5fca8d5@verizon.net>
From: Christopher Morrow 
Date: Mon, 4 May 2020 16:36:55 -0400
Message-ID: 
To: Stephen Kent 
Cc: SIDR Operations WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [Sidrops] About the use of manifests (follow-up from Apr Interim meeting)
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, 04 May 2020 20:37:12 -0000

On Mon, May 4, 2020 at 4:06 PM Stephen Kent
 wrote:
>
> Chris,
> > did you mean 'angel hair pasta' ? :) (which I agree, far better than
> > that gross fat worm pasta... but...)
> yes, angel hair, unless I was thinking about elbow macaroni, with sharp
> angles

:)

> > i think this was the meat of the previous discussion:
> >    "originally we left a lot of wiggle room, because "
> agreed.
> > and today/now:
> >    "uhm, leaving this much wiggle room was ... oops! folk would REALLY
> > like to understand
> >     the tradeoffs in a succinct manner (that does not require phd in
> > pkix) and some better
> >     guidelines on what they should set as default behavior that
> > can/will set a base security/safety
> >     level for their deployment."
> >
> > which I think is the goal of job's draft? I understood from previous
> > email conversations on
> > the WG list that the previous author set was happy to suggest
> > improvements but had no time/$$
> > for the full edit job?
>
> I will offer edited text for section 6 later today.

cool! are you planning on running this to ground fully? or sending
along the text and having another person manage the update stream/etc?


From nobody Mon May  4 13:37:48 2020
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 11C8C3A1020 for ; Mon,  4 May 2020 13:37:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aelmans-eu.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gt2pht2zaaih for ; Mon,  4 May 2020 13:37:44 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 152643A1021 for ; Mon,  4 May 2020 13:37:43 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id l18so95753wrn.6 for ; Mon, 04 May 2020 13:37:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aelmans-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DIWLqQiNfOcnLjDcZJBzY1OfKh3xl6F8+lYD53kjom8=; b=cyPTHj6aMUn4ujLdnqFfC6gQO/fT9l+gYvZ/OrLwQs7LOhnB+WhbETqBB2hgJNurF/ idXLtM9+zW7F5l3jG0TP9kkNURTogwEVSjo++0zbAH3Rc+DNSMGbQSSOYkeOk9yeirs6 XRfu/vZMZA+ZFF8XlcmxCT/PIcWZ5cpkzYb4PinP1xffKSeatmSw7CPv+UpxriOUKQLC ZdZ35AN4U+UAjDpYioN3SlCDvR5g7MsPmKn599swE57vvuxncPSMvBU32LCvIFTv10id LpFRp/ZxksdyQT2SonKq4X1ZGoX3EgvIDopDZIPTlqWWxXwVeI1CtzlrAuh1dIU82s2I 35Ww==
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=DIWLqQiNfOcnLjDcZJBzY1OfKh3xl6F8+lYD53kjom8=; b=ru1H1pVMNLrSDCUWIGjjTyLj3QLJFVgNCPrl9jy8ulFOIObw/yeOQ8fSPQSG8qs/9Z y6kdP2VXmMiWcozXjzAxLqm7schWyxTMPt2eugp6NvpMO0WkIp+kRb/HUDNJd2spxbyJ WnCaLxUVuY4PoQjh+SM36Dl+fivYuwyHb/CG1i3f7N92Y8gFzgB20sREZ48mdPnLWC2C ZdA/ITTwSjEUFEFZzO1iZjEo81QBEYiKWK0fA9vh6DZgwe1c46/2CaVumFkZFlNsQG0V IzAv5NcT9tkSfTedLTtsYaAcXIEPPEQdxzMOIC85AfJl3plczMochNWCUK4O7X5BV2q2 LLUA==
X-Gm-Message-State: AGi0PuaqBl1+paHnvC5cLgyvnOSLA/N3rqWUhavgjaDy5T+cqt6FYzi0 AWBp2Z24cfbHgJh2s3dfUqVVvZtYMUXS68q14sbFVg==
X-Google-Smtp-Source: APiQypKMvhq9f72oNZfE/QY+0OVqZ7AhhYBrroWBsUnbYdtda9pW2FcipIgz10najCp3KjVWrMWrWz/iHMxt8f7r0QM=
X-Received: by 2002:adf:91e4:: with SMTP id 91mr36777wri.356.1588624662135; Mon, 04 May 2020 13:37:42 -0700 (PDT)
MIME-Version: 1.0
References: <29748EA5-6016-4E6D-9261-A069F7431390@nlnetlabs.nl> <7CF309AA-0B5F-4FE8-80E8-5E041CA21CF1@ripe.net>
In-Reply-To: <7CF309AA-0B5F-4FE8-80E8-5E041CA21CF1@ripe.net>
From: Melchior Aelmans 
Date: Mon, 4 May 2020 22:37:31 +0200
Message-ID: 
To: Oleg Muravskiy 
Cc: Tim Bruijnzeels , SIDROps Chairs ,  SIDR Operations WG 
Content-Type: multipart/alternative; boundary="000000000000ab1fa105a4d880a3"
Archived-At: 
Subject: Re: [Sidrops] Adopt draft-sidrops-bruijnzeels-deprecate-rsync?
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, 04 May 2020 20:37:47 -0000

--000000000000ab1fa105a4d880a3
Content-Type: text/plain; charset="UTF-8"

I support adoption.

Cheers,
Melchior

On Mon, May 4, 2020 at 5:37 PM Oleg Muravskiy  wrote:

> On 29 Apr 2020, at 15:18, Tim Bruijnzeels  wrote:
> >
> > Dear co-chairs, WG,
> >
> > As mentioned yesterday I would like ask the chairs to do a call for
> adoption on:
> >
> https://datatracker.ietf.org/doc/draft-sidrops-bruijnzeels-deprecate-rsync/
> >
> > I am also more than happy to discuss the content, and adapt following
> discussion, but maybe this is better done if adopted :)
>
> Support
>
>
> Oleg
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
>

--000000000000ab1fa105a4d880a3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I support adoption.

Cheers,
M=
elchior

On Mon, May 4, 2020 at 5:37 PM Oleg Muravskiy <oleg@ripe.net> wrote:
On 29 Apr 2020, at 15:18, Tim Bruijnzeels=
 <tim@nlnetlabs.nl=
> wrote:

> 

> Dear co-chairs, WG,

> 

> As mentioned yesterday I would like ask the chairs to do a call for ad=
option on:

> https://datatracker.=
ietf.org/doc/draft-sidrops-bruijnzeels-deprecate-rsync/

> 

> I am also more than happy to discuss the content, and adapt following =
discussion, but maybe this is better done if adopted :)



Support





Oleg

_______________________________________________

Sidrops mailing list

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




--000000000000ab1fa105a4d880a3--


From nobody Mon May  4 13:44:23 2020
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 0D3923A102D for ; Mon,  4 May 2020 13:44:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level: 
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjTgtsoXUVWR for ; Mon,  4 May 2020 13:44:19 -0700 (PDT)
Received: from sonic305-3.consmr.mail.bf2.yahoo.com (sonic305-3.consmr.mail.bf2.yahoo.com [74.6.133.42]) (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 110BA3A103B for ; Mon,  4 May 2020 13:44:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1588625058; bh=2CTmOHARGRjTHqAm0sI+Ki9DPqFHpHCfXlpMvH+FAwI=;  h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=KIQp4L1vFiuEWwt1ifXMM8foof3gW03CQmk4AtEq+K0vbyL5EzNOMiNnzqmPtWaIq2qQZs27L9cA0kZ80wkKvsv5avcbSY1q4niyvh+tnS2wfLkFId0RfhlYfmEdGPXuMaCKcpR51zZAXKQ4m/or3fOip87hrW12Pr+wfyJJWleLXAEOv7d7Ef7aovUfUQ1pGG49HC+OnUnK0moBlAX8p9FSleKODNpWAfzLHI2xnCtN+I93rQktn/X3iWYTIFS4K0QEcTMy8IDhz60EHN/GskLQK1VLFffjcrXaIQH0jyKdcDFCJOwTWHqhmt63SVsKvbLDLAAaxweDZl7M6I5n2w==
X-YMail-OSG: y6M0AykVM1lQjysuW4ZauM4FyPPkmujHphvl9qF0GIaGGz7747yxSwrDNksS_gF oEsoeuWrJ8xrAwErYJrZlEMloOFHmwFYBy65SIvCBwEKqHqz8siBH8BaagHZ0TTEUQjl.5czroSC u22jbUnyJXxKI79OT_zkhgn_phYrQN8z24Ounw6ak4d_XomBfgVbjSHWsQgwaK7BdSvceTrzDGr0 iNzfFeFwVisJU8aUtimCzZJwD9ajHkog6vNfaiyZ3IfTrXitbES.92RtNkbwl3FEfUo58E30Cu7f yZYTI5RxsukRKdROV8JACrLT3kUM.FQrWcGuEUdRt0MWW7BtDRLz2u11MnWIL1vE1B4uR11vZQx2 WTSP5OEyMuM7XIM4K9rOSz2ISkOnC0NguMUI_L..L.o42hohvjKuWcgpo70x.fUGRsmC4u.rfDKH zUhBkICx0aCPDohGn8OHdSRXCUZOQ7t9bGvy6ZbANYmhOwFGS9woCQ_X9t3FBYHKUNp1nTD0iQMv mig84agjh0GH4OpXXKEWqlHSEvT23FmQLpAQEoYfKqa1wp1JaAEMqMROnUYUPTfSseleSk.QWqle lJkVnJl7qFwZnBT8QTlfoo.5lTSVtYtkmuI3mtskCuR8ttPwR1e_gWtfA7HEYDdz4fTnNF.CmGr3 at1zeSY9j0uA8TSsPZPYMkhFcWhM9y37Blx3HDc7D5jgmeVy0ctRPDTtUjkf3dSYPNkSFUD2irtf l.j4_3VL_w_PlFoFNzLZTwQlfy3jqgxnJlrG5s22XTfkDFw_I_yB.Usp_jWfPQviq4fVtQsXyQxK f.R7csYd.85RtBtyrDrqOoDFOPRClJA79z7o8ddhcOcWvq5qu4mN0lnqcoUhb94vKox2gEdlLwgd _l.BQCkSokTrwnwo4I5CrKNXGmMBnRm4T05AExidpUVuYmZ09i39aiiCQU7dvPMNGYHVjJxpUpt_ 4MrX1E6FlcQ9pyJrG8MAAECqKSkF7QH_QR8fEw1nMmbybuy6OKTH4s62.jnLP1t47KwPlHKXjonh A7M3jT5xyeNTG7WKlX4JAcERXQfyQQxg3bV9w3Lczdzl2jL8TX8wNxsjmA8YLdjuj_HLtk11oFRi cTAw1cNkeAuT.3sy3aF2lL1k9bD2v0iGRj595BDFC67993EYTu9Cig5spuuLfwbTSEfQZFm98SZ4 XDu0Hbl_Kp5BliDLvw.ofq9.ZHUfm_lI5YpSfz7t0uLlRSZsZm5SiFVzUCF9.3GIFkm0Jhzvn0.j W9wfxFRZWuKBdSV4srakF.oMdJL4kM7kNRz.nXvOlHD_5eg004ohl.5zGxDa2B6L9Wo3UGQy9LTx zeys8KgD3VfL0zq0MbEYzaogAcp3yIooNSxb39wEcYY_d3Y8CCWGHpt9sn6B22S05Nn_qwCJwPev yVeLd.GF9vsL4TUTQLng-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Mon, 4 May 2020 20:44:18 +0000
Received: by smtp402.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 5e4d1794b9897d746b58521c398b99d5;  Mon, 04 May 2020 20:44:17 +0000 (UTC)
To: sidrops@ietf.org
References: <20200503190202.GD57581@vurt.meerval.net> <60c43db2-030e-723e-177c-13cc14758c64@verizon.net> <20200503200112.GI57581@vurt.meerval.net> <2d3b8f2f-2872-3652-56d9-6f23f8eb56fa@verizon.net>  <9d77bc6f-7eb0-474e-9f6b-48f9e5fca8d5@verizon.net> 
From: Stephen Kent 
Message-ID: 
Date: Mon, 4 May 2020 16:44:16 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] About the use of manifests (follow-up from Apr Interim meeting)
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, 04 May 2020 20:44:21 -0000

Chris,
> ...
> cool! are you planning on running this to ground fully? or sending
> along the text and having another person manage the update stream/etc?

someone has offered to handle the XML editing to produce a revised RFC, 
when we have agreed-upon  text, so I think we're good for now.

Steve


From nobody Mon May  4 14:07:27 2020
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 7B1133A108B for ; Mon,  4 May 2020 14:07:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azgMTkhkqdXK for ; Mon,  4 May 2020 14:07:23 -0700 (PDT)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 2D5D13A1077 for ; Mon,  4 May 2020 14:07:23 -0700 (PDT)
Received: by mail-qt1-x82e.google.com with SMTP id s30so267913qth.2 for ; Mon, 04 May 2020 14:07:23 -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=C+6R/HmUKu14s75aAIsiaaDzm7VG4v3YPLUTW6JEZGo=; b=pumUnCXR3ZRFd1Jd9E6INBVn/lRDiOdFe9pjQ7vQOcN0NhNzP9VgcGiZvxU7dJ/l5X ulqwf1tyJM2PqePwoF3bFe+huSHfxW/kGVqSDhvsx8tiACN3WHVUrrTF72sv+7Xf5J2C 8Vc7w0GZ4jcg8oXJPIO+mzccqK8zBIcVVrRrDTOWo+zFNtR9qj3ruTF5CrfQN+xLJ8hY HKCLutTHeDBgitrHC5TokB4gfvoPMHeu2n2Jzj/Dbz0IC42LvBX0t3ruskrXs9TVdVYW PosphJiSVHxznsZ4pVKVd146RD6Z6OyltYzpJqyPVHd5nbrZrD8EpulxQQ96MMQPYmKo bsXQ==
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=C+6R/HmUKu14s75aAIsiaaDzm7VG4v3YPLUTW6JEZGo=; b=XRh1mY5ZcLX1lxSfac7G6WEKwN3uKopADafUpZSQOSgQ9eYRZygli9Gg3U/jmyiLHr rQCGTffBtfMrmygZwKc5Q3cuS8YRqFiKLWqxLoIOi0bKvWGs3WEiQOcfjU8uqsl8lOR1 iAkhGei9EML9cvvxlwFj6/zqnK7lzmoNhb4VV7wedkk2sveSGzTArYb6hii6Uq5517oV KuuujWJ+jyxxz3xBaCzV7fyBSvlml2bXQoOng8rYtRMfWZGbaCSOjtfknQS6BCpQ6LnF OappmH/ApefEePEoDL//Ad7ITqZOo1q07W+w8FMSvpViJe5vGo+3WdekCOCGsVb3BHQt 0tKQ==
X-Gm-Message-State: AGi0PuaNYYbXaOA7bT5wgrp+u8a5wg5V907AJ+JZPFIONF80AKrFXpZS T4DDVvCrprltdi7BAGGqxV2FR/dcg7M9ZFO/JYcuK3XS
X-Google-Smtp-Source: APiQypLhPMdthUIC/8XNad+liZmpqenhQJDev6vSlhjHZt43h34Vs0RBzzzOiBn6mUEWy5ebS0FTJDr7oAekpbDozi4=
X-Received: by 2002:ac8:193d:: with SMTP id t58mr1088113qtj.93.1588626441908;  Mon, 04 May 2020 14:07:21 -0700 (PDT)
MIME-Version: 1.0
References: <20200503190202.GD57581@vurt.meerval.net> <60c43db2-030e-723e-177c-13cc14758c64@verizon.net> <20200503200112.GI57581@vurt.meerval.net> <2d3b8f2f-2872-3652-56d9-6f23f8eb56fa@verizon.net>  <9d77bc6f-7eb0-474e-9f6b-48f9e5fca8d5@verizon.net>  
In-Reply-To: 
From: Christopher Morrow 
Date: Mon, 4 May 2020 17:07:10 -0400
Message-ID: 
To: Stephen Kent 
Cc: SIDR Operations WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [Sidrops] About the use of manifests (follow-up from Apr Interim meeting)
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, 04 May 2020 21:07:25 -0000

On Mon, May 4, 2020 at 4:44 PM Stephen Kent
 wrote:
>
> Chris,
> > ...
> > cool! are you planning on running this to ground fully? or sending
> > along the text and having another person manage the update stream/etc?
>
> someone has offered to handle the XML editing to produce a revised RFC,
> when we have agreed-upon  text, so I think we're good for now.

ok, thanks!


From nobody Mon May  4 18:15:37 2020
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 DF75C3A12C7 for ; Mon,  4 May 2020 18:15:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSRpOHF23eS6 for ; Mon,  4 May 2020 18:15:33 -0700 (PDT)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 B403D3A133A for ; Mon,  4 May 2020 18:15:29 -0700 (PDT)
Received: by mail-io1-xd2c.google.com with SMTP id y26so673671ioj.2 for ; Mon, 04 May 2020 18:15:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+qvv5cAWKN5VaGhzXOC17rPa0LDBTYzbQVacwrFDIk0=; b=cDpUp8ulOGhRxWykK9egbUh2L7/4xtzfLMnbTNRezEE4BX8re5EnUBkV5Aadi6+jcC bpeZOL1zcpDKczD5pfTaet9XDLD0YQ4aYJR0qZHeVH/pdGSX6KxsGtWMgQrBMQOZbV3p Mx6/k+5g7yNSxpW41+PZRpK/UCbkpHjpamS3zBv4AV+O9FcJR6u9B62Bx2CXhabJEESK +iAmEITwqo9A7SS7e4KBCYuTmFY9gvM1Hlr3a6z1U5a1mjqQJYIfymLxjORZzNd7Bd0k zPMldHLg07NWnoIY1FsOaDd7kg+RRApiEC55CYzyIxUpXpjTKhdNe9FPIpdeOEam0Est B53w==
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:content-transfer-encoding; bh=+qvv5cAWKN5VaGhzXOC17rPa0LDBTYzbQVacwrFDIk0=; b=sLhJ02GdOYPnZg91gbEWKqW/gaIeDvJ8W4h8iz508pUWTz2lglNtOpMGOkga3VvPVl OnQoGaco/27iTM75ZP0pZUQKoXlOI1ICz6CvgKfKuaz+yRizI685DmP7BACiVQWxD/nZ BwWZo4qCavBM7I9IKqjBNcVEBI78bj3i8J7+XbXJG26iwoCnO9+4WGeMrNzsFPcR2FR6 iNHXB9yRwnwWKqwDO5O80RBXL4ZyjE4lluVzXtbI1yDh+ln3nLHaFyBjZf29Cos40Idh iw2VhZdqV/hXJAS6KIF9Ss+3obK9cNY8t3HjgT54HQkRNlBJqGmAYnPIZNW3ooQKVP4i EsKA==
X-Gm-Message-State: AGi0PuaMdr/1jz3f+8BKTWQPjvcTcQ9Nr4TbU5/egbwNSotmc40q+aWt 6kPqsCiz6JuZc9NhWc4xVl2VEhGc3BXKP4fxDlYKPUKF
X-Google-Smtp-Source: APiQypI6FPZUXHKUFpHsJvOuE1WxVTphfZEaqKGsQhEYKlz8HHmDbx/KR8GvhY3VS3d4YAma3MMXITwUIs7atOfEUAw=
X-Received: by 2002:a02:40c2:: with SMTP id n185mr1196822jaa.43.1588641328320;  Mon, 04 May 2020 18:15:28 -0700 (PDT)
MIME-Version: 1.0
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net>
In-Reply-To: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net>
From: George Michaelson 
Date: Tue, 5 May 2020 11:15:16 +1000
Message-ID: 
To: Stephen Kent 
Cc: "sidrops@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Sidrops] proposed, revised text for Section 6
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 May 2020 01:15:36 -0000

I just want to note that while I think you made a logically consistent
choice, I do not agree with its intent, in as much as I believe cached
state could be used to construct the valid state which the manifest
and CRL declare.

So, I think you drove to a harder place than I intended. But, I accept
this is a choice, and a strong choice.

I suspect I am in a minority of one on this. I would not seek to
impede a group decision driving to a more narrow constrained
definition.

-George

On Tue, May 5, 2020 at 6:09 AM Stephen Kent
 wrote:
>
> To get the discussion going, I generated the following text for Section 6=
. I deleted anything that was not definitive (e.g., deferred to local polic=
y) and removed the warning message suggested text (I assume RP software dev=
elopers can write their own messages, but we can add this back if folks fee=
l it's useful.
>
> I also added a paragraph about the manifest/CRL circular relationship.
>
> In all cases I adopted the approach George suggested, i.e., if there's an=
 error indicating that one or more signed objects may be missing (or not cu=
rrent), ignore ALL data associated with the CA instance at the pub point an=
d DO NOT rely on cached data.
>
> Comments welcome, as usual.
>
> All new text is in red.
>
> Steve
>
> -----
>
>
>
> 6.1. Determining Manifest State & Object Acceptance
>
>
>
>    For a given publication point, and given CA instance, an RP MUST perfo=
rm
>
>    the following tests to determine the manifest state of the publication
>
>    point. (Note that, during CA key rollover [RFC6489], signed objects fo=
r
>
>    two or more different CA instances will appear at the same publication
>
>    point. The tests described below are to be performed for a specified C=
A
>
>    instance, i.e., a the manifest=E2=80=99s EE certificate was issued by =
that CA.)
>
>
>
>    1. Select the CA's current manifest (the "current" manifest is the
>
>        manifest issued by this CA  having the highest manifestNumber amon=
g
>
>        all valid manifests (as defined in Section 4.4).
>
>
>
>       If the publication point does not contain a valid manifest, proceed
>
>       as described in Section 6.2. (Lacking a valid manifest, the followi=
ng
>
>       tests cannot be performed.)
>
>
>
>    2. Check that the current time (translated to UTC) is between
>
>       thisUpdate and nextUpdate.
>
>
>
>       If the current time does not lie within this interval, proceed
>
>       as described in Section 6.4.
>
>
>
>
>
>   3. Acquire all objects at the publication point associated with this
>
>      CA instance, i.e., the CRL and each object containing an EE
>
>      certificate issued by the CA. If there are files listed in a manifes=
t
>
>      that do not  appear at the publication point, then proceed as
>
>      described  Section 6.5.
>
>
>
>
>
>    4. Verify that the listed hash value of every file listed in the
>
>       manifest matches the value obtained by hashing the file at the
>
>       publication point.
>
>
>
>       If the computed hash value of a file listed on the manifest does
>
>       not match the hash value contained in the manifest, then proceed
>
>       as described in Section 6.6.
>
>
>
>    5. If a current manifest contains entries for objects that are not
>
>       within the scope of the manifest, then the out-of-scope entries
>
>       MUST be disregarded in the context of this manifest.  If there
>
>       is no other current manifest that describes these objects within
>
>       that other manifest's scope, then see Section 6.2.
>
>
>
>
>
>    Note that there is a =E2=80=9Cchicken and egg=E2=80=9D relationship be=
tween the
>
>    manifest and the CRL for a given CA instance. If the EE certificate
>
>    for the manifest is revoked, the CA or publication point manager has
>
>    made an error. In this case all signed objects associated with the CA
>
>    instance MUST be ignored. Similarly, if the CRL for the CA instance
>
>    is not listed on a valid, current manifest, all signed objects
>
>    associated with the CA instance MUST be ignored, because the CRL is
>
>    missing.
>
>
>
>
>
> 6.2.  Missing Manifests
>
>
>
>    The absence of a current manifest at a publication point could occur
>
>    due to an error by the publisher or due to (malicious or accidental)
>
>    deletion or corruption of all valid manifests.
>
>
>
>    When no valid manifest is available, there is no protection against
>
>    attacks that delete signed objects or replay old versions of signed
>
>    objects. To guard against the adverse impact of processing an
>
>    incomplete set of signed objects, an RP MUST treat all signed objects
>
>    associated with the missing manifest as invalid. (These objects are
>
>    all issued by the same instance of a CA.) RP software MUST issue a
>
>    warning when there is no current manifest for a CA instance.
>
>
>
>    An RP may have access to a local cache containing a previously
>
>    issued manifest that is still valid. It is RECOMMENDED that the RP
>
>    not make use of this data, to ensure consistent a consistent outcome
>
>    in when a manifest is missing.
>
>
>
> 6.3.  Invalid Manifests
>
>
>
>    The presence of an invalid manifest at a publication point could
>
>    occur due to an error by the publisher or due to (malicious or
>
>    accidental) corruption of a valid manifest.  An invalid manifest MUST
>
>    never be used, even if the manifestNumber of the invalid manifest is
>
>    greater than that of other (valid) manifests.
>
>
>
>    If there is no valid, current manifest available at the publication
>
>    point for the CA instance, an RP MUST treat the signed objects at the
>
>    publication point as indicated above in Section 6.2. A warning MUST
>
>    be issued when an invalid manifest is encountered.
>
>
>
> 6.4.  Stale Manifests
>
>
>
>    A manifest is considered stale if the current time is after the
>
>    nextUpdate time for the manifest.  This could be due to publisher
>
>    failure to promptly publish a new manifest, or due to (malicious or
>
>    accidental) corruption or suppression of a more recent manifest.
>
>
>
>    All signed objects at the publication point issued by the entity that
>
>    has published the stale manifest, and all descendant signed objects
>
>    that are validated using a certificate issued by the entity that has
>
>    published the stale manifest at this publication point, MUST be
>
>    treated at invalid and a warning MUST be issued.
>
>
>
>    The primary risk in using such signed objects is that a newer
>
>    manifest exists that, if present, would indicate that certain objects
>
>    have been removed or replaced.  (For example, the new manifest might
>
>    show the existence of a newer CRL and the removal of one or more
>
>    revoked certificates).  Thus, the use of objects from a stale
>
>    manifest may cause an RP to incorrectly treat invalid objects as
>
>    valid.  The risk is that the CRL covered by the stale manifest has
>
>    been superseded, and thus an RP will improperly treat a revoked
>
>    certificate as valid.
>
>
>
>
>
> 6.5.  Mismatch between Manifest and Publication Point
>
>
>
>    If there exist valid signed objects associated with a CA instance and
>
>    they do not appear in any current, valid manifest for this CA instance=
,
>
>    these objects MUST be ignored by an RP, and a warning MUST be issued.
>
>
>
>    If there are files listed on the manifest that do not appear in
>
>    the repository, then these objects have been improperly deleted from
>
>    repository (via malice or accident).  A primary purpose of manifests i=
s
>
>    to detect such deletions.  Therefore, in this case, an RP MUST ignore
>
>    all signed objects associated with this CA instance.
>
>
>
> 6.6.  Hash Values Not Matching Manifests
>
>
>
>    A file appearing on a manifest with an incorrect hash value could
>
>    occur because of publisher error, but it also may indicate that an
>
>    attack has occurred, e.g., one in which an older version of an object
>
>    has been substituted for a newer version of the object. In this case
>
>    an RP cannot know the content of the missing object, and thus all
>
>    signed objects associated with this instance of the CA MUST be ignored
>
>    by the RP, and a warning MUST be issued.
>
>
>
>
>
>
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops


From nobody Mon May  4 21:33:57 2020
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 6E6AB3A13B9 for ; Mon,  4 May 2020 21:33:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5A6BfHuoETQ for ; Mon,  4 May 2020 21:33:54 -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 2595E3A13B2 for ; Mon,  4 May 2020 21:33:08 -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 1jVpGU-00076R-Oo; Tue, 05 May 2020 04:33:06 +0000
Date: Mon, 04 May 2020 21:33:06 -0700
Message-ID: 
From: Randy Bush 
To: George Michaelson 
Cc: SIDR Operations WG 
In-Reply-To: 
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net> 
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [Sidrops] proposed, revised text for Section 6
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 May 2020 04:33:55 -0000

> I just want to note that while I think you made a logically consistent
> choice, I do not agree with its intent, in as much as I believe cached
> state could be used to construct the valid state which the manifest
> and CRL declare.
> 
> So, I think you drove to a harder place than I intended. But, I accept
> this is a choice, and a strong choice.
> 
> I suspect I am in a minority of one on this. I would not seek to
> impede a group decision driving to a more narrow constrained
> definition.

sra has bludgeoned me much closer to your position

randy


From nobody Tue May  5 00:45:16 2020
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 994603A15B8 for ; Tue,  5 May 2020 00:45:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 QS6mIvcs8E0F for ; Tue,  5 May 2020 00:45:11 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0: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 A38A83A15B6 for ; Tue,  5 May 2020 00:45:11 -0700 (PDT)
Received: from [IPv6:2001:981:4b52:1:dc54:11f4:4cf3:af71] (unknown [IPv6:2001:981:4b52:1:dc54:11f4:4cf3:af71]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 0489829BB6; Tue,  5 May 2020 09:45:09 +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=1588664709; bh=9uPFWhuiroEYECFwFpgOM6YrSAdjDcdjPG2HZ8PxMuU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=dNI6VPxtGONfTr/JbyRgMs8RrjgJ5sKcD3pYgox5givGAX1Bsk2KBSPDEhhd51Pjd GuaWFTH99POyuDfKx60GRSpZX/YVLjLctc7Bk7ZObPyBDOZ3DQWhbQi8b6dZo4hvx9 ns0NsRScuc+U+Rc9HapuDBBlekIrnwq/ID1vpUmI=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Tim Bruijnzeels 
In-Reply-To: 
Date: Tue, 5 May 2020 09:45:07 +0200
Cc: SIDR Operations WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <87pnbrspdr.wl-morrowc@ops-netman.net> <24232.24434.41224.396200@oz.mt.att.com>  <12F90135-5597-490B-947F-F588C2ED3B48@nlnetlabs.nl>  <0BC5FAFC-A5A3-4B67-82C1-C1BE90335C95@nlnetlabs.nl> 
To: Randy Bush 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [Sidrops] ASPA duplicates
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 May 2020 07:45:14 -0000

Hi,

> On 4 May 2020, at 15:39, Randy Bush  wrote:
>=20
>> This might not be easy for existing RPs - with ROAs the thought has
>> also been that they are cumulative. Now you would need to keep much
>> more state, and even check between all configured TAs - which until
>> now could just be processed in parallel.
>>=20
>> I understand your reasoning, but I think this warrants at least some
>> normative wording in the document and discussion in the security
>> section. And most importantly I am curious to learn what RP software
>> implementers think (nowadays I do the CA side, which is much easier =
in
>> this context).
>=20
> from draft-ietf-sidrops-8210bis
>=20
> 11.  ROA PDU Race Minimization
>=20
>   When a cache is sending ROA PDUs to the router, especially during an
>   initial full load, two undesirable race conditions are possible:
>=20
>   Break Before Make:  For some prefix P, an AS may announce two (or
>      more) ROAs because they are in the process of changing what
>      provider AS is announcing P.  This is is a case of "make before
>      break."  If a cache is feeding a router and sends the one not yet
>      in service a significant time before sending the one currently in
>      service, then BGP data could be marked invalid during the
>      interval.  To minimize that interval, the cache SHOULD announce
>      all ROAs for the same prefix as close to sequentially as =
possible.
>=20
>   Shorter Prefix First:  If an AS has issued a ROA for P0, and another
>      AS (likely their customer) has issued a ROA for P1 which is a =
sub-
>      prefix of P0, a router which receives the ROA for P0 before that
>      for P1 is likely to mark a BGP prefix P1 invalid.  Therefore, the
>      cache SHOULD announce the sub-prefix P1 before the covering =
prefix
>      P0.

Thanks for the pointer! It's unfortunate that there are no transactions, =
but I accept (already did) that this is what it is.

However, my point which you quoted was about the suggestion that =
Alexander made that there MUST NOT be multiple ASPA objects for the same =
customer ASN in the RPKI, and that if there are they should all be =
ignored - even if they are all valid objects.

At least that was my understanding of his intent. So that there is a =
simple model to deal with ASNs being present on multiple CA certificates =
in the RPKI (delegated or different TAs even) and the confusion and race =
conditions that may arise from managing ASPA objects with that ASN as =
customer ASN all together. Ignoring the objects provides a soft landing =
then.

I am not against this per se, but I think *this* needs clarification in =
the ASPA doc, and possibly some more discussion here. I am sure that =
it's possible, but it requires that RPs keep more state than they do =
today.

Furthermore, I see some advantage here (it's a simple model), but as a =
downside this provides a sort of denial attack where a parent CA can =
issue an ASPA object to essentially invalidate the object issued by the =
operational holder of the ASN. Worse, this can happen between TAs, so =
only one TA would need to be subverted in order to invalidate ASPA =
objects under any of the other TAs.

For ROAs the RPs just build a complete list of all VRPs found on all =
valid ROAs anywhere, and only then a set is made and duplicates are =
excluded when talking to the router. So VRPs appearing elsewhere do not =
have the power to force other VRPs to the 'ignore list'. For ROAs the =
advice is that parent CAs have a responsibility NOT to invalidate their =
children's announcements, and for inter RIR transfers make before break =
is at least theoretically possible. A similar model could also apply to =
ASPA objects.

I know this is a political minefield as much as a technical issue. =
Nonetheless, I think we should make a clear decision which scenario is =
desired under today's operational reality.

Tim





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


From nobody Tue May  5 04:36:55 2020
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 87CBF3A1646 for ; Tue,  5 May 2020 04:36:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cF9bC0fmP4ul for ; Tue,  5 May 2020 04:36:52 -0700 (PDT)
Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (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 66AE93A1644 for ; Tue,  5 May 2020 04:36:52 -0700 (PDT)
Received: by mail-wr1-f52.google.com with SMTP id z8so1402678wrw.3 for ; Tue, 05 May 2020 04:36:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=N7bB/elqYIyntubbnS3u8gswCCBlF01HEhV0bymmHsE=; b=pkXMVbKotcPw7PBnplw9Q6R8om5SHqS2sWW/x1dSGh2YAPlMtqFH7ii87bPRy2UaZf xkulURgGv1Had1qPvUeGKA3jDAfCFkj3/b+O6HigbtUB/YpRbS8g3AWZtkHOE9/KCA+U g6B+neQrMRS2IdG2+TWaqXwCKNTSqDhocRhVcxguqegbeOZVG3JN+OVvmzOmeUuddg0h /1Yc2xercqESChrq/EjXpMeYUiVf3HPoKAfKbr1XxH98QcRZTP8/2+32wmzMxBEyXI9D HHyigHbEe5qw8jHOR1BNhj9MfiEWaZ1DOaYf+AjpVi8C4Haucjg1Tqc+dCBcynPGfhRM CkqQ==
X-Gm-Message-State: AGi0PuY8aheWpKbflXdZni36o8hdruAAYZ8SCCs2D1ZbRr9uLxQQXPXw qcXqBM9rRGbvFITSS1tHpk8X9ofoBCg=
X-Google-Smtp-Source: APiQypIupp7VvyeoK1hqboWD+Onl3s+Ejwl0e0ThM1wdtEDLOCHxK7g7mYwadqwq0forDbbQJ0qb8g==
X-Received: by 2002:adf:fe41:: with SMTP id m1mr3227764wrs.52.1588678610298; Tue, 05 May 2020 04:36:50 -0700 (PDT)
Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id e13sm2835866wrw.88.2020.05.05.04.36.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 May 2020 04:36:49 -0700 (PDT)
Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 7b7ece02; Tue, 5 May 2020 11:36:48 +0000 (UTC)
Date: Tue, 5 May 2020 11:36:47 +0000
From: Job Snijders 
To: sidrops@ietf.org
Message-ID: <20200505113647.GA93200@vurt.meerval.net>
References:   <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net>    <20200415124611.7af291b1@glaurung.nlnetlabs.nl> <974eeeaa-32e6-45b2-860f-6b1408ae14e6@www.fastmail.com> <24215.11555.329412.270610@oz.mt.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <24215.11555.329412.270610@oz.mt.att.com>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: 
Subject: Re: [Sidrops] trying to limit RP processing variability
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 May 2020 11:36:53 -0000

On Wed, Apr 15, 2020 at 11:49:55AM -0400, Jay Borkenhagen wrote:
> Job Snijders writes:
>  > On Wed, Apr 15, 2020, at 12:46, Martin Hoffmann wrote:
>  > > An attacker who can delete files can as easily replace them with
>  > > something else with the same result. So I am not sure the added code
>  > > complexity is worth it.
>  > 
>  > Agreed. 
>  > 
>  > fwiw: rpki-client runs as "openrsync -rlt --delete rsync://xxx/repository xxx/repository"
>  > 
> 
> I agree with this behavior as well.

I think I was wrong to agree here. I had discussions with some people
about 'where does the publication point exist?' - is it a remote entity?
or is a local construction of pulled data? I'm now leaning more towards
an interpretation that the publication point only exists in the mind of
the RP.

Phrased differently: It seems somewhat strange to let unauthenticated
untrusted network data (aka 'rsync --delete') destroy an otherwise
perfectly healthy and valid CA.

What perhaps should be done:

- rsync pulls data in (without '--delete')
- the validation process deletes files that are not listed on the valid
  manifest (iff a valid contemporaneous CRL exists)
- Additionally, implementers will need to pull the untrusted RPKI data
  into a staging area, to guard against letting the rsync overwrite
  otherwise healthy .roa files with garbage.

Kind regards,

Job


From nobody Tue May  5 05:14:07 2020
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 E44063A16AC for ; Tue,  5 May 2020 05:14:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42nEyzy46qbw for ; Tue,  5 May 2020 05:13:59 -0700 (PDT)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 C8A113A166C for ; Tue,  5 May 2020 05:13:58 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id x25so2040675wmc.0 for ; Tue, 05 May 2020 05:13:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=from:date:to:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=eojVlZruyiREWtr16O8mUC6bSsqPIrNYUtdiqshkWbw=; b=R31FZlbM5YI2tONIWp3mqtOHmN4G7uOA24Eg+ZeI6kDHaSqo078f9GsqLvB0deDuHi xHv7j+r+6HItK2AfVhkvqtx5GzEJbNyoHkJeWeC0vwLPAkHYWqTx7HCCcRx5JJcP0Ib8 FhH7hxhb6GRsCOJlB0VVSiddxWrfIY8j7VgfO5+2G+FDDbIrCWbtswWuemgU0CULrRZd 4+EOn0TegrwNFPYkf713HRyF5UUHSd9YwcpOaq8bcnAWaQzAEGNv1WaNxpmwH48sqpRo yc4F8eYuHIL1OydGBDU/l3Q1nTcRNqNbBnyrKH5jdtbf2G8gCkNE8wij5Y+smWfR0OZl HCKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=eojVlZruyiREWtr16O8mUC6bSsqPIrNYUtdiqshkWbw=; b=nKioD4EKOXWEx6aBYd6CTy0bcfDrpt7LQr9Vsi9iJscoHvWJkNLqnck192BvOkQWCC mDQj9BoZWHPZhP267xzBqCgif1WEIRSuxT/FZfznhhrd57OMsdJGrNNVDTX1IovUeHMz hhVZ9eividI/Cr9N5bMWzOEf/zjhcr/GQDfrVhHMMVIWQqiypeLm41qfE03sTGy9A0Cs fODD7qjaeW6bR5U1wzzIHQ/JDD4nlofjGZMXwPka29aP4Gn9BjnN/d+iIIEaybhM+thE wehiA1YUYY/4a0Tmw+ew/AREuaHUAfkAOad3L4nA0T94a70KEc2JF5jykUygRmKgRofm HaMg==
X-Gm-Message-State: AGi0Pubk3plQF2gx9zrpohG4WR0NqEMNZh5Gl3j9ZCXRT6+8URY4exxa elDcLL8T8c8bqNMoly64vhBoNQW1vPI=
X-Google-Smtp-Source: APiQypLMylC6rXj0FlPEZ2HrxX0rGU4R8xZ04DaiNrTwPTjqpOPMrSAnReyziob+3gaZruH95UwdsA==
X-Received: by 2002:a1c:3182:: with SMTP id x124mr3456104wmx.54.1588680836301;  Tue, 05 May 2020 05:13:56 -0700 (PDT)
Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id y31sm3241606wrd.83.2020.05.05.05.13.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 May 2020 05:13:55 -0700 (PDT)
From: Job Snijders 
X-Google-Original-From: Job Snijders 
Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 8af0bf22; Tue, 5 May 2020 12:13:54 +0000 (UTC)
Date: Tue, 5 May 2020 12:13:53 +0000
To: sidrops@ietf.org
Message-ID: <20200505121353.GB93200@vurt.meerval.net>
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: 
Subject: Re: [Sidrops] proposed, revised text for Section 6
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 May 2020 12:14:05 -0000

Dear group,

On Mon, May 04, 2020 at 04:08:43PM -0400, Stephen Kent wrote:
> To get the discussion going, I generated the following text for Section 6. I
> deleted anything that was not definitive (e.g., deferred to local policy)
> and removed the warning message suggested text (I assume RP software
> developers can write their own messages, but we can add this back if folks
> feel it's useful.
> 
> I also added a paragraph about the manifest/CRL circular relationship.
> 
> In all cases I adopted the approach George suggested, i.e., if there's an
> error indicating that one or more signed objects may be missing (or not
> current), ignore ALL data associated with the CA instance at the pub point
> and DO NOT rely on cached data.
> 
> Comments welcome, as usual.
> 
> All new text is in red.

Small note: neither the archive
(https://mailarchive.ietf.org/arch/msg/sidrops/Qy7YAVOUYrDVZxUPFPNZfekoJKI/)
nor my mail client show any text in red. I am assuming the below quoted
text replaces all of section 6 in RFC 6486. I added section numbers to
the below quoted text and line-wrapped it. My comments are inline.

Stephen, question for you: is the use of the word 'files' and 'objects'
synonymous in the below text? Or are 'files' something different than
'objects'?

> 6.1. Determining Manifest State & Object Acceptance
> 
> For a given publication point, and given CA instance, an RP MUST
> perform the following tests to determine the manifest state of the
> publication point. (Note that, during CA key rollover [RFC6489],
> signed objects for two or more different CA instances will appear at
> the same publication point. The tests described below are to be
> performed for a specified CA instance, i.e., a the manifest’s EE
> certificate was issued by that CA.)
>
> 6.1.1. Select the CA's current manifest (the "current" manifest is the
> manifest issued by this CA having the highest manifestNumber among all
> valid manifests (as defined in Section 4.4). If the publication point
> does not contain a valid manifest, proceed as described in Section
> 6.2. (Lacking a valid manifest, the following tests cannot be
> performed.)
> 
> 6.1.2. Check that the current time (translated to UTC) is between
> thisUpdate and nextUpdate. If the current time does not lie within
> this interval, proceed as described in Section 6.4.
>
> 6.1.3. Acquire all objects at the publication point associated with
> this CA instance, i.e., the CRL and each object containing an EE
> certificate issued by the CA. If there are files listed in a manifest
> that do not appear at the publication point, then proceed as described
> Section 6.5.
> 
> 6.1.4. Verify that the listed hash value of every file listed in the
> manifest matches the value obtained by hashing the file at the
> publication point. If the computed hash value of a file listed on the
> manifest does not match the hash value contained in the manifest, then
> proceed as described in Section 6.6.
> 
> 6.1.5. If a current manifest contains entries for objects that are not
> within the scope of the manifest, then the out-of-scope entries MUST
> be disregarded in the context of this manifest.If there is no other
> current manifest that describes these objects within that other
> manifest's scope, then see Section 6.2.
> 
> Note that there is a “chicken and egg” relationship between the
> manifest and the CRL for a given CA instance. If the EE certificate
> for the manifest is revoked, the CA or publication point manager has
> made an error. In this case all signed objects associated with the CA
> instance MUST be ignored. Similarly, if the CRL for the CA instance is
> not listed on a valid, current manifest, all signed objects associated
> with the CA instance MUST be ignored, because the CRL is missing.
> 
> 6.2. Missing Manifests
> 
> The absence of a current manifest at a publication point could occur
> due to an error by the publisher or due to (malicious or accidental)
> deletion or corruption of all valid manifests.
>
> When no valid manifest is available, there is no protection against
> attacks that delete signed objects or replay old versions of signed
> objects. To guard against the adverse impact of processing an
> incomplete set of signed objects, an RP MUST treat all signed objects
> associated with the missing manifest as invalid. (These objects are
> all issued by the same instance of a CA.) RP software MUST issue a
> warning when there is no current manifest for a CA instance.
>
> An RP may have access to a local cache containing a previously issued
> manifest that is still valid. It is RECOMMENDED that the RP not make
> use of this data, to ensure consistent a consistent outcome in when a
> manifest is missing.
> 
> 6.3. Invalid Manifests
> 
> The presence of an invalid manifest at a publication point could occur
> due to an error by the publisher or due to (malicious or accidental)
> corruption of a valid manifest.An invalid manifest MUST never be used,
> even if the manifestNumber of the invalid manifest is greater than
> that of other (valid) manifests.
> If there is no valid, current manifest available at the publication
> point for the CA instance, an RP MUST treat the signed objects at the
> publication point as indicated above in Section 6.2. A warning MUST be
> issued when an invalid manifest is encountered.
> 
> 6.4. Stale Manifests
> 
> A manifest is considered stale if the current time is after the
> nextUpdate time for the manifest.This could be due to publisher
> failure to promptly publish a new manifest, or due to (malicious or
> accidental) corruption or suppression of a more recent manifest.  All
> signed objects at the publication point issued by the entity that has
> published the stale manifest, and all descendant signed objects that
> are validated using a certificate issued by the entity that has
> published the stale manifest at this publication point, MUST be
> treated at invalid and a warning MUST be issued.
>
> The primary risk in using such signed objects is that a newer manifest
> exists that, if present, would indicate that certain objects have been
> removed or replaced. (For example, the new manifest might show the
> existence of a newer CRL and the removal of one or more revoked
> certificates). Thus, the use of objects from a stale manifest may
> cause an RP to incorrectly treat invalid objects as valid. The risk is
> that the CRL covered by the stale manifest has been superseded, and
> thus an RP will improperly treat a revoked certificate as valid.
> 
> 6.5. Mismatch between Manifest and Publication Point
> 
> If there exist valid signed objects associated with a CA instance and
> they do not appear in any current, valid manifest for this CA
> instance, these objects MUST be ignored by an RP, and a warning MUST
> be issued.

Are we sure about the above? The above approach would preclude us from
using the current valid manifest to determine which .roa files should be
deleted from the local system, right?

> If there are files listed on the manifest that do not appear in the
> repository, then these objects have been improperly deleted from
> repository (via malice or accident). A primary purpose of manifests is
> to detect such deletions. Therefore, in this case, an RP MUST ignore
> all signed objects associated with this CA instance.

A more robust approach might be to *not* ignore locally cached data (iff
the locally cached data matches the filename and hash listed on the
valid manifest, and a valid CRL is present)

> 6.6. Hash Values Not Matching Manifests
> 
> A file appearing on a manifest with an incorrect hash value could
> occur because of publisher error, but it also may indicate that an
> attack has occurred, e.g., one in which an older version of an object
> has been substituted for a newer version of the object. In this case
> an RP cannot know the content of the missing object, and thus all
> signed objects associated with this instance of the CA MUST be ignored
> by the RP, and a warning MUST be issued.

Same comment as in previous section: perhaps a more robust approach
might be to *not* ignore locally cached data (iff the locally cached
data matches the filename and hash listed on the valid manifest, and a
valid CRL is present).

Kind regards,

Job


From nobody Tue May  5 08:49:19 2020
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 2ABBE3A0817 for ; Tue,  5 May 2020 08:49:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level: 
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yaqJTxCg83M for ; Tue,  5 May 2020 08:49:15 -0700 (PDT)
Received: from sonic303-2.consmr.mail.bf2.yahoo.com (sonic303-2.consmr.mail.bf2.yahoo.com [74.6.131.41]) (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 521983A082F for ; Tue,  5 May 2020 08:49:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1588693754; bh=8Lz/kdGl/0BSSVDXE1anjU3irBCZT/1ywwKWfVsnmOc=;  h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=nSCXw+Y9IFHQ14kYkcXKGaq1MEwYBzkJ6qNpW5zcLDtcWT5pbrz87KMRXKT/749LeO4Q/UxtLOBY/kWPSTCyyUEeoil4ActeNJQHGQGnRpDcNrB/mqXXd73HOwGdHaj79w0xJ2+ImCGHX7XmeGyB5RHVSbCtZ1C1Id5/PkRu10ZdRMUuVK6ZexB7KH6q9oA2KrvY93vP1IEAaMaA1neLHf31wotIF76wLP6F+ucqHheE1oO6pRUWtSp/2FEly+ZRokaFDzqIwJwFhaOIASKBjgKoqh9JTSrOdSuLxc0qmZoFQijazZ1DgT0eNMPnRbtRCFZ1+EoZ9UDW3NIQBqH4+A==
X-YMail-OSG: sqy5Wf8VM1nuepXqPGhp5HgaGfN_B9NPU6w46EKP3DEvLMnKZaDqB5F7QwMTyIJ pNLu_uur9P0f3nQrZorB5jhbqDt8w3lXqgEKAp7eIoO9IatuKD.yroBt.0zbMmaKshuRhyksfXR8 fmQqwTuNFn9ohEntk0ropBLBj5S517Jry2r_7sUPpBq5YETgyIxNRVfkcoXuWxuBWmmMNH8SbZ9l DEHlU04zLp6KfHzVVVe5R0Rjc1UQYtezCq5Te0r3jcR6TC3s2HMB.AOkWaC7SyNuTLmMKJU0YSYy LrrITea42arxsJTU5ua0voMWqfrobkcuWyyFpl1FbzjslP3QMc_ra.41iFWyf6rtrVPqbMNEADOd NLGTqw4IWhMnarKurs16jAtCOjjRRCaqNE8iOv4BD3kMBx.rR3gHETnrotRbTMqQeQaKZgE0Zt.1 DvLXkcAEPBhppId1b2Eg81inUSZdBrgvvd8XK_y8FaOpirFa0mDQ.Oz1Sm1zxC4DJKhx3snP2yEp bOSVvfsd_idHn1edvX3565efqNc4RDrjGFjaGASh1qrPWdaZkrMBC0oL9YYZq0YhNHCiPVE7jXX6 qHgEDPtos7a3aYck288PHcsGCq.t_4hvSDH8r7HF5PPF54s1WrCRK.n7.IOW9382S0LIR5OT15Bt IuF0bhjD1.0GcCKfaMypD.IaRCyXJakaM7.lELtD.vOpO3basPbH.LloQh08yUxaoQVS_BsiuS5d cD1jaRn6fGEoolcFStL_yAOFaOZik656M1ZH6JOlF1b4_LHiXO_ZgQ6.iCBIlD4kIev9UphVkh18 1ucOazS_YFncl8vxMDlsYn.VUfL.tUwWkOUnXrvmkODjSqIddOn5Wr8Kz8o_f9V_nmp.0VMEquQp v8_t_G_6HpzG5NYws6HQROBhBRJOkYA352l0Iv6KfHH1AyTTGQlslPe90Ki_N.UHu0vbq9rh.3Dl pqwME5Sibzn.bsN7FlVtIUv5nXvcau7CX12TcWxFp1J0z_vt_igKpbvfk0NIsTFNkufd8FEXyJ_C wb3utMqI8rzzIqG2as76pu.UyDKCA0Mq1V0GhJqTIHSmXYFY7lQVbfXDkSoUD5YDdVbdZnkP1FJw .W8MX2CQWpGvwxCi.R_5kRMNLW776E0x3WbT0f0gD3lA0HlK9Pp1CAszg8Ydjo1_t4tvawXVgQ6f oojiowDo4ZLfUIMkoTXi9C71MeBOy7icBO2yCKjK5Mu9Mi6b5wFBpr_yRpjwehMto3Ue4pbjLmZj oKyIOsIa2UtwqYsMXL1EA7qA_L9zO7WQyYtBjsOvAQM9U3UKhZVOMXVS809d8MuNIamc2qsB3yQT 3jgOnzm16qA0FtdmQPCgnpagMJ4oe3D_pYav_8dFLy228f.l5xruKB2fL4fhqEOhM969By5sM47g VRDgta8B17AORLYZ_Dk9g1A--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Tue, 5 May 2020 15:49:14 +0000
Received: by smtp427.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e332219c6e2483285e558ff6fc0e39c8;  Tue, 05 May 2020 15:49:08 +0000 (UTC)
To: sidrops@ietf.org
References:   <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net>    <20200415124611.7af291b1@glaurung.nlnetlabs.nl> <974eeeaa-32e6-45b2-860f-6b1408ae14e6@www.fastmail.com> <24215.11555.329412.270610@oz.mt.att.com> <20200505113647.GA93200@vurt.meerval.net>
From: Stephen Kent 
Message-ID: <90271ae6-0295-9c8d-514c-ea59ec4c9850@verizon.net>
Date: Tue, 5 May 2020 11:49:08 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200505113647.GA93200@vurt.meerval.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] trying to limit RP processing variability
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 May 2020 15:49:18 -0000

Job,
> ...
> I think I was wrong to agree here. I had discussions with some people
> about 'where does the publication point exist?' - is it a remote entity?
> or is a local construction of pulled data? I'm now leaning more towards
> an interpretation that the publication point only exists in the mind of
> the RP.

4.2 of RFC 6480 says:

    For every certificate in the PKI, there will be a corresponding file
    system directory in the repository that is the authoritative
    publication point for all objects (certificates, CRLs, ROAs, and
    manifests) verifiable via this certificate.

It goes on to note that the publication point is identified by the SIA 
(URI) in a CA cert.

4.8.8 of RFC 6487  reiterates this characterization of a pub point being 
identified by the SIA in a CA cert.

So, I believe that a pub point is a location in the repository system 
where a CA publishes signed objects.

I'm not commenting on the rest of your analysis, just this definition.

Steve


From nobody Tue May  5 12:52:50 2020
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 84DD73A0765 for ; Tue,  5 May 2020 12:52:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level: 
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhhC_u1imM-w for ; Tue,  5 May 2020 12:52:47 -0700 (PDT)
Received: from sonic302-3.consmr.mail.bf2.yahoo.com (sonic302-3.consmr.mail.bf2.yahoo.com [74.6.135.42]) (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 2075D3A074E for ; Tue,  5 May 2020 12:52:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1588708366; bh=enFi3RvHJWiiU8I/KMY8Qow5qEZYsEgVnvy5cgaKEY0=;  h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=EFeo0FTT6RCA3foIZ9DktFmhdP9qMc9qV0BYwPwFAN6cBfUKKA8oAICMn+Vw8wAArEPRCyL3tikqmStJ1bcqzrfrKVEs2ULDWRiglN240xEsNzTgIXlawusL5fEtDrLK3x2gx6XN9N4uKBPUqcXs2EO1IWISUuSBtSKDal3enVbt3bUK84PHvkuTcGMyvvpZX0rTLpuP9OofuxRUulemIL8jRdWL5dl3yt04OTyiuU1zmvDJ4z1MWW+2B4yigQl7UBGF5bs4qVDnQKuG4nnaXxQyOXojjViePP2jPAaPEEIDS3rQaXVlKo1a2sVlpRej79oktcX7bEk9SDUSsBW7EA==
X-YMail-OSG: B7pS..oVM1lXtWuQ.IeQgyo4Hw028zQxllMjSyGI.nPeI5Ipk6pWuwMAMFjrZWt FLx.s0_kor3aJ3HCuKe8gmuT168NZyHVrork7Yxg6MLHp.y2B0Bo.xonupLBws6afkZulXOm4_GN tGtEdICTYrWwGvVEyFDn4bqAuqec1kOZwfCFuENL3dCmtFZdsDX_so9W2uptQKu4yt0GLCP2Ctyf 7yaw2YBlsJJcvk1So7hAZMTpGNAbChXUXLzLn2Xzz76hkflg2bUnoVYCi.PMbYDbcrgv3HkWMoVt 61e6bRW1DEt9wrXR1dWSgkCSTbT.B.oD.S6uwZ3s4K7jzIqDm3q2Ji7nh8XXIncPLNY5Gm.i5lpo lDtYsBhbpR0.weA8W9BTKpqt1gh3IaM.B2e5dUesc4h_enCj4Kv_61fBMGo3dOw4LeZnyKwjQBJ0 s5tMzQvSrzHazKNaS5KI7zBVmA2MIYMQBp.F8h2iJOe6Qo_KwK4bi7OfJS7dy1pu1SbL3KY.braW GZdYtRAbVQn2zeh8I3ezhZrpJzgVRut_qWdLYvrUOtr4KdDtGDEETMsQ.cwoc_ocKMdawlOzRLV0 I6YkLB8xXBCbMPQKnxy4SEOeYXM7.8FYSYlus_jzvqGwnHdodck.RM1r4si7BtxCdqnFXhYLNkTB 9cw7L3kzKwIz2axz1M18777m8TCqkvh6WMvKFbYgTd1L4LR6kwDuKp9Xk9._vQAj.0E7lu7UKIKd uUEUJqXy_T8wpsc3VCGKTifwx6k89oFpOoE79JTPNlRgLUfLTmAePepTo4KEOhrDI1tHbKFiighy 6woP9XIk6G9AWQPRE7FdmvXvfh3bQHfnCVzBEtsfEF.SKzfVkmzBIWgYnoah2JNGN0wLuejZzKDf dlnYntcKxHPb7ABOBNwrbznf9vftvaHgrmkv2IULUCPlEyusv9HlAsuExVy.zlP2OnzRai6aqxMK wFs89pGU7NJSihPhSH3cdE6qNQdV4HVHLG5sePQTcO5px1LS9GDPlnr2sWiXnjzjBYe_Bve9_dM8 UoZJ8tke8ubdKb8X2UTr0ewVCJcJhANsjV7J3F5JrXaUfCrPpw_THdgOs64z5A3QRine4yK6Wm4T qIYOuRvbVwQPIVRz8Vb4UXkZhN8cqhVtou8cbbnURk.XFNzAwvRopaBi96F.SC27GvWj0ZafKm2m ynlpYkyXYQvU_CLw44wtqqDDefIy6i..zkYOpIZxTHp9OKBqQYZ1ylpfHofJNpRp7m.U4b9AvSut w7Mx7X9YWnYhB1X2ZVSFIuJU_1tSb8CRTtN3Wgd0u4z7d6syCDiDrfNsUDq334Y.7DFiLbuzM95F gxRG2SiDkk9Y7_j1Qf95JBOsZX0n7mXNgfEnY0PStMf4wuOR2YxVyBmjmp0DT9.gZw6S8B8Na0JJ EMAoV1yN8hRd.0Yde.3TYktapk1ncA.uHblJInw6Gku9Sa4KEtkQQYw--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Tue, 5 May 2020 19:52:46 +0000
Received: by smtp414.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a6c49a31cf33071dd31fe3be279abe39;  Tue, 05 May 2020 19:52:45 +0000 (UTC)
To: sidrops@ietf.org
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net> 
From: Stephen Kent 
Message-ID: <7355e27e-ee58-f84b-4fed-9674ae542d94@verizon.net>
Date: Tue, 5 May 2020 15:52:44 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] proposed, revised text for Section 6
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 May 2020 19:52:49 -0000

George,
> I just want to note that while I think you made a logically consistent
> choice, I do not agree with its intent, in as much as I believe cached
> state could be used to construct the valid state which the manifest
> and CRL declare.
>
> So, I think you drove to a harder place than I intended. But, I accept
> this is a choice, and a strong choice.
>
> I suspect I am in a minority of one on this. I would not seek to
> impede a group decision driving to a more narrow constrained
> definition.

I believe Job made a good argument supporting your observation, and we 
can revise the text to take advantage of the cached state. I will note, 
in passing, that this can introduce variances in local processing based 
on local cache loss and/or differences in cache refresh timing by 
different RPs. But, if everyone is comfortable accepting the potential 
variance, I'm happy to proceed.

Steve


From nobody Tue May  5 13:09:24 2020
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 D30853A09D3 for ; Tue,  5 May 2020 13:09:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfdS6D-X0BnE for ; Tue,  5 May 2020 13:09:20 -0700 (PDT)
Received: from sonic304-10.consmr.mail.bf2.yahoo.com (sonic304-10.consmr.mail.bf2.yahoo.com [74.6.128.33]) (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 EF10A3A09CC for ; Tue,  5 May 2020 13:09:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1588709358; bh=QfdJQRe1ltwRVx6DFp2ROS2aD8fEJVAzEDPMbAIKi50=;  h=From:Subject:To:References:Date:In-Reply-To:From:Subject; b=ABGvYQy6B5rODx+zjnawFsMxKrAAygM4auG+QvlGmfEjetFdX/so87QR2fCBmIIwF4nvgvPcHnJNlsVwDwLeTRYgYVCfLX8Fa4cNNCuDzjp8ZIk2UOcHn6Y9H/Ev+dknE6ZO4Nf0Tj1/zZzAxpn/kZM3QLbX6e9c+AfTLtGvsy/TI1KMtsRtBEw20zCD/bu7nvXkU4R31gdv9/oOxOpu/K3vOzt1HHB5+/AzDxcW5u1fO60HOjXJ00yAiVD85HLHTgGgkn9YdsyJN2TOLxr7wqSFirI6WRqrtVAkNeI/yEqdj72YTBymdZ6qKh3KfnF7T/MIWt7EX+NBTnK+o+SAqg==
X-YMail-OSG: v3u.HlIVM1kupX340tyU3ZTzy8uPFyDwSMGkGd2gmFiRiHCC2rjbB7locnx0ZMZ yjNMbYAcyIu2XTRYIGuMsRCVoZMiwckv2Q_ArwKsIlnDcuV0b5iEI9kfsfhU0hMmGn5lRsofxUaC ztUNHQeuslgzY2bhhMiEue7znwTOwGWJXo.NosyuKtLzFODo3JBGY4vEMS83sjoE8m_3sf0quuoz NoNFhK6ArIyKicVx2ViclvbBuVajNxkukYRiZriGRXqeGy7I_cHEUqigjd8gaaGw9B4Em81C5j0N KD_.EdDfC2qmgHFUYGXrqNeZ_iHtNHPxE8q8oUwzPe9b0gBxpU99Hq2C24XeQXPXBFxjZM7cMAzw aol9kD8XGyLjAnDAN512KJPkipdB5uG9d4PLU8YNBNkWYsQwehhE3UwxlKNHVPbLaPxIFa2OTIMX 0Tjwj4TUM8yzd5m6MDROvfxl1RKPtaCJAsOzOv4MgVPxi3p.jZujN93HJ71NK707fj21rAqDfS97 Aq.Bo7SnQWep3usWO_my9iVdFJqOkzB_ZQDJzZlXxxmCZt0NSXLH.Vfsvbbxbczgd05ntt9B4OLo ciS.fBPY4wlje8gaFxCqM5qR7XppeO45.a0zDQVq09DiIN.jvBwFxV27mpsGAgd.Jo621dG74XzG efi.z2IqeXbNj7jvwUkEkDv06KnFe_XD8WJ3yQcOTvIPuaqGetCBe5mr7kNNTUDYuhjFWcyNLBvD y5OA2KbZi.fotHaFdAf9agnLIbHXJHI.A6dexQoyozqDl.QkW8p.8Mnr_nJnMnIAB91SdyL85kiu bz5f.1GozFKGb4KUDEB7PGfNmr.MckO94a0SaXp97jrUq7Xq1wpZhXMEGnz8jGbV5Kdih9dD5hxq 2TTQ0EpZwoMk_mOVGW1zABoEQ2s7rKQYctksROHD0XGl04yEQLkttdZ.nQgsRWl2CCOG8zYzGskU MghI9QqpvXMj0xm80Y7nxva3MZaBQkbA_H6.Z2NhXRZUvhO6ARjw47WHr7i4mjTaXFGQ49IQajJE Nrtz6ET6b0PiEJiUVVgfkSsAF5v3E9LQB9MxFfqxvNfPvYuRaK2VCYEoanKrDJuHPlBEWc75_Xjy rLK3U.jl1M1srURFAmpKQUiWCEvRpnFujI7kApnVYCzpl4n3q0w3ZKNO6ZwZ9IaUWId1LiFfI.NY 0CbeACZ0l5Txv8BoY8apOFAmuxG_37vJ4sVfrb.sYw9jkPFlOQgx_mqUJB4DhRGuJRdt45aV_jlk hWX3JzDlY4gWe6b8ahHr390OerVl7CjRV6aEQlS8k7jiNC24eIsxE.qSVcE47TktRmadb5kiuWUZ wl7crxXWBl6hiHNOsPACCfc5fXgy82c0swWeCIg6BLKds97aYr8FzCrvidnYIUXKph0GZG1N9sDp cIYNE3USOIxYRhWhmY9zt4XvUWAIKXWcZ5i2ThfXVVS39knuw_Jwchp8-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Tue, 5 May 2020 20:09:18 +0000
Received: by smtp411.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1eaa3523c370bd50ab92f7dc853cbc25;  Tue, 05 May 2020 20:09:13 +0000 (UTC)
From: Stephen Kent 
To: sidrops@ietf.org
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net> <20200505121353.GB93200@vurt.meerval.net>
Message-ID: <526818da-c518-52d7-f9bf-799f1eb6637e@verizon.net>
Date: Tue, 5 May 2020 16:09:12 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200505121353.GB93200@vurt.meerval.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] proposed, revised text for Section 6
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 May 2020 20:09:23 -0000

Job,
> Small note: neither the archive
> (https://mailarchive.ietf.org/arch/msg/sidrops/Qy7YAVOUYrDVZxUPFPNZfekoJKI/)
> nor my mail client show any text in red. I am assuming the below quoted
> text replaces all of section 6 in RFC 6486. I added section numbers to
> the below quoted text and line-wrapped it. My comments are inline.
whoops. sorry about that. it was red when I sent it :-).
> Stephen, question for you: is the use of the word 'files' and 'objects'
> synonymous in the below text? Or are 'files' something different than
> 'objects'?
every object is represented by a file in the repository, so  the terms 
are equivalent in most cases on this document.
>> 6.1. Determining Manifest State & Object Acceptance
>>
>> For a given publication point, and given CA instance, an RP MUST
>> perform the following tests to determine the manifest state of the
>> publication point. (Note that, during CA key rollover [RFC6489],
>> signed objects for two or more different CA instances will appear at
>> the same publication point. The tests described below are to be
>> performed for a specified CA instance, i.e., a the manifest’s EE
>> certificate was issued by that CA.)
>>
>> 6.1.1. Select the CA's current manifest (the "current" manifest is the
>> manifest issued by this CA having the highest manifestNumber among all
>> valid manifests (as defined in Section 4.4). If the publication point
>> does not contain a valid manifest, proceed as described in Section
>> 6.2. (Lacking a valid manifest, the following tests cannot be
>> performed.)
>>
>> 6.1.2. Check that the current time (translated to UTC) is between
>> thisUpdate and nextUpdate. If the current time does not lie within
>> this interval, proceed as described in Section 6.4.
>>
>> 6.1.3. Acquire all objects at the publication point associated with
>> this CA instance, i.e., the CRL and each object containing an EE
>> certificate issued by the CA. If there are files listed in a manifest
>> that do not appear at the publication point, then proceed as described
>> Section 6.5.
>>
>> 6.1.4. Verify that the listed hash value of every file listed in the
>> manifest matches the value obtained by hashing the file at the
>> publication point. If the computed hash value of a file listed on the
>> manifest does not match the hash value contained in the manifest, then
>> proceed as described in Section 6.6.
>>
>> 6.1.5. If a current manifest contains entries for objects that are not
>> within the scope of the manifest, then the out-of-scope entries MUST
>> be disregarded in the context of this manifest.If there is no other
>> current manifest that describes these objects within that other
>> manifest's scope, then see Section 6.2.
>>
>> Note that there is a “chicken and egg” relationship between the
>> manifest and the CRL for a given CA instance. If the EE certificate
>> for the manifest is revoked, the CA or publication point manager has
>> made an error. In this case all signed objects associated with the CA
>> instance MUST be ignored. Similarly, if the CRL for the CA instance is
>> not listed on a valid, current manifest, all signed objects associated
>> with the CA instance MUST be ignored, because the CRL is missing.
The original text didn't mark each step in the process as a sub-sub 
section, but your marking is a good strategy.
>> 6.2. Missing Manifests
>>
>> The absence of a current manifest at a publication point could occur
>> due to an error by the publisher or due to (malicious or accidental)
>> deletion or corruption of all valid manifests.
>>
>> When no valid manifest is available, there is no protection against
>> attacks that delete signed objects or replay old versions of signed
>> objects. To guard against the adverse impact of processing an
>> incomplete set of signed objects, an RP MUST treat all signed objects
>> associated with the missing manifest as invalid. (These objects are
>> all issued by the same instance of a CA.) RP software MUST issue a
>> warning when there is no current manifest for a CA instance.
>>
>> An RP may have access to a local cache containing a previously issued
>> manifest that is still valid. It is RECOMMENDED that the RP not make
>> use of this data, to ensure consistent a consistent outcome in when a
>> manifest is missing.
>>
>> 6.3. Invalid Manifests
>>
>> The presence of an invalid manifest at a publication point could occur
>> due to an error by the publisher or due to (malicious or accidental)
>> corruption of a valid manifest.An invalid manifest MUST never be used,
>> even if the manifestNumber of the invalid manifest is greater than
>> that of other (valid) manifests.
>> If there is no valid, current manifest available at the publication
>> point for the CA instance, an RP MUST treat the signed objects at the
>> publication point as indicated above in Section 6.2. A warning MUST be
>> issued when an invalid manifest is encountered.
>>
>> 6.4. Stale Manifests
>>
>> A manifest is considered stale if the current time is after the
>> nextUpdate time for the manifest.This could be due to publisher
>> failure to promptly publish a new manifest, or due to (malicious or
>> accidental) corruption or suppression of a more recent manifest.  All
>> signed objects at the publication point issued by the entity that has
>> published the stale manifest, and all descendant signed objects that
>> are validated using a certificate issued by the entity that has
>> published the stale manifest at this publication point, MUST be
>> treated at invalid and a warning MUST be issued.
>>
>> The primary risk in using such signed objects is that a newer manifest
>> exists that, if present, would indicate that certain objects have been
>> removed or replaced. (For example, the new manifest might show the
>> existence of a newer CRL and the removal of one or more revoked
>> certificates). Thus, the use of objects from a stale manifest may
>> cause an RP to incorrectly treat invalid objects as valid. The risk is
>> that the CRL covered by the stale manifest has been superseded, and
>> thus an RP will improperly treat a revoked certificate as valid.
>>
>> 6.5. Mismatch between Manifest and Publication Point
>>
>> If there exist valid signed objects associated with a CA instance and
>> they do not appear in any current, valid manifest for this CA
>> instance, these objects MUST be ignored by an RP, and a warning MUST
>> be issued.
> Are we sure about the above? The above approach would preclude us from
> using the current valid manifest to determine which .roa files should be
> deleted from the local system, right?
I'm not an implementer, but can't one delete cached roa files based on 
them not appearing in the current, valid manifest?
>> If there are files listed on the manifest that do not appear in the
>> repository, then these objects have been improperly deleted from
>> repository (via malice or accident). A primary purpose of manifests is
>> to detect such deletions. Therefore, in this case, an RP MUST ignore
>> all signed objects associated with this CA instance.
> A more robust approach might be to *not* ignore locally cached data (iff
> the locally cached data matches the filename and hash listed on the
> valid manifest, and a valid CRL is present)
Are you saying "IFF ALL of the missing files are present in the local 
cache, are not expired, and there is a valid CRL at the publication 
point, and it matches the file name and hash in the manifest, then we're 
OK to use the cached objects to fill in the missing files from the pub 
point? I think that's a reasonable exception. if others agree, I'll 
modify the text accordingly.
>> 6.6. Hash Values Not Matching Manifests
>>
>> A file appearing on a manifest with an incorrect hash value could
>> occur because of publisher error, but it also may indicate that an
>> attack has occurred, e.g., one in which an older version of an object
>> has been substituted for a newer version of the object. In this case
>> an RP cannot know the content of the missing object, and thus all
>> signed objects associated with this instance of the CA MUST be ignored
>> by the RP, and a warning MUST be issued.
> Same comment as in previous section: perhaps a more robust approach
> might be to *not* ignore locally cached data (iff the locally cached
> data matches the filename and hash listed on the valid manifest, and a
> valid CRL is present).

I think I agree with your analysis here too.

One final note, as I mentioned in my reply to George- the goal of 
consistent RP processing of RPKI data is more dependent on RPs having 
consistent caches on which to rely in the context of 6.5 and 6.6 processing.

Steve


From nobody Tue May  5 13:49:36 2020
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 1632D3A0AB6 for ; Tue,  5 May 2020 13:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxWyYyX0ReWL for ; Tue,  5 May 2020 13:49:28 -0700 (PDT)
Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72CE3A0AAD for ; Tue,  5 May 2020 13:49:28 -0700 (PDT)
Received: by mail-oi1-x235.google.com with SMTP id t199so3112188oif.7 for ; Tue, 05 May 2020 13:49:28 -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=ytNN/1G8+1S+c2NUKrwnQ9cfKPwM02EgyH6X13KkwgI=; b=Aig0QLshoVeZ9CSGLkqXz/8ffeYqfNm42YawCBCrbAN9KRz5GWoUV4FvLdzr5kJ1Rl DPhZNa6IrZWnHYNr2+PaVILgJc8xJbPfmp5tb5yhSHSU1k+NOdxtUHZOT+wNX0rEOjjR lg3GTKl9EWmYU08xGokebXZ7xXMPukdSFmM+bI7gc8d/br3LIx81SrCazlPTgddyPPr0 we8PekohEEVnTre6r7a5qDlJPKmv4tdkzUHqPWxIiZRuMr3jXlL8vUp88pIlB7oGVDnm u8nYdw0O21Bl9WvRUb6sT4kVfJwsAfJhWKZ4q5BpesdOzPV3a9BQXrgSINodwQtFasgr Bjwg==
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=ytNN/1G8+1S+c2NUKrwnQ9cfKPwM02EgyH6X13KkwgI=; b=S5n10tbPIRriMd0zisEuSEKq90epWxYOaPGzB/1b7XAqH6vHrE1GV10f0BIl+jJJcU 61v9aFUlO007cNwuyGUQZYMqLL+3ikZa6f95XlKNXIa4mpXiPem8vJXBEoYs71x5Kw++ HUU10F7IIMmmNllwQZCXWNbwEhPjuyWS808A1ZI8nTgHEoTVVi8Gvcaz6/Z0kRbW2n6K BAg4etVcsGX02Q6EydNRFPeqWKdCDmD2ScasPAlNi0b2ebIrzls7D7fdYO6HZzM8vn8Z 78X8Hg7+GGPtRM+ZzFEsS9I0UVAN8Y3ZYz2PYw/7Seqjdb01TAA1rR5UMYS9IgsJDSB/ ochw==
X-Gm-Message-State: AGi0PuZ8FG+OGZEgmyfsqh9wihRGL5kX9zrnKavTmAnqEQ5iaEE+E7dM by68NF1bt/IrEE7+x6Ay5JBs9xT06dC7ag4BdpM=
X-Google-Smtp-Source: APiQypL6Ix0wTl3A/eFwe0imRsa+rYuvvduGtE0QdESyDWugr92LMNY04ndBeLz6E+yFGHSyOQwY9pfa5cH6vsGP8uY=
X-Received: by 2002:aca:2113:: with SMTP id 19mr367082oiz.128.1588711767800; Tue, 05 May 2020 13:49:27 -0700 (PDT)
MIME-Version: 1.0
References: <87pnbrspdr.wl-morrowc@ops-netman.net> <24232.24434.41224.396200@oz.mt.att.com>  <12F90135-5597-490B-947F-F588C2ED3B48@nlnetlabs.nl>  <0BC5FAFC-A5A3-4B67-82C1-C1BE90335C95@nlnetlabs.nl>  
In-Reply-To: 
From: Alexander Azimov 
Date: Tue, 5 May 2020 23:49:16 +0300
Message-ID: 
To: Tim Bruijnzeels 
Cc: Randy Bush , SIDR Operations WG 
Content-Type: multipart/alternative; boundary="00000000000091fdd505a4ecc821"
Archived-At: 
Subject: Re: [Sidrops] ASPA duplicates
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 May 2020 20:49:35 -0000

--00000000000091fdd505a4ecc821
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Tim,


=D0=B2=D1=82, 5 =D0=BC=D0=B0=D1=8F 2020 =D0=B3. =D0=B2 10:45, Tim Bruijnzee=
ls :

> Hi,
>
> > On 4 May 2020, at 15:39, Randy Bush  wrote:
> >
> >> This might not be easy for existing RPs - with ROAs the thought has
> >> also been that they are cumulative. Now you would need to keep much
> >> more state, and even check between all configured TAs - which until
> >> now could just be processed in parallel.
> >>
> >> I understand your reasoning, but I think this warrants at least some
> >> normative wording in the document and discussion in the security
> >> section. And most importantly I am curious to learn what RP software
> >> implementers think (nowadays I do the CA side, which is much easier in
> >> this context).
> >
> > from draft-ietf-sidrops-8210bis
> >
> > 11.  ROA PDU Race Minimization
> >
> >   When a cache is sending ROA PDUs to the router, especially during an
> >   initial full load, two undesirable race conditions are possible:
> >
> >   Break Before Make:  For some prefix P, an AS may announce two (or
> >      more) ROAs because they are in the process of changing what
> >      provider AS is announcing P.  This is is a case of "make before
> >      break."  If a cache is feeding a router and sends the one not yet
> >      in service a significant time before sending the one currently in
> >      service, then BGP data could be marked invalid during the
> >      interval.  To minimize that interval, the cache SHOULD announce
> >      all ROAs for the same prefix as close to sequentially as possible.
> >
> >   Shorter Prefix First:  If an AS has issued a ROA for P0, and another
> >      AS (likely their customer) has issued a ROA for P1 which is a sub-
> >      prefix of P0, a router which receives the ROA for P0 before that
> >      for P1 is likely to mark a BGP prefix P1 invalid.  Therefore, the
> >      cache SHOULD announce the sub-prefix P1 before the covering prefix
> >      P0.
>
> Thanks for the pointer! It's unfortunate that there are no transactions,
> but I accept (already did) that this is what it is.
>
> However, my point which you quoted was about the suggestion that Alexande=
r
> made that there MUST NOT be multiple ASPA objects for the same customer A=
SN
> in the RPKI, and that if there are they should all be ignored - even if
> they are all valid objects.
>
> At least that was my understanding of his intent. So that there is a
> simple model to deal with ASNs being present on multiple CA certificates =
in
> the RPKI (delegated or different TAs even) and the confusion and race
> conditions that may arise from managing ASPA objects with that ASN as
> customer ASN all together. Ignoring the objects provides a soft landing
> then.
>
> I am not against this per se, but I think *this* needs clarification in
> the ASPA doc, and possibly some more discussion here. I am sure that it's
> possible, but it requires that RPs keep more state than they do today.
>
I do agree. In this thread was raised the proper question which wasn't
covered by the current draft and we may have found the proper answer.
I'll add clarification with the next update.


> Furthermore, I see some advantage here (it's a simple model), but as a
> downside this provides a sort of denial attack where a parent CA can issu=
e
> an ASPA object to essentially invalidate the object issued by the
> operational holder of the ASN. Worse, this can happen between TAs, so onl=
y
> one TA would need to be subverted in order to invalidate ASPA objects und=
er
> any of the other TAs.
>
If we ignore duplicate object it can't be used for DoS. The draft doesn't
suggest any actions against 'unknown' paths.
The question of what happens if one TA issues invalid records for address
space/ASNs that are operated by another TA where such records do not exist,
should be discussed separately if we admit such an attack vector. IMO it is
highly unlikely, but if it happens can already lead to global connectivity
disruption.


> For ROAs the RPs just build a complete list of all VRPs found on all vali=
d
> ROAs anywhere, and only then a set is made and duplicates are excluded wh=
en
> talking to the router. So VRPs appearing elsewhere do not have the power =
to
> force other VRPs to the 'ignore list'. For ROAs the advice is that parent
> CAs have a responsibility NOT to invalidate their children's announcement=
s,
> and for inter RIR transfers make before break is at least theoretically
> possible. A similar model could also apply to ASPA objects.
>
I believe the operation requirements for address space transfer is
different from the ASN transfer from one RIR to another. But even in the
ROA scenario, different ROAs existing in two RIRs simultaneously might
cause problems.


> I know this is a political minefield as much as a technical issue.
> Nonetheless, I think we should make a clear decision which scenario is
> desired under today's operational reality.
>
The ASN transfers do happen, but as far as I know, it doesn't represent
common day-to-day operations. IMO the security reasoning should prevail for
ASPA and might be reconsidered for ROA.

--00000000000091fdd505a4ecc821
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Tim,


=D0=B2=D1=82, 5 =D0=
=BC=D0=B0=D1=8F 2020 =D0=B3. =D0=B2 10:45, Tim Bruijnzeels <tim@nlnetlabs.nl>:
Hi,



> On 4 May 2020, at 15:39, Randy Bush <randy@psg.com> wrote:

> 

>> This might not be easy for existing RPs - with ROAs the thought ha=
s

>> also been that they are cumulative. Now you would need to keep muc=
h

>> more state, and even check between all configured TAs - which unti=
l

>> now could just be processed in parallel.

>> 

>> I understand your reasoning, but I think this warrants at least so=
me

>> normative wording in the document and discussion in the security
>> section. And most importantly I am curious to learn what RP softwa=
re

>> implementers think (nowadays I do the CA side, which is much easie=
r in

>> this context).

> 

> from draft-ietf-sidrops-8210bis

> 

> 11.=C2=A0 ROA PDU Race Minimization

> 

>=C2=A0 =C2=A0When a cache is sending ROA PDUs to the router, especially=
 during an

>=C2=A0 =C2=A0initial full load, two undesirable race conditions are pos=
sible:

> 

>=C2=A0 =C2=A0Break Before Make:=C2=A0 For some prefix P, an AS may anno=
unce two (or

>=C2=A0 =C2=A0 =C2=A0 more) ROAs because they are in the process of chan=
ging what

>=C2=A0 =C2=A0 =C2=A0 provider AS is announcing P.=C2=A0 This is is a ca=
se of "make before

>=C2=A0 =C2=A0 =C2=A0 break."=C2=A0 If a cache is feeding a router =
and sends the one not yet

>=C2=A0 =C2=A0 =C2=A0 in service a significant time before sending the o=
ne currently in

>=C2=A0 =C2=A0 =C2=A0 service, then BGP data could be marked invalid dur=
ing the

>=C2=A0 =C2=A0 =C2=A0 interval.=C2=A0 To minimize that interval, the cac=
he SHOULD announce

>=C2=A0 =C2=A0 =C2=A0 all ROAs for the same prefix as close to sequentia=
lly as possible.

> 

>=C2=A0 =C2=A0Shorter Prefix First:=C2=A0 If an AS has issued a ROA for =
P0, and another

>=C2=A0 =C2=A0 =C2=A0 AS (likely their customer) has issued a ROA for P1=
 which is a sub-

>=C2=A0 =C2=A0 =C2=A0 prefix of P0, a router which receives the ROA for =
P0 before that

>=C2=A0 =C2=A0 =C2=A0 for P1 is likely to mark a BGP prefix P1 invalid.=
=C2=A0 Therefore, the

>=C2=A0 =C2=A0 =C2=A0 cache SHOULD announce the sub-prefix P1 before the=
 covering prefix

>=C2=A0 =C2=A0 =C2=A0 P0.



Thanks for the pointer! It's unfortunate that there are no transactions=
, but I accept (already did) that this is what it is.



However, my point which you quoted was about the suggestion that Alexander =
made that there MUST NOT be multiple ASPA objects for the same customer ASN=
 in the RPKI, and that if there are they should all be ignored - even if th=
ey are all valid objects.



At least that was my understanding of his intent. So that there is a simple=
 model to deal with ASNs being present on multiple CA certificates in the R=
PKI (delegated or different TAs even) and the confusion and race conditions=
 that may arise from managing ASPA objects with that ASN as customer ASN al=
l together. Ignoring the objects provides a soft landing then.



I am not against this per se, but I think *this* needs clarification in the=
 ASPA doc, and possibly some more discussion here. I am sure that it's =
possible, but it requires that RPs keep more state than they do today.
<=
/blockquote>
I do agree. In this thread was raised the proper question =
which wasn't covered by the current draft and we may have found the pro=
per answer.=C2=A0
I'll add clarification with the next update=
.
=C2=A0

Furthermore, I see some advantage here (it's a simple model), but as a =
downside this provides a sort of denial attack where a parent CA can issue =
an ASPA object to essentially invalidate the object issued by the operation=
al holder of the ASN. Worse, this can happen between TAs, so only one TA wo=
uld need to be subverted in order to invalidate ASPA objects under any of t=
he other TAs.
If we ignore duplicate object it can'=
;t be used for DoS. The draft doesn't suggest any actions against '=
unknown' paths.
The question of what happens if one TA issues=
 invalid records for address space/ASNs that are operated by another TA whe=
re such records do not exist, should be discussed separately=C2=A0if we adm=
it such an attack vector. IMO it is highly unlikely, but if it happens can =
already lead to global connectivity disruption.
=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
For ROAs the RPs just build a complete list of all VRPs found on all valid =
ROAs anywhere, and only then a set is made and duplicates are excluded when=
 talking to the router. So VRPs appearing elsewhere do not have the power t=
o force other VRPs to the 'ignore list'. For ROAs the advice is tha=
t parent CAs have a responsibility NOT to invalidate their children's a=
nnouncements, and for inter RIR transfers make before break is at least the=
oretically possible. A similar model could also apply to ASPA objects.
<=
/blockquote>
I believe=C2=A0the operation requirements for address spac=
e transfer is different from the ASN transfer from one RIR to another. But =
even in the ROA scenario, different ROAs existing in two RIRs simultaneousl=
y might cause problems.
=C2=A0

I know this is a political minefield as much as a technical issue. Nonethel=
ess, I think we should make a clear decision which scenario is desired unde=
r today's operational reality.
The ASN transfers d=
o happen, but as far as I know, it doesn't represent common day-to-day =
operations. IMO the security reasoning=C2=A0should prevail for ASPA and mig=
ht be reconsidered for ROA. 


--00000000000091fdd505a4ecc821--


From nobody Tue May  5 13:53:37 2020
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 63BFE3A0AD9 for ; Tue,  5 May 2020 13:53:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cbuGrE2nnRW for ; Tue,  5 May 2020 13:53:26 -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 7CBE83A0B08 for ; Tue,  5 May 2020 13:53:23 -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 1jW4Z7-0001Lp-8S; Tue, 05 May 2020 20:53:21 +0000
Date: Tue, 05 May 2020 13:53:20 -0700
Message-ID: 
From: Randy Bush 
To: Tim Bruijnzeels 
Cc: SIDR Operations WG 
In-Reply-To: 
References: <87pnbrspdr.wl-morrowc@ops-netman.net> <24232.24434.41224.396200@oz.mt.att.com>  <12F90135-5597-490B-947F-F588C2ED3B48@nlnetlabs.nl>  <0BC5FAFC-A5A3-4B67-82C1-C1BE90335C95@nlnetlabs.nl>  
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [Sidrops] ASPA duplicates
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 May 2020 20:53:35 -0000

yes, the CAs could issue multiple ASPAs for an AS

the cache merges them into one ASPA PDU to feed the routers

randy


From nobody Tue May  5 13:57:14 2020
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 E538C3A0AD9; Tue,  5 May 2020 13:57:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1gaqmlUsoZd; Tue,  5 May 2020 13:57:08 -0700 (PDT)
Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D766A3A0C4F; Tue,  5 May 2020 13:56:46 -0700 (PDT)
Received: by mail-oi1-x22e.google.com with SMTP id s202so3308123oih.3; Tue, 05 May 2020 13:56:46 -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=XxnTGPCKHeck5HCGufXhifbE6JXfWHHVwacsVisMyxQ=; b=tLCcrT1z2PFeN0M3JPYG+ZjHHRvth59diU3r3ooxOIpK6Bzvx19wPcc184yBIfBs68 83iZIxd4GAuV4BGE1HcP44l/KkDtsT0s9q7INKHxKqoR6x4FXl1LMG6Zrja1KpWkeVy1 CEL/OIc6T4TQf1JRVsT/LnqgtRoKBvBWr7z0zpc+sR5w2gue5Bq+daTwIJMKHLXnA0rg g18T7uqCAa5NjG2rkPopomfNXzwUm5ygQJqmSQEVPVYplSClk6fb14M1POvHAFKe3Vvm Mqgce8rV4LXh2scpbVvnHXFWxw+qG09Mqy55hiYS54JEdzdZMTY2xXYrMflDQ1n0HANC 5QWQ==
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=XxnTGPCKHeck5HCGufXhifbE6JXfWHHVwacsVisMyxQ=; b=Tc2AHGGq3E17af9B8PT4L6TMCUO5rBfZasgJI0GW31na7w8GiXG8pyo93UVQ4G0/Hu 9AL80d2vHM0SpIRTi3N2wyqRQlrjDYU6gd4oSRjnBo701yFs0aoxQdF2ciUV/gGXOkkY 9Q2Gp9u5b2kRFr68mRaxodwCWXN1Hph/S1OxGnyf7ie7PUn1plTtjBh6UZYWcXyzgKaE biI+QpAvoITjQ8KH5QVuOLYvNKdsD0BAy4v9mZ1KLKhtaBk0NbUYp9oTf/Vm4/NXOuy9 YUVyZCF+4p9JhZfpEFg2MQ6swkIzJY0Hcm09Kv8SMuAUfRTmxs5iujpBdv0uf+vItRMr yTWg==
X-Gm-Message-State: AGi0Puat0MhJKSnnoWnl9e15FfM61RBJNrVTX34eQePFHS6QkZffuJfE Dc1RD43kpcpaHA3x8xyxDKsxlvS0j9mEd6Zj3d5m7N7X
X-Google-Smtp-Source: APiQypLtHrJXY6oMVeJlfqudTXV3nziOB48lxwlLSDznqNXqNutOC4+k0sRY3EIYYnaN70z/eQOePO09H635Ifvje3o=
X-Received: by 2002:aca:4d55:: with SMTP id a82mr414506oib.4.1588712200980; Tue, 05 May 2020 13:56:40 -0700 (PDT)
MIME-Version: 1.0
References: <29748EA5-6016-4E6D-9261-A069F7431390@nlnetlabs.nl> <7CF309AA-0B5F-4FE8-80E8-5E041CA21CF1@ripe.net> 
In-Reply-To: 
From: Alexander Azimov 
Date: Tue, 5 May 2020 23:56:30 +0300
Message-ID: 
To: Melchior Aelmans 
Cc: Oleg Muravskiy , SIDROps Chairs ,  SIDR Operations WG , Tim Bruijnzeels 
Content-Type: multipart/alternative; boundary="00000000000063cc4005a4ece23b"
Archived-At: 
Subject: Re: [Sidrops] Adopt draft-sidrops-bruijnzeels-deprecate-rsync?
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 May 2020 20:57:14 -0000

--00000000000063cc4005a4ece23b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I support adoption while its naming may lead to confusion.
As discussed during the interim, the draft does not suggest depreciation of
rsync.

=D0=BF=D0=BD, 4 =D0=BC=D0=B0=D1=8F 2020 =D0=B3. =D0=B2 23:37, Melchior Aelm=
ans :

> I support adoption.
>
> Cheers,
> Melchior
>
> On Mon, May 4, 2020 at 5:37 PM Oleg Muravskiy  wrote:
>
>> On 29 Apr 2020, at 15:18, Tim Bruijnzeels  wrote:
>> >
>> > Dear co-chairs, WG,
>> >
>> > As mentioned yesterday I would like ask the chairs to do a call for
>> adoption on:
>> >
>> https://datatracker.ietf.org/doc/draft-sidrops-bruijnzeels-deprecate-rsy=
nc/
>> >
>> > I am also more than happy to discuss the content, and adapt following
>> discussion, but maybe this is better done if adopted :)
>>
>> Support
>>
>>
>> Oleg
>> _______________________________________________
>> 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
>


--=20
Best regards,
Alexander Azimov

--00000000000063cc4005a4ece23b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I support adoption while its naming may lead to confusion.=
=C2=A0
As discussed during the=C2=A0interim, the draft does not suggest=
 depreciation of rsync.

=D0=BF=D0=BD, 4 =D0=BC=D0=B0=D1=8F 2020 =D0=
=B3. =D0=B2 23:37, Melchior Aelmans <melchior@aelmans.eu>:
I support adoption.

Ch=
eers,
Melchior

On Mon, May 4, 2020 at 5:37 PM Oleg Muravskiy=
 <oleg@ripe.net&g=
t; wrote:
On 29 =
Apr 2020, at 15:18, Tim Bruijnzeels <tim@nlnetlabs.nl> wrote:

> 

> Dear co-chairs, WG,

> 

> As mentioned yesterday I would like ask the chairs to do a call for ad=
option on:

> https://datatracker.=
ietf.org/doc/draft-sidrops-bruijnzeels-deprecate-rsync/

> 

> I am also more than happy to discuss the content, and adapt following =
discussion, but maybe this is better done if adopted :)



Support





Oleg

_______________________________________________

Sidrops mailing list

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



_______________________________________________

Sidrops mailing list

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




-- 
Best regards,
Alexander Azi=
mov


--00000000000063cc4005a4ece23b--


From nobody Tue May  5 14:58:48 2020
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 3C5BD3A0BCF for ; Tue,  5 May 2020 14:58:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSOiBcoYpRkM for ; Tue,  5 May 2020 14:58:44 -0700 (PDT)
Received: from mail4.dllstx09.us.to.gin.ntt.net (mail4.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::192:26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB3463A0BD1 for ; Tue,  5 May 2020 14:58:44 -0700 (PDT)
Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) by mail4.dllstx09.us.to.gin.ntt.net (Postfix) with ESMTPSA id A6A2FEE0117 for ; Tue,  5 May 2020 21:58:43 +0000 (UTC)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id E18F127C0054 for ; Tue,  5 May 2020 17:58:42 -0400 (EDT)
Received: from imap1 ([10.202.2.51]) by compute3.internal (MEProxy); Tue, 05 May 2020 17:58:42 -0400
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrjeejgdefudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedflfhosgcuufhnihhjuggvrhhsfdcuoehjohgssehnthht rdhnvghtqeenucggtffrrghtthgvrhhnpeegjeehtdeltdfgjeetjeegiedvfeevgfehff duteejheevuefgffeigeethfehgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgr mhepmhgrihhlfhhrohhmpehjohgsodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhith ihqddutdegjeeludehkeegqddvfeeffeekfedvtddqjhhosgeppehnthhtrdhnvghtsehs ohgsohhrnhhoshhtrdhnvght
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6E7A6C200A6; Tue,  5 May 2020 17:58:42 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <7355e27e-ee58-f84b-4fed-9674ae542d94@verizon.net>
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net>  <7355e27e-ee58-f84b-4fed-9674ae542d94@verizon.net>
Date: Tue, 05 May 2020 23:58:21 +0200
From: "Job Snijders" 
To: sidrops@ietf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Sidrops] proposed, revised text for Section 6
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 May 2020 21:58:46 -0000

Dear Group,,

On Tue, May 5, 2020, at 21:52, Stephen Kent wrote:
> > I just want to note that while I think you made a logically consiste=
nt
> > choice, I do not agree with its intent, in as much as I believe cach=
ed
> > state could be used to construct the valid state which the manifest
> > and CRL declare.
> >
> > So, I think you drove to a harder place than I intended. But, I acce=
pt
> > this is a choice, and a strong choice.
> >
> > I suspect I am in a minority of one on this. I would not seek to
> > impede a group decision driving to a more narrow constrained
> > definition.
>=20
> I believe Job made a good argument supporting your observation, and we=
=20
> can revise the text to take advantage of the cached state. I will note=
,=20
> in passing, that this can introduce variances in local processing base=
d=20
> on local cache loss and/or differences in cache refresh timing by=20
> different RPs. But, if everyone is comfortable accepting the potential=
=20
> variance, I'm happy to proceed.

About the next period of time: yes, Stephen, please proceed to write dow=
n your thoughts. I would like to read your messages (through this mailin=
glist). I can't compensate you for your efforts with a monetary currency=
, but I can commit my attention to what you write.

For what it is worth - as member (and dependent) of the community around=
 OpenBSD rpki-client, I observe people are holding the various pieces of=
 the puzzle up against the light in various direction and positions, try=
ing to see how how to align (if possible) the implementation of our RPKI=
 cache software with the spirit of George's observation. Test balloons i=
n the form of POSIX.1 patch(1) files are shared within that community. A=
nd it appears it'll be a multi-week effort to resolve the puzzle in a wa=
y that all people involved would want to run in production on their EBGP=
 routers.

As SIDROPS are not in an easy working space: the timezones differences a=
re really hard, emails might not arrive, reliable distribution of audio =
from interim meetings seems challenging, and we all speak an approximati=
on of a common language. Receiving messages in simple English helps impr=
ove my participation in this process.

Stephen, my request to you: share=C2=A0directly with the working group w=
hat you perceive as the space and "variances", and make strong strong su=
ggestions about the specific single path/vector you perceive as most opt=
imal through the space, and I look forward to comparing notes and observ=
ations.

Kind regards,

Job


From nobody Tue May  5 15:00:01 2020
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 208B43A0C24 for ; Tue,  5 May 2020 14:59:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h60OKUkr4IVi for ; Tue,  5 May 2020 14:59:52 -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 185843A0C07 for ; Tue,  5 May 2020 14:59:52 -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 1jW5bR-0001Uj-T3; Tue, 05 May 2020 21:59:50 +0000
Date: Tue, 05 May 2020 14:59:48 -0700
Message-ID: 
From: Randy Bush 
To: Stephen Kent 
Cc: SIDR Operations WG 
In-Reply-To: <7355e27e-ee58-f84b-4fed-9674ae542d94@verizon.net>
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net>  <7355e27e-ee58-f84b-4fed-9674ae542d94@verizon.net>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [Sidrops] proposed, revised text for Section 6
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 May 2020 22:00:00 -0000

> I will note, in passing, that this can introduce variances in local
> processing based on local cache loss and/or differences in cache
> refresh timing by different RPs. But, if everyone is comfortable
> accepting the potential variance, I'm happy to proceed.

if i insteaad not process current fetch, than we will also have
inconsistent views, yes?

and of course, as fetch times may vary, inconsistency will be normal

the question is how much and what kinds of inconsistency the attacker
can cause

randy


From nobody Tue May  5 18:34:50 2020
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 609DE3A0CBD for ; Tue,  5 May 2020 18:34:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zra-B7MrZD3z for ; Tue,  5 May 2020 18:34:44 -0700 (PDT)
Received: from sonic304-10.consmr.mail.bf2.yahoo.com (sonic304-10.consmr.mail.bf2.yahoo.com [74.6.128.33]) (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 C30973A0CBB for ; Tue,  5 May 2020 18:34:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1588728882; bh=Tz+0Te3TYnH9dxmOqLHln/3wX2HSNgoiNZZrApXrDYI=;  h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject;  b=qqfE1IqFrr4ur8R04RsHTdE1zy0xFZ9t1TGB/SBbcdJyfrwElVqpn8Kkei73WQugK0nquZ5At9AorvuaxqcblOXPrEYVOW91+47bzGi0SGHDRAx88+BKOM9HUfKzoelkiUwbQhd8U1gnG6CyZcasy2LooQ5DIbNfOamgdz5Ts5blpAObY2W7wNtjhEIS9F6AWjIR1g0XlO5vrKWkhzAMPjtUMBh9WPeGoLNDlKTCO9teL0RiY6pmslPVTkFUMeQsCLJJKJXUzMk+kj6N+yLltdoCuLjVzKU9JyZKXpfcZP2Z/wJnxirfy8Tph0flvqfHl3M8uSND/PVZuco5xycmnw==
X-YMail-OSG: ug0exj4VM1ksTiVOWwvP4nbi0RDpL0GLjMH8euSi8Y7YPMCLaZiR2Cg6AqHXdlS mN_E227WiBs0pSw8nJDt04GEZL9er4UOkdIs6j0aHFYHpBvj66uNbRNE0LLmKAHTGC9xyBOCS3bk u5eF9vD3wDB.CnSzbbPWXUD7Q13XOQvUPBnkJl6..UiMa54TRWOilpne45ogDKwhmfdBxmgEHQfi JixmVQFOeDaDn8bVWQiZXe8kfGKrv0BnRmrbKlE4m7mdaMnfSH7p7XUf344Rvh7.YBwRcR_l.Ndq RN1piOUbyNoxZ1ryNAg_wHZdGS7EEhqiOI0OMlRwIlt1DSZzq3Ni.s8LSwkgvnGGLBpvBTDVkbDI b5GjC328G93CVS6OFa.3scM4wy3eiRMKW3jqqoY9IMNQy0xQfwu1.uneGweehe5c4KQv_lZ.D1YR ESvk20MKx68VYr6Z8mfJaF7arwaWalMfhuklmizNl4.W7_f3Q_M2cTddqDTbwfLU1S2i4MOJMqr. fBygr8xmnUDLactzgU6uxOOMCP8.AlX7Odykt16_.A.ylo_bqV_OEXwF5DgeL1n1B8RpWQClKtoa GztNhpe99EIzqqNE68X5dE03NL5ZnccmAxwIS1UjEdB8GNJZIUCEMoh9FUMN.7A_y1tDoAwkxSTD tLNk6qnZxcVOGFlofG3B3oLgiOcZa_wX5uzVVe8aZ_BV_c16Urdp._tUHZqmahhcI0.np7FSjFWL Rn5OzYUuugYVP9nbXfIsEPeFrAxyyDyWdJo6twbJyV5u34DZx91pF3eL3CpSdsSjPbUMilLfcRvn xWHtU2wsJJa5ihoxQGMQxInhflEC_qzsM_37ItTX2vIe7asdgZrF3Kyaz9W96C92hUJ9HhoN0aQe buL5ULY17AQp7jreIP2MQxXP_v4HKVv_ztWFLNJRdlFj4Ad5zaLQqjDNa2eoX9hyfBF.sRri332V 1SKGa2vhgcu7HFBhZodgAewKqE7cT778.iDXc6xrk13oEQHNAD74bmXH52W_9kLsTqNy9Noosdcj JHt.pVcsIVK48FSkqnuNdVRgvY4cZBX9OQla1mteXeiQe.1FP.xL7nQ5x2pMu4yls5SDowdLzHWG GbLUkWUsl5aexjZHgFrsFj8RVs5TvrkBuraDQo.rwbj90EsRulHUgB.JIEtma7GEW6Cr__I8wHlS U6JnnpX9MCTB8hH2LMMQWpIZRFGObOwqnoghW7abUVUqFfsoIAonrjio4lpeXTGasFzS6wLIDx_F IHt62KZzeK.2k4UW7mCCJS9H4PZP14Wfa5AczJnShwFFiWK5kWDIREK0VcOybCNPgA3O4x_Mdka. ClgxkBYLn9Q.t6ineQxrFjEIlvJby1R4GTIs0HW6aWsQ15ML9VCprCB4lY3V3JuGpdbcVgo7REgo IMrykpYSi1hbcKGyr8jcc.2baxk0BzzfqNBU5rXyLA64Y3z8yMUOPqh6M.Rfw431sIQ--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Wed, 6 May 2020 01:34:42 +0000
Received: by smtp407.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 20788d33a5b3b56c93a9fc7e39b2b159;  Wed, 06 May 2020 01:34:40 +0000 (UTC)
To: Randy Bush 
Cc: SIDR Operations WG 
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net>  <7355e27e-ee58-f84b-4fed-9674ae542d94@verizon.net> 
From: Stephen Kent 
Message-ID: <730ce7ed-928b-19e6-cfa3-a5a2eddb03df@verizon.net>
Date: Tue, 5 May 2020 21:34:39 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] proposed, revised text for Section 6
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, 06 May 2020 01:34:47 -0000

Randy,
>> I will note, in passing, that this can introduce variances in local
>> processing based on local cache loss and/or differences in cache
>> refresh timing by different RPs. But, if everyone is comfortable
>> accepting the potential variance, I'm happy to proceed.
> if i insteaad not process current fetch, than we will also have
> inconsistent views, yes?
>
> and of course, as fetch times may vary, inconsistency will be normal
>
> the question is how much and what kinds of inconsistency the attacker
> can cause

These are all valid questions. The WG needs to decide if per-RP 
variance, based on fetch timing, local cache failure, etc. meets the 
goal of uniform RP processing of RPKI data. I am agnostic on this point.

Steve



From nobody Tue May  5 18:35:17 2020
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 145E93A0CBB for ; Tue,  5 May 2020 18:34:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iLNnSbo9urh for ; Tue,  5 May 2020 18:34:44 -0700 (PDT)
Received: from sonic304-10.consmr.mail.bf2.yahoo.com (sonic304-10.consmr.mail.bf2.yahoo.com [74.6.128.33]) (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 7442C3A0CB9 for ; Tue,  5 May 2020 18:34:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1588728882; bh=Tz+0Te3TYnH9dxmOqLHln/3wX2HSNgoiNZZrApXrDYI=;  h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject;  b=qqfE1IqFrr4ur8R04RsHTdE1zy0xFZ9t1TGB/SBbcdJyfrwElVqpn8Kkei73WQugK0nquZ5At9AorvuaxqcblOXPrEYVOW91+47bzGi0SGHDRAx88+BKOM9HUfKzoelkiUwbQhd8U1gnG6CyZcasy2LooQ5DIbNfOamgdz5Ts5blpAObY2W7wNtjhEIS9F6AWjIR1g0XlO5vrKWkhzAMPjtUMBh9WPeGoLNDlKTCO9teL0RiY6pmslPVTkFUMeQsCLJJKJXUzMk+kj6N+yLltdoCuLjVzKU9JyZKXpfcZP2Z/wJnxirfy8Tph0flvqfHl3M8uSND/PVZuco5xycmnw==
X-YMail-OSG: ug0exj4VM1ksTiVOWwvP4nbi0RDpL0GLjMH8euSi8Y7YPMCLaZiR2Cg6AqHXdlS mN_E227WiBs0pSw8nJDt04GEZL9er4UOkdIs6j0aHFYHpBvj66uNbRNE0LLmKAHTGC9xyBOCS3bk u5eF9vD3wDB.CnSzbbPWXUD7Q13XOQvUPBnkJl6..UiMa54TRWOilpne45ogDKwhmfdBxmgEHQfi JixmVQFOeDaDn8bVWQiZXe8kfGKrv0BnRmrbKlE4m7mdaMnfSH7p7XUf344Rvh7.YBwRcR_l.Ndq RN1piOUbyNoxZ1ryNAg_wHZdGS7EEhqiOI0OMlRwIlt1DSZzq3Ni.s8LSwkgvnGGLBpvBTDVkbDI b5GjC328G93CVS6OFa.3scM4wy3eiRMKW3jqqoY9IMNQy0xQfwu1.uneGweehe5c4KQv_lZ.D1YR ESvk20MKx68VYr6Z8mfJaF7arwaWalMfhuklmizNl4.W7_f3Q_M2cTddqDTbwfLU1S2i4MOJMqr. fBygr8xmnUDLactzgU6uxOOMCP8.AlX7Odykt16_.A.ylo_bqV_OEXwF5DgeL1n1B8RpWQClKtoa GztNhpe99EIzqqNE68X5dE03NL5ZnccmAxwIS1UjEdB8GNJZIUCEMoh9FUMN.7A_y1tDoAwkxSTD tLNk6qnZxcVOGFlofG3B3oLgiOcZa_wX5uzVVe8aZ_BV_c16Urdp._tUHZqmahhcI0.np7FSjFWL Rn5OzYUuugYVP9nbXfIsEPeFrAxyyDyWdJo6twbJyV5u34DZx91pF3eL3CpSdsSjPbUMilLfcRvn xWHtU2wsJJa5ihoxQGMQxInhflEC_qzsM_37ItTX2vIe7asdgZrF3Kyaz9W96C92hUJ9HhoN0aQe buL5ULY17AQp7jreIP2MQxXP_v4HKVv_ztWFLNJRdlFj4Ad5zaLQqjDNa2eoX9hyfBF.sRri332V 1SKGa2vhgcu7HFBhZodgAewKqE7cT778.iDXc6xrk13oEQHNAD74bmXH52W_9kLsTqNy9Noosdcj JHt.pVcsIVK48FSkqnuNdVRgvY4cZBX9OQla1mteXeiQe.1FP.xL7nQ5x2pMu4yls5SDowdLzHWG GbLUkWUsl5aexjZHgFrsFj8RVs5TvrkBuraDQo.rwbj90EsRulHUgB.JIEtma7GEW6Cr__I8wHlS U6JnnpX9MCTB8hH2LMMQWpIZRFGObOwqnoghW7abUVUqFfsoIAonrjio4lpeXTGasFzS6wLIDx_F IHt62KZzeK.2k4UW7mCCJS9H4PZP14Wfa5AczJnShwFFiWK5kWDIREK0VcOybCNPgA3O4x_Mdka. ClgxkBYLn9Q.t6ineQxrFjEIlvJby1R4GTIs0HW6aWsQ15ML9VCprCB4lY3V3JuGpdbcVgo7REgo IMrykpYSi1hbcKGyr8jcc.2baxk0BzzfqNBU5rXyLA64Y3z8yMUOPqh6M.Rfw431sIQ--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Wed, 6 May 2020 01:34:42 +0000
Received: by smtp407.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 20788d33a5b3b56c93a9fc7e39b2b159;  Wed, 06 May 2020 01:34:40 +0000 (UTC)
To: Randy Bush 
Cc: SIDR Operations WG 
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net>  <7355e27e-ee58-f84b-4fed-9674ae542d94@verizon.net> 
From: Stephen Kent 
Message-ID: <730ce7ed-928b-19e6-cfa3-a5a2eddb03df@verizon.net>
Date: Tue, 5 May 2020 21:34:39 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] proposed, revised text for Section 6
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, 06 May 2020 01:34:47 -0000

Randy,
>> I will note, in passing, that this can introduce variances in local
>> processing based on local cache loss and/or differences in cache
>> refresh timing by different RPs. But, if everyone is comfortable
>> accepting the potential variance, I'm happy to proceed.
> if i insteaad not process current fetch, than we will also have
> inconsistent views, yes?
>
> and of course, as fetch times may vary, inconsistency will be normal
>
> the question is how much and what kinds of inconsistency the attacker
> can cause

These are all valid questions. The WG needs to decide if per-RP 
variance, based on fetch timing, local cache failure, etc. meets the 
goal of uniform RP processing of RPKI data. I am agnostic on this point.

Steve



From nobody Wed May  6 00:12:16 2020
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 E550F3A079D for ; Wed,  6 May 2020 00:12:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqiPv-CuxzDH for ; Wed,  6 May 2020 00:12:12 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 8768F3A0798 for ; Wed,  6 May 2020 00:12:12 -0700 (PDT)
Received: from lhreml703-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 4319D1050092CE86DBBF; Wed,  6 May 2020 08:12:11 +0100 (IST)
Received: from lhreml703-chm.china.huawei.com (10.201.108.52) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 6 May 2020 08:12:10 +0100
Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Wed, 6 May 2020 08:12:10 +0100
Received: from DGGEML532-MBX.china.huawei.com ([169.254.8.111]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0487.000; Wed, 6 May 2020 15:12:05 +0800
From: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" 
To: Alexander Azimov 
CC: "rv@nic.dtag.de" , SIDR Operations WG 
Thread-Topic: question on draft-ietf-sidrops-aspa-verification-04
Thread-Index: AdYdy08vebzctU/sRBSjzmRHyKjH2ACpL0yAALmBBzA=
Date: Wed, 6 May 2020 07:12:05 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.108.203.151]
Content-Type: multipart/related; boundary="_006_C01B0098369B2D4391851938DA6700B717A0C386DGGEML532MBXchi_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04
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, 06 May 2020 07:12:15 -0000

--_006_C01B0098369B2D4391851938DA6700B717A0C386DGGEML532MBXchi_
Content-Type: multipart/alternative;
 boundary="_000_C01B0098369B2D4391851938DA6700B717A0C386DGGEML532MBXchi_"

--_000_C01B0098369B2D4391851938DA6700B717A0C386DGGEML532MBXchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgQWxleCwNCg0KVGhhbmtzIGZvciB0aGUgZWxhYm9yYXRpb24sIHdoaWNoIHRvdGFsbHkgbWFr
ZXMgc2Vuc2UgdG8gbWUuIEEgc3VnZ2VzdGlvbiBoZXJlLCB0aGUgZGVzY3JpcHRpb24gb2YgaG93
IHRvIGRlYWwgd2l0aCB0aGUgUDJQIHJlbGF0aW9uIHVzaW5nIEFTUEEgKGp1c3QgYXMgd2hhdCB5
b3UgZGVzY3JpYmVkIGJlbG93KSBjYW4gYmUgYWRkZWQgdG8gdGhlIGRyYWZ0IGZvciBjbGFyaWZp
Y2F0aW9uLg0KDQpGdXJ0aGVyLCBTZWN0aW9uIDUuMiBzYXlzOg0KV2hlbiByb3V0ZSBpcyByZWNl
aXZlZCBmcm9tIHByb3ZpZGVyIG9yIFJTIGl0IG1heSBoYXZlIGJvdGggVXBzdHJlYW0NCiAgIGFu
ZCBEb3duc3RyZWFtIHBhdGhzLCB3aGVyZSBhIERvd25zdHJlYW0gZm9sbG93cyBhbiBVcHN0cmVh
bSBwYXRoLg0KDQpUaGUg4oCcZG93bnN0cmVhbeKAnSByZWZlcnMgdG8gYm90aCBQMkMgcGF0aCBh
bmQgUDJQIHBhdGgsIHJpZ2h0PyBJZiBzbywgSSBzdWdnZXN0IHRvIGNoYW5nZSB0aGUgdXNhZ2Ug
b2Yg4oCcZG93bnN0cmVhbeKAnSB0byDigJxub24tdXBzdHJlYW3igJ0gb3Igc2ltaWxhciB3b3Jk
aW5nIHRvIGF2b2lkIGNvbmZ1c2lvbi4NCg0KQW5vdGhlciBwb2ludCB0byBjb25maXJtIHdpdGgg
eW91IGFib3V0IFNlY3Rpb24gNS4yOg0KQWRkaXRpb25hbCBjYXV0aW9uIHNob3VsZCBiZSBleGVy
Y2lzZWQgd2hlbiBwcm9jZXNzaW5nIHByZWZpeGVzIHRoYXQNCiAgIGFyZSByZWNlaXZlZCBmcm9t
IHRyYW5zcGFyZW50IElYZXMsIGFzIHRoZXkgZG9uJ3QgYWRkIHRoZWlyIEFTTiBpbg0KICAgdGhl
IEFTUEFUSC4NCg0KVG8gbXkgdW5kZXJzdGFuZGluZywgdGhhdCBpbiB0aGlzIGRyYWZ0LCB5b3Ug
YXNzdW1lIGJ5IGRlZmF1bHQgdGhhdCBSUyBwcmVwZW5kcyBpdHMgb3duIEFTTiB0byB0aGUgQVNf
UGF0aCwgcmlnaHQ/DQoNCkFuZCBhIGZpbmFsIHF1ZXN0aW9uIGFib3V0IFNlY3Rpb24gNyBTaWJs
aW5ncyAoQ29tcGxleCBSZWxhdGlvbnMpLCByZWdhcmRsZXNzIG9mIHRoZSBjdXJyZW50IGRlc2Ny
aXB0aW9uIG9mIHdoYXQgc2libGluZyByZWxhdGlvbiBpcywgZG8gd2UgdGhpbmsgdGhhdCBzaWJs
aW5nIEFTZXMgYXJlIEFTZXMgdGhhdCBiZWxvbmcgdG8gdGhlIHNhbWUgb3BlcmF0b3I/IFNvIGFu
eSB0eXBlIG9mIHRyYW5zaXRpb24gaXMgZnJlZSBvZiBjaGFyZ2U/DQoNCg0KQlIsDQoNCll1bmFu
DQoNCkZyb206IEFsZXhhbmRlciBBemltb3YgW21haWx0bzphLmUuYXppbW92QGdtYWlsLmNvbV0N
ClNlbnQ6IFN1bmRheSwgTWF5IDMsIDIwMjAgMjo1NCBBTQ0KVG86IEd1eXVuYW4gKFl1bmFuIEd1
LCBJUCBUZWNobm9sb2d5IFJlc2VhcmNoIERlcHQuIE5XKSA8Z3V5dW5hbkBodWF3ZWkuY29tPg0K
Q2M6IHJ2QG5pYy5kdGFnLmRlOyBTSURSIE9wZXJhdGlvbnMgV0cgPHNpZHJvcHNAaWV0Zi5vcmc+
DQpTdWJqZWN0OiBSZTogcXVlc3Rpb24gb24gZHJhZnQtaWV0Zi1zaWRyb3BzLWFzcGEtdmVyaWZp
Y2F0aW9uLTA0DQoNCkhpIFl1bmFuLA0KDQpMZXQgc2F5IHRoYXQgdGhhdCBBUzEgaXMgdGhlIG9y
aWdpbmF0b3Igb2YgdGhlIHByZWZpeCwgYW5kIGhhcyBjcmVhdGVkIEFTUEEgcmVjb3Jkcy4gU2lu
Y2UgQVMyIGlzIGEgcGVlciBpdCB3aWxsIG5vdCBiZSBpbmNsdWRlZCBpbiB0aGUgbGlzdCBvZiBw
cm92aWRlcnMuIFRoZSBBUzIgaXNuJ3QgY3JlYXRpbmcgYW55IHJlY29yZHMgKyBtYWtpbmcgdGhl
IGxlYWsgYW5kIEFTMyBpcyBwZXJmb3JtaW5nIEFTUEEgdmVyaWZpY2F0aW9uIHByb2NlZHVyZS4N
ClRoZSA1LjEgc2F5czoNCg0KDQogICBXaGVuIGEgcm91dGUgaXMgcmVjZWl2ZWQgZnJvbSBhIGN1
c3RvbWVyLCBhIGxpdGVyYWwgcGVlciwgb3IgYnkgYSBSUw0KDQogICBhdCBhbiBJWCwgZWFjaCBw
YWlyIChBUyhJLTEpLCBBUyhJKSkgTVVTVCBiZWxvbmcgdG8gY3VzdG9tZXItcHJvdmlkZXINCg0K
ICAgb3Igc2libGluZyByZWxhdGlvbnNoaXANCg0KDQpJbiBvdXIgY2FzZSwgQVMzIG5lZWRzIHRv
IGNoZWNrIHRoYXQgQVMxIC0+IEFTMiBiZWxvbmdzIHRvIGMycCBwYWlycy4gSXQgd2lsbCBjaGVj
ayB0aGUgZXhpc3RlbmNlIG9mIEFTUEEgcmVjb3JkIGZvciBBUzEgLSBpdCBpcyBwcmVzZW50LCB0
aGVuIGl0IHdpbGwgY2hlY2sgdGhlIHByZXNlbmNlIG9mIEFTMiBpbiB0aGUgbGlzdCAtIGl0IHdp
bGwgbm90IGJlIHRoZXJlLCB0aHVzIG1ha2luZyB0aGUgcGF0aCBpbnZhbGlkLg0KDQpMZXQgbWUg
a25vdyBpZiB5b3UgaGF2ZSBmdXJ0aGVyIHF1ZXN0aW9ucy4NCg0K0YHRgCwgMjkg0LDQv9GALiAy
MDIwINCzLiDQsiAwNToyMSwgR3V5dW5hbiAoWXVuYW4gR3UsIElQIFRlY2hub2xvZ3kgUmVzZWFy
Y2ggRGVwdC4gTlcpIDxndXl1bmFuQGh1YXdlaS5jb208bWFpbHRvOmd1eXVuYW5AaHVhd2VpLmNv
bT4+Og0KSGkgQWxleCBhbmQgUnVlZGlnZXIsDQoNClRvIGNvbnRpbnVlIG91ciBkaXNjdXNzaW9u
IGF0IHRoZSBtZWV0aW5nLCBsZXTigJlzIHVzZSB0aGUgZXhhbXBsZSB5b3UgcHJvdmlkZWQgeWVz
dGVyZGF5LiBCb3RoIGxhdGVyYWwgcGVlcmluZyBiZXR3ZWVuIEFTMeKAlEFTMiwgYW5kIEFTMuKA
lEFTMy4NCg0KRmlyc3QgcXVlc3Rpb24sIGRvZXMgQVMxIG9yIEFTMiBzaWduIGFueSBBU1BBIG9i
amVjdCBmb3IgdGhpcyBwYWlyIGFuZCBob3c/ICBJIHNlZSBkZXNjcmlwdGlvbiBmb3IgU2libGlu
ZyByZWxhdGlvbiByZXByZXNlbnRhdGlvbiBpbiBTZWN0aW9uIDcsIGJ1dCBoYXZlbuKAmXQgYmVl
biBhYmxlIHRvIGZpbmQgYW55IGZvciBQMlAuDQoNClNlY29uZCBxdWVzdGlvbiwgaWYgeWVzIHRv
IHRoZSBhYm92ZSBxdWVzdGlvbiwgaG93IGRvZXMgQVMgMyB1c2UgYW55IG9mIHRoZSBBU1BBIG9i
amVjdChzKSB0byBkZXRlY3QgdGhlIGxlYWs/IEFuZCBpZiBubywgaG93IHRvIGRldGVjdCB0aGUg
bGVhayBhbnl3YXk/DQoNClRoYW5rcy4NCg0KWXVuYW4NCg0KDQoNClsxMC4xLjEuMC8yNF0NCg0K
DQoNCltBUyAxXQ0KDQpbQVMgMixBUyAzXQ0KDQoNCg0KDQoNCi0tDQpCZXN0IHJlZ2FyZHMsDQpB
bGV4YW5kZXIgQXppbW92DQo=

--_000_C01B0098369B2D4391851938DA6700B717A0C386DGGEML532MBXchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls
eToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIg
NDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg
ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm
b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30N
CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv
bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u
TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1
cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJ
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6
ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcHJlDQoJ
e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0
ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z
aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFn
cmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0
eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJ
bWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t
YW4iLHNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6
IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t
c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30N
CnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0
eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0
DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN
CgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN
Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDAN
Cgl7bXNvLWxpc3QtaWQ6MjgxMzc4MTk3Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s
aXN0LXRlbXBsYXRlLWlkczotMTMyNzE5NTM1MiA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2
NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpA
bGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2
ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10
YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZl
bDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s
ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0
O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl
cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxl
dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt
Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGww
OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2
ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRl
eHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJn
aW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86
c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu
ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk
aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+
PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1
ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEFsZXgsPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHRoZSBlbGFi
b3JhdGlvbiwgd2hpY2ggdG90YWxseSBtYWtlcyBzZW5zZSB0byBtZS4gQSBzdWdnZXN0aW9uIGhl
cmUsIHRoZSBkZXNjcmlwdGlvbiBvZiBob3cgdG8gZGVhbCB3aXRoIHRoZSBQMlAgcmVsYXRpb24g
dXNpbmcgQVNQQSAoanVzdCBhcyB3aGF0DQogeW91IGRlc2NyaWJlZCBiZWxvdykgY2FuIGJlIGFk
ZGVkIHRvIHRoZSBkcmFmdCBmb3IgY2xhcmlmaWNhdGlvbi4gPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5GdXJ0aGVyLCBTZWN0aW9uIDUuMiBzYXlzOjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr
Ij5XaGVuIHJvdXRlIGlzIHJlY2VpdmVkIGZyb20gcHJvdmlkZXIgb3IgUlMgaXQgbWF5IGhhdmUg
Ym90aCBVcHN0cmVhbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYW5kIERvd25zdHJlYW0gcGF0aHMs
IHdoZXJlIGEgRG93bnN0cmVhbSBmb2xsb3dzIGFuIFVwc3RyZWFtIHBhdGguPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUg4oCcZG93bnN0cmVhbeKAnSByZWZl
cnMgdG8gYm90aCBQMkMgcGF0aCBhbmQgUDJQIHBhdGgsIHJpZ2h0PyBJZiBzbywgSSBzdWdnZXN0
IHRvIGNoYW5nZSB0aGUgdXNhZ2Ugb2Yg4oCcZG93bnN0cmVhbeKAnSB0byDigJxub24tdXBzdHJl
YW3igJ0gb3Igc2ltaWxhciB3b3JkaW5nIHRvIGF2b2lkDQogY29uZnVzaW9uLiA8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFub3RoZXIgcG9pbnQgdG8gY29uZmly
bSB3aXRoIHlvdSBhYm91dCBTZWN0aW9uIDUuMjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+QWRkaXRpb25hbCBjYXV0aW9u
IHNob3VsZCBiZSBleGVyY2lzZWQgd2hlbiBwcm9jZXNzaW5nIHByZWZpeGVzIHRoYXQ8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj
ayI+Jm5ic3A7Jm5ic3A7IGFyZSByZWNlaXZlZCBmcm9tIHRyYW5zcGFyZW50IElYZXMsIGFzIHRo
ZXkgZG9uJ3QgYWRkIHRoZWlyIEFTTiBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdGhlIEFTUEFU
SC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRvIG15IHVuZGVy
c3RhbmRpbmcsIHRoYXQgaW4gdGhpcyBkcmFmdCwgeW91IGFzc3VtZSBieSBkZWZhdWx0IHRoYXQg
UlMgcHJlcGVuZHMgaXRzIG93biBBU04gdG8gdGhlIEFTX1BhdGgsIHJpZ2h0PyAmbmJzcDs8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFuZCBhIGZpbmFsIHF1ZXN0
aW9uIGFib3V0IFNlY3Rpb24gNyBTaWJsaW5ncyAoQ29tcGxleCBSZWxhdGlvbnMpLCByZWdhcmRs
ZXNzIG9mIHRoZSBjdXJyZW50IGRlc2NyaXB0aW9uIG9mIHdoYXQgc2libGluZyByZWxhdGlvbiBp
cywgZG8gd2UgdGhpbmsgdGhhdCBzaWJsaW5nDQogQVNlcyBhcmUgQVNlcyB0aGF0IGJlbG9uZyB0
byB0aGUgc2FtZSBvcGVyYXRvcj8gU28gYW55IHR5cGUgb2YgdHJhbnNpdGlvbiBpcyBmcmVlIG9m
IGNoYXJnZT8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJSLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RCI+WXVuYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwv
c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQWxleGFuZGVyIEF6aW1vdiBbbWFpbHRvOmEuZS5h
emltb3ZAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgTWF5IDMsIDIwMjAg
Mjo1NCBBTTxicj4NCjxiPlRvOjwvYj4gR3V5dW5hbiAoWXVuYW4gR3UsIElQIFRlY2hub2xvZ3kg
UmVzZWFyY2ggRGVwdC4gTlcpICZsdDtndXl1bmFuQGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+Q2M6
PC9iPiBydkBuaWMuZHRhZy5kZTsgU0lEUiBPcGVyYXRpb25zIFdHICZsdDtzaWRyb3BzQGlldGYu
b3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogcXVlc3Rpb24gb24gZHJhZnQtaWV0Zi1z
aWRyb3BzLWFzcGEtdmVyaWZpY2F0aW9uLTA0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+SGkmbmJzcDtZdW5hbiw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkxldCBzYXkgdGhhdCB0aGF0IEFTMSBpcyB0aGUgb3JpZ2luYXRvciBvZiB0
aGUgcHJlZml4LCBhbmQgaGFzIGNyZWF0ZWQgQVNQQSByZWNvcmRzLiBTaW5jZSBBUzIgaXMgYSBw
ZWVyIGl0IHdpbGwgbm90IGJlIGluY2x1ZGVkIGluIHRoZSBsaXN0IG9mIHByb3ZpZGVycy4gVGhl
IEFTMiBpc24ndCBjcmVhdGluZyBhbnkgcmVjb3JkcyZuYnNwOyYjNDM7IG1ha2luZyB0aGUgbGVh
ayBhbmQgQVMzIGlzIHBlcmZvcm1pbmcgQVNQQSB2ZXJpZmljYXRpb24NCiBwcm9jZWR1cmUuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgNS4x
IHNheXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9ImJyZWFr
LWJlZm9yZTpwYWdlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBXaGVu
IGEgcm91dGUgaXMgcmVjZWl2ZWQgZnJvbSBhIGN1c3RvbWVyLCBhIGxpdGVyYWwgcGVlciwgb3Ig
YnkgYSBSUzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6
YmxhY2siPiZuYnNwOyZuYnNwOyBhdCBhbiBJWCwgZWFjaCBwYWlyIChBUyhJLTEpLCBBUyhJKSkg
TVVTVCBiZWxvbmcgdG8gY3VzdG9tZXItcHJvdmlkZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgb3Igc2libGluZyBy
ZWxhdGlvbnNoaXA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJl
Zm9yZTpwYWdlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gb3VyIGNh
c2UsIEFTMyBuZWVkcyB0byBjaGVjayB0aGF0IEFTMSAtJmd0OyBBUzIgYmVsb25ncyB0byBjMnAg
cGFpcnMuIEl0IHdpbGwgY2hlY2sgdGhlIGV4aXN0ZW5jZSBvZiBBU1BBIHJlY29yZCBmb3IgQVMx
IC0gaXQgaXMgcHJlc2VudCwgdGhlbiBpdCB3aWxsIGNoZWNrIHRoZSBwcmVzZW5jZSBvZiBBUzIg
aW4gdGhlIGxpc3QgLSBpdCB3aWxsIG5vdCBiZSB0aGVyZSwgdGh1cyBtYWtpbmcgdGhlIHBhdGgg
aW52YWxpZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+TGV0IG1lIGtub3cgaWYgeW91IGhhdmUgZnVydGhlciBxdWVzdGlvbnMuPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPtGB0YAsIDI5INCw
0L/RgC4gMjAyMCDQsy4g0LIgMDU6MjEsIEd1eXVuYW4gKFl1bmFuIEd1LCBJUCBUZWNobm9sb2d5
IFJlc2VhcmNoIERlcHQuIE5XKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmd1eXVuYW5AaHVhd2VpLmNv
bSI+Z3V5dW5hbkBodWF3ZWkuY29tPC9hPiZndDs6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu
MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp
Z2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgQWxleCBh
bmQgUnVlZGlnZXIsDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRvIGNvbnRpbnVlIG91
ciBkaXNjdXNzaW9uIGF0IHRoZSBtZWV0aW5nLCBsZXTigJlzIHVzZSB0aGUgZXhhbXBsZSB5b3Ug
cHJvdmlkZWQgeWVzdGVyZGF5LiBCb3RoIGxhdGVyYWwgcGVlcmluZyBiZXR3ZWVuIEFTMeKAlEFT
MiwgYW5kIEFTMuKAlEFTMy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Rmlyc3QgcXVl
c3Rpb24sIGRvZXMgQVMxIG9yIEFTMiBzaWduIGFueSBBU1BBIG9iamVjdCBmb3IgdGhpcyBwYWly
IGFuZCBob3c/Jm5ic3A7IEkgc2VlIGRlc2NyaXB0aW9uIGZvciBTaWJsaW5nIHJlbGF0aW9uIHJl
cHJlc2VudGF0aW9uIGluIFNlY3Rpb24gNywgYnV0IGhhdmVu4oCZdCBiZWVuIGFibGUgdG8gZmlu
ZCBhbnkNCiBmb3IgUDJQLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNlY29uZCBxdWVz
dGlvbiwgaWYgeWVzIHRvIHRoZSBhYm92ZSBxdWVzdGlvbiwgaG93IGRvZXMgQVMgMyB1c2UgYW55
IG9mIHRoZSBBU1BBIG9iamVjdChzKSB0byBkZXRlY3QgdGhlIGxlYWs/IEFuZCBpZiBubywgaG93
IHRvIGRldGVjdCB0aGUgbGVhayBhbnl3YXk/DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PlRoYW5rcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPll1bmFuPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNs
YXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRp
bmc9IjAiIGFsaWduPSJsZWZ0Ij4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjEwLjVwdCI+
DQo8dGQgd2lkdGg9IjY1IiBzdHlsZT0id2lkdGg6NDguNzVwdDtwYWRkaW5nOjBjbSAwY20gMGNt
IDBjbTtoZWlnaHQ6MTAuNXB0Ij48L3RkPg0KPHRkIHdpZHRoPSIxMCIgc3R5bGU9IndpZHRoOjcu
NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDoxMC41cHQiPjwvdGQ+DQo8dGQgd2lk
dGg9Ijk0IiBzdHlsZT0id2lkdGg6NzAuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdo
dDoxMC41cHQiPjwvdGQ+DQo8dGQgd2lkdGg9IjQ0IiBzdHlsZT0id2lkdGg6MzMuMHB0O3BhZGRp
bmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDoxMC41cHQiPjwvdGQ+DQo8dGQgd2lkdGg9IjIiIHN0
eWxlPSJ3aWR0aDoxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTAuNXB0Ij48
L3RkPg0KPHRkIHdpZHRoPSIyMTUiIHN0eWxlPSJ3aWR0aDoxNjEuMjVwdDtwYWRkaW5nOjBjbSAw
Y20gMGNtIDBjbTtoZWlnaHQ6MTAuNXB0Ij48L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0
OjI3Ljc1cHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6Mjcu
NzVwdCI+PC90ZD4NCjx0ZCBjb2xzcGFuPSIyIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6
MGNtIDBjbSAwY20gMGNtO2hlaWdodDoyNy43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21z
by1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3Jh
cGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpl
eGFjdGx5Ij4NCjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMTA0IiBoZWlnaHQ9IjM3IiBpZD0iX3gw
MDAwX2kxMDI1IiBzcmM9ImNpZDppbWFnZTAwMS5wbmdAMDFENjIzOTkuOTFCMzE3NTAiIGFsdD0i
MTAuMS4xLjAvMjQiPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzow
Y20gMGNtIDBjbSAwY207aGVpZ2h0OjI3Ljc1cHQiPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6
MGNtIDBjbSAwY20gMGNtO2hlaWdodDoyNy43NXB0Ij48L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5n
OjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MjcuNzVwdCI+PC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9
ImhlaWdodDo1LjI1cHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWln
aHQ6NS4yNXB0Ij48L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWln
aHQ6NS4yNXB0Ij48L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWln
aHQ6NS4yNXB0Ij48L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWln
aHQ6NS4yNXB0Ij48L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWln
aHQ6NS4yNXB0Ij48L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWln
aHQ6NS4yNXB0Ij48L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjQ4LjBwdCI+DQo8dGQg
c3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDo0OC4wcHQiPjwvdGQ+DQo8dGQg
c3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDo0OC4wcHQiPjwvdGQ+DQo8dGQg
Y29sc3Bhbj0iMiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTto
ZWlnaHQ6NDguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVudDpm
cmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJv
dW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5j
aG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxpbWcgYm9y
ZGVyPSIwIiB3aWR0aD0iMTM4IiBoZWlnaHQ9IjY0IiBpZD0iX3gwMDAwX2kxMDI2IiBzcmM9ImNp
ZDppbWFnZTAwMi5wbmdAMDFENjIzOTkuOTFCMzE3NTAiIGFsdD0iQVMgMSI+PG86cD48L286cD48
L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6NDgu
MHB0Ij48L3RkPg0KPHRkIHJvd3NwYW49IjIiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzow
Y20gMGNtIDBjbSAwY207aGVpZ2h0OjQ4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28t
ZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBo
O21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhh
Y3RseSI+DQo8aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjIxNSIgaGVpZ2h0PSI2OSIgaWQ9Il94MDAw
MF9pMTAyNyIgc3JjPSJjaWQ6aW1hZ2UwMDMucG5nQDAxRDYyMzk5LjkxQjMxNzUwIiBhbHQ9IkFT
IDIsQVMgMyI+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0
OjMuNzVwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDozLjc1
cHQiPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDozLjc1
cHQiPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDozLjc1
cHQiPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDozLjc1
cHQiPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDozLjc1
cHQiPjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+
PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsZXhhbmRlciBBemltb3Y8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_C01B0098369B2D4391851938DA6700B717A0C386DGGEML532MBXchi_--

--_006_C01B0098369B2D4391851938DA6700B717A0C386DGGEML532MBXchi_
Content-Type: image/png; name="image001.png"
Content-Description: image001.png
Content-Disposition: inline; filename="image001.png"; size=513;
 creation-date="Wed, 06 May 2020 07:12:05 GMT";
 modification-date="Wed, 06 May 2020 07:12:05 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAGgAAAAlCAYAAACu2qwTAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO
xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAGBSURBVGje
7ZftjcMgDIYZofPw66bxHMkGbJAtWIZhXEgvKR+GouiqQu99JVdt6tjgBxyiGBpS27b9rOuqFEoB
QBAAARAEQBAAAdD4sqRYG/fNgBwbrVhpw+k0LZMPpw4jezHOVd+e/MFH88nH0tPfm3iLM6xV7zg/
DMgZ7SeimUhnA34U8Lky89+9ca76duYPQM4YHlYU78iT3vKIQ0RzAEqKFg94X2XEtlqMzjhXfbvy
/xbbtndg/P+eM1ywswOSJrC3j6xo7wLUk1+CWECOd1DUDmcHJBbvVUH+EFBP/nM3NFpk/H9ymACg
dwPKDgfFBlTtjvAVLe6Tz6BX+RtjKeAc15RkdchjAyoesOkpyhkSJyYVvdc39Wvlr58oJThcWwAz
7CBxZcWrVLpe6e9ynF5f8kfk7F2nlr/Wao/3m9p8ZgQ0o9qHg3H1TwCV7zYABAEQAEEABAEQAEEA
BEAoBQBBAARAEABBAARAEAABEDQUoPAFNp4ty3LbAYUP2Lh2B6WaqndH7933AAAAAElFTkSuQmCC

--_006_C01B0098369B2D4391851938DA6700B717A0C386DGGEML532MBXchi_
Content-Type: image/png; name="image002.png"
Content-Description: image002.png
Content-Disposition: inline; filename="image002.png"; size=1838;
 creation-date="Wed, 06 May 2020 07:12:05 GMT";
 modification-date="Wed, 06 May 2020 07:12:05 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAIoAAABACAYAAADF9O+2AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO
xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAauSURBVHja
7Z1LTBtnEMc59phjjzn2mGOPfUB4OGAgIU0ITShKKxRFVcCY9bKlNeUR1zxlaghgXkkToYZGcmkp
SoUoitpUFSpVK6uHSImiiKQlosYhFBSQvvq/sO16uzY29ppd71j6R8iPFeH77cw3882Ms5qamrK0
Fud0vlwtuCvL6r1fW7nBxexa38brNT4G5TuurRY0XA/KlcuNh6TXc+uGn+Iz5Y7e8Yu8q9jlcr2U
jt+ZFCnNLvx+Y1teBe/pK7D77ufYRv4udN5aK+2cZyd67rLTV35lZ4YCcelU38/iZ4rds8zSOLH6
Ro1vG+BUcR0OTmg5QotoQFBgOc7wvYPhxdyyCBNBq+tbdrL3p7ihiFcAp6hlejuPu7qaY/OFqoQu
O1kaA4AiAXLUPhqyXr69VT74W8rhiGpx+n9hRR9/uR52UX8RMDoF5SABiQZMts33rLKhx+V0Og/R
AusAlGre/a4eAFEK+x9r6/RGnn1kuaax7TVa5AMCBXdqGdc/U+j8YlVPgKhZGERQ5xo8HbTQaQbF
JrS8ml8/slTaPvdCr4AoVdz61Vqhfeh3uEla8DSAgjsTOQ+Eq0aBRFKZ50eWZx9dudjoKqJF1xCU
Cv7TvuLmqVWjAaLcuxz74MafBItGoFQKnlajQyIJeypLw3Xa5KYalPNC14XCjyZXMgESuWWx8Fef
UFY3RaDARFuEGxkFiTwisnBjS4LTeZggSAIUmGaYaD2Hv0nDEt6UW7jRhxQN7RMUpMCRDsddl6mQ
SCrtvMNKuCtzBMI+QHmb7/VY277ZyHRIJOHwEifdBEMCoNicLa/kc+MrmexylHrLu8AK6kce0mFi
AqCgzgNH+GaBRJ69pVR/nKBcENxnCxs/D5oNEim/kmsfC1IUFAco+XW+JZhhM4IiWhX3LEO5JUER
AxTxsM9xLSOyr8kk4lDLQnuVGKCc43u6rW0zW2YGhSKgOEBB3akZ8iZ751XmGToFCAwVUJCFRYGP
2SGRNrXZtuENcj8qoJzk+m+WtH9nekgkoa0EPUgEhwIU9N1o0VJhVKHFBP1IBIcCFHTtJdKQtW9N
LrPHwWXGq702G2J4PF68t/d18N4Hj+j8J92goPNO+zv1HvMHmQoM0vMh5pV+jgaT7BrR35O8UDaJ
GluCQwEK+nzTYk3CMPgXNyMXefd5bxzX8D5gbGE2wHjlNTSoVUEUSHAo9yhpiHjExYW7EMHYZP5J
OSg7ACR0LQ1BgdAcbzYQTnsDh98bWDgUFRTs8tPhdnZg2PlZ7n5gKRJxJ+kA5Wjd2JrZzn3C/+/K
8sFAsGIo4FQDJquwyb+eDrfjlW9GlQu9a1ni2dASKNqBIvsbPAnrUgQoSFtr7nZUHqruRox+ZK7p
gEDBBt9sSTcFKKIiQMHoCO1AecQWWJSHaoi78/5YexatQREPB2t9GyaBI+bfIgKUN2uHNzUDRbQQ
KlHN7vP+xVCk9dCBRUHyEUlIs21m97QoGHqjVemjuFGNZTkW/9ubxHRJ8k2v/KEBMMe7v0fC7a7p
QfEFRiNAMXvBEhUwKUAJA4JQ+X9RD9LVSFsTJLuHgs1Tm1W8+5Lp8igDgSNqgPwLSrXgOnXsw5vP
CJIdYTAhNYWpgIIwEDUYZmrRiCZ0IKATgcBQAQX/UE0K1aLEBQrqRLVOvOldsKg5tuHnNCQwBihm
6jemOpQkQIHQKYeOObOCglN0GrATByiwKvn24T+MOKMtaWvSPvcCky4JiDhAMeteBWc7GARIIXEC
oEBmS8Bh2jVGoxMMCYKCOwsTqc2QVzHrAWBKQIGqhA7e2uwPZTIkOxMiP3uKvmsCYZ+giFEQ7+ku
aZ3KyP0KIKGZsykCRczY8gP+0k9m1zMNFIxExWhUAiBFoECljoH54x3zhpl9v5fgUuFaafFTDAry
K6WOoR9OdN0xPCxwpXCptPAagALh/AOnqtbmqedGjIbEadXCBEGiNSiS3uG7mhApGKkiDqUDSKjR
gJw0ggIhnLTUD98vcc/q3hXh7AqWkLKuBwCK5IpOOry38PWyehyZASuCmXQ0EvSAQZGEL6xGZlMv
wODoAYDAilAiTUeg6AUYAIJGNpxTESA6BkUJDO7qosu3mZbQoP8GFfMY2wFA6Pt3DASKfMN71tHj
BjToRESVP2pyk6mgQ6SFsVkIczGWAk1aaKvA/H5aSIOCotz4oiUEBdwYUINFhptARRlU1DK9XdQ2
w+TChAXpdUwWwGfQqIbZahTmZigoaoKbQNkhVMV1OCodnU65zvOuaul1mk9vYlBIxtM/WRyVHTC6
Ub8AAAAASUVORK5CYII=

--_006_C01B0098369B2D4391851938DA6700B717A0C386DGGEML532MBXchi_
Content-Type: image/png; name="image003.png"
Content-Description: image003.png
Content-Disposition: inline; filename="image003.png"; size=3071;
 creation-date="Wed, 06 May 2020 07:12:05 GMT";
 modification-date="Wed, 06 May 2020 07:12:05 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAANcAAABFCAYAAADZ03P9AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO
xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAt/SURBVHja
7V1dcBPXFfZjH/uYxzzmMY95TFsI/pfsJBSHP9dDGSbDdAAj765VJ3ItbEU1xmOPANmSfyi0TEM8
o9AAMeMhDNOmaUidFFR3hikkkyGkJkQ2f2YwM9v9VlqzklerlbR3tas9nvlm7NWPpbv3u+ec75x7
bk1vb28Na3CBwAt7/KEtm7lj73u4sfmNnbHln+2PiUAd/4el+u5TKTVquRNLyuObDsbv4jVv8aPT
e4WQNxAI/NSKz0wglAtmb7y/p//VHfxwuN4Xu7mxc+Jx4zvv32/5/SfiG8OfiluOfSluHU8awpaj
/5Rf4w3PiQ09p5d+cSD+pMk3vtDBDfKd/uArdBMJriAXrEp793Bow4HYCixQ88CsuHn0H4aJZBRv
jvxdbA6eewarByvY4R/yhUKhn9ANJVQdueD2bRVGxzZ2xh96Dp1baTv+L9MJldeySVaw+XcfPtrQ
GbsPYpPbSKgKcimkes03uewZmF19a+yaZaTKBQgNYm/yTaSIZARHk2uPEP61HUilR7Lf9PTX0k2u
XiDmRmyvRmcg+JJjyQWLsJmPzDQFPliyE6m0SNbgP53aLoyOUDzmXKSV5nD7m12Rj6AaI57XU5o3
cdPL+ZRmq+dB0StFQ1f8Zkt47qldSZULT//5FU9X7JqdVjSCPuBxbBNGjipKc1Ng5kHr4cuyalxM
PJ+rNP98f+wZyAalmfMHX7YNuTr8g0JD98m7v4xcdQSpctXFem7q+7f94R00ee1roRC/SwRYhcfh
CV1kojSDbFCakUtlrTQbetJOYeSIpy+xbGc30Iib2NTz59Qu/9DbNJntA38g8CLctkrE74rSLLmP
P7IQwQo+AZOx6d0z95xKKjVw4xp/+8f/7e0JNdPErrAYIbnpqNh57eDUA7htlVy4QTJFBIP1hBVl
Tq5qIpaaYHBvqbqjcviVMNRbx03fQ8WO3bwbWM9a3+Q9M5TmvA9gdccq72RXUFdJFE7csSKoJWTH
VS3c8U89fWcfOkFp3spH4uXEY5oXkS9o6D61WI3EUitJjfz01/D5aeJbowDWc5N3Xj/yV8fMEW//
x48bu2I3SlWa110AUxHgFVNc61TgRmMlpcnPFsg1whI4cU5BsYQLW4rSrDkQyA1VO7EUQEEkiZ4d
NgvRhNPnEzy4UpTmdQoOWFrN7qCWUgRLTVUc5gMpnJZDZ1NuVZqz/kD2Gkk2txBrrYpjYHYVEiwR
wjy0+0cOefvOLlWf0nxqEZpEUeSCawTT5zZiKYNWx5/4gdRDc1CNKZxSlOa1X+oOxm47sbTJLKB2
DcWhRI7y4IZFGgRDOV0hFTEda/mDr6DC2K3EUqzXhs74CsVe5eWxILe7QWlG+IQwqiC5dgrDRzz9
F1bdTC5ZOQzMPMD2BiJKicogH5lx0o6J8ufLB0vY16hLLlQHu2G1obwXO7jR+wFnan0Ti/kKfuVq
DGwyczuxFGD/kFmFm24BXGlUMrDYImJ3eN+7+LSNj5zUJBcqk+1WQFlRU9+beLRLCO0h0hgHCnFR
L+jWOYO9YVrqYQ12e7pxxckHLDRYcIg0xuH2sCKf0lyDngSWtEI7syh+l1oUBa3H5pZF/Hw3f0P/
PYw+j7EKRHgOFOTKFeQuV5rRVjA39qpBXwH2H+CGmEiJGsRQri+LEeV3TQJ+K14Vc3/wGvM/K3J9
yPkRcQwqhBRW5FWaa9AtxxKrJZEhMf8kmzyZ65GS3k8Ur86xWYXQx4GIY0zIQG7QTbWoxXg8NVYo
hQJIdevbDCmeiIkzZZKEIbkA9KOnpqKFgcM1cAYAxeraSnMNzJkVLmGaCOnf1a5h5FbGy8sXj+WN
vdi4hXrqDyEbLdzxS62HrzgqXpcXeVauYd/ZJx1CeN9zcvUmHlnhEkbUXzJ3oDKWyJhYkY6/WIoa
nr4PH249/uUXbWP/vgRI145tG08GFGyPJ2u3j197FWiLJl3bi8OaelST4nWZVErszmZhlhvt8KPT
a+RirfTILqHGj6ZLJ68uKrcx30AzXH1ky8WfWmmPfNKqEEi6tk9NLoV0GeLNZ70+dv2W+vG28etH
soiZec8MMW1nHduiX70kf24Dnw2xKfN4i0m8rjfHSkduhU8NXCB2g6Ol8ok65jn9fO1YyhpiAWiF
XPLkjCRfVBOoADEXSifmV0w6CGc+s/x58P93R6/mjT0RmzozXmdDLuSLkTdeIxfTAcoXG2WuJ+aX
s7+kjuWSY7Ni4rISgcY16DFeKauRQ0xeIZb0+4AuMaW/cx4fUL2WN0rMtuiCN1s9TcKz2af1XLYL
M4N4PUNIViEF8sXIG6vzXMxMu/zl9SzU/PNYS9ddPLP+eUWLIGVIqk6AHjFhgbKIJ1nIfMTUIK2C
ebyv+n8yTx6bFa/nzh+GizTyxsq2JddvksyFGzdNIr5aI2UsOakzPgtqq8daaTY3XrdGEEMHYaVd
n3VyqkPg6T+/ulMY6nOrAphxI7PGZFvs+p9yrRZ7cpkZrxv1qEwmFyUCs4GKFTcfN6SyXHcQt+2O
JvNuv2FagGBWvC65hIk56+IutRhGJSw6ao8ryTWe3CehfXf0vwXbHWCVZnUvTIvXtSwgI6uVK4ZR
8aXaJQx+tNIhDPVQ9YUxWFP07RzgHLgm3/hCFrlo20AatAuZ9nGZKYatVTe7pT98tUnwlQRttM3x
fEIXRRw3m0UuYGf3yKD30F8euHVgcGYuDqUm0hQRnwmjY3K3YiKW5hzK2ptT54t/j6DMfeb8CmrC
LhFhigP1u3wOuTqjM3Zf3fcya7DcGHtBJd3km0rROV12roy3P3Ir4teRy9I9OnYZFMkVhktMRCkN
SLgj8e52ciHnl3tAw7rBglqGk9XdkPfCilvfNfENtbAuHbD4LPNdTkC+Ym/NAevwDwqevsRyNQ9I
scfBEPIDuR3keFyrEvZfWEVLeEPkSpv76jm4TAt0oiQJG6ZYLZ2W1rqDtoU/erolNPu42gak+d2Z
H3f5Bw8QMcyD2w5hWFukdQ5jKDxoQjTR+t7co2oZDFhjWGUihLlw0/FBCgoVHhgaOC839tnrg5cd
vyp5+z9+DGtMZGADrOBYyd2SwsH54Xo7KAwNGtS0Vj56GSKHE1VEJPgQYxGxSNwwT8Q4v7JdGB3R
G4uiBg4qIs4OdlLSEDe6rmtqkcQL66T5Rn7662qu9Hlj6MrTVn78b4VSOMX71v7gy8gNOSF4xeqC
lZSqL6wnWAM3dbsa4y/EWV5u/HMjudGSBg9vDHUIhYp2rIrGACBjXshsExgKHNIijFPvLTlBxyJg
rjdx8f8YbXVe1gCiAhjbDuxCMoVUUHAoOWyP/FdD98m71VDtAze3rmvidjFnCJgyiGsk859OYYJb
/cVRC4kkJpHKftjbE2oGwZxc3ItOug3c5DfFhhemDiSq6jHB0Syyuf+CyFI1whduDp57hoYyKDbG
KkmT2cYWrCt+02lJZlhcHEeLFtWl7FBn5m+384cDEBPQ0RfdpVCSX46ChJUPOz3hgqJ3A75wBzfI
u7lTk5MAdwpxOlIiTojDMFdhcXHec6nf2ZJBRfs27HVB5TBaT8HaIDYCYH1g5dTAUSzK46i4xmuw
bwhbqOGCUhW7c4GUCFIjlQgfDFfxSBYW8VW53lBl3ATJ2iA2AmB9YOXUwBlHyuMko1enVI/wAYun
nUiGDmhY+GFhzTj8kG42oWLA4gmSQYyq1AZdxFUIWeAhocWgmWEG3WSCLQQPiFIQwmA9rKjuQOoI
+7DkjcFSyMLCQ6KbS7ANIITBeiA2h3uG2BuqsBl5MlSLoK8g+tujPyVSR9jgyLJPJd1Ugj2tmeSe
IfaGKoxjrpBDVQQvuHGI1QC1lYM1Uq43D8ymBbLguWewiGhgioade/zhdqsav9KNJDgCyKEqghfc
OMRqgKJAA7BGyvUd/HBYFse4Qb5Sh8fTjSMQGOH/gyyQiJxRDxgAAAAASUVORK5CYII=

--_006_C01B0098369B2D4391851938DA6700B717A0C386DGGEML532MBXchi_--


From nobody Wed May  6 05:04:10 2020
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 039F33A09B4 for ; Wed,  6 May 2020 05:04:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfYFCrinAouN for ; Wed,  6 May 2020 05:04:06 -0700 (PDT)
Received: from sonic309-13.consmr.mail.bf2.yahoo.com (sonic309-13.consmr.mail.bf2.yahoo.com [74.6.129.123]) (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 B80F53A09AD for ; Wed,  6 May 2020 05:04:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1588766645; bh=nFUs0NnpAkxN0lyS9s9oX/bNHgJp6TVUL4x6CmcywM8=;  h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=REJTuuh9jRzd1xQBhSJyQ0sHJ08LNpbP+NCMMVUm8JJatnXDOlMunJNxs4Ccz3t2mhDnmCVfnjvOJdW9CCGjGgyAYbDgbgEijxD9mO1Nb/lYU/1VUCA2ptr54d9rSUHDzVQ2GKnGKGh2kMXRRzbxELwA2I8/moU9rkas8OjyW0Byx5lU45sK2iYrHZHf68TkHvDRtmnywaJwtO3a48UQM+quwpVdEwD0CNJa/beZlmDeNvp27bXvXHlnpV6cQSgQBPsrShpfMul27P2xxOIh7iVDpS6fcZTyHurbiyiJp2Y+ZY+SPOQlqSfV5Af+mDFEpItI654kHJ/mM1wzz+bqxQ==
X-YMail-OSG: 5L0G97cVM1laXlZUtGWoJeX1ldePBp20oJPzZm9DLq8W3afRQ.RU0p5XeulUbCX n84YCgDgV32.TJ54ZcLiyP5G1g84uENtZoKOU3u30eLlPPMTgNv67KJAAvgRAL8S9XNiFAbKpH1M _nmUWX_avQQgfqo8QXh9kZRX3kTRAw4PL90Dgs6Nk3jAEq5M8YuAhw6Lq50DN2SaGKMR8Ml0XylU LWsgGeMmbL8iPs9Qh5MseZqEu6B.bDVIHs6dkKomBr0Lk1aaGgMasT_dKGLMzIhMQ4gaHo.RMXyS 34xTya0B0MSzI2Xrd133tXHZ2w9JuiBmkps2qInhOk4TTwP2yNgvUVY6Ob9d8YXvIpn5YmkpqjJa tQo6n3UzEuEXrRdOWzPWQNT084ZEoM6pgzsNHK7IXlfdYFZ1FT6gOO.2AU60GEFndpy_AEdPi5xp .mbe.kNTtMa6SJ7PEd9zyd2GzO3epzTpM3WJxzuRYn2luIgDP8ds5P1.Ub5t59c2bA0FZd0crsZF xdb0r2c_kKEdaeyw5VI6FesIUEuKOePlAXXTtDZ2JuKVqqZyRySIHey7odB1v71KGP.wsKucXAXT x..zVX.rAwDUkl4HH9BgyJW_.hCaiYSJlOmFDEHshvAXvpx7vNB4P2.0M6gQUGe0vRF4rOQMM8K1 R3frew6pMnb6W2e0iMpoKKJ75f7o4IjRUq1..2NTzyDOhJg.NEJSI3eASeW1N9MHmfLkMZSA_t3S TqLiXDuKOhRvSG4cOK7GxJWqpHF8QR3CiH3GCbGZWDzw9xD3sANiLldnNuNrE0OhwLf0SuEF9wN1 yGn5xR21eMywdWVHS4GEo6B7bKC0d_4BYudnS5KqDA2bnyzC_9.xY5YJ_HoFwFh8LVFY6aWfTtHU PmVRY7a88jutlPKA2FNv4D9BC9fCSyufQWRn8dLiGKIEnU8ERjNy2qu8VF9P5.VksggsB4.PwFbo fGbYjw0AGMSBhSHuTnIO9ZjpxNYvaHWBb1cD70AAdzYVmm1lgqlBq_peoxIQHtL9mrm6mcgko7C7 5MIl_n2b40hXHGhp2xC72EP4jRT1Lwm483EiHKgFxmY2l5XKlzoeILF0uivxNF_TbWg2YWPckaaP j3a8zZaDu2F5Jc3JK0njkeBgOUxt_vRp57q9BOVj5OEdJFXyq_SAGwAWEjl.hWo5BjC6MJcQ5H4S N1K.4ay4rXRT8sBaOhRAob4Ip5AcS3YPqjxMefkERyzAt4Ibd8jf1HkT2ig23ngZBPVQ8f7iMm6a 97dLgYog4aj_yBWWzWGzK0ja1pIaSTssftlAFR887zlMfux08AC4oYBIJA.7PMxzKB_YLjALC0wl n.N4VGSsNP2_5GqvBSSOZoVMJ7CTQMx5cHJf_JgYJEozEG4pnB4QrOb2pZSgP0O5tSXYSvN743PK NOgo.THs_Kw5Auk8-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Wed, 6 May 2020 12:04:05 +0000
Received: by smtp435.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a1aac05263e475b7ae21df513f55877c;  Wed, 06 May 2020 12:04:04 +0000 (UTC)
To: sidrops@ietf.org
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net>  <7355e27e-ee58-f84b-4fed-9674ae542d94@verizon.net> 
From: Stephen Kent 
Message-ID: <11f35653-2a5b-c8b8-ef8e-fbfddbdb5b8a@verizon.net>
Date: Wed, 6 May 2020 08:04:03 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.15756 hermes_aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] proposed, revised text for Section 6
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, 06 May 2020 12:04:08 -0000

Job,
> Dear Group,,
>
> On Tue, May 5, 2020, at 21:52, Stephen Kent wrote:
>>> I just want to note that while I think you made a logically consistent
>>> choice, I do not agree with its intent, in as much as I believe cached
>>> state could be used to construct the valid state which the manifest
>>> and CRL declare.
>>>
>>> So, I think you drove to a harder place than I intended. But, I accept
>>> this is a choice, and a strong choice.
>>>
>>> I suspect I am in a minority of one on this. I would not seek to
>>> impede a group decision driving to a more narrow constrained
>>> definition.
>> I believe Job made a good argument supporting your observation, and we
>> can revise the text to take advantage of the cached state. I will note,
>> in passing, that this can introduce variances in local processing based
>> on local cache loss and/or differences in cache refresh timing by
>> different RPs. But, if everyone is comfortable accepting the potential
>> variance, I'm happy to proceed.
> About the next period of time: yes, Stephen, please proceed to write down your thoughts. I would like to read your messages (through this mailinglist). I can't compensate you for your efforts with a monetary currency, but I can commit my attention to what you write.
thanks for your review.
> For what it is worth - as member (and dependent) of the community around OpenBSD rpki-client, I observe people are holding the various pieces of the puzzle up against the light in various direction and positions, trying to see how how to align (if possible) the implementation of our RPKI cache software with the spirit of George's observation. Test balloons in the form of POSIX.1 patch(1) files are shared within that community. And it appears it'll be a multi-week effort to resolve the puzzle in a way that all people involved would want to run in production on their EBGP routers.
>
> As SIDROPS are not in an easy working space: the timezones differences are really hard, emails might not arrive, reliable distribution of audio from interim meetings seems challenging, and we all speak an approximation of a common language. Receiving messages in simple English helps improve my participation in this process.
I'll try to be clear in my writing.
> Stephen, my request to you: share directly with the working group what you perceive as the space and "variances", and make strong strong suggestions about the specific single path/vector you perceive as most optimal through the space, and I look forward to comparing notes and observations.

will do.

Steve


From nobody Wed May  6 05:16:29 2020
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 9CEB43A09EA; Wed,  6 May 2020 05:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ntrv.dk
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 UqqLmTtiRJXo; Wed,  6 May 2020 05:16:25 -0700 (PDT)
Received: from DirectAdminCP.boxne.com (ns3.boxne.com [216.244.91.100]) (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 586B03A09E3; Wed,  6 May 2020 05:16:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ntrv.dk; s=x; h=Content-Type:Cc:To:Subject:Message-ID:Date:From:Reply-To:In-Reply-To: References:MIME-Version:Sender:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ao97ttM3jKLY+zwtYtRXTsmupP1KW+ruf0BWPGNutIk=; b=1hEHx+OZwau1oUgA2iCuTDZ3hb XRRWU9AsatxeAtJslD1KegzSqL7Olqi1w/zElaRwIWr+eqRGnjCOJnoSvAyi0VVBtS43wBBS4mguY M1gK0IKpatNnl5xwIvkJJaA/peL9dj+E/7dyYqCQ99Qhla8uh3WLbOhvLzN+FBC0l9cz+ruZ+3llj OQK/zhUDHLPU5kExUGble2/9OtPyvp/IUU85f+J3GZuTmoHs0UfV1EQ3TPDJNWXUooRqrsvby4DBg o6h5muirFoLrCN06EJxVYyASlAitoGYCqPONIfh7d0dVPOikdd3OC4obXQXtDrELf+akWdFbyxw+Z qx2uWQRQ==;
Received: from mail-vs1-f41.google.com ([209.85.217.41]) by DirectAdminCP.boxne.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93.0.4) (envelope-from ) id 1jWIyN-00F337-Mj; Wed, 06 May 2020 08:16:23 -0400
Received: by mail-vs1-f41.google.com with SMTP id m24so822438vsq.10; Wed, 06 May 2020 05:16:22 -0700 (PDT)
X-Gm-Message-State: AGi0PubDtJu2XsZBjBCu29aKm0fzEGQ2+wWEdXuwGkCBB99JMhXY7pzr 4tiGwtgwH3mpzeLVweNHSrubdzA6Bj8uDyHE9vs=
X-Google-Smtp-Source: APiQypJ+a/ikIjRBNOamDi9Euyk1/dYoLMPhcoNvTDqSbKMz1l4EwJk0dqQ9d45FFe66Z5oXWLnOhemCvKvSfWJZSwo=
X-Received: by 2002:a67:7f0a:: with SMTP id a10mr7282031vsd.147.1588767381945;  Wed, 06 May 2020 05:16:21 -0700 (PDT)
MIME-Version: 1.0
References: <29748EA5-6016-4E6D-9261-A069F7431390@nlnetlabs.nl>
In-Reply-To: <29748EA5-6016-4E6D-9261-A069F7431390@nlnetlabs.nl>
Reply-To: ch@ntrv.dk
From: Chriztoffer Hansen 
Date: Wed, 6 May 2020 14:16:09 +0200
X-Gmail-Original-Message-ID: 
Message-ID: 
To: SIDROps Chairs , SIDR Operations WG 
Cc: Tim Bruijnzeels 
Content-Type: text/plain; charset="UTF-8"
X-Authenticated-Id: ch@ntrv.dk
Archived-At: 
Subject: Re: [Sidrops] Adopt draft-sidrops-bruijnzeels-deprecate-rsync?
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, 06 May 2020 12:16:27 -0000

On Wed, 29 Apr 2020 at 15:18, Tim Bruijnzeels  wrote:
> As mentioned yesterday I would like to ask the chairs to do a call for adoption on:
> https://datatracker.ietf.org/doc/draft-sidrops-bruijnzeels-deprecate-rsync/

In favour :+1:

-- 
Chriztoffer


From nobody Wed May  6 05:36:11 2020
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 36B083A0A05 for ; Wed,  6 May 2020 05:36:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1bvIW3swcxy for ; Wed,  6 May 2020 05:36:05 -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 0F0123A0A24 for ; Wed,  6 May 2020 05:35:22 -0700 (PDT)
Received: from bufobufo.ripe.net ([193.0.23.13]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jWJGj-0003g0-Mr; Wed, 06 May 2020 14:35:21 +0200
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::516]) by bufobufo.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jWJGj-0002pX-Hg; Wed, 06 May 2020 14:35:21 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail=_0D2216A0-0B35-493A-B960-4C0C0D416992"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Oleg Muravskiy 
In-Reply-To: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net>
Date: Wed, 6 May 2020 14:35:20 +0200
Cc: "sidrops@ietf.org" 
Message-Id: <1065C1CC-191A-4CFF-A87C-4F1CB165F303@ripe.net>
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net>
To: Stephen Kent 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-ACL-Warn: Delaying message
X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b741eb87e01f4d6ad15ba135d51b513e5cc
Archived-At: 
Subject: Re: [Sidrops] proposed, revised text for Section 6
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, 06 May 2020 12:36:08 -0000

--Apple-Mail=_0D2216A0-0B35-493A-B960-4C0C0D416992
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Steve,

I have some comments inline:

> On 4 May 2020, at 22:08, Stephen Kent =
 wrote:
>=20
> 6.1. Determining Manifest State & Object Acceptance
>=20
> =20
>    For a given publication point, and given CA instance, an RP MUST =
perform=20
>    the following tests to determine the manifest state of the =
publication
>    point. (Note that, during CA key rollover [RFC6489], signed objects =
for
>    two or more different CA instances will appear at the same =
publication=20
>    point. The tests described below are to be performed for a =
specified CA
>    instance, i.e., a the manifest=E2=80=99s EE certificate was issued =
by that CA.)
> =20
>    1. Select the CA's current manifest (the "current" manifest is the=20=

>        manifest issued by this CA  having the highest manifestNumber =
among=20
>        all valid manifests (as defined in Section 4.4).

Without additional context (the discussion we've had here on the list), =
it would not be clear for the reader where the possible multiple =
candidates for the =E2=80=9Ccurrent=E2=80=9D  manifest come from. The CA =
certificate contains a link (rsync URL) to a manifest, which is only one =
file, so how could there be multiple options to =E2=80=9Cselect=E2=80=9D =
from? I guess you refer to a possible use of a cache, or a difference =
between contents of rsync and RRDP repositories?

> =20
>       If the publication point does not contain a valid manifest, =
proceed
>       as described in Section 6.2. (Lacking a valid manifest, the =
following=20
>       tests cannot be performed.)
> =20
>    2. Check that the current time (translated to UTC) is between
>       thisUpdate and nextUpdate.
> =20
>       If the current time does not lie within this interval, proceed=20=

>       as described in Section 6.4.
> =20
>   3. Acquire all objects at the publication point associated with this=20=

>      CA instance, i.e., the CRL and each object containing an EE=20
>      certificate issued by the CA. If there are files listed in a =
manifest=20
>      that do not  appear at the publication point, then proceed as
>      described  Section 6.5.

Wouldn=E2=80=99t we miss all the subordinate Resource Certificates if we =
only look at objects containing an EE certificate?
I think it would be enough if we say

	Acquire from this publication point all files listed in a =
manifest and verify that they are issued by this CA instance.

Although it would be better to expand the =E2=80=9Cverify=E2=80=9D part.

Also, we should probably mention explicitly what the =E2=80=9Cpublication =
point=E2=80=9D is (see my later remark about possible discrepancy =
between different URLs from the CA cert).

> =20
> =20
>    4. Verify that the listed hash value of every file listed in the
>       manifest matches the value obtained by hashing the file at the
>       publication point.
> =20
>       If the computed hash value of a file listed on the manifest does
>       not match the hash value contained in the manifest, then proceed
>       as described in Section 6.6.
> =20
>    5. If a current manifest contains entries for objects that are not
>       within the scope of the manifest, then the out-of-scope entries
>       MUST be disregarded in the context of this manifest.  If there
>       is no other current manifest that describes these objects within
>       that other manifest's scope, then see Section 6.2.
> =20
> =20
>    Note that there is a =E2=80=9Cchicken and egg=E2=80=9D relationship =
between the=20
>    manifest and the CRL for a given CA instance. If the EE certificate=20=

>    for the manifest is revoked, the CA or publication point manager =
has
>    made an error. In this case all signed objects associated with the =
CA=20
>    instance MUST be ignored. Similarly, if the CRL for the CA instance
>    is not listed on a valid, current manifest, all signed objects=20
>    associated with the CA instance MUST be ignored, because the CRL is
>    missing.
> =20
> =20
> 6.2.  Missing Manifests
> =20
>    The absence of a current manifest at a publication point could =
occur
>    due to an error by the publisher or due to (malicious or =
accidental)
>    deletion or corruption of all valid manifests.=20
> =20
>    When no valid manifest is available, there is no protection against
>    attacks that delete signed objects or replay old versions of signed
>    objects. To guard against the adverse impact of processing an=20
>    incomplete set of signed objects, an RP MUST treat all signed =
objects
>    associated with the missing manifest as invalid. (These objects are=20=

>    all issued by the same instance of a CA.) RP software MUST issue a
>    warning when there is no current manifest for a CA instance.
> =20
>    An RP may have access to a local cache containing a previously=20
>    issued manifest that is still valid. It is RECOMMENDED that the RP
>    not make use of this data, to ensure consistent a consistent =
outcome
>    in when a manifest is missing.=20

The end of last sentence should have some duplicate words removed.

> =20
> 6.3.  Invalid Manifests
> =20
>    The presence of an invalid manifest at a publication point could
>    occur due to an error by the publisher or due to (malicious or
>    accidental) corruption of a valid manifest.  An invalid manifest =
MUST
>    never be used, even if the manifestNumber of the invalid manifest =
is
>    greater than that of other (valid) manifests.
> =20
>    If there is no valid, current manifest available at the publication=20=

>    point for the CA instance, an RP MUST treat the signed objects at =
the
>    publication point as indicated above in Section 6.2. A warning MUST=20=

>    be issued when an invalid manifest is encountered.
> =20
> 6.4.  Stale Manifests
> =20
>    A manifest is considered stale if the current time is after the
>    nextUpdate time for the manifest.  This could be due to publisher
>    failure to promptly publish a new manifest, or due to (malicious or
>    accidental) corruption or suppression of a more recent manifest.
> =20
>    All signed objects at the publication point issued by the entity =
that
>    has published the stale manifest, and all descendant signed objects
>    that are validated using a certificate issued by the entity that =
has
>    published the stale manifest at this publication point, MUST be
>    treated at invalid and a warning MUST be issued.
> =20
>    The primary risk in using such signed objects is that a newer
>    manifest exists that, if present, would indicate that certain =
objects
>    have been removed or replaced.  (For example, the new manifest =
might
>    show the existence of a newer CRL and the removal of one or more
>    revoked certificates).  Thus, the use of objects from a stale
>    manifest may cause an RP to incorrectly treat invalid objects as
>    valid.  The risk is that the CRL covered by the stale manifest has
>    been superseded, and thus an RP will improperly treat a revoked
>    certificate as valid.=20
> =20
> =20
> 6.5.  Mismatch between Manifest and Publication Point
> =20
>    If there exist valid signed objects associated with a CA instance =
and
>    they do not appear in any current, valid manifest for this CA =
instance,

This should probably be the =E2=80=9Cthe current, valid manifest=E2=80=9D,=
 not =E2=80=9Cany=E2=80=9D (as we only consider one manifest as the =
current in 6.1/1)?

>    these objects MUST be ignored by an RP, and a warning MUST be =
issued.
> =20
>    If there are files listed on the manifest that do not appear in
>    the repository, then these objects have been improperly deleted =
from
>    repository (via malice or accident).  A primary purpose of =
manifests is=20
>    to detect such deletions.  Therefore, in this case, an RP MUST =
ignore=20
>    all signed objects associated with this CA instance.
> =20
> 6.6.  Hash Values Not Matching Manifests
> =20
>    A file appearing on a manifest with an incorrect hash value could
>    occur because of publisher error, but it also may indicate that an
>    attack has occurred, e.g., one in which an older version of an =
object
>    has been substituted for a newer version of the object. In this =
case
>    an RP cannot know the content of the missing object, and thus all
>    signed objects associated with this instance of the CA MUST be =
ignored=20
>    by the RP, and a warning MUST be issued.
>=20


I wonder how far we should get with listing all possible inconsistencies =
in this document, but from my developer=E2=80=99s perspective I think  =
we should list as much as possible, if we want RP software to behave in =
the same way.

Going through what we described in RFC8488, one of such inconsistencies =
is when manifest contains more than one CRL entry.

Another is when the manifest is not in the publication point of a CA =
certificate. There are two distinct links from the CA certificate =E2=80=93=
 one to the publication point, and one to the manifest. Technically, the =
manifest link could contain different directory than a publication point =
link. If you discover a manifest by following the manifest link, and =
follow the rules applied above, using the link from the CA cert (and not =
the location of the manifest), you would not catch this discrepancy.
Also note  that similar discrepancy could exist with the CRL location =
(as it also has its own link from the cert), but that one is covered by =
the new text above.

Cheers,
Oleg






--Apple-Mail=_0D2216A0-0B35-493A-B960-4C0C0D416992
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
Steve,

I have some =
comments inline:

On 4 May 2020, at 22:08, =
Stephen Kent <stkent=3D40verizon.net@dmarc.ietf.org> wrote:

6.1. =
Determining Manifest State & =
Object Acceptance
 
   For a given =
publication point, and given CA =
instance, an RP =
MUST perform 
   the following tests =
to determine the manifest state of the publication
   point. (Note that, during CA key rollover [RFC6489], signed objects =
for
   two or more =
different CA instances will appear at the same publication 
   point. The tests =
described below are to be performed for a specified CA
   instance, i.e., a =
the manifest=E2=80=99s EE certificate was issued by that =
CA.)
 
   1. Select the CA's current manifest =
(the "current" manifest is the 
       manifest issued by =
this CA  having the highest manifestNumber among 
       all valid manifests =
(as defined in Section 4.4).

Without additional context (the discussion we've =
had here on the list), it would not be clear for the reader where the =
possible multiple candidates for the =E2=80=9Ccurrent=E2=80=9D =
 manifest come from. The CA certificate contains a link (rsync URL) =
to a manifest, which is only one file, so how could there be multiple =
options to =E2=80=9Cselect=E2=80=9D from? I guess you refer to a =
possible use of a cache, or a difference between contents of rsync and =
RRDP repositories?

 
      If the publication =
point does not contain a valid manifest, proceed
      as described in =
Section 6.2. (Lacking a valid manifest, the following 
      tests cannot be =
performed.)
 
   2. Check that the =
current time (translated to UTC) is between
      thisUpdate and =
nextUpdate.
 
      If the current time =
does not lie within this interval, proceed 
      as described in =
Section 6.4.
 
  3. Acquire all objects at the publication point associated with =
this 
     CA instance, i.e., =
the CRL and each object containing an EE 
     certificate issued =
by the CA. If there are files listed in a manifest 
     that do not  appear at the publication point, then proceed =
as
     described  Section =
6.5.

Wouldn=E2=80=99t we miss all the subordinate =
Resource Certificates if we only look at objects containing an EE =
certificate?
I think it would be enough if we =
say

	Acquire from this publication =
point all files listed in a manifest and verify that they are issued by =
this CA instance.

Although it would =
be better to expand the =E2=80=9Cverify=E2=80=9D part.

Also, we should probably mention explicitly what =
the =E2=80=9Cpublication point=E2=80=9D is (see my later remark about =
possible discrepancy between different URLs from the CA cert).

 
 
   4. Verify that the =
listed hash value of every file listed in the
      manifest matches the =
value obtained by hashing the file at the
      publication =
point.
 
      If the computed hash =
value of a file listed on the manifest does
      not match the hash =
value contained in the manifest, then proceed
      as =
described in =
Section 6.6.
 
   5. If a current =
manifest contains entries for objects that are not
      within the scope of =
the manifest, then the out-of-scope entries
      MUST be disregarded in the =
context of this manifest.  If there
      is no other current =
manifest that describes these objects within
      that other =
manifest's scope, then see Section 6.2.
 
 
   Note that there is a =
=E2=80=9Cchicken and egg=E2=80=9D relationship between the 
   manifest and the CRL =
for a given CA instance. If the EE certificate 
   for the manifest is =
revoked, the CA or publication point manager has
   made an error. In =
this case all signed objects associated with the CA 
   instance MUST be =
ignored. Similarly, if the CRL for the CA instance
   is not listed on a =
valid, current manifest, all signed objects 
   associated with the =
CA instance MUST be ignored, because the CRL is
   missing.
<=
p class=3D"MsoPlainText" style=3D"margin: 0in 0in 0.0001pt; font-size: =
10.5pt; font-family: Courier;"> 
 
6.2.  Missing =
Manifests
 
   The absence of a =
current manifest at a publication point could occur
   due to an error by =
the publisher or due to (malicious or accidental)
   deletion or =
corruption of all valid manifests. 
 
   When no valid =
manifest is available, there is no protection against
   attacks that delete =
signed objects or replay old versions of signed
   objects. To guard against the adverse impact of processing an 
   incomplete set of =
signed objects, an RP MUST treat all signed objects
   associated with the missing manifest as invalid. =
(These objects are 
   all issued by the =
same instance of a CA.) RP software MUST issue a
   warning when there =
is no current manifest for a CA instance.
 
   An RP may have =
access to a local cache containing a previously 
   issued manifest that =
is still valid. It is RECOMMENDED that the RP
   not make use of this =
data, to ensure consistent a consistent outcome
   in when a manifest =
is missing. 

The end of last sentence should have =
some duplicate words removed.

 
6.3.  Invalid =
Manifests
 
   The presence of an =
invalid manifest at a publication point could
   occur due to an =
error by the publisher or due to (malicious or
   accidental) =
corruption of a valid manifest.  An invalid manifest =
MUST
   never be used, even =
if the manifestNumber of the invalid manifest is
   greater than that of =
other (valid) manifests.
 
   If there is no =
valid, current manifest available at the publication 
   point for the CA =
instance, an RP MUST treat the signed objects at the
   publication point as =
indicated above in Section 6.2. A warning MUST 
   be issued when an =
invalid manifest is encountered.
 
6.4.  Stale =
Manifests
 
   A manifest is =
considered stale if the current time is after the
   nextUpdate time for =
the manifest.  This could be due to =
publisher
   failure to promptly =
publish a new manifest, or due to (malicious or
   accidental) =
corruption or suppression of a more recent manifest.
 
   All signed objects =
at the publication point issued by the entity that
   has published the =
stale manifest, and all descendant signed objects
   that are validated =
using a certificate issued by the entity that has
   published the stale =
manifest at this publication point, MUST be
   treated at invalid and a warning MUST be =
issued.
 
   The primary risk in =
using such signed objects is that a newer
   manifest exists =
that, if present, would indicate that certain objects
   have been removed or =
replaced.  (For example, the =
new manifest might
   show the existence =
of a newer CRL and the removal of one or more
   revoked =
certificates).  Thus, the use of =
objects from a stale
   manifest may cause =
an RP to incorrectly treat invalid objects as
   valid.  The risk is that the =
CRL covered by the stale manifest has
   been superseded, and =
thus an RP will improperly treat a revoked
   certificate as =
valid. 
 
 
6.5.  Mismatch between =
Manifest and Publication Point
 
   If there exist valid =
signed objects associated with a CA =
instance and
   they do not appear in any current, valid manifest for =
this CA instance,

This should probably be the =E2=80=9Cthe current, =
valid manifest=E2=80=9D, not =E2=80=9Cany=E2=80=9D (as we only consider =
one manifest as the current in 6.1/1)?

   these objects MUST =
be ignored by an RP, and a warning MUST be issued.
 
   If there are files listed on the manifest that do not =
appear in
   the repository, then =
these objects have been improperly deleted from
   repository (via =
malice or accident).  A primary purpose of =
manifests is 
   to detect such =
deletions.  Therefore, in this =
case, an RP MUST ignore 
   all signed objects =
associated with this CA instance.
 
6.6.  Hash Values Not =
Matching Manifests
 
   A file appearing on =
a manifest with an incorrect hash value could
   occur because of =
publisher error, but it also may indicate that an
   attack has =
occurred, e.g., one in which an older version of =
an object
   has been substituted =
for a newer version of the object. In this case
   an RP cannot know =
the content of the missing object, and thus all
   signed objects =
associated with this instance of the CA MUST be ignored 
   by the RP, and a =
warning MUST be issued.



I wonder how far we should get with listing all =
possible inconsistencies in this document, but from my developer=E2=80=99s=
 perspective I think  we should list as much as possible, if we =
want RP software to behave in the same way.

Going through what we described in RFC8488, one of =
such inconsistencies is when manifest contains more than one CRL =
entry.

Another is when the manifest =
is not in the publication point of a CA certificate. There are two =
distinct links from the CA certificate =E2=80=93 one to the publication =
point, and one to the manifest. Technically, the manifest link could =
contain different directory than a publication point link. If you =
discover a manifest by following the manifest link, and follow =
the rules applied above, using the link from the CA cert (and not the =
location of the manifest), you would not catch this =
discrepancy.
Also note  that similar =
discrepancy could exist with the CRL location (as it also has its own =
link from the cert), but that one is covered by the new text =
above.

Cheers,
Oleg





=

--Apple-Mail=_0D2216A0-0B35-493A-B960-4C0C0D416992--


From nobody Wed May  6 12:46:42 2020
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 A0E093A0AC7 for ; Wed,  6 May 2020 12:46:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAbnFghZQcnO for ; Wed,  6 May 2020 12:46:38 -0700 (PDT)
Received: from hrabosky.cbbtier3.att.net (braeburn.org [12.0.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1191E3A0AC2 for ; Wed,  6 May 2020 12:46:38 -0700 (PDT)
Received: from oz.mt.att.com (zoe.cbbtier3.att.net [12.0.1.45]) by hrabosky.cbbtier3.att.net (Postfix) with ESMTP id 89F0437D50 for ; Wed,  6 May 2020 19:46:37 +0000 (UTC)
Received: by oz.mt.att.com (Postfix, from userid 1000) id 54F9856412FC; Wed,  6 May 2020 15:46:37 -0400 (EDT)
X-Mailer: emacs 25.2.2 (via feedmail 11-beta-1 I); VM 8.2.0b under 25.2.2 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <24243.5147.589924.749920@oz.mt.att.com>
Date: Wed, 6 May 2020 15:46:35 -0400
From: Jay Borkenhagen 
To: SIDR Operations WG 
In-Reply-To: <730ce7ed-928b-19e6-cfa3-a5a2eddb03df@verizon.net>
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net>  <7355e27e-ee58-f84b-4fed-9674ae542d94@verizon.net>  <730ce7ed-928b-19e6-cfa3-a5a2eddb03df@verizon.net>
Reply-To: Jay Borkenhagen 
X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3  D198 7DED 6648 2308 D3C0 
Archived-At: 
Subject: Re: [Sidrops] proposed, revised text for Section 6
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, 06 May 2020 19:46:40 -0000

Stephen Kent writes:
 > These are all valid questions. The WG needs to decide if per-RP 
 > variance, based on fetch timing, local cache failure, etc. meets the 
 > goal of uniform RP processing of RPKI data. I am agnostic on this point.
 > 

Recently I had attempted to gauge if there was WG consensus along
these lines:

   Each validation run of each RP MUST generate the same set of
   Validated ROA Payloads (VRPs) when presented with identical input,
   using unexpired records from the most recent successful retrieval
   to deal only with complete failure to retrieve from a PP.

Now I have come around to agree with Job's perspective that coarse
behavior like 'rsync --delete' is not what RPs should do.

An RP should not assume that objects missing in any PP retrieval are
the fault of the responsible CA.  The objects could be missing due to
fault of the CA, problems reaching the PP, or other potential causes,
and the RP cannot know which one it was.  If the RP's cached objects
can fill in the gaps, that's great.

Thus I now feel the straw proposal I offered above is too restrictive.
I would still want different RP implementations to be 'deterministic'
such that they produce the same VRPs, but only when operating on an
identical local cache (including an empty cache as one important case).


Thanks.

						Jay B.




From nobody Wed May  6 13:09:44 2020
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 C63B73A0AFB for ; Wed,  6 May 2020 13:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.128
X-Spam-Level: *
X-Spam-Status: No, score=1.128 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=3.227, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQ46-mMQofCe for ; Wed,  6 May 2020 13:09:39 -0700 (PDT)
Received: from sonic305-3.consmr.mail.bf2.yahoo.com (sonic305-3.consmr.mail.bf2.yahoo.com [74.6.133.42]) (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 0FA1A3A0AFC for ; Wed,  6 May 2020 13:09:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1588795777; bh=pA0F3bJSR1FmRUoaKRICf8wgYD3hnN4KaQyLmLOd6kU=;  h=From:Subject:To:Cc:References:Date:In-Reply-To:From:Subject;  b=c/HnWqYqBD13EUlLN1pZt0QC2D93spadefMiU1vKiV+A3m6vIfXMxrd4X9SA2VJeC/mAOYIrqm1zIECMs7WD6MBRsUF/UZRhCm+uI9PWGBvdf6eCZEZIGK3CsIQteMvgzXgnVygsrkbb/eSjFGUgCrqb9phaxNDLMjGyQ0yEAhe7yqt5ICKIekqxIlkFALu3Yr2OvTOa7qIy/nuY3V+fO3fPE+yehBPcDEyVQnb6DPrkyI+OCGDUOsABY53h/bhhf9+Ks5n7uo5XzWIn/RSyyG59Z9sf8WcSiMiYs31Y0ZQYjVuH6ifYqxBy2jOqSShfmxUBcHU5iaeuf3lWRN6dvg==
X-YMail-OSG: c9gc5fkVM1kNxvOqsMEEbmtzo2Ku1T_vL3ZicRnej4KRCILhKfueMqP1pwdSbbb J2mrw1x0JgUSpCpoXAFgQx88_sYKq7LWQwD6QvBd0Qtscgsun5.YGZG80mQ3VLTU915x9wPBifev Vte7xZypbsm_FIsPpI3QkOWWBOsCgWm_1tIMyTg3tKEjDLtkBh1EdhSG29hzgpYn7D6OY37nA7eb w3677rPAMPZHGXqVCSEXgUgZXIaVvcOI830vJeklhx5zHgKa0rhXQgDrIuJFyFyrXiiFiA_OLKTB 2RVJNTPVu4IfTxIxF2BVZrEIICG0F2KLKhPJMpLWEG02qLhZJXardZa._SWO10lKSqqb88ebaulI Pov0bWI7y1wJRfbZ0zQAEuAmAZ_yuE4GA7Wj_hPkiOgImhKDrASjERVheDmlBHs08EN35b.KKGT7 7ZBZwLFJNKs1zz5NqvIHAHru7VEwc0UuZZ6j.d0m89ItFTtNy21fDd0XRXv84ufOM4Rg1Tln9EvK WQW9Er8x39S6US2ZHldNaDl95z0OeOOR50bS0OhmopbOQayA8vXDNhkWCOASYuHAP6wk5Agm_OZU 3hwEeE_0ViDuvzKhTIBB4kPcv4cxnvlV_Ki2mn6OCdYTiu.NhreArNX9Uq_QKPtFbAEzPpVKaRwM XcuRvNbgnlQa_0l85n6m7XLderZv5QsElDmDRpg4tioBOUIS6aEos1htyNYhpd7bprvyUjMxRpuu Dzkvss2RW.gicnfsIjKllhvm6.V.QA.CfEWrpUOQyWc1IoEQQjZr_KCa0nIkK3cjLA671JloKW9c oUhK2tbzpgYRu3cRW2Yr0wRfTwlD5j5wItmstfCWlK2VFZfTYfpSKoPxOzz0qgJ_5sZ8reEw8sZ. XFRP8cl_RqeAFw35_L24_MfeEKM_25N7u4tTlH.iZ0CWYsjqQATapRCw6e073y8eVUuiIPz8JrzQ qpMvry60dZSKyaKyCkpJZT7e0gauC4SG1JdWs_zU5YfRn_yrVU0uScC4ZpiEB03Duqhpw3pkdtaI JPx.yEoAs8.QmVQXpQC.60tZ1MlP5B10205OWF9P9pPOjbh1HajrM8JYKgZPzswcIPoTRZsUeEfr gzeEBvj45tuW91NBvzEo3T6jnvp1K_ttBguD98FGp4YcDkZrSgLMbVNsZcedFRJdzM02MPk346S1 ZJWz5jXON9k34L0K.6ATF6YglvZY8aoRpLPJXBukBeMiTGyj0D57WQt30ey6WMlaRD44DbnqH9W4 goGZmg.RvynFG2jY8UYWveCvruoG5x7UfebPRhpBsUD62GtspqJSofwuq2xiiHYrkWmhwfZcQDlQ xk9dYgY7KAt18aEgAR5geyGb6JdteJpPcsy2B0r0PhOzQrhITozdhe6CBLobNbZERs72YUiSvw8n P4vnX.7P.lv6nrOTGEH7YCXLmWk0ygQA.vV_y65K1UHGSvnJfKJ0mEgZ_OGP3j278_2Kc.g--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Wed, 6 May 2020 20:09:37 +0000
Received: by smtp426.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9ff6afda8069908ca9351e9048219e78;  Wed, 06 May 2020 20:09:35 +0000 (UTC)
From: Stephen Kent 
To: Oleg Muravskiy 
Cc: "sidrops@ietf.org" 
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net> <1065C1CC-191A-4CFF-A87C-4F1CB165F303@ripe.net>
Message-ID: <507640b8-30e7-9f95-e6ed-adba12efb090@verizon.net>
Date: Wed, 6 May 2020 16:09:34 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <1065C1CC-191A-4CFF-A87C-4F1CB165F303@ripe.net>
Content-Type: multipart/alternative; boundary="------------E1A38708AB64A22993D6A875"
Content-Language: en-US
X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] proposed, revised text for Section 6
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, 06 May 2020 20:09:43 -0000

This is a multi-part message in MIME format.
--------------E1A38708AB64A22993D6A875
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Oleg,
> Hi Steve,
>
> I have some comments inline:
I'm happy to see that your message shows the red highlighting I used.
>
>> On 4 May 2020, at 22:08, Stephen Kent 
>> > > wrote:
>>
>> 6.1. Determining Manifest State & Object Acceptance
>>
>> For a given publication point, and given CA instance,an RP MUST perform
>> the following tests to determine the manifest state of the publication
>> point.(Note that, during CA key rollover [RFC6489], signed objects for
>> two or more different CA instances will appear at the same publication
>> point. The tests described below are to be performed for a specified CA
>> instance, i.e., a the manifest’s EE certificate was issued by that CA.)
>>
>> 1.Selectthe CA's current manifest (the "current" manifest is the
>> manifest issued by this CAhaving the highest manifestNumber among
>> all valid manifests (as defined in Section 4.4).
>
> Without additional context (the discussion we've had here on the 
> list), it would not be clear for the reader where the possible 
> multiple candidates for the “current”  manifest come from. The CA 
> certificate contains a link (rsync URL) to a manifest, which is only 
> one file, so how could there be multiple options to “select” from? I 
> guess you refer to a possible use of a cache, or a difference between 
> contents of rsync and RRDP repositories?

I will revise the text to say that the processing starts with the 
manifest URL extracted from a CA cert, which should simplify matters. I 
was not trying to refer to a local cache or RRDP in the text above.

>
>> If the publication point does not contain a valid manifest,proceed
>> as described in Section 6.2. (Lacking a valid manifest, the following
>> tests cannot be performed.)
>>
>> 2. Check that the current time (translated to UTC) is between
>> thisUpdate and nextUpdate.
>>
>> If the current time does not lie within this interval,proceed
>> as described in Section 6.4.
>>
>> 3.Acquire all objects at the publication point associated with this
>> CA instance, i.e., the CRL and each object containing an EE
>> certificate issued by the CA. If there are files listed in a manifest
>> that do notappear at the publication point, then proceed as
>> describedSection 6.5.
>
> Wouldn’t we miss all the subordinate Resource Certificates if we only 
> look at objects containing an EE certificate?
> I think it would be enough if we say
>
> Acquire from this publication point all files listed in a manifest and 
> verify that they are issued by this CA instance.
Good point. I will reword the description of this processing step.
>
> Although it would be better to expand the “verify” part.
I will do so.
>
> Also, we should probably mention explicitly what the “publication 
> point” is (see my later remark about possible discrepancy between 
> different URLs from the CA cert).
  I did not mean to refer the the local cache above. I would like to 
describe this process in terms of the repository system model, as 
described in 6480, ignoring use of RRDP vs. rsync.
>
>> 6.2.Missing Manifests
>>
>> The absence of a current manifest at a publication point could occur
>> due to an error by the publisher or due to (malicious or accidental)
>> deletion or corruption of all valid manifests.
>>
>> When no valid manifest is available, there is no protection against
>> attacks that delete signed objects or replay old versions of signed
>> objects.To guard against the adverse impact of processing an
>> incomplete set of signed objects, an RP MUST treat all signed objects
>> associated with the missing manifest as invalid. (These objects are
>> all issued by the same instance of a CA.) RP software MUST issue a
>> warning when there is no current manifest for a CA instance.
>>
>> An RP may have access to a local cache containing a previously
>> issued manifest that is still valid. It is RECOMMENDED that the RP
>> not make use of this data, to ensure consistent a consistent outcome
>> in when a manifest is missing.
>
> The end of last sentence should have some duplicate words removed.
yep.
>
>>
>> 6.4.Stale Manifests
>>
>> A manifest is considered stale if the current time is after the
>> nextUpdate time for the manifest.This could be due to publisher
>> failure to promptly publish a new manifest, or due to (malicious or
>> accidental) corruption or suppression of a more recent manifest.
>>
>> All signed objects at the publication point issued by the entity that
>> has published the stale manifest, and all descendant signed objects
>> that are validated using a certificate issued by the entity that has
>> published the stale manifest at this publication point, MUST be
>> treated at invalid and a warning MUST be issued.
>>
>> The primary risk in using such signed objects is that a newer
>> manifest exists that, if present, would indicate that certain objects
>> have been removed or replaced.(For example, the new manifest might
>> show the existence of a newer CRL and the removal of one or more
>> revoked certificates).Thus, the use of objects from a stale
>> manifest may cause an RP to incorrectly treat invalid objects as
>> valid.The risk is that the CRL covered by the stale manifest has
>> been superseded, and thus an RP will improperly treat a revoked
>> certificate as valid.
>>
>> 6.5.Mismatch between Manifest and Publication Point
>>
>> If there exist valid signed objectsassociated with a CA instanceand
>> they do not appear in any current, valid manifest for this CA instance,
>
> This should probably be the “the current, valid manifest”, not “any” 
> (as we only consider one manifest as the current in 6.1/1)?
agreed. a will change to "the current, valid manifest"
>
>> these objects MUST be ignored by an RP, and a warning MUST be issued.
>>
>> If there are files listed on the manifest that do not appear in
>> the repository, then these objects have been improperly deleted from
>> repository (via malice or accident).A primary purpose of manifests is
>> to detect such deletions.Therefore, in this case, an RP MUST ignore
>> all signed objects associated with this CA instance.
>>
>> 6.6.Hash Values Not Matching Manifests
>>
>> A file appearing on a manifest with an incorrect hash value could
>> occur because of publisher error, but it also may indicate that an
>> attack has occurred,e.g., one in which an older version of an object
>> has been substituted for a newer version of the object. In this case
>> an RP cannot know the content of the missing object, and thus all
>> signed objects associated with this instance of the CA MUST be ignored
>> by the RP, and a warning MUST be issued.
>>
>>
>
>
> I wonder how far we should get with listing all possible 
> inconsistencies in this document, but from my developer’s perspective 
> I think  we should list as much as possible, if we want RP software to 
> behave in the same way.
agreed.  I will try to address the inconsistencies you noted; feel free 
to suggest others.
>
> Going through what we described in RFC8488, one of such 
> inconsistencies is when manifest contains more than one CRL entry.
RFC 8488 talks only about the requirement to omit the optional CRL filed 
in the generic CMS format we adopted. It does not address the issue you 
mention here, i.e., what if the manifest includes more than one CRL. 
But, I agree that there does not appear to be an explicit prohibition of 
having more than one CRL enumerated in a manifest. We should say this 
explicitly. Next question: what do we do if we encounter more than one?
> Another is when the manifest is not in the publication point of a CA 
> certificate. There are two distinct links from the CA certificate – 
> one to the publication point, and one to the manifest.
yes, and 6487 does not say that the manifest must be in the directory 
specified by the pub point URI (id-ad-caRepository) Maybe we should 
revise 6487 to make that a requirement. I can address that here as well.
> Technically, the manifest link could contain different directory than 
> a publication point link. If you discover a manifest by following the 
> manifest link, and follow the rules applied above, using the link from 
> the CA cert (and not the location of the manifest), you would not 
> catch this discrepancy.
> Also note  that similar discrepancy could exist with the CRL location 
> (as it also has its own link from the cert), but that one is covered 
> by the new text above.

yes, 6487 does not require the CRLDP to point to a file in the pub point 
specified by the id-ad-caRepository URL in the CA cert. Again, how about 
a revision to 6487 to clarify this? It would make life simpler.

Steve


--------------E1A38708AB64A22993D6A875
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Oleg,

    

    

      
      Hi Steve,
      


      

      
I have some comments inline:

      

    

    I'm happy to see that your message shows the red highlighting I
    used.

    

      

        


          

            
On 4 May 2020, at 22:08, Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
              wrote:

            

            

              
6.1. Determining Manifest State & Object Acceptance

              
 

              
   For a
                given publication point, and given CA instance, an RP MUST
                perform 

              
   the
                following tests to determine the manifest state of the
                publication

              
   point. (Note that, during CA key
                  rollover [RFC6489], signed objects for

              
   two
                  or more different CA instances will appear at the same
                  publication 

              
   point.
                  The tests described below are to be performed for a
                  specified CA

              
   instance,
                  i.e., a the manifest’s EE certificate was issued by
                  that CA.)

              
 

              
   1. Select the CA's current
                manifest (the "current" manifest is the 

              
       manifest
                issued by this CA  having the highest manifestNumber
                among 

              
       all
                valid manifests (as defined in Section 4.4).

            

          

          


          

          
Without additional context (the discussion we've had here
            on the list), it would not be clear for the reader where the
            possible multiple candidates for the “current”  manifest
            come from. The CA certificate contains a link (rsync URL) to
            a manifest, which is only one file, so how could there be
            multiple options to “select” from? I guess you refer to a
            possible use of a cache, or a difference between contents of
            rsync and RRDP repositories?

        

      

    

    
I will revise the text to say that the processing starts with the
      manifest URL extracted from a CA cert, which should simplify
      matters. I was not trying to refer to a local cache or RRDP in the
      text above.

    

    

      


        

          

            

              
 

              
      If the
                publication point does not contain a valid manifest, proceed

              
      as
                  described in Section 6.2. (Lacking a valid
                manifest, the following 

              
      tests
                cannot be performed.)

              
 

              
   2.
                Check that the current time (translated to UTC) is
                between

              
      thisUpdate
                and nextUpdate.

              
 

              
      If the
                current time does not lie within this interval, proceed 

              
      as
                  described in Section 6.4.

            

          

          

            

              
 

              
  3. Acquire all objects at
                  the publication point associated with this 

              
     CA
                  instance, i.e., the CRL and each object containing an
                  EE 

              
     certificate
                  issued by the CA. If there are files listed in a
                  manifest 

              
     that
                  do not  appear at the publication point,
                  then proceed as

              
     described  Section
                  6.5.

            

          

          


          

          
Wouldn’t we miss all the subordinate Resource
            Certificates if we only look at objects containing an EE
            certificate?

          
I think it would be enough if we say

          


          

          
	Acquire
            from this publication point all files listed in a manifest
            and verify that they are issued by this CA instance.

        

      

    

    Good point. I will reword the description of this processing step.

    

      

        

          


          

          
Although it would be better to expand the “verify” part.

        

      

    

    I will do so.

    

      

        

          


          

          
Also, we should probably mention explicitly what the
            “publication point” is (see my later remark about possible
            discrepancy between different URLs from the CA cert).

        

      

    

     I did not mean to refer the the local cache above. I would like to
    describe this process in terms of the repository system model, as
    described in 6480, ignoring use of RRDP vs. rsync.

    

      

        


          

            

              
 

              
 

              
6.2.  Missing
                Manifests

              
 

              
   The
                absence of a current manifest at a publication point
                could occur

              
   due to
                an error by the publisher or due to (malicious or
                accidental)

              
   deletion
                or corruption of all valid manifests. 

              
 

              
   When no
                valid manifest is available, there is no protection
                against

              
   attacks
                that delete signed objects or replay old versions of
                signed

              
   objects. To guard against the
                  adverse impact of processing an 

              
   incomplete
                  set of signed objects, an RP MUST treat all signed
                  objects

              
   associated with the missing
                  manifest as invalid. (These objects are 

              
   all
                  issued by the same instance of a CA.) RP software MUST
                  issue a

              
   warning
                  when there is no current manifest for a CA instance.

              
 

              
   An RP
                  may have access to a local cache containing a
                  previously 

              
   issued
                  manifest that is still valid. It is RECOMMENDED that
                  the RP

              
   not
                  make use of this data, to ensure consistent a
                  consistent outcome

              
   in
                  when a manifest is missing. 

            

          

          


          

          
The end of last sentence should have some duplicate words
            removed.

        

      

    

    yep.

    

      

        


          

            


              
6.4.  Stale
                Manifests

              
 

              
   A
                manifest is considered stale if the current time is
                after the

              
   nextUpdate
                time for the manifest.  This
                could be due to publisher

              
   failure
                to promptly publish a new manifest, or due to (malicious
                or

              
   accidental)
                corruption or suppression of a more recent manifest.

              
 

              
   All
                signed objects at the publication point issued by the
                entity that

              
   has
                published the stale manifest, and all descendant signed
                objects

              
   that
                are validated using a certificate issued by the entity
                that has

              
   published
                the stale manifest at this publication point, MUST be

              
   treated at invalid and a
                  warning MUST be issued.

              
 

              
   The
                primary risk in using such signed objects is that a
                newer

              
   manifest
                exists that, if present, would indicate that certain
                objects

              
   have
                been removed or replaced.  (For
                example, the new manifest might

              
   show
                the existence of a newer CRL and the removal of one or
                more

              
   revoked
                certificates).  Thus,
                the use of objects from a stale

              
   manifest
                may cause an RP to incorrectly treat invalid objects as

              
   valid.  The
                risk is that the CRL covered by the stale manifest has

              
   been
                superseded, and thus an RP will improperly treat a
                revoked

              
   certificate
                as valid. 

              
 

              
 

              
6.5.  Mismatch
                between Manifest and Publication Point

              
 

              
   If
                there exist valid signed objects associated with a CA
                  instance and

              
   they do not appear in any
                  current, valid manifest for this CA instance,

            

          

          


          

          
This should probably be the “the current, valid
            manifest”, not “any” (as we only consider one manifest as
            the current in 6.1/1)?

        

      

    

    agreed. a will change to "the current, valid manifest"

    

      

        


          

            
   these
                objects MUST be ignored by an RP, and a warning MUST be
                issued.

            
 

            
   If there are files listed
                on the manifest that do not appear in

            
   the
                repository, then these objects have been improperly
                deleted from

            
   repository
                (via malice or accident).  A
                primary purpose of manifests is 

            
   to
                detect such deletions.  Therefore,
                in this case, an RP MUST ignore 

            
   all
                signed objects associated with this CA instance.

            
 

            
6.6.  Hash
              Values Not Matching Manifests

            
 

            
   A file
              appearing on a manifest with an incorrect hash value could

            
   occur
              because of publisher error, but it also may indicate that
              an

            
   attack
              has occurred, e.g., one in which an older
                version of an object

            
   has
                been substituted for a newer version of the object. In
                this case

            
   an RP
                cannot know the content of the missing object, and thus
                all

            
   signed
                objects associated with this instance of the CA MUST be
                ignored 

            
   by the
                RP, and a warning MUST be issued.

            


            

          

          

        

        


        

        
I wonder how far we should get with listing all possible
          inconsistencies in this document, but from my developer’s
          perspective I think  we should list as much as possible, if we
          want RP software to behave in the same way.

      

    

    agreed.  I will try to address the inconsistencies you noted; feel
    free to suggest others.

    

      

        


        

        
Going through what we described in RFC8488, one of such
          inconsistencies is when manifest contains more than one CRL
          entry.

      

    

    RFC 8488 talks only about the requirement to omit the optional CRL
    filed in the generic CMS format we adopted. It does not address the
    issue you mention here, i.e., what if the manifest includes more
    than one CRL. But, I agree that there does not appear to be an
    explicit prohibition of having more than one CRL enumerated in a
    manifest. We should say this explicitly. Next question: what do we
    do if we encounter more than one?

    

      

        
Another is when the manifest is not in the publication
          point of a CA certificate. There are two distinct links from
          the CA certificate – one to the publication point, and one to
          the manifest. 

      

    

    yes, and 6487 does not say that the manifest must be in the
    directory specified by the pub point URI (id-ad-caRepository) Maybe
    we should revise 6487 to make that a requirement. I can address that
    here as well.

    

      

        
Technically, the manifest link could contain different
          directory than a publication point link. If you discover a
          manifest by following the manifest link, and follow
            the rules applied above, using the link from the CA cert
            (and not the location of the manifest), you would not catch
            this discrepancy. 

        
Also note  that similar discrepancy could exist
            with the CRL location (as it also has its own link from the
            cert), but that one is covered by the new text above.

      

    

    
 yes, 6487 does not require the CRLDP to point to a file in the
      pub point specified by the id-ad-caRepository URL in the CA cert.
      Again, how about a revision to 6487 to clarify this? It would make
      life simpler.

    
Steve

    

  


--------------E1A38708AB64A22993D6A875--


From nobody Wed May  6 13:10:11 2020
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 ED8783A0AFC for ; Wed,  6 May 2020 13:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.128
X-Spam-Level: *
X-Spam-Status: No, score=1.128 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=3.227, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9MofLFJmrEK for ; Wed,  6 May 2020 13:09:40 -0700 (PDT)
Received: from sonic305-3.consmr.mail.bf2.yahoo.com (sonic305-3.consmr.mail.bf2.yahoo.com [74.6.133.42]) (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 9FE303A0AF6 for ; Wed,  6 May 2020 13:09:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1588795777; bh=pA0F3bJSR1FmRUoaKRICf8wgYD3hnN4KaQyLmLOd6kU=;  h=From:Subject:To:Cc:References:Date:In-Reply-To:From:Subject;  b=c/HnWqYqBD13EUlLN1pZt0QC2D93spadefMiU1vKiV+A3m6vIfXMxrd4X9SA2VJeC/mAOYIrqm1zIECMs7WD6MBRsUF/UZRhCm+uI9PWGBvdf6eCZEZIGK3CsIQteMvgzXgnVygsrkbb/eSjFGUgCrqb9phaxNDLMjGyQ0yEAhe7yqt5ICKIekqxIlkFALu3Yr2OvTOa7qIy/nuY3V+fO3fPE+yehBPcDEyVQnb6DPrkyI+OCGDUOsABY53h/bhhf9+Ks5n7uo5XzWIn/RSyyG59Z9sf8WcSiMiYs31Y0ZQYjVuH6ifYqxBy2jOqSShfmxUBcHU5iaeuf3lWRN6dvg==
X-YMail-OSG: c9gc5fkVM1kNxvOqsMEEbmtzo2Ku1T_vL3ZicRnej4KRCILhKfueMqP1pwdSbbb J2mrw1x0JgUSpCpoXAFgQx88_sYKq7LWQwD6QvBd0Qtscgsun5.YGZG80mQ3VLTU915x9wPBifev Vte7xZypbsm_FIsPpI3QkOWWBOsCgWm_1tIMyTg3tKEjDLtkBh1EdhSG29hzgpYn7D6OY37nA7eb w3677rPAMPZHGXqVCSEXgUgZXIaVvcOI830vJeklhx5zHgKa0rhXQgDrIuJFyFyrXiiFiA_OLKTB 2RVJNTPVu4IfTxIxF2BVZrEIICG0F2KLKhPJMpLWEG02qLhZJXardZa._SWO10lKSqqb88ebaulI Pov0bWI7y1wJRfbZ0zQAEuAmAZ_yuE4GA7Wj_hPkiOgImhKDrASjERVheDmlBHs08EN35b.KKGT7 7ZBZwLFJNKs1zz5NqvIHAHru7VEwc0UuZZ6j.d0m89ItFTtNy21fDd0XRXv84ufOM4Rg1Tln9EvK WQW9Er8x39S6US2ZHldNaDl95z0OeOOR50bS0OhmopbOQayA8vXDNhkWCOASYuHAP6wk5Agm_OZU 3hwEeE_0ViDuvzKhTIBB4kPcv4cxnvlV_Ki2mn6OCdYTiu.NhreArNX9Uq_QKPtFbAEzPpVKaRwM XcuRvNbgnlQa_0l85n6m7XLderZv5QsElDmDRpg4tioBOUIS6aEos1htyNYhpd7bprvyUjMxRpuu Dzkvss2RW.gicnfsIjKllhvm6.V.QA.CfEWrpUOQyWc1IoEQQjZr_KCa0nIkK3cjLA671JloKW9c oUhK2tbzpgYRu3cRW2Yr0wRfTwlD5j5wItmstfCWlK2VFZfTYfpSKoPxOzz0qgJ_5sZ8reEw8sZ. XFRP8cl_RqeAFw35_L24_MfeEKM_25N7u4tTlH.iZ0CWYsjqQATapRCw6e073y8eVUuiIPz8JrzQ qpMvry60dZSKyaKyCkpJZT7e0gauC4SG1JdWs_zU5YfRn_yrVU0uScC4ZpiEB03Duqhpw3pkdtaI JPx.yEoAs8.QmVQXpQC.60tZ1MlP5B10205OWF9P9pPOjbh1HajrM8JYKgZPzswcIPoTRZsUeEfr gzeEBvj45tuW91NBvzEo3T6jnvp1K_ttBguD98FGp4YcDkZrSgLMbVNsZcedFRJdzM02MPk346S1 ZJWz5jXON9k34L0K.6ATF6YglvZY8aoRpLPJXBukBeMiTGyj0D57WQt30ey6WMlaRD44DbnqH9W4 goGZmg.RvynFG2jY8UYWveCvruoG5x7UfebPRhpBsUD62GtspqJSofwuq2xiiHYrkWmhwfZcQDlQ xk9dYgY7KAt18aEgAR5geyGb6JdteJpPcsy2B0r0PhOzQrhITozdhe6CBLobNbZERs72YUiSvw8n P4vnX.7P.lv6nrOTGEH7YCXLmWk0ygQA.vV_y65K1UHGSvnJfKJ0mEgZ_OGP3j278_2Kc.g--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Wed, 6 May 2020 20:09:37 +0000
Received: by smtp426.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9ff6afda8069908ca9351e9048219e78;  Wed, 06 May 2020 20:09:35 +0000 (UTC)
From: Stephen Kent 
To: Oleg Muravskiy 
Cc: "sidrops@ietf.org" 
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net> <1065C1CC-191A-4CFF-A87C-4F1CB165F303@ripe.net>
Message-ID: <507640b8-30e7-9f95-e6ed-adba12efb090@verizon.net>
Date: Wed, 6 May 2020 16:09:34 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <1065C1CC-191A-4CFF-A87C-4F1CB165F303@ripe.net>
Content-Type: multipart/alternative; boundary="------------E1A38708AB64A22993D6A875"
Content-Language: en-US
X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] proposed, revised text for Section 6
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, 06 May 2020 20:09:43 -0000

This is a multi-part message in MIME format.
--------------E1A38708AB64A22993D6A875
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Oleg,
> Hi Steve,
>
> I have some comments inline:
I'm happy to see that your message shows the red highlighting I used.
>
>> On 4 May 2020, at 22:08, Stephen Kent 
>> > > wrote:
>>
>> 6.1. Determining Manifest State & Object Acceptance
>>
>> For a given publication point, and given CA instance,an RP MUST perform
>> the following tests to determine the manifest state of the publication
>> point.(Note that, during CA key rollover [RFC6489], signed objects for
>> two or more different CA instances will appear at the same publication
>> point. The tests described below are to be performed for a specified CA
>> instance, i.e., a the manifest’s EE certificate was issued by that CA.)
>>
>> 1.Selectthe CA's current manifest (the "current" manifest is the
>> manifest issued by this CAhaving the highest manifestNumber among
>> all valid manifests (as defined in Section 4.4).
>
> Without additional context (the discussion we've had here on the 
> list), it would not be clear for the reader where the possible 
> multiple candidates for the “current”  manifest come from. The CA 
> certificate contains a link (rsync URL) to a manifest, which is only 
> one file, so how could there be multiple options to “select” from? I 
> guess you refer to a possible use of a cache, or a difference between 
> contents of rsync and RRDP repositories?

I will revise the text to say that the processing starts with the 
manifest URL extracted from a CA cert, which should simplify matters. I 
was not trying to refer to a local cache or RRDP in the text above.

>
>> If the publication point does not contain a valid manifest,proceed
>> as described in Section 6.2. (Lacking a valid manifest, the following
>> tests cannot be performed.)
>>
>> 2. Check that the current time (translated to UTC) is between
>> thisUpdate and nextUpdate.
>>
>> If the current time does not lie within this interval,proceed
>> as described in Section 6.4.
>>
>> 3.Acquire all objects at the publication point associated with this
>> CA instance, i.e., the CRL and each object containing an EE
>> certificate issued by the CA. If there are files listed in a manifest
>> that do notappear at the publication point, then proceed as
>> describedSection 6.5.
>
> Wouldn’t we miss all the subordinate Resource Certificates if we only 
> look at objects containing an EE certificate?
> I think it would be enough if we say
>
> Acquire from this publication point all files listed in a manifest and 
> verify that they are issued by this CA instance.
Good point. I will reword the description of this processing step.
>
> Although it would be better to expand the “verify” part.
I will do so.
>
> Also, we should probably mention explicitly what the “publication 
> point” is (see my later remark about possible discrepancy between 
> different URLs from the CA cert).
  I did not mean to refer the the local cache above. I would like to 
describe this process in terms of the repository system model, as 
described in 6480, ignoring use of RRDP vs. rsync.
>
>> 6.2.Missing Manifests
>>
>> The absence of a current manifest at a publication point could occur
>> due to an error by the publisher or due to (malicious or accidental)
>> deletion or corruption of all valid manifests.
>>
>> When no valid manifest is available, there is no protection against
>> attacks that delete signed objects or replay old versions of signed
>> objects.To guard against the adverse impact of processing an
>> incomplete set of signed objects, an RP MUST treat all signed objects
>> associated with the missing manifest as invalid. (These objects are
>> all issued by the same instance of a CA.) RP software MUST issue a
>> warning when there is no current manifest for a CA instance.
>>
>> An RP may have access to a local cache containing a previously
>> issued manifest that is still valid. It is RECOMMENDED that the RP
>> not make use of this data, to ensure consistent a consistent outcome
>> in when a manifest is missing.
>
> The end of last sentence should have some duplicate words removed.
yep.
>
>>
>> 6.4.Stale Manifests
>>
>> A manifest is considered stale if the current time is after the
>> nextUpdate time for the manifest.This could be due to publisher
>> failure to promptly publish a new manifest, or due to (malicious or
>> accidental) corruption or suppression of a more recent manifest.
>>
>> All signed objects at the publication point issued by the entity that
>> has published the stale manifest, and all descendant signed objects
>> that are validated using a certificate issued by the entity that has
>> published the stale manifest at this publication point, MUST be
>> treated at invalid and a warning MUST be issued.
>>
>> The primary risk in using such signed objects is that a newer
>> manifest exists that, if present, would indicate that certain objects
>> have been removed or replaced.(For example, the new manifest might
>> show the existence of a newer CRL and the removal of one or more
>> revoked certificates).Thus, the use of objects from a stale
>> manifest may cause an RP to incorrectly treat invalid objects as
>> valid.The risk is that the CRL covered by the stale manifest has
>> been superseded, and thus an RP will improperly treat a revoked
>> certificate as valid.
>>
>> 6.5.Mismatch between Manifest and Publication Point
>>
>> If there exist valid signed objectsassociated with a CA instanceand
>> they do not appear in any current, valid manifest for this CA instance,
>
> This should probably be the “the current, valid manifest”, not “any” 
> (as we only consider one manifest as the current in 6.1/1)?
agreed. a will change to "the current, valid manifest"
>
>> these objects MUST be ignored by an RP, and a warning MUST be issued.
>>
>> If there are files listed on the manifest that do not appear in
>> the repository, then these objects have been improperly deleted from
>> repository (via malice or accident).A primary purpose of manifests is
>> to detect such deletions.Therefore, in this case, an RP MUST ignore
>> all signed objects associated with this CA instance.
>>
>> 6.6.Hash Values Not Matching Manifests
>>
>> A file appearing on a manifest with an incorrect hash value could
>> occur because of publisher error, but it also may indicate that an
>> attack has occurred,e.g., one in which an older version of an object
>> has been substituted for a newer version of the object. In this case
>> an RP cannot know the content of the missing object, and thus all
>> signed objects associated with this instance of the CA MUST be ignored
>> by the RP, and a warning MUST be issued.
>>
>>
>
>
> I wonder how far we should get with listing all possible 
> inconsistencies in this document, but from my developer’s perspective 
> I think  we should list as much as possible, if we want RP software to 
> behave in the same way.
agreed.  I will try to address the inconsistencies you noted; feel free 
to suggest others.
>
> Going through what we described in RFC8488, one of such 
> inconsistencies is when manifest contains more than one CRL entry.
RFC 8488 talks only about the requirement to omit the optional CRL filed 
in the generic CMS format we adopted. It does not address the issue you 
mention here, i.e., what if the manifest includes more than one CRL. 
But, I agree that there does not appear to be an explicit prohibition of 
having more than one CRL enumerated in a manifest. We should say this 
explicitly. Next question: what do we do if we encounter more than one?
> Another is when the manifest is not in the publication point of a CA 
> certificate. There are two distinct links from the CA certificate – 
> one to the publication point, and one to the manifest.
yes, and 6487 does not say that the manifest must be in the directory 
specified by the pub point URI (id-ad-caRepository) Maybe we should 
revise 6487 to make that a requirement. I can address that here as well.
> Technically, the manifest link could contain different directory than 
> a publication point link. If you discover a manifest by following the 
> manifest link, and follow the rules applied above, using the link from 
> the CA cert (and not the location of the manifest), you would not 
> catch this discrepancy.
> Also note  that similar discrepancy could exist with the CRL location 
> (as it also has its own link from the cert), but that one is covered 
> by the new text above.

yes, 6487 does not require the CRLDP to point to a file in the pub point 
specified by the id-ad-caRepository URL in the CA cert. Again, how about 
a revision to 6487 to clarify this? It would make life simpler.

Steve


--------------E1A38708AB64A22993D6A875
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Oleg,

    

    

      
      Hi Steve,
      


      

      
I have some comments inline:

      

    

    I'm happy to see that your message shows the red highlighting I
    used.

    

      

        


          

            
On 4 May 2020, at 22:08, Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
              wrote:

            

            

              
6.1. Determining Manifest State & Object Acceptance

              
 

              
   For a
                given publication point, and given CA instance, an RP MUST
                perform 

              
   the
                following tests to determine the manifest state of the
                publication

              
   point. (Note that, during CA key
                  rollover [RFC6489], signed objects for

              
   two
                  or more different CA instances will appear at the same
                  publication 

              
   point.
                  The tests described below are to be performed for a
                  specified CA

              
   instance,
                  i.e., a the manifest’s EE certificate was issued by
                  that CA.)

              
 

              
   1. Select the CA's current
                manifest (the "current" manifest is the 

              
       manifest
                issued by this CA  having the highest manifestNumber
                among 

              
       all
                valid manifests (as defined in Section 4.4).

            

          

          


          

          
Without additional context (the discussion we've had here
            on the list), it would not be clear for the reader where the
            possible multiple candidates for the “current”  manifest
            come from. The CA certificate contains a link (rsync URL) to
            a manifest, which is only one file, so how could there be
            multiple options to “select” from? I guess you refer to a
            possible use of a cache, or a difference between contents of
            rsync and RRDP repositories?

        

      

    

    
I will revise the text to say that the processing starts with the
      manifest URL extracted from a CA cert, which should simplify
      matters. I was not trying to refer to a local cache or RRDP in the
      text above.

    

    

      


        

          

            

              
 

              
      If the
                publication point does not contain a valid manifest, proceed

              
      as
                  described in Section 6.2. (Lacking a valid
                manifest, the following 

              
      tests
                cannot be performed.)

              
 

              
   2.
                Check that the current time (translated to UTC) is
                between

              
      thisUpdate
                and nextUpdate.

              
 

              
      If the
                current time does not lie within this interval, proceed 

              
      as
                  described in Section 6.4.

            

          

          

            

              
 

              
  3. Acquire all objects at
                  the publication point associated with this 

              
     CA
                  instance, i.e., the CRL and each object containing an
                  EE 

              
     certificate
                  issued by the CA. If there are files listed in a
                  manifest 

              
     that
                  do not  appear at the publication point,
                  then proceed as

              
     described  Section
                  6.5.

            

          

          


          

          
Wouldn’t we miss all the subordinate Resource
            Certificates if we only look at objects containing an EE
            certificate?

          
I think it would be enough if we say

          


          

          
	Acquire
            from this publication point all files listed in a manifest
            and verify that they are issued by this CA instance.

        

      

    

    Good point. I will reword the description of this processing step.

    

      

        

          


          

          
Although it would be better to expand the “verify” part.

        

      

    

    I will do so.

    

      

        

          


          

          
Also, we should probably mention explicitly what the
            “publication point” is (see my later remark about possible
            discrepancy between different URLs from the CA cert).

        

      

    

     I did not mean to refer the the local cache above. I would like to
    describe this process in terms of the repository system model, as
    described in 6480, ignoring use of RRDP vs. rsync.

    

      

        


          

            

              
 

              
 

              
6.2.  Missing
                Manifests

              
 

              
   The
                absence of a current manifest at a publication point
                could occur

              
   due to
                an error by the publisher or due to (malicious or
                accidental)

              
   deletion
                or corruption of all valid manifests. 

              
 

              
   When no
                valid manifest is available, there is no protection
                against

              
   attacks
                that delete signed objects or replay old versions of
                signed

              
   objects. To guard against the
                  adverse impact of processing an 

              
   incomplete
                  set of signed objects, an RP MUST treat all signed
                  objects

              
   associated with the missing
                  manifest as invalid. (These objects are 

              
   all
                  issued by the same instance of a CA.) RP software MUST
                  issue a

              
   warning
                  when there is no current manifest for a CA instance.

              
 

              
   An RP
                  may have access to a local cache containing a
                  previously 

              
   issued
                  manifest that is still valid. It is RECOMMENDED that
                  the RP

              
   not
                  make use of this data, to ensure consistent a
                  consistent outcome

              
   in
                  when a manifest is missing. 

            

          

          


          

          
The end of last sentence should have some duplicate words
            removed.

        

      

    

    yep.

    

      

        


          

            


              
6.4.  Stale
                Manifests

              
 

              
   A
                manifest is considered stale if the current time is
                after the

              
   nextUpdate
                time for the manifest.  This
                could be due to publisher

              
   failure
                to promptly publish a new manifest, or due to (malicious
                or

              
   accidental)
                corruption or suppression of a more recent manifest.

              
 

              
   All
                signed objects at the publication point issued by the
                entity that

              
   has
                published the stale manifest, and all descendant signed
                objects

              
   that
                are validated using a certificate issued by the entity
                that has

              
   published
                the stale manifest at this publication point, MUST be

              
   treated at invalid and a
                  warning MUST be issued.

              
 

              
   The
                primary risk in using such signed objects is that a
                newer

              
   manifest
                exists that, if present, would indicate that certain
                objects

              
   have
                been removed or replaced.  (For
                example, the new manifest might

              
   show
                the existence of a newer CRL and the removal of one or
                more

              
   revoked
                certificates).  Thus,
                the use of objects from a stale

              
   manifest
                may cause an RP to incorrectly treat invalid objects as

              
   valid.  The
                risk is that the CRL covered by the stale manifest has

              
   been
                superseded, and thus an RP will improperly treat a
                revoked

              
   certificate
                as valid. 

              
 

              
 

              
6.5.  Mismatch
                between Manifest and Publication Point

              
 

              
   If
                there exist valid signed objects associated with a CA
                  instance and

              
   they do not appear in any
                  current, valid manifest for this CA instance,

            

          

          


          

          
This should probably be the “the current, valid
            manifest”, not “any” (as we only consider one manifest as
            the current in 6.1/1)?

        

      

    

    agreed. a will change to "the current, valid manifest"

    

      

        


          

            
   these
                objects MUST be ignored by an RP, and a warning MUST be
                issued.

            
 

            
   If there are files listed
                on the manifest that do not appear in

            
   the
                repository, then these objects have been improperly
                deleted from

            
   repository
                (via malice or accident).  A
                primary purpose of manifests is 

            
   to
                detect such deletions.  Therefore,
                in this case, an RP MUST ignore 

            
   all
                signed objects associated with this CA instance.

            
 

            
6.6.  Hash
              Values Not Matching Manifests

            
 

            
   A file
              appearing on a manifest with an incorrect hash value could

            
   occur
              because of publisher error, but it also may indicate that
              an

            
   attack
              has occurred, e.g., one in which an older
                version of an object

            
   has
                been substituted for a newer version of the object. In
                this case

            
   an RP
                cannot know the content of the missing object, and thus
                all

            
   signed
                objects associated with this instance of the CA MUST be
                ignored 

            
   by the
                RP, and a warning MUST be issued.

            


            

          

          

        

        


        

        
I wonder how far we should get with listing all possible
          inconsistencies in this document, but from my developer’s
          perspective I think  we should list as much as possible, if we
          want RP software to behave in the same way.

      

    

    agreed.  I will try to address the inconsistencies you noted; feel
    free to suggest others.

    

      

        


        

        
Going through what we described in RFC8488, one of such
          inconsistencies is when manifest contains more than one CRL
          entry.

      

    

    RFC 8488 talks only about the requirement to omit the optional CRL
    filed in the generic CMS format we adopted. It does not address the
    issue you mention here, i.e., what if the manifest includes more
    than one CRL. But, I agree that there does not appear to be an
    explicit prohibition of having more than one CRL enumerated in a
    manifest. We should say this explicitly. Next question: what do we
    do if we encounter more than one?

    

      

        
Another is when the manifest is not in the publication
          point of a CA certificate. There are two distinct links from
          the CA certificate – one to the publication point, and one to
          the manifest. 

      

    

    yes, and 6487 does not say that the manifest must be in the
    directory specified by the pub point URI (id-ad-caRepository) Maybe
    we should revise 6487 to make that a requirement. I can address that
    here as well.

    

      

        
Technically, the manifest link could contain different
          directory than a publication point link. If you discover a
          manifest by following the manifest link, and follow
            the rules applied above, using the link from the CA cert
            (and not the location of the manifest), you would not catch
            this discrepancy. 

        
Also note  that similar discrepancy could exist
            with the CRL location (as it also has its own link from the
            cert), but that one is covered by the new text above.

      

    

    
 yes, 6487 does not require the CRLDP to point to a file in the
      pub point specified by the id-ad-caRepository URL in the CA cert.
      Again, how about a revision to 6487 to clarify this? It would make
      life simpler.

    
Steve

    

  


--------------E1A38708AB64A22993D6A875--


From nobody Wed May  6 13:10:49 2020
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 4C57F3A0AFE for ; Wed,  6 May 2020 13:10:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUjx7c9hXe-m for ; Wed,  6 May 2020 13:10:46 -0700 (PDT)
Received: from sonic317-26.consmr.mail.bf2.yahoo.com (sonic317-26.consmr.mail.bf2.yahoo.com [74.6.129.81]) (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 6797A3A0AFB for ; Wed,  6 May 2020 13:10:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1588795845; bh=cyOBp4z82KlSOUOqYRUfcQFiWSxDhyXb3kxtASBb7tM=;  h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=EXctTtzPbxg4iKc7qhO+dB6TV+yCGsc2pQKORtX57SVKrCtGTtnfFoXu8N6VgtaFrBF7pYFEtyVNzMB+e6H806ZqMm5TpmFfn/UN68PINwMGthdXBlk9qM1unQeyC2AyvL1cTfCzk2UC9FMINw9WaDuNKApvOsIXVMPA6H2yjhNSWfGYSfisNp8B2i95AZVcfpBAnXZP3qXaPq+TcixVU2hEQJuiz/v2b37ELtM/n4uHGMypFWga15X8oVG8jNYRqS2OAEgcZWGH6gz4E78YL7JrYlg4AF5eVsi78L5QuJUui+3pjPrVw0wTTgIcWGI1T0eEakiNjzEkK60+9QTxew==
X-YMail-OSG: Xkay0z8VM1n3wm5Z0fupzQwuR.otjaSXA4cIRsoAhq02UBHj_e3E0r6dxB.7jgl RnnpcVY0c9RX_GLPUrVSbqwReHP3mpxAZbi84t0UFxQZIhBhKDs0NggsvcvBgg4AWnvCqO3NLbon 6cEVsDmUEsunC9lq9_W3n8NlTUn7KqiI5Eq5Z5Hc6ixc6CPJRavebomCx1WmG8jORTaZdDmUjCmY WKuInwR5RrwnY.2Dziy63Vd8W2Jy6bYmluf_b_dwTvj3GMnz.txQ0m2vxZzxiBMElJYbNMgU6Ouj xdDsK81MO5jh1A3QudFnHn1lPNcrOIgenxdSJykOG2wndZM.v7cRntuTGNqdfeSMn3FEDON68YT5 IPF1ppoOHTfiR2Rkaz4rJ6hjcB2uoQHIMgOJZB3i_2B.GUbaUNY32Jb.vGVswNM83mqKQa.pxBoa gm5ws_8Mt3fCPecKuGdEpWqr8wvwwqpOFeHcO0X402FzzScwurV2Jt3BX_E66vDuIRNemGzuV31l JxwwHbrHWAgblUzmGPeldC0f0IE6AIaM66CoeZEjx51vYk7RLNguE.rOG5_e9FUq4WjQNt7fZ0ad JskOZYBUos2LedeFet2BiNAZMM8aSOhadqUoCLG1kFHYqmYnD3jyjQlt87v7T6UyJKTnboB8PWTs Ma1zA9AbBB77krPLfGqcfZ_HFUVgXugW9v.Iz0R2Aa3bOefOuGxE39musW8LmzbycYbdts2UeeaK 3or4jGvKzWSODmkcXPZRdmiz3DjE0IMJWOduSqRiHleAVHNpiw7inCE.mzQnN0RvDjqVeOPZ2V1I QV6vzrtA7U5CcgrFpP0gGmTnMZlZTA77WLWdYV8WEzejoQaw.mw8ySsyWVqKVxgAZ7kQZXUmQE6r Y2t8ryIpoVKneLRYnaI5G9QjivtPWwKd1KppYhiJhTdfEtofZ8_qPokrftqKmq1YxxflJzj2hjaS HifyA0utxRCNsYdvSk3yL.TAWjlS29Bwr5Kf.StHFylGaC0o3z4sIXYSKSiHWTsEtVr0CdLotStU Kn4IM7e4tVEQTB.yLJF8a44CxR2WjEZ2WXgDIBurP3LEfD9D3Zs504iQVS8uUsLQteYNlcSQtpli YrZK9Ll5U67.KE38Hfffkjx4EBWmswk3Xagsx1sEVY_WkEHz378mygo8gHrnewd.E.XYFefJhtV5 HACgQobkdIe57IPEcgjVzc78WE4RpZbGgB4r05_XkVFc9iPBWe6bD04hJHRauXAglYe0rjss2ptC Wb_kOMLjIaFP8BypQn.dlbNbGlS3R224lvyq1txrViqM2QXin9Bj0Pwat0RcyiOyH7VQAr1KAq_z LtbPuEUG_uHpOc61N4kcBi2zj8AhwCqq_MfUHHxQ_xrUKWVHzq6xRv9ShcQK1JKpxhTUMkp6y3dL SsjMpYFFjHlNTbb0bTBY9NT7nDpTT8eHTusHkreg5QjLbHrE9uVE-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Wed, 6 May 2020 20:10:45 +0000
Received: by smtp427.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ddffa0210a83c22c6f2ca0e78990e46b;  Wed, 06 May 2020 20:10:43 +0000 (UTC)
To: sidrops@ietf.org
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net>  <7355e27e-ee58-f84b-4fed-9674ae542d94@verizon.net>  <730ce7ed-928b-19e6-cfa3-a5a2eddb03df@verizon.net> <24243.5147.589924.749920@oz.mt.att.com>
From: Stephen Kent 
Message-ID: <35eb5a4d-9234-288c-6a19-5cdfe02ea0e3@verizon.net>
Date: Wed, 6 May 2020 16:10:42 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <24243.5147.589924.749920@oz.mt.att.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] proposed, revised text for Section 6
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, 06 May 2020 20:10:48 -0000

jay,
> Stephen Kent writes:
>   > These are all valid questions. The WG needs to decide if per-RP
>   > variance, based on fetch timing, local cache failure, etc. meets the
>   > goal of uniform RP processing of RPKI data. I am agnostic on this point.
>   >
>
> Recently I had attempted to gauge if there was WG consensus along
> these lines:
>
>     Each validation run of each RP MUST generate the same set of
>     Validated ROA Payloads (VRPs) when presented with identical input,
>     using unexpired records from the most recent successful retrieval
>     to deal only with complete failure to retrieve from a PP.
>
> Now I have come around to agree with Job's perspective that coarse
> behavior like 'rsync --delete' is not what RPs should do.
>
> An RP should not assume that objects missing in any PP retrieval are
> the fault of the responsible CA.  The objects could be missing due to
> fault of the CA, problems reaching the PP, or other potential causes,
> and the RP cannot know which one it was.  If the RP's cached objects
> can fill in the gaps, that's great.
I am revising the text to mandate use of an RP's cache to fill in for 
missing or damaged files.
> Thus I now feel the straw proposal I offered above is too restrictive.
> I would still want different RP implementations to be 'deterministic'
> such that they produce the same VRPs, but only when operating on an
> identical local cache (including an empty cache as one important case).

OK.

Steve


From nobody Wed May  6 15:26:03 2020
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 2BB5C3A0B5E for ; Wed,  6 May 2020 15:25:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAt1QQy4udT4 for ; Wed,  6 May 2020 15:25:44 -0700 (PDT)
Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 3E9F33A0CFF for ; Wed,  6 May 2020 15:25:44 -0700 (PDT)
Received: by mail-il1-x136.google.com with SMTP id t12so1755052ile.9 for ; Wed, 06 May 2020 15:25:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R8sPwDycT/3AN3sLuUctHrVHDez3l98F9dHmkH2Iarw=; b=ZmwdT0oIpzVJEwXCacpTslmXZAmycua7c6FOj2P9UljdtjuCrt3C6B9anj9N71Fo2J 57bikNe246ICAPSTuYXD6QJ1HQ+Qa1qydBxg2/+8N7dUK9gF+kVMSwcSE+9RrI8yQ+Es h6Umzzn1XuhIAiH437nHCMy6lmSbpvrGr6Q2BubL8FQ97cbk6EIK2V+snO5esThMQFDm 1QPTBT0iNww5nwJxvcEZnmDXrOWbNWD8F1ICJQVYFWhkftqKMdvUzBO97U3kPaVUUbJu IAZJb4ZwYfAZNeBb5mbXrKDyDD0bGICZnMZ7VmG3g8RKsgIxeilcgCk3NBcdFwPDoeVa gHBw==
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=R8sPwDycT/3AN3sLuUctHrVHDez3l98F9dHmkH2Iarw=; b=lkg5bkoWqHrOFcp/lK2fALx2bBlQjVJLTjqZhGkH0CvfhDxwDSzhgw80qi491PU/ko xOFpgMS+brQ9pcltsl7HMQ6pURDLkbDqwh9dXziO/14PSiijQsrY/JH91nMRrpUj0yXh 83BkOP4ud4R9Vy5IK7FYdiIj2xRpKGpwxoRXVGEXiY0ti68AicuERz/a1wjvr3MeoWiN Zeq7wDfrI1tepJRmreOu/3EJ8kc47HKn0kKLKitkHKDGwVx4dupOMhoyznt+mAZ4Xc+W er0OsApqo7NIzUUKvl3a0eLaRzBpQEcaSZwh+oS7pxwVfjfy4qG8mAgciR2F7fRzUy9m JDow==
X-Gm-Message-State: AGi0Pua29ywOw1P8jK8UEpDvndHNVyh5+9TOtdrH0DlMzBRKoFTVLOEw HFqsE6tjQfU6g2pBntnEYW56ud0GzXDClDrAZ33SYVH7
X-Google-Smtp-Source: APiQypLfM59E+px4ED0Pu49iejyD6jwExbPOn5+aRrDcoHYwWOc1i5VuQYjHEfVJPzenCi1ij+pCDLEJhpxeS+GD+r8=
X-Received: by 2002:a05:6e02:80e:: with SMTP id u14mr12118329ilm.176.1588803943354;  Wed, 06 May 2020 15:25:43 -0700 (PDT)
MIME-Version: 1.0
References: <29748EA5-6016-4E6D-9261-A069F7431390@nlnetlabs.nl>
In-Reply-To: <29748EA5-6016-4E6D-9261-A069F7431390@nlnetlabs.nl>
From: George Michaelson 
Date: Thu, 7 May 2020 08:25:32 +1000
Message-ID: 
To: SIDROps Chairs 
Cc: SIDR Operations WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [Sidrops] Adopt draft-sidrops-bruijnzeels-deprecate-rsync?
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, 06 May 2020 22:25:47 -0000

co-author, also +1 to adoption.

This work is necessary now, to define the process to move off rsync.
We only have a higher hill to climb, if we delay on this and let the
RP population grow.

This complements proposed work in RP timing, and it provides for a
secure channel to fetch repository contents which mitigates some of
the MITM risks inherent in rsync which is incapable of being secured.

-G

On Wed, Apr 29, 2020 at 11:19 PM Tim Bruijnzeels  wrote:
>
> Dear co-chairs, WG,
>
> As mentioned yesterday I would like ask the chairs to do a call for adoption on:
> https://datatracker.ietf.org/doc/draft-sidrops-bruijnzeels-deprecate-rsync/
>
> I am also more than happy to discuss the content, and adapt following discussion, but maybe this is better done if adopted :)
>
> Thanks
> Tim
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops


From nobody Wed May  6 15:33:17 2020
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 50C8E3A0D94; Wed,  6 May 2020 15:33:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.099
X-Spam-Level: 
X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40aGcx224JyZ; Wed,  6 May 2020 15:33:13 -0700 (PDT)
Received: from relay.ops-netman.net (relay.kvm02.ops-netman.net [IPv6:2606:700:e:550:5c82:28ff:fe4c:9503]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9FDC3A0D95; Wed,  6 May 2020 15:33:12 -0700 (PDT)
Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by relay.ops-netman.net (Postfix) with ESMTPS id 7F9A73C21A1; Wed,  6 May 2020 22:33:11 +0000 (UTC)
Received: from mailserver.ops-netman.net.ops-netman.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 45E0623A; Wed,  6 May 2020 22:33:11 +0000 (UTC)
Date: Wed, 06 May 2020 22:33:11 +0000
Message-ID: <87y2q4ofrs.wl-morrowc@ops-netman.net>
From: Chris Morrow 
To: sidrops@ietf.org,sidrops-ads@ietf.org,sidrops-chairs@ietf.org
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 Mule/6.0 (HANACHIRUSATO)
Organization: Operations Network Management, Ltd.
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: [Sidrops] ADOPTION: draft-sidrops-bruijnzeels-deprecate-rsync (Ends 2020/27/5)
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, 06 May 2020 22:33:16 -0000

Howdy WG Folks!  Can we please read/consider and think back to our
robust conversation at the interim meeting :) about:

  draft-sidrops-bruijnzeels-deprecate-rsync
  https://tools.ietf.org/html/draft-sidrops-bruijnzeels-deprecate-rsync-01

and consider whether or not we should adopt this draft as a working-group
work item? We shall endeavor to close out this adoption call 27 May 2020.

Abstract included:
  "This document formulates a plan of a phased transition to a state
   where RPKI repositories and Relying Party software performing RPKI
   Validation will use the RPKI Repository Delta Protocol (RRDP)
   [RFC8182] as the only mandatory to implement access protocol.

   In short this plan consists of the following phases.

   In phase 0, today's deployment, RRDP is supported by most, but not
   all Repositories, and most but not all RP software.

   In the proposed phase 1 RRDP will become mandatory to implement for
   Repositories, in addition to rsync.  This phase can start as soon as
   this document is published.

   Once the proposed updates are implemented by all Repositories phase 2
   will start.  In this phase RRDP will become mandatory to implement
   for all RP software, and rsync must no longer be used.

   Measurements will need to be done to help determine when it will be
   safe to transition to the final phase of this plan.  During this
   phase Repositories will no longer be required to provide rsync access
   for RPKI validation purposes.  However, they may still provide rsync
   access for direct access to files for other purposes, if desired, at
   a best effort basis.

   Although this document currently includes descriptions and updates to
   RFCs for each of these phases, we may find that it will be beneficial
   to have separate documents for the plan, and each phase, so that it
   might be more clear to all when the updates to RFCs take effect."

There have already been ~10 folk express support on-list for this, so we'll
count their votes in the final tally 5/27/2020.

thanks!
-chris
co-chair-persona


From nobody Wed May  6 18:13:39 2020
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 38DA03A0E09; Wed,  6 May 2020 18:13:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLe0ahg9-nde; Wed,  6 May 2020 18:13:34 -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 D60B23A0DE4; Wed,  6 May 2020 18:13:33 -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 1jWV6R-0005vV-Ek; Thu, 07 May 2020 01:13:31 +0000
Date: Wed, 06 May 2020 18:13:30 -0700
Message-ID: 
From: Randy Bush 
To: George Michaelson 
Cc: SIDROps Chairs , SIDR Operations WG 
In-Reply-To: 
References: <29748EA5-6016-4E6D-9261-A069F7431390@nlnetlabs.nl> 
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [Sidrops] Adopt draft-sidrops-bruijnzeels-deprecate-rsync?
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, 07 May 2020 01:13:39 -0000

i am sufficiently old school that i do not speak for adoption or wglc of
a draft on which i am co-author.

randy


From nobody Wed May  6 18:16:50 2020
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 3EF3F3A0E0F for ; Wed,  6 May 2020 18:16:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wltZXtCc3_Og for ; Wed,  6 May 2020 18:16:39 -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 50F2B3A0E0D for ; Wed,  6 May 2020 18:16:39 -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 1jWV9S-0005w2-2H; Thu, 07 May 2020 01:16:38 +0000
Date: Wed, 06 May 2020 18:16:37 -0700
Message-ID: 
From: Randy Bush 
To: Jay Borkenhagen 
Cc: SIDR Operations WG 
In-Reply-To: <24243.5147.589924.749920@oz.mt.att.com>
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net>  <7355e27e-ee58-f84b-4fed-9674ae542d94@verizon.net>  <730ce7ed-928b-19e6-cfa3-a5a2eddb03df@verizon.net> <24243.5147.589924.749920@oz.mt.att.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [Sidrops] proposed, revised text for Section 6
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, 07 May 2020 01:16:47 -0000

in

   https://mailarchive.ietf.org/arch/msg/sidrops/tVb6sAm9g2KLOC2msTgxb-WW4zI/

i think sra told you how to get what you want

randy


From nobody Thu May  7 02:00:45 2020
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 524BE3A085D for ; Thu,  7 May 2020 02:00:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 s2TFYtow39YH for ; Thu,  7 May 2020 02:00:41 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.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 D1BA03A084A for ; Thu,  7 May 2020 02:00:40 -0700 (PDT)
Received: from [IPv6:2001:981:4b52:1:1cf9:f327:7f8b:f81b] (unknown [IPv6:2001:981:4b52:1:1cf9:f327:7f8b:f81b]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id E8D422D12C; Thu,  7 May 2020 11:00:38 +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=1588842038; bh=wb3UeW1Gfc0E/FsCdE9RWF7haH8uMJALzhGLNijHpes=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=p9f2rPBqGBzapOeGDO92mtqL84zQYRoEDD5+kSi8JckUjCpf87yGpDcNad1WZWxSY Yr+vcCMQCCqAWxlM7q/YEBjpq2HgTcTxnu3PDDIke9H2mj2FbgMD05EbHp4cSPsRqx jGqzlxJyJbOuvyc9CHDfBM/voPd4k9FKENgFNGSs=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Tim Bruijnzeels 
In-Reply-To: <507640b8-30e7-9f95-e6ed-adba12efb090@verizon.net>
Date: Thu, 7 May 2020 11:00:38 +0200
Cc: Oleg Muravskiy , "sidrops@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <7A134E0C-52E1-4FAD-A4E6-D971EFCDC63E@nlnetlabs.nl>
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net> <1065C1CC-191A-4CFF-A87C-4F1CB165F303@ripe.net> <507640b8-30e7-9f95-e6ed-adba12efb090@verizon.net>
To: Stephen Kent 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [Sidrops] proposed, revised text for Section 6
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, 07 May 2020 09:00:42 -0000

Hi Steve,

> On 6 May 2020, at 22:09, Stephen Kent =
 wrote:
>=20
>> I wonder how far we should get with listing all possible =
inconsistencies in this document, but from my developer=E2=80=99s =
perspective I think  we should list as much as possible, if we want RP =
software to behave in the same way.
> agreed.  I will try to address the inconsistencies you noted; feel =
free to suggest others.
>>=20
>> Going through what we described in RFC8488, one of such =
inconsistencies is when manifest contains more than one CRL entry.
> RFC 8488 talks only about the requirement to omit the optional CRL =
filed in the generic CMS format we adopted. It does not address the =
issue you mention here, i.e., what if the manifest includes more than =
one CRL. But, I agree that there does not appear to be an explicit =
prohibition of having more than one CRL enumerated in a manifest. We =
should say this explicitly. Next question: what do we do if we encounter =
more than one?
>> Another is when the manifest is not in the publication point of a CA =
certificate. There are two distinct links from the CA certificate =E2=80=93=
 one to the publication point, and one to the manifest.=20
> yes, and 6487 does not say that the manifest must be in the directory =
specified by the pub point URI (id-ad-caRepository) Maybe we should =
revise 6487 to make that a requirement. I can address that here as well.
>> Technically, the manifest link could contain different directory than =
a publication point link. If you discover a manifest by following the =
manifest link, and follow the rules applied above, using the link from =
the CA cert (and not the location of the manifest), you would not catch =
this discrepancy.
>> Also note  that similar discrepancy could exist with the CRL location =
(as it also has its own link from the cert), but that one is covered by =
the new text above.
> yes, 6487 does not require the CRLDP to point to a file in the pub =
point specified by the id-ad-caRepository URL in the CA cert. Again, how =
about a revision to 6487 to clarify this? It would make life simpler.
>=20

I agree.

I think all CA implementations already do the following, which is =
implied by RFC 6487 and 6481 in particular. But the text is not =
sufficiently explicit. Updates will help, especially RP software.

* There is only ever one (1!) *current* CA certificate issued for a =
given key (implied by RFC6492)
* This CA certificate has the following SIA entries:
    - id-ad-caRepository pointing to its full publication point
    - id-ad-rpkiManifest pointing to a manifest in that publication =
point
    - (still optionally) id-ad-rpkiNotify pointing to the RRDP (RFC =
8182) notification file

* For a CA certificate (i.e. a single key) there will be ONE current MFT =
only
* For a CA certificate (i.e. a single key) there will be ONE current CRL =
only
* That CRL name and hash MUST match the one and only .crl file on the =
MFT
* Any issued (EE or CA) certificate under this CA certificate (single =
key) MUST use a CRLDP that matches the name of this .crl file, under the =
issuing CA certificate's id-ad-caRepository

Did I miss anything still?

Tim


From nobody Thu May  7 02:58:47 2020
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 908C83A060A; Thu,  7 May 2020 02:58:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=workonline.africa
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9z8hpljqzaMu; Thu,  7 May 2020 02:58:21 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10082.outbound.protection.outlook.com [40.107.1.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00543A0B26; Thu,  7 May 2020 02:58:18 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HC0fQ7PtGNoX5m/aytkXmJFwVx2PSQTmkqDEoJ2838keIsSmLm1dUKkEE7vZWn45WKEmBkOxcvWaOfZ1clkxO9Qtdk1/s3TvJOGGbp7/s8mS6OSwvOPWeg+GEm1ZnBP2jh6UrWMlTOah5EBg8uEWBnMFesBFaRqXr25R7Rb7asmSKTAuwN1G9+9+3Viy/NCzDFbWMwMrE+76/d/vRcs5pqEJBLu3YeSRFhMZyIDBJd5hGu+CJKAe8/jWNhxR8ocAMx1LnlUwU5JfWld8x35+zA1BIyNCUnBKUOhMb3yx2ebAY5VylqY8JzhGPppmOwBl4MgP/udy0zvsVUrJa/2vFA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oqVciiKuWt2BapPcBhH+wSlpx0X93r2bByhzKdYnDMs=; b=du047gRehsJD+38S7qFc+OqFaCVXViACyFXGVmCruNmRldEGJLb5a/kkUE4DtiCi9bqAEn+nHYREKnKi1pa36cA/kVRNvQnWYoXRrvRxcDiT88+Lkmx8qYfgBdDbdonQkNDWMwEftLNSh+ls5kb2Rc/2Zkcbfh0fyDU2Zw42zLdGaAAmOcQhHPvoraqulZmZGvtnzHGF2ykGfMuPGmoTSQjYqNQvPD03W8vz2593zgPufRTWsYraR/DephlZ4s0wbrKTD23KI5SWpM1vu9kfmGO5k0nXXYU0s+xE9cLBKeAUMeO8K4xLznilmlIElVmmWJyOFdRtbcYT3bhvMW+GcQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=workonline.africa; dmarc=pass action=none header.from=workonline.africa; dkim=pass header.d=workonline.africa; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=workonline.africa; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oqVciiKuWt2BapPcBhH+wSlpx0X93r2bByhzKdYnDMs=; b=PIpNZMvWT+/butl/NFznMYFF/ocONeBIf+7IVQi0fR6w0gFbQheC44X7CU1EfwtfmUAjz0MgW8/VPXyxtcfxrdKVnYzhbMhhPzBetMDEZMI6dvevBmZGcoHQFmlhU9VYy4afaIYoZnzwtErDTsogY7CefOsmRdB8Fofkn1VHEQI=
Received: from AM7P190MB0583.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:113::21) by AM7SPR01MB0005.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:141::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.26; Thu, 7 May 2020 09:58:16 +0000
Received: from AM7P190MB0583.EURP190.PROD.OUTLOOK.COM ([fe80::1d53:1387:1a8a:2b66]) by AM7P190MB0583.EURP190.PROD.OUTLOOK.COM ([fe80::1d53:1387:1a8a:2b66%8]) with mapi id 15.20.2979.028; Thu, 7 May 2020 09:58:16 +0000
From: Ben Maddison 
To: "morrowc@ops-netman.net" , "sidrops-chairs@ietf.org" , "sidrops@ietf.org" , "sidrops-ads@ietf.org" 
Thread-Topic: [Sidrops] ADOPTION: draft-sidrops-bruijnzeels-deprecate-rsync (Ends 2020/27/5)
Thread-Index: AQHWI/Zkp7vGNqQkgEeFF6y/nCDPLqicZB2A
Date: Thu, 7 May 2020 09:58:16 +0000
Message-ID: <5da878b13286d1a6efa4c29de8b8f289813d0c4e.camel@workonline.africa>
References: <87y2q4ofrs.wl-morrowc@ops-netman.net>
In-Reply-To: <87y2q4ofrs.wl-morrowc@ops-netman.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 
authentication-results: ops-netman.net; dkim=none (message not signed) header.d=none;ops-netman.net; dmarc=none action=none header.from=workonline.africa;
x-originating-ip: [165.0.73.66]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ed5e7ec1-f0a4-46a3-6813-08d7f26d29c7
x-ms-traffictypediagnostic: AM7SPR01MB0005:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 03965EFC76
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 68a2pJcxSRMRO+so37FsT5YdcHZ+hWybxX2mazPfTRR7hsHWJfoBvYybF1TkuZ8fveJ+C/zWxWtQ1fSx+R7T1pMmh9uY65x4MPFpVk71bx6KQJOu96K4Ll68qbzjWQ4WslN7IlTqO9Vbja7GSd7kG+KeVKsA3VjCec9JID+2CBRJ+IYy0gud+BuMgACV+RimU1ZOufsFsLTYO2iye2DTp0R3UqE6d622yYS+TdxraCyGA1Lb9pUAEMMzkdv5xgJ5oPzFRDTTOy17huVbwooKEVphpe/AhevzcoJuHDTvV/KvfrXsc2TL+5pl+malfICuTvCxXYx/yT0R7lbE7z7wNfWM/x45hOHTo+Lhpqu1vYTn2YxS7uvmd0TdcyxG0atCZ/EFY95qIZuiJ0dHN7u6wAZymFyG5IATXWp9dlYBWYiQAoAjYarwgT/8z9EuJEZ+U3vJUebUY7lSsisyjmJni17o0OeeNUaG4DXcFN9sXN/1DF/jGiSQrbK8mzzQsyJ85AsQi82Nul+AVAoTpQFs+h3edQIHhixYmyIhjj/XoyP0cC2yb4eIEUMWfEmIjf72jhh1IuXS1/F9kwPKylBpooSRe5OopuVAPknc50pIHLQcg6+7/xYtrvQqJEgAXHpqiXZIWw+Y+jl/VPnFbUVUZVhpUu+CbBd4HAxzYD2Rmc0=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AM7P190MB0583.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFTY:; SFS:(376002)(346002)(396003)(39830400003)(366004)(136003)(33430700001)(71200400001)(66476007)(64756008)(66946007)(91956017)(66446008)(4744005)(66556008)(5660300002)(966005)(83310400001)(83300400001)(2906002)(83280400001)(83320400001)(83290400001)(8676002)(26005)(6512007)(76116006)(508600001)(86362001)(8936002)(316002)(33440700001)(110136005)(2616005)(186003)(6506007)(6486002)(46492006)(99106002); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: OnmyYyGcgdVyGUg+fwosoVBqju+6IDkqv26mKOxPbEp/0kpWlsUynuqVH2hLElaSRsMbv6FwSWls0T0JmmjHuCPTYDr0+1uODik1gKnCgC8Kr3k9MQY8sTrb0JdS12VoIqlD9UzTpnaXBy+AdjZkS+1RcjWGxgtQMV4kX1h75f7R0+9gqPUZaHE5sHHZR82aOE8p/x4qshk81c4n9E79OTSDjqTWbaVv3lRw6i3o0+1UKoqHy0Uljbgd4InscqpEgqK5m28eJufoNvbm2KoFqxdBcZjqfK5gwehOfbYx5ozPKtrkEeCWh3L7Cr9dHLK0VKu1ww5RLCkPxGuOh3NO5ALzMH8f5jyWTErcZPMTeasTyeqdRwWuADxsHLfqPDgJwcbIQIMZeH0yPYbXdXFuVogQr+FbTJh1R7TVUpjkldmT5ELX4HRqUkfrcxhL04kxDE2MZCMBmyyQF7Wm+sLqyQ7Cb0IQLk19L5nF0BXv/bBtiKi6sPhCiGHTtksHcAPq9vUTKxV31AoRdSPLSxHLNy6Rg+zDj4b83pl3X4PlFMu8Jh9VgK7R6Rwu9R6D/07KnoKH6rVE5shypQhpaebf6sspGT/DMbvAAuipGLNfaC8Bp/85AHcx5Ye2sejIqz5Yd3gBzCuPc0wAkUqJGx+KHlq35Ko3ddNlSyObWMLtOFVx9rVlFIasxOlyk3vAsjjrzGZXfZbgR8IK3uDi6O6MfiuDYh+exVVw1AezlKr8ePHo8jnj3dwoJiF7Eavzg15M+dr57xvugEXzG0YNnFPCYVeyPBFCB/xqjMPgn7HPAi8=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: workonline.africa
X-MS-Exchange-CrossTenant-Network-Message-Id: ed5e7ec1-f0a4-46a3-6813-08d7f26d29c7
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2020 09:58:16.1440 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: tgIx3p5jI+klHlrZJVHpzedVhGDAnyDBj8LMq4fWTrHgPp1+sXx4mhL6OOA1oUONMMFdT4JoNEEznzWS168D4Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7SPR01MB0005
Archived-At: 
Subject: Re: [Sidrops] ADOPTION: draft-sidrops-bruijnzeels-deprecate-rsync (Ends 2020/27/5)
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, 07 May 2020 09:58:27 -0000

T24gV2VkLCAyMDIwLTA1LTA2IGF0IDIyOjMzICswMDAwLCBDaHJpcyBNb3Jyb3cgd3JvdGU6DQo+
IEhvd2R5IFdHIEZvbGtzISAgQ2FuIHdlIHBsZWFzZSByZWFkL2NvbnNpZGVyIGFuZCB0aGluayBi
YWNrIHRvIG91cg0KPiByb2J1c3QgY29udmVyc2F0aW9uIGF0IHRoZSBpbnRlcmltIG1lZXRpbmcg
OikgYWJvdXQ6DQo+IA0KPiAgIGRyYWZ0LXNpZHJvcHMtYnJ1aWpuemVlbHMtZGVwcmVjYXRlLXJz
eW5jDQo+ICAgDQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zaWRyb3BzLWJy
dWlqbnplZWxzLWRlcHJlY2F0ZS1yc3luYy0wMQ0KPiANCj4gYW5kIGNvbnNpZGVyIHdoZXRoZXIg
b3Igbm90IHdlIHNob3VsZCBhZG9wdCB0aGlzIGRyYWZ0IGFzIGEgd29ya2luZy0NCj4gZ3JvdXAN
Cj4gd29yayBpdGVtPyBXZSBzaGFsbCBlbmRlYXZvciB0byBjbG9zZSBvdXQgdGhpcyBhZG9wdGlv
biBjYWxsIDI3IE1heQ0KPiAyMDIwLg0KPiANClN1cHBvcnQgYWRvcHRpb24NCg0KQ2hlZXJzLA0K
DQpCZW4NCg0K


From nobody Thu May  7 03:40:10 2020
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 C5F473A0B7E for ; Thu,  7 May 2020 03:40:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 kJpvZFHVDjM6 for ; Thu,  7 May 2020 03:40:07 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.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 A2E653A0B7F for ; Thu,  7 May 2020 03:40:07 -0700 (PDT)
Received: from [IPv6:2001:981:4b52:1:1cf9:f327:7f8b:f81b] (unknown [IPv6:2001:981:4b52:1:1cf9:f327:7f8b:f81b]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 4D1AF2D32A; Thu,  7 May 2020 12:40:05 +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=1588848005; bh=BaeuJgVJRZD+VrE/+mpuD66qXpWghnj4TMCfAvh+iS8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=pPHRgeyXCf8dEb0Gq+7AUpNyrm/y/7xwhwbAifWNuODJsaF01kSzk7+SZRUfdbUxj P6wT/ezXlQEaN/SMjwZBd4tsP0ismELxmgpyFf792s5xsmGk/D2q8syAhBKprSb011 GpE3i+qAiynw5xYbEPsP/GjhdKa2oOvNXrhgzdKU=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Tim Bruijnzeels 
In-Reply-To: <526818da-c518-52d7-f9bf-799f1eb6637e@verizon.net>
Date: Thu, 7 May 2020 12:40:04 +0200
Cc: sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8816E312-F721-48E9-A025-C3409CCE27A3@nlnetlabs.nl>
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net> <20200505121353.GB93200@vurt.meerval.net> <526818da-c518-52d7-f9bf-799f1eb6637e@verizon.net>
To: Stephen Kent 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [Sidrops] proposed, revised text for Section 6
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, 07 May 2020 10:40:09 -0000

Hi Steve, all,

> On 5 May 2020, at 22:09, Stephen Kent =
 wrote:
>=20
>>> 6.5. Mismatch between Manifest and Publication Point
>>>=20
>>> If there exist valid signed objects associated with a CA instance =
and
>>> they do not appear in any current, valid manifest for this CA
>>> instance, these objects MUST be ignored by an RP, and a warning MUST
>>> be issued.
>> Are we sure about the above? The above approach would preclude us =
from
>> using the current valid manifest to determine which .roa files should =
be
>> deleted from the local system, right?
> I'm not an implementer, but can't one delete cached roa files based on =
them not appearing in the current, valid manifest?

We may be intending the same thing here. Generally speaking I am in =
favour of not deleting any objects because of rsync --delete, or updates =
/ withdraws in RRDP only. So add things only, and delete them when you =
have seen a signed statement that the objects are no longer relevant.

The repository server is essentially untrusted by the RP, or should be! =
Definitely when using rsync, but RRDP with self-signed HTTPS is also =
highly questionable. Changing RRDP to say that TLS Verification MUST be =
done can help a bit, but even then there are issues with web TAs, and it =
could be that the repository server itself is compromised.

But details around this can be complicated. I don't think that we can =
specify one way to do deal with this that will be acceptable to all RP =
implementation. There is more than one way to do it, and therefore it =
may be better to specify the boundaries of what an RP MAY or MAY NOT do =
regarding caching.

I think the following consideration should be kept in mind:

1) stale/expired mft

Do NOT just delete things because the CA did not issue / you did not see =
a new current MFT. Only delete if you see a new current MFT that =
confirms that something is no longer relevant.

2) poisoning

Be careful if you rely on the SHA256 hashes only. I could include your =
object on my MFT and then remove it in an update. This should not remove =
your object from the cache.

3) key rolls

New keys may publish updated delegated .cer files under the same name. =
Be careful when just relying on the URIs.

4) require confirmation: rsync delete / RRDP update/withdraw?

If delegated .cer files are removed, should their content also be =
removed? Maybe. But what if this is a temporary issue at the parent? The =
child would not typically re-publish things. You will not see a new =
delta.

There is something to be said for deleting objects only if they are =
removed at the repository *AND* they are actively removed by a new =
manifest.

I have some ideas about how I would make this work if I were to =
implement something, but I do not presume that that would be the only or =
best way.

Note that different implementations regarding this will lead to =
differences in the availability of cached objects. But they would not =
lead to different validation outcomes based on the same set of objects.


Tim


From nobody Thu May  7 08:38:29 2020
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 F34BA3A0A09 for ; Thu,  7 May 2020 08:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbgrEu8ZS0HH for ; Thu,  7 May 2020 08:38:26 -0700 (PDT)
Received: from sonic314-13.consmr.mail.bf2.yahoo.com (sonic314-13.consmr.mail.bf2.yahoo.com [74.6.132.123]) (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 5D2CF3A0A07 for ; Thu,  7 May 2020 08:38:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1588865905; bh=wZGqEVtcZRACq/R6xhk1jdYZWPixxpJ4Ym6Ud/0pV7I=;  h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject;  b=Y8KQGRkG9Yv43pY+CamH9+nzWIHBTxlQEf1os5MZhlXcCFgB4zwMsvE/2R59mpC7G1MvQnZ4+zGJupFM1j89z6VoE6mEPw9IxLbecni9NATj0rsbsTZmaWysmiQ9FniC5CuQr4imC21dC7mhpnCyP8hJHlAWdn82sSSAEuVYCUUTnq4jQStjuP+5HTVHQpkTiwrmCM1AsKcE/5gO4diIJK6bZrOssoL+BJLiy3pMowvbzCP8Jq4QnD2/9Az9x9VPhVLMxm5WI0TCTiQg26tVq2QgdDFhhmD+mfwdVN//PyUk3twwDIHqLweE9+6so08ZMQwD371vxT0+9GfftZZDrA==
X-YMail-OSG: dZWHeCQVM1m.J.GwO6OGLfIfIIN2fpvzcvOuvDdTnH_mUF0J1ahEWHF7ZxiwoMy i0cL80LaamtIKGVhBQDxLbYHqlk6DyK1YCDfYV9SppuTUQ.RGoCGJ76V187RP_Mqx7M1V_psSsOg DeRd7fR5etbzS4DcvZ1lukctiQTcO9.czeLqQxjxcW0XCkfD3dahGOqSP2.OvwlYzg739BUFxxtY B_NnzEPyKQm3IfOpKCiWCbUzzFyn86mEMfc8IVCtyLW7qqzZ8WXSkBLavS2aaRKpBcMXj.JJ2ZhJ Ws7CdljwBVvHeYaLqZXAJL846ew8hn6RXm6IzKzv2Gixn6JCpDW6DqIx4DYyoU1w89L_tqU78XEk q0B.ZS3PrxuYhMWommJyVNYCDlg54mmr6eC7bc6vJR1O9lxjQyCkouZJDJCsR7PveE4.vPM_IL9g InyvwjMLaunCXogEaQwG8TLU4VEX_7P53TQZN72jTanfuUmS43OwlQm4euh466PjGqqCnFusBNd4 5KnqOoqmsPZryrXC6fO0Qk39_Ij56kvrkt_Y9Cgaf14BqgNIZKs5JhTSSYDSXdU7SyEmRpHeVwT0 g5buYBEqdd7_mgPKXtYnkGR4eNLi5iDpCxEJmPo8EU4vjz2v3Tpcs.5b94fgvbfCFhfL7O.BIDyS 5KrZsgCgaCaaMeydAaopLQLfXTuwA0BT4rKEF038F_F_ZIA5NBHUYXeAzm8hHoqecpptgNgvwgTt Paif8Sj..tHKDUBW8Hi1dQUIzdn8TeZfBKeH_qHfANlRmu0brotHSupgTiRg9AYGFnTy7qXrJach zoXg9VolPTTbjylC3iqa5JknHpnapHwI_hJUqJAxi5gmfjQDpCvzGzDYWHko1gLWZ.DX1VK3w6IW xSj5aZwezIrWxC2P5uP.2gU9rQeXzJBgLtrSHItcKrpnOIco7_lG1cRe3yTmh1k79XFun0lxnak6 HWeDRCSVLWZG9at7pS4uyS.N.Xl0VlPEFjpcQOpPRdcFefKggqI.w6NVymPRNSjW895y5_FbV4lH hdfdGJ27H2HxiCffnByL4_eWc.10brgdEBiDD8Qj5lQ30Vw1JTFKPxlNKo1pAtrGU8xo6DQnhZck 0q2UV7xZu1sfOOcCogDkQyuTH3yiEJlqQeq1hJi0uZ6M4Tfc_QRmfbs16NiB.mbKnGcKhIJ7xRQT lezg.jpxUNJAbeNL9h_SBs1gOqHHBlyX4k92WeyWCxI_pPFWFQ6Y9hDJ3DeeRDdo3sSWPEg7s9sJ XtKVy28J2K6zwkSaQrMIpvTmEgUMiHZgVjL.bM7UDRogTZzO_TCJv_xUH511DnC7HD7hHTxYF7fI KfQdrjtkF.wadeOEoH8g4h6.INDtREdElaGqHkC7s9KmkOfcRk1_Hcfj0yjrFkeiwYUFgV09_.kn uBMV0HrI-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Thu, 7 May 2020 15:38:25 +0000
Received: by smtp425.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 57b79290b34f9850e15154201c256a31;  Thu, 07 May 2020 15:38:22 +0000 (UTC)
To: Tim Bruijnzeels 
Cc: Oleg Muravskiy , "sidrops@ietf.org" 
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net> <1065C1CC-191A-4CFF-A87C-4F1CB165F303@ripe.net> <507640b8-30e7-9f95-e6ed-adba12efb090@verizon.net> <7A134E0C-52E1-4FAD-A4E6-D971EFCDC63E@nlnetlabs.nl>
From: Stephen Kent 
Message-ID: 
Date: Thu, 7 May 2020 11:38:21 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <7A134E0C-52E1-4FAD-A4E6-D971EFCDC63E@nlnetlabs.nl>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] proposed, revised text for Section 6
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, 07 May 2020 15:38:28 -0000

Tim,

> ...
> I agree.
>
> I think all CA implementations already do the following, which is implied by RFC 6487 and 6481 in particular. But the text is not sufficiently explicit. Updates will help, especially RP software.
>
> * There is only ever one (1!) *current* CA certificate issued for a given key (implied by RFC6492)
> * This CA certificate has the following SIA entries:
>      - id-ad-caRepository pointing to its full publication point
>      - id-ad-rpkiManifest pointing to a manifest in that publication point
>      - (still optionally) id-ad-rpkiNotify pointing to the RRDP (RFC 8182) notification file
>
> * For a CA certificate (i.e. a single key) there will be ONE current MFT only
> * For a CA certificate (i.e. a single key) there will be ONE current CRL only
> * That CRL name and hash MUST match the one and only .crl file on the MFT
> * Any issued (EE or CA) certificate under this CA certificate (single key) MUST use a CRLDP that matches the name of this .crl file, under the issuing CA certificate's id-ad-caRepository

This all sounds appropriate to me. I can state these assumptions in the 
intro for Section 6.

What do we want to do if we encounter two or more .crl files in a 
manifest? use the first one, ignore any others, and issue a warning?

What do we want to do if the CRLDP in a CA cert does not match the file 
name in the manifest? Issue a warning and use the .crl file from the 
manifest?

Steve



From nobody Thu May  7 08:38:35 2020
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 3A86B3A0A07 for ; Thu,  7 May 2020 08:38:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17mCEkau6xFB for ; Thu,  7 May 2020 08:38:26 -0700 (PDT)
Received: from sonic314-13.consmr.mail.bf2.yahoo.com (sonic314-13.consmr.mail.bf2.yahoo.com [74.6.132.123]) (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 9136D3A0A08 for ; Thu,  7 May 2020 08:38:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1588865905; bh=wZGqEVtcZRACq/R6xhk1jdYZWPixxpJ4Ym6Ud/0pV7I=;  h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject;  b=Y8KQGRkG9Yv43pY+CamH9+nzWIHBTxlQEf1os5MZhlXcCFgB4zwMsvE/2R59mpC7G1MvQnZ4+zGJupFM1j89z6VoE6mEPw9IxLbecni9NATj0rsbsTZmaWysmiQ9FniC5CuQr4imC21dC7mhpnCyP8hJHlAWdn82sSSAEuVYCUUTnq4jQStjuP+5HTVHQpkTiwrmCM1AsKcE/5gO4diIJK6bZrOssoL+BJLiy3pMowvbzCP8Jq4QnD2/9Az9x9VPhVLMxm5WI0TCTiQg26tVq2QgdDFhhmD+mfwdVN//PyUk3twwDIHqLweE9+6so08ZMQwD371vxT0+9GfftZZDrA==
X-YMail-OSG: dZWHeCQVM1m.J.GwO6OGLfIfIIN2fpvzcvOuvDdTnH_mUF0J1ahEWHF7ZxiwoMy i0cL80LaamtIKGVhBQDxLbYHqlk6DyK1YCDfYV9SppuTUQ.RGoCGJ76V187RP_Mqx7M1V_psSsOg DeRd7fR5etbzS4DcvZ1lukctiQTcO9.czeLqQxjxcW0XCkfD3dahGOqSP2.OvwlYzg739BUFxxtY B_NnzEPyKQm3IfOpKCiWCbUzzFyn86mEMfc8IVCtyLW7qqzZ8WXSkBLavS2aaRKpBcMXj.JJ2ZhJ Ws7CdljwBVvHeYaLqZXAJL846ew8hn6RXm6IzKzv2Gixn6JCpDW6DqIx4DYyoU1w89L_tqU78XEk q0B.ZS3PrxuYhMWommJyVNYCDlg54mmr6eC7bc6vJR1O9lxjQyCkouZJDJCsR7PveE4.vPM_IL9g InyvwjMLaunCXogEaQwG8TLU4VEX_7P53TQZN72jTanfuUmS43OwlQm4euh466PjGqqCnFusBNd4 5KnqOoqmsPZryrXC6fO0Qk39_Ij56kvrkt_Y9Cgaf14BqgNIZKs5JhTSSYDSXdU7SyEmRpHeVwT0 g5buYBEqdd7_mgPKXtYnkGR4eNLi5iDpCxEJmPo8EU4vjz2v3Tpcs.5b94fgvbfCFhfL7O.BIDyS 5KrZsgCgaCaaMeydAaopLQLfXTuwA0BT4rKEF038F_F_ZIA5NBHUYXeAzm8hHoqecpptgNgvwgTt Paif8Sj..tHKDUBW8Hi1dQUIzdn8TeZfBKeH_qHfANlRmu0brotHSupgTiRg9AYGFnTy7qXrJach zoXg9VolPTTbjylC3iqa5JknHpnapHwI_hJUqJAxi5gmfjQDpCvzGzDYWHko1gLWZ.DX1VK3w6IW xSj5aZwezIrWxC2P5uP.2gU9rQeXzJBgLtrSHItcKrpnOIco7_lG1cRe3yTmh1k79XFun0lxnak6 HWeDRCSVLWZG9at7pS4uyS.N.Xl0VlPEFjpcQOpPRdcFefKggqI.w6NVymPRNSjW895y5_FbV4lH hdfdGJ27H2HxiCffnByL4_eWc.10brgdEBiDD8Qj5lQ30Vw1JTFKPxlNKo1pAtrGU8xo6DQnhZck 0q2UV7xZu1sfOOcCogDkQyuTH3yiEJlqQeq1hJi0uZ6M4Tfc_QRmfbs16NiB.mbKnGcKhIJ7xRQT lezg.jpxUNJAbeNL9h_SBs1gOqHHBlyX4k92WeyWCxI_pPFWFQ6Y9hDJ3DeeRDdo3sSWPEg7s9sJ XtKVy28J2K6zwkSaQrMIpvTmEgUMiHZgVjL.bM7UDRogTZzO_TCJv_xUH511DnC7HD7hHTxYF7fI KfQdrjtkF.wadeOEoH8g4h6.INDtREdElaGqHkC7s9KmkOfcRk1_Hcfj0yjrFkeiwYUFgV09_.kn uBMV0HrI-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Thu, 7 May 2020 15:38:25 +0000
Received: by smtp425.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 57b79290b34f9850e15154201c256a31;  Thu, 07 May 2020 15:38:22 +0000 (UTC)
To: Tim Bruijnzeels 
Cc: Oleg Muravskiy , "sidrops@ietf.org" 
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net> <1065C1CC-191A-4CFF-A87C-4F1CB165F303@ripe.net> <507640b8-30e7-9f95-e6ed-adba12efb090@verizon.net> <7A134E0C-52E1-4FAD-A4E6-D971EFCDC63E@nlnetlabs.nl>
From: Stephen Kent 
Message-ID: 
Date: Thu, 7 May 2020 11:38:21 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <7A134E0C-52E1-4FAD-A4E6-D971EFCDC63E@nlnetlabs.nl>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] proposed, revised text for Section 6
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, 07 May 2020 15:38:28 -0000

Tim,

> ...
> I agree.
>
> I think all CA implementations already do the following, which is implied by RFC 6487 and 6481 in particular. But the text is not sufficiently explicit. Updates will help, especially RP software.
>
> * There is only ever one (1!) *current* CA certificate issued for a given key (implied by RFC6492)
> * This CA certificate has the following SIA entries:
>      - id-ad-caRepository pointing to its full publication point
>      - id-ad-rpkiManifest pointing to a manifest in that publication point
>      - (still optionally) id-ad-rpkiNotify pointing to the RRDP (RFC 8182) notification file
>
> * For a CA certificate (i.e. a single key) there will be ONE current MFT only
> * For a CA certificate (i.e. a single key) there will be ONE current CRL only
> * That CRL name and hash MUST match the one and only .crl file on the MFT
> * Any issued (EE or CA) certificate under this CA certificate (single key) MUST use a CRLDP that matches the name of this .crl file, under the issuing CA certificate's id-ad-caRepository

This all sounds appropriate to me. I can state these assumptions in the 
intro for Section 6.

What do we want to do if we encounter two or more .crl files in a 
manifest? use the first one, ignore any others, and issue a warning?

What do we want to do if the CRLDP in a CA cert does not match the file 
name in the manifest? Issue a warning and use the .crl file from the 
manifest?

Steve



From nobody Thu May  7 08:46:22 2020
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 38C3D3A0A4D for ; Thu,  7 May 2020 08:46:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhwjssyXOzkC for ; Thu,  7 May 2020 08:46:02 -0700 (PDT)
Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (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 097463A0764 for ; Thu,  7 May 2020 08:45:56 -0700 (PDT)
Received: by mail-wm1-f53.google.com with SMTP id 188so7086725wmc.2 for ; Thu, 07 May 2020 08:45:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=axRkW5UMKHB7WyPyPErnLHRa2r3TcY1A2IxmS6TKDl8=; b=pbp+0hMDAwhmalecnYSJLHcYaGzOr7v/7rziqmfacRNtOgExh6Psyf6rixoAbZP3Kp LQ94c7TE86ThRTes9mdHj8wDU/4xxvqckqWvDwvCd9hX1LGmQbOnI644iNng+9tvb6zZ edGI8b1Y7YeVr5ramGTZjAUzriAAO4t8+VgluTN9rP7tvZglEaATwtJ7Fkahs07z5M69 bU7WA1/RVU+WmwqfcIn9gnOJfjmklzv4Bd4L4oqAjkeIAlmgxBqfOpthmLy4DvBEA8gR +h7ZyR9wlRqaoRgyQ6njKNCesmNd1FxFpfUZp5JSGvvLZ5olOYBfFwzoKP0eCrmRCOdb mY6Q==
X-Gm-Message-State: AGi0PuaoZwd4ZvpgOAnoAOU43ibJnrt0uHHcTJi/gqEyKOSejwEFn2D9 HiPvdetb/0wq7yeVlORUafB83g==
X-Google-Smtp-Source: APiQypILnLZlx6JPoc3WrO+Dc+oYzZKf4VfueNgoeQXM8yU6uyG/Csb+83ZraOevv/PZibyfSouKSw==
X-Received: by 2002:a1c:6402:: with SMTP id y2mr11181111wmb.116.1588866354591;  Thu, 07 May 2020 08:45:54 -0700 (PDT)
Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id h6sm8437839wmf.31.2020.05.07.08.45.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 May 2020 08:45:53 -0700 (PDT)
Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id b4999502; Thu, 7 May 2020 15:45:53 +0000 (UTC)
Date: Thu, 7 May 2020 15:45:52 +0000
From: Job Snijders 
To: sidrops@ietf.org
Message-ID: <20200507154552.GD72636@vurt.meerval.net>
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net> <1065C1CC-191A-4CFF-A87C-4F1CB165F303@ripe.net> <507640b8-30e7-9f95-e6ed-adba12efb090@verizon.net> <7A134E0C-52E1-4FAD-A4E6-D971EFCDC63E@nlnetlabs.nl> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: 
Subject: Re: [Sidrops] proposed, revised text for Section 6
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, 07 May 2020 15:46:14 -0000

On Thu, May 07, 2020 at 11:38:21AM -0400, Stephen Kent wrote:
> What do we want to do if we encounter two or more .crl files in a
> manifest?  use the first one, ignore any others, and issue a warning?

Which one is the first one? The fileList is an (unordered) sequence of
FileAndHash objects, right?

Shouldn't standard X509 be followed here? Only use the CRL that the .cer
points to? I was under the impression that the CRL exists as part of the
X509 validation, rather than as part of the 'RPKI validation overlay'?

> What do we want to do if the CRLDP in a CA cert does not match the
> file name in the manifest? Issue a warning and use the .crl file from
> the manifest?

The latter option seems counter-intuitive to me.

Kind regards,

Job


From nobody Thu May  7 10:30:55 2020
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 815F93A0AFA for ; Thu,  7 May 2020 10:30:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjpzIjlz_Kft for ; Thu,  7 May 2020 10:30:50 -0700 (PDT)
Received: from sonic310-14.consmr.mail.bf2.yahoo.com (sonic310-14.consmr.mail.bf2.yahoo.com [74.6.135.124]) (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 E4AF73A0C40 for ; Thu,  7 May 2020 10:30:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1588872635; bh=snxra/TuJ00LWwONV9PtAPlg+ac/su4XGHquIU3r6KI=;  h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=INI3OGvm3RvchkHHhC8NYIj7nqQySth11yP6VoJoGrjcQPyJUEubmFIY962neMCg3AO3C+0ME2dfF7weMDKv5t1tKX0/Ui/sm3TW7iPrswAa0+P5WM18usOUORZwbCWJ1SJepSnGuSg0zdBNRGh3ZCYN+nCa0v9JMWc3dVMdLZYpNxmVRbm3P2loQiF9ATzUt/MjYB/8J8I9yLCifsD4+7v7f1qoCweQPCmqVaZn+K/qnm2D/B+aL8ylbpjtk4IDN04Mn96Yab/aJ4vDHiUJMScE3rVeG29smjW+5854vVSgDxh4SyMPJTw/X+eCWCfhfRaRxJxGn0u+d3RYnSSQ5g==
X-YMail-OSG: cd80R6EVM1nWJT2FXFH69sbhOr1FAoATdIVqmsffSHBgz0jF1tLR9lqqPweqmU1 xc6b730Nt5zlMFHbJOE1N_dV.SxzQz0xRcmt2oLw0TdolP6O2KD0WVquLcvTBwNeQxHp78bk0McT KxnyU5i0jiXqV9x55qi2RWPFIDsDP9XqRyAOj5D7Ex_fTO7SD.Jz4OziEH_wAIOErTbkrNmk4exu N_4vTYjD7pmYmpzPAGRVXs7QFtxc_CJvw9MUCPVvW_qpTM0FBUSkZCcGrWTG75.I9Ar775IyJh.p .js_zG02nIrI87OJJ7kZzbHF6Zb7TCTioxKQEAMc8dof0fWyDrWAZgYUi84a.jmTiyLjfqlE.6BW IoWiKwxXwkU82q7DM68GeBgVDoXm7LlBs2q139tEA.NhiTC6GH_9Bcp8JK6paI_Ig8x2aY..2IeS yoQEeI2HTVV7TKMDpyPM22cnlhmxaIuStOu.ooW8c46llgMX6xnpsIhjV26KhROVzUYoNKCT9rOg SvmPynRDQk1RWXCLClAxzlNlg7d40CyY11.2CtuIX4sMP.D4HUMJ1zQ.JT.3pJIgOiY5w..VNfsu dClxW8kFBGHepNyHxpZuVNdgbvn_o9PoWmabignig3XxC0NQEHPrLLgze.3ozAb_RUwyvizlCUWm TeSEtiyHwVOqQ5sSt5y3pKHUKWVlN7vFXokr8GfbSNGNdKsDURWZaG..rXbWifr4kJIJiuyT0wrk vJ7a0DPH97c1Yb.r1iUhQv2LDVMXQGg_CQ50P9A30.bTH635OJ5p3ekhCHNoQEVWWfjPieNjvJyx PaW7yrnGiFsXD_xZ2h.hZDrwVer4JTIEip30yIawOV9lBzlrPDh1evF6qgoJzZai6FAF0jIXOMjn LZJBvbbSbAW2ZoqlRM5o7eWl1N820Grpow0xEILw_CwY.IFA.iDbnzXWRbYUlPzx0hADMgbd8NTE scpfCbc1djfdJFUxqkRv4X5On8uGf8Hua2yu3dPH_j2ugDtabRDzijJV0zbDfXReVltBodWTOiEz det9aNwwp6z_yPH4F6fWYkQsAYKdTqIbreBQ7soem7tfLz4poPANb0lm1xvbkXpHuRP81wBd6xLg b8IQlwCb3HZXJXrSWvzoD9vRSgGk38PmUr2mHVDUpQpheb4Pzheewqm1Saofl88QhlQmPcy5BJk5 R_5OyTLvokBZy6C4zBtO31WjXP2a_9SN_DkdoNCPSAUYM9PCHm5AWcDBxLS8JJ.5xBCjfaMdwClt YZ5pGdaxiEXpm_qDaoxZf7XkWzaCD9DOlIA6vh.e8Mh_BH1aM3gvO6ctxYIrFU54tU1dhTFRK.BP 2FCapxpumuZbXQx8JfGY2Znlgq4BM0WtOLSFGpJlIa6EOSMmR1TcQc1kdFV7t8zpfQtTFhJNv
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Thu, 7 May 2020 17:30:35 +0000
Received: by smtp402.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 219d55b25d0b5661cf23e51766119709;  Thu, 07 May 2020 17:30:32 +0000 (UTC)
To: sidrops@ietf.org
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net> <1065C1CC-191A-4CFF-A87C-4F1CB165F303@ripe.net> <507640b8-30e7-9f95-e6ed-adba12efb090@verizon.net> <7A134E0C-52E1-4FAD-A4E6-D971EFCDC63E@nlnetlabs.nl>  <20200507154552.GD72636@vurt.meerval.net>
From: Stephen Kent 
Message-ID: <3493e056-c5cf-3e66-b141-03ad24eb0e43@verizon.net>
Date: Thu, 7 May 2020 13:30:31 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <20200507154552.GD72636@vurt.meerval.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] proposed, revised text for Section 6
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, 07 May 2020 17:30:53 -0000

Job,
> On Thu, May 07, 2020 at 11:38:21AM -0400, Stephen Kent wrote:
>> What do we want to do if we encounter two or more .crl files in a
>> manifest?  use the first one, ignore any others, and issue a warning?
> Which one is the first one? The fileList is an (unordered) sequence of
> FileAndHash objects, right?

The ASN.1 for fileList is a SEQUENCE. In ASN.1 terms, this means it is 
ordered. A SET is used to represent an unordered collection of data 
items. So there is no ambiguity about ordering of files here.

> Shouldn't standard X509 be followed here? Only use the CRL that the .cer
> points to? I was under the impression that the CRL exists as part of the
> X509 validation, rather than as part of the 'RPKI validation overlay'?

This document focuses on how to use a manifest to decide which files at 
a pub point are to be processed, which is why I thought about the issue 
of multiple CRLs from that perspective. But, I agree that we ought to 
rely first on the CRL identified by the the CRLDP in the CA cert, and 
then confirm that the manifest includes that file. If we adopt that 
approach, the ordering or .crl files in a manifestwill not be relevant.

Steve


From nobody Thu May  7 10:52:59 2020
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 D98CE3A07F0 for ; Thu,  7 May 2020 10:52:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tss163pfigH8 for ; Thu,  7 May 2020 10:52:47 -0700 (PDT)
Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13E43A07F5 for ; Thu,  7 May 2020 10:52:38 -0700 (PDT)
Received: from allealle.ripe.net ([193.0.23.12]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jWkhJ-0002ul-9L; Thu, 07 May 2020 19:52:37 +0200
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::7a5]) by allealle.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jWkhJ-0004UV-50; Thu, 07 May 2020 19:52:37 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Oleg Muravskiy 
In-Reply-To: 
Date: Thu, 7 May 2020 19:52:36 +0200
Cc: Tim Bruijnzeels , "sidrops@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <02AD118C-6267-4C83-8252-1DD710D4C4AA@ripe.net>
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net> <1065C1CC-191A-4CFF-A87C-4F1CB165F303@ripe.net> <507640b8-30e7-9f95-e6ed-adba12efb090@verizon.net> <7A134E0C-52E1-4FAD-A4E6-D971EFCDC63E@nlnetlabs.nl> 
To: Stephen Kent 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-ACL-Warn: Delaying message
X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b74e9b870784b87d0c14b36b130be2cb445
Archived-At: 
Subject: Re: [Sidrops] proposed, revised text for Section 6
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, 07 May 2020 17:52:49 -0000

Steve,

> On 7 May 2020, at 17:38, Stephen Kent  wrote:
>=20
> Tim,
>=20
>> ...
>> I agree.
>>=20
>> I think all CA implementations already do the following, which is =
implied by RFC 6487 and 6481 in particular. But the text is not =
sufficiently explicit. Updates will help, especially RP software.
>>=20
>> * There is only ever one (1!) *current* CA certificate issued for a =
given key (implied by RFC6492)
>> * This CA certificate has the following SIA entries:
>>     - id-ad-caRepository pointing to its full publication point
>>     - id-ad-rpkiManifest pointing to a manifest in that publication =
point
>>     - (still optionally) id-ad-rpkiNotify pointing to the RRDP (RFC =
8182) notification file
>>=20
>> * For a CA certificate (i.e. a single key) there will be ONE current =
MFT only
>> * For a CA certificate (i.e. a single key) there will be ONE current =
CRL only
>> * That CRL name and hash MUST match the one and only .crl file on the =
MFT
>> * Any issued (EE or CA) certificate under this CA certificate (single =
key) MUST use a CRLDP that matches the name of this .crl file, under the =
issuing CA certificate's id-ad-caRepository
>=20
> This all sounds appropriate to me. I can state these assumptions in =
the intro for Section 6.

I like this as well.

> What do we want to do if we encounter two or more .crl files in a =
manifest? use the first one, ignore any others, and issue a warning?
>=20
> What do we want to do if the CRLDP in a CA cert does not match the =
file name in the manifest? Issue a warning and use the .crl file from =
the manifest?

I would suggest that we only use a CRL that is on a manifest AND matches =
the CRLDP in a CA cert (and all the above conditions that Tim mentioned =
are also true). If there are also other CRLs in the manifest, we ignore =
them with a warning. =20

If there are CRLs in the manifest, but none matches the CRLDP, we =
continue as if there is no valid CRL (so follow rules of section 6.1 of =
your revised text).

Oleg


From nobody Thu May  7 10:57:52 2020
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 3E7033A0866 for ; Thu,  7 May 2020 10:57:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5-ihKYKMFpi for ; Thu,  7 May 2020 10:57:47 -0700 (PDT)
Received: from sonic302-3.consmr.mail.bf2.yahoo.com (sonic302-3.consmr.mail.bf2.yahoo.com [74.6.135.42]) (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 BC9AC3A0826 for ; Thu,  7 May 2020 10:57:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1588874265; bh=YuxVvvlm3VyYX5a00AIwfNKCcm0BF8GoFkR2MtXYY7U=;  h=To:From:Subject:Date:References:From:Subject; b=GmrxqxdCWAW8bxS9PaqWBqZ6etMVxU+mdZE7qwJZUhuDViU3QCVOhqqFIWG7IxYlvcZQBBbAgxAvIpJ6TPtXycCbfL/ysahprZ/FIq64HKX8M5qhePJEGmpZG8EVBeGmKlTOoHIXvsqwdnkRvN/8f/Um9kbLgnPbDFWj0rqmlTlRiN9/ZASQnI3oslyZQXeLb9cBnsAcOoz5CiW6dKXSODd9EkBEBlvHW5xijnQYj0UAfxXh4oOt4REPu9T9MugSJc+PYJ2NX/Cp0qec5pNY9/KxLPuP9C7G4W4EQYZJC/lhR2AcnBzw0oHezvClT9WDUcsXSoS4toDAHmsAQCHdcg==
X-YMail-OSG: o7PBcA0VM1l.wQpg.c2OxW2wtSaPsBRUMnUfgISrfwW1UX6mFrfJf.ZpXkyTgZf J3KwvbnKKvn4OPnCeRojQ0WZMDRo5eYonixtOh5QJpTC2_6YktnkrBD_uIDe2Uh67B1xkQNvBuko sIn19alp7ntTQ2DVFulA3FF5iDJiFOM1VFAB8hmX5r2cv2dzrNk.it12Ltt5fP8MATeT209VIOXq gO3Yon847eqPO9sjwFdt831y4jhq1n4ArzqlIj.VdOBhmNta1GUIHczGilOrJz_r_t3DVsaUBnuJ DJktBrPNAwCoevvjUl.6z7OIXekxwnRL2z2ZSPF0depsAniRcCRJp_J_clgKxEpxZgp7ObO8Yee0 PUm2PaiNDuKSJBEibQhUQ4vaPWASmM6e.gfjYUo4KbtN0rTG5TU0fU5QGOB0CmbO0jFEgkGn40Uy MJmrxF5mQEfd8utOdcWi1DyC.TscRD9Dl3k_FCPJ3k5bZhOGtL_yJBuCYRDz4gkZY79fafeC.Fe9 dn4cfET85iBHFXOu1tFNs5YiFSAjZEmWijFeE_RWNStynaW7wMA6mZhGHtQ3D0EUYfsUW0br3YHN rywnEixde2cjI1f31nkxZ.zMCbT6c3Ox7BMZa2Po.U78Ca5RUgjaLMKrZsiY.4dDpaDorohvE7T9 m1ypv5bRKOdS6hPxNGOyEJJPFdTP8sCcgPuChwbbMs0TPLJFKUqhZTUPi1_CEK6FQSNIpbF7nkVF qGj8hLvzy3dkj5BjhfJKsAjR5eP70dIRtPH9tFRz33yG6x2OwfRYJgSbAbV8uYwN182EQrOW86Q. a9FUY4SUbP829IPl4QHEMKY2YOj4lzZlWQnDHBK8ge426yYaCc9O_QSJgnrcQ9AFOGMmQorreMkn IKPMFYyp7jNHybrc2qr754Fn7HzUlgIJBmNEtyboVLBRBfybTZrQRKUl2HoV8FAozaMLx8ddhXXA 1KvdjFOWsdC0Pf75xPfpnS16RxMWvKkdIZACT93.Mp.ewSieQYFbUx9VXijzaPP.vXRypGTRg5i_ 7cpLJ2xG3byT16Hb0UXdQpUhGHA0dIb0Q4n0zpbKhE2ojSRmvUURyHpMBXeDGL1Lj40zUDffI3p_ JLF8uy4yCPrAJBAV3LGu4ncgqaLHRnspUoCRapISz4tSjpq6wisjD7th4reL_NIeeMvMD6_hUSu9 if5lALf8hHLwngttroOv5sTRuY3HtfP1kzlf1HkZv7LmJW5byr8hPFmGJkQdkM.8Vu6xRT6FUZiE hQZuPfXaE0.QuSCcY_MbqMK44_TasUPzFkRoWovMPTRhdRXfAkj845vsnBzAiXfaxpz5zhDO8651 lxiw5jaAOJuaEr096D9JUDMSqXT0okwvC826MxqC6.eS4AYHh6yXSxmkLgR7K00Ih6wN0zcntZyo WiA--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Thu, 7 May 2020 17:57:45 +0000
Received: by smtp403.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID da1142e519ef353b1b96db1895bb1b24;  Thu, 07 May 2020 17:57:40 +0000 (UTC)
To: "sidrops@ietf.org" 
From: Stephen Kent 
Message-ID: 
Date: Thu, 7 May 2020 13:57:40 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------17FE96969D2EF143C150FCBA"
Content-Language: en-US
References: 
X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: [Sidrops] revised section 6, take 2
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, 07 May 2020 17:57:50 -0000

This is a multi-part message in MIME format.
--------------17FE96969D2EF143C150FCBA
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

I revised the text at the beginning of Section 6 to omit the notion of 
"local policy". I restructured and renumbered the processing steps to be 
more comprehensive and to focus on replacing missing or damaged files 
from an RP's local cache, where this is sfaely possible. I also noted 
that the CRLDP is the authoritative pointer to the CRL for a CA, and it 
is to be used to locate that CRL. The manifest is used to ensure that 
the RP is seeing the most recent CRL. If duplicate .crl file entries 
appear in the manifest, only the one matching the CRLDP is to be used.

Steve

-----


6.Relying Party Use of Manifests

Each RP must determine which signed objects it will use for

validating assertions about INRs and their use (e.g., which ROAs to

use in the construction of route filters). Manifests are designed

to allow an RP to detect manipulation of repository data and/or

errors by a CA or repository manager. Unless _all_ of the files

enumerated in a manifest can be obtained by an RP (either from a

publication point or from a local cache), an RP MUST ignore the

data associated with the publication point. This stringent response

is needed to prevent an RP from misinterpreting data associated with

a publication point, and thus possibly treating invalid routes as

valid, or vice versa.

Note that there is a “chicken and egg” relationship between the
manifest and the CRL for a given CA instance. If the EE certificate
for the current manifest is revoked, i.e., it appears in the current CRL,

then the CA or publication point manager has made a serious error. In this

case all signed objects associated with the CA instance MUST be ignored.

Similarly, if the CRL is not listed on a valid, current manifest, all

signed objects associated with the CA instance MUST be ignored, because

the CRL is considered missing.

The primary locator for the CRL issued by a CA is the URI contained in 
the CRLDP contained in the CA’s certificate. An RP MUST use this URI to

retrieve the CRL and use that CRL to determine if the EE certificate in

the manifest is revoked. The manifest provides an RP with a means to

verify that the CRL at the indication location is current.

6.1. Manifest Processing Overview

For a given publication point, an RP MUST perform a series of tests to

determine which signed object files at the publication point are

acceptable. The tests described below are to be performed using the

manifest identified by the id-ad-rpkiManifest URI extracted from a CA 
certificate’s SIA. The files referenced by the manifest MUST be

be located at the publication point specified by the id-ad-caRepository

URI from the (same) certificate’s SIA. If the manifest and files it

references do not reside at the same publication point, an RP MUST *???*

**

A manifest SHOULD contain exactly one CRL (.crl) file and it MUST be at

the location specified in the CRLDP in the CA certificate. If more than

one .crl file appears in the manifest, only file names matching

the CRL specified by the CRLDP will be processed. If more than one .crl

entry appears in the manifest, and matches the CRLDP, the first one

encountered MUST be used. Any other .crl filesMUST be ignored and a

warning MUST be issued.

Note that, during CA key rollover [RFC6489], signed objects for two or

more different CA instances will appear at the same publication point.

Manifest processing is to be performed separately for each CA instance,

guided by the SIA id-ad-rpkiManifest URI in each CA certificate.

Note also that the processing described here will be performed using

locally cached files if an RP does not detect newer versions of the files

in the RPKI repository system.



6.2 Acquiring a Manifest for a CA

Acquire the manifest identified by the SIA id-ad-rpkiManifest URI

in the CA certificate. If an RP cannot retrieve a manifest using this

URI, or if the manifest is not valid (Section 4.4), an RP SHOULD examine

the most recent, cached manifest matching this URI. If that manifest is

current (Section 4.4) proceed to 6.3. If the publication point
does not contain a valid manifest, and the cached manifest is not current,

processing for this publication point stops and a warning MUST be issued.


6.3 Detecting Stale and or Prematurely-issued Manifests

Check that the current time (translated to UTC) is between
thisUpdate and nextUpdate. If the current time lies within this interval,

proceed to 6.4. If the current time is earlier than thisUpdate, the CA

has made an error. If the RP cache contains a current manifest, use that 
manifest instead and issue a warning. If an RP has no access to a 
current manifest, processing stops and a warning MUST be issued. If the 
current

time is later than nextUpdate, then the manifest is stale. If the RP 
cache contains a current manifest, use that manifest instead and issue a 
warning.

If no current manifest is available, processing stops and a warning MUST 
be issued.


6.4 Acquiring Files Referenced by a Manifest

Acquire all files enumerated in the manifest (fileList) from

the publication point. This includes the CRL, each object containing an

EE certificate issued by the C, and all subordinate CA and EE certificates.

If there are files listed in the manifest that cannot be retrieved from 
the publication point, or if they fail the validity tests specified in

[RFC6488], the RP SHOULD examine its cache to determine if these files

are available locally. If _all_ of the missing/invalid files are available

from the RP’s cache, i.e., each file name matches the list extracted from

the manifest, the RP SHOULD use the cached files to replace those missing

from the publication point, and proceed to 6.5. However, if _any_ of the 
missing/invalid files cannot be replaced in this fashion, then processing

stops and a warning MUST be issued.


6.5 Matching File Names and Hashes

Verify that the hash value of every file listed in the
manifest matches the value obtained by hashing the file acquired from the
publication point or local cache. If the computed hash value of a file

listed on the manifest does not match the hash value contained in the

manifest, then an RP SHOULD examine its local cache to determine if the

same file is available. The RP SHOULD use cached files to replace any

(damaged) downloaded files, so long as the hash of the cached file matches

the hash from the manifest. If _any_ of the files with hash mismatches

cannot be replaced in this fashion, then processing stops and a warning

MUST be issued. Otherwise proceed to 6.6.


6.6 Out of Scope Manifest Entries

If a current manifest contains entries for objects that are not
within the scope of the manifest (Section 2), then the out-of-scope

entries MUST be disregarded.




--------------17FE96969D2EF143C150FCBA
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    
I revised the text at the beginning of
        Section 6 to omit the notion of "local policy". I restructured
        and renumbered the processing steps to be more comprehensive and
        to focus on replacing missing or damaged files from an RP's
        local cache, where this is sfaely possible. I also noted that
        the CRLDP is the authoritative pointer to the CRL for a CA, and
        it is to be used to locate that CRL. The manifest is used to
        ensure that the RP is seeing the most recent CRL. If duplicate
        .crl file entries appear in the manifest, only the one matching
        the CRLDP is to be used.

      

    
Steve

    
-----

    


      

    

    

    
6. 
        Relying Party Use of Manifests

    
 

    
Each RP must determine
        which signed
        objects it will use for

    
validating assertions
        about INRs and
        their use (e.g., which ROAs to

    
use in the construction
        of route
        filters). Manifests are designed 

    
to allow an RP to detect
        manipulation
        of repository data and/or 

    
errors by a CA or
        repository manager.
        Unless all of the files 

    
enumerated in a manifest
        can be
        obtained by an RP (either from a 

    
publication point or
        from a local
        cache), an RP MUST ignore the

    
data associated with the
        publication
        point. This stringent response

    
is needed to prevent an
        RP from
        misinterpreting data associated with

    
a publication point, and
        thus possibly
        treating invalid routes as

    
valid, or vice versa.

    
 

    
Note that there is a
        “chicken and egg”
        relationship between the 

        manifest and the CRL for a given CA instance. If the EE
        certificate 

        for the current manifest is revoked, i.e., it appears in the
        current CRL,

    
then the CA or
        publication point
        manager has made a serious error. In this 

    
case all signed objects
        associated with
        the CA instance MUST be ignored. 

    
Similarly, if the CRL is
        not listed on
        a valid, current manifest, all 

    
signed objects
        associated with the CA
        instance MUST be ignored, because 

    
the CRL is considered
        missing. 

    
 

    
The primary locator for
        the CRL issued
        by a CA is the URI contained in the CRLDP contained in the CA’s
        certificate. An
        RP MUST use this URI to 

    
retrieve the CRL and use
        that CRL to
        determine if the EE certificate in 

    
the manifest is revoked.
        The manifest
        provides an RP with a means to

    
verify that the CRL at
        the indication
        location is current.

    
 

    
 

    
6.1. Manifest Processing
        Overview

        

        For a given publication point, an RP MUST perform a series of
        tests to

    
determine which signed
        object files at
        the publication point are

    
acceptable. The tests
        described below
        are to be performed using the 

    
manifest identified by
        the id-ad-rpkiManifest
        URI extracted from a CA certificate’s SIA. The files referenced
        by the manifest
        MUST be 

    
be located at the
        publication point
        specified by the id-ad-caRepository 

    
URI from the (same)
        certificate’s SIA.
        If the manifest and files it

    
references do not reside
        at the same
        publication point, an RP MUST ???

    
 

    
A manifest SHOULD contain exactly
        one CRL (.crl)
        file and it MUST be at 

    
the location specified in the CRLDP
        in the CA
        certificate. If more than 

    
one .crl file appears in
        the manifest,
        only file names matching  

    the CRL specified by the
      CRLDP will be
      processed. If more than one .crl 

    
    
entry appears in the
        manifest, and matches the CRLDP, the first one 

      

    
encountered MUST be
        used. Any other .crl files MUST be ignored and a

    
warning MUST be
        issued.
    

    
 

    
Note that, during CA key
        rollover
        [RFC6489], signed objects for two or 

    
more different CA
        instances will appear
        at the same publication point. 

    
Manifest processing is
        to be performed
        separately for each CA instance, 

    
guided by the SIA
        id-ad-rpkiManifest
        URI in each CA certificate.

    
 

    
Note also that the
        processing described
        here will be performed using 

    
locally cached files if
        an RP does not
        detect newer versions of the files

    
in the RPKI repository
        system.

    


        

        6.2 Acquiring a Manifest for a CA

    
 

    
Acquire the manifest
        identified by the
        SIA id-ad-rpkiManifest URI

    
in the CA certificate.
        If an RP cannot
        retrieve a manifest using this 

    
URI, or if the manifest
        is not valid
        (Section 4.4), an RP SHOULD examine 

    
the most recent, cached
        manifest
        matching this URI. If that manifest is 

    
current (Section 4.4)
        proceed to 6.3. If
        the publication point 

        does not contain a valid manifest, and the cached manifest is
        not current,

    
processing for this
        publication point
        stops and a warning MUST be issued.

        

      

    


        6.3 Detecting Stale and or Prematurely-issued Manifests

    
 

    
Check that the current
        time (translated
        to UTC) is between 

        thisUpdate and nextUpdate. If the current time lies within this
        interval, 

    
proceed to 6.4. If the
        current time is
        earlier than thisUpdate, the CA 

    
has made an error. If
        the RP cache contains
        a current manifest, use that manifest instead and issue a
        warning. If an RP has
        no access to a current manifest, processing stops and a warning
        MUST be issued.
        If the current 

    
time is later than
        nextUpdate, then the
        manifest is stale. If the RP cache contains a current manifest,
        use that
        manifest instead and issue a warning.

    
If no current manifest
        is available,
        processing stops and a warning MUST be issued.

        

      

    


        6.4 Acquiring Files Referenced by a Manifest

    
 

    
Acquire all files
        enumerated in the
        manifest (fileList) from 

    
the publication point.
        This includes
        the CRL, each object containing an 

    
EE certificate issued by
        the C, and all
        subordinate CA and EE certificates. 

    
If  there are files listed in the
        manifest that cannot
        be retrieved from the publication point, or if they fail the
        validity tests
        specified in 

    
[RFC6488], the RP SHOULD
        examine its
        cache to determine if these files 

    
are available locally.
        If all of
        the missing/invalid files are available

    
from the RP’s cache,
        i.e., each file name
        matches the list extracted from 

    
the manifest, the RP
        SHOULD use the
        cached files to replace those missing 

    
from the publication
        point, and proceed
        to 6.5. However, if any of the missing/invalid files
        cannot be replaced
        in this fashion, then processing 

    
stops and a warning MUST
        be issued.

    
 

    


        6.5 Matching File Names and Hashes

    
 

    
Verify that the hash
        value of every
        file listed in the 

        manifest matches the value obtained by hashing the file acquired
        from the 

        publication point or local cache. If the computed hash value of
        a file 

    
listed on the manifest
        does not match
        the hash value contained in the 

    
manifest, then an RP
        SHOULD examine its
        local cache to determine if the

    
same file is available.
        The RP SHOULD
        use cached files to replace any 

    
(damaged) downloaded
        files, so long as
        the hash of the cached file matches 

    
the hash from the
        manifest. If any
        of the files with hash mismatches 

    
cannot be replaced in
        this fashion, then
        processing stops and a warning 

    
MUST be issued.
        Otherwise proceed to 6.6.

        

      

    


        6.6 Out of Scope Manifest Entries

    
 

    
If a current manifest
        contains entries
        for objects that are not 

        within the scope of the manifest (Section 2), then the
        out-of-scope 

    
entries MUST be
        disregarded. 

    


        

      

    

      

  


--------------17FE96969D2EF143C150FCBA--


From nobody Fri May  8 07:38:51 2020
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 4D9923A0B1C for ; Fri,  8 May 2020 07:38:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3mL37W9PNQM for ; Fri,  8 May 2020 07:38:47 -0700 (PDT)
Received: from sonic313-13.consmr.mail.bf2.yahoo.com (sonic313-13.consmr.mail.bf2.yahoo.com [74.6.133.123]) (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 A750E3A0B1B for ; Fri,  8 May 2020 07:38:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1588948725; bh=huLbNFptYu47oWzejk7egVj/1pZA6bohOKmAPbqP9J4=;  h=To:From:Subject:Date:References:From:Subject; b=pfANhyiDWee7rQUFYvOWuq7+mdhWODTHvgI6G2Ee8HeUL0Rh2RwoFzccjRRjkLLRq5heNE0wFrz6FieFzXnhBCOsSbdKkcC3KVmjnwKT3doaasZaKFmPsx1pZTA/V+2uhqVRFmgXFEVkWn+IzqIEbaZlvescr9DK063AaDFsa7UJAuDdfBR6QRU1G9omxEZIdECOJwwQRAEu3nAbgL0OOY11hTCmAYJDLfH5zpnOiN1uhErYWfo7O+L67NyD3P2dpD7JrByC0ackt3riJT6YCRgqZyDkn7jE+45dUTzp3lPDqGjnceKG+4JBfnjXSUOCKHsMB359bwEU7xR/+nj1oA==
X-YMail-OSG: iOMxyfIVM1mTUAWAwfwwT.zvXla6o7YrXAMcotJ59WkL_l2VIzN0xt.zNd7qcfi gn9kdwv_FJ8wn8eYiSqO533cPM0zmqZZFkN4jsDYk_BmCx3VtpgajFEhMKcQTwA.uB5nhpl6rIbq OXQS9cXHtwmXY7ZvGbgOMh.ZUtZEMbgdFS_oxNoQjXSFPWZ1rF2qWvNFTX_IkZI2LdCIUQO1r2SF vW1ONpuxDCb217xnLv4vFzxExGJ48FgZmJdHvYtBEa62S14JfAF6aJLns_EWb6NKHi5WHYN3y8BG wYFlEitCCfvzhajHkMWejZFJUg9QFlw2SDGABbagmCeZFj5zUhRgsoLNxzwXJYEVeFV2AG7iufzn rv82gPrFOHSsgzEIsVZBQwFUv.6nDIWh_7QuRcHiy21rmp8keotRTY57W.bOvJ4wLvgEtkGnWcEn S5mhH_s5Fw8wq06mmMjdh8GNWsCrZkLBfa9y2VDzF_iqpWFQScCS5ICIOfbtRkwHNeNx_oPsaY9T KygPuovW1CbYLCyIQr76VOVCEZbt1FMOpVFB9L5V7E3XgbBYFDG9rX6WUJ_B_gDKPpP7DmoLHgU. vzD1wSEqiPb9aQXoltEjTUdQr9BBuEYFH6_VDDlqL61iYwAF6WjnTraO_go8N1k8w.PGzIKKU6fp 4MoYN4ZgLNuEwJBoh_wp_gXF6DPaAe_UKkmFWCAL7H7UIAVornRSnkPIenSXLzCuvzl.r6cfoRUz rgEOxXPVyGiAWkV.uexmbQLPCtSwmO80URcPz2Bvb_lsEIT34CUYMaN9yduS6WblABi4fObx_Qsp XkhWJSn8WTkqbY5vhEDqJG_5vxENK2Vye1odaL1O7wv0SErPCpIu5ST9xxG7KyoGi25HQ1bVTjmJ q3dsfytRexi1moXZbSqpTpUqJvgoFXy6WumPG_b7oy5qaHelQLA2fcSpvbQzxPzWbZ_G5Z4kjYvj EJ5O8GvxC26ixbW_fU2NYGNL_dgu_cCfXF75pUQu.6lWSRXbeDHK5IAzVajY_UOg4CGFOTSvycCR 3nYrKroDm5fXr6KvKjYzUUzD..lQfZJ5BtkDWHKDre1iwoBcE985S3mgsWmK.3FXLmLsnWCzQVhi ZT5_0t8pb4Nlz1I12O0tHjm3xPr7v2No1zMvqu9eyufmgWFVdCEtE1jjEW5SuMPNsd2CX.iuHdzw SR0RTzixg6_jWnlMUsrKgqfuO4_G7hQxRkEY0o3q3NeVul7acWvQwEUn3Do65K1SIt41FTrF9bup ziuvZ3CYHqzooA7604ZA20HztkhEs7Xc3fE2mU1.Y8SbejB_zE9vpofPh7zy055yJHYkiyQTLPAt KSF1r58oBRiyl0aPETEeuZ7G44hhQht8aWUgp375M5y9T3T_Tzwqa_4E814MLsLzGDloAf4xN4Qz Htk.qRQJwQ4k5wQ6ALPxHaKI7
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Fri, 8 May 2020 14:38:45 +0000
Received: by smtp404.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4ea07566cd5ec84872f2edfe3f2e74bd;  Fri, 08 May 2020 14:38:42 +0000 (UTC)
To: "sidrops@ietf.org" 
From: Stephen Kent 
Message-ID: <75d43357-c378-c9f9-3610-84840fca8255@verizon.net>
Date: Fri, 8 May 2020 10:38:41 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------9F5EDA4898811B7F4B18B094"
Content-Language: en-US
References: <75d43357-c378-c9f9-3610-84840fca8255.ref@verizon.net>
X-Mailer: WebService/1.1.15902 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: [Sidrops] once again, with feeling ...
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, 08 May 2020 14:38:50 -0000

This is a multi-part message in MIME format.
--------------9F5EDA4898811B7F4B18B094
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

I made some more revisions, adding a paragraph to the overview, and a 
section explaining what I meant by termination of manifest processing.

have a good weekend,

Steve

-----


6.Relying Party Use of Manifests

Each RP must determine which signed objects it will use for

validating assertions about INRs and their use (e.g., which ROAs to

use in the construction of route filters). Manifests are designed

to allow an RP to detect manipulation of repository data and/or

errors by a CA or repository manager. Unless _all_ of the files

enumerated in a manifest can be obtained by an RP (either from a

publication point or from a local cache), an RP MUST ignore the

data associated with the publication point. This stringent response

is needed to prevent an RP from misinterpreting data associated with

a publication point, and thus possibly treating invalid routes as

valid, or vice versa.

The processing described below is designed to cause all RPs with

access to the same local cache and RPKI repository data to achieve

the same results with regard to validation of RPKI data. However, in

operation, different RPs will access repositories at different times,

and some RPs may experience local cache failures, so there is no

guarantee that all RPs will achieve the same results with regard to

validation of RPKI data

Note that there is a “chicken and egg” relationship between the
manifest and the CRL for a given CA instance. If the EE certificate
for the current manifest is revoked, i.e., it appears in the current CRL,

then the CA or publication point manager has made a serious error. In this

case all signed objects associated with the CA instance MUST be ignored.

Similarly, if the CRL is not listed on a valid, current manifest, all

signed objects associated with the CA instance MUST be ignored, because

the CRL is considered missing.

The primary locator for the CRL issued by a CA is the URI contained in 
the CRLDP contained in the CA’s certificate. An RP MUST use this URI to

retrieve the CRL and use that CRL to determine if the EE certificate in

the manifest is revoked. The manifest provides an RP with a means to

verify that the CRL at the indication location is current.

6.1. Manifest Processing Overview

For a given publication point, an RP MUST perform a series of tests to

determine which signed object files at the publication point are

acceptable. The tests described below are to be performed using the

manifest identified by the id-ad-rpkiManifest URI extracted from a CA 
certificate’s SIA. The files referenced by the manifest MUST be

be located at the publication point specified by the id-ad-caRepository

URI from the (same) certificate’s SIA. If the manifest and files it

references do not reside at the same publication point, an RP MUST *???*

**

A manifest SHOULD contain exactly one CRL (.crl) file and it MUST be at

the location specified in the CRLDP in the CA certificate. If more than

one .crl file appears in the manifest, only file names matching the CRL 
specified by the CRLDP will be processed. If more than one .crl entry

appears in the manifest, and matches the CRLDP, the first one encountered

MUST be used. Any other .crl files MUST be ignored and a warning MUST be 
issued.

Note that, during CA key rollover [RFC6489], signed objects for two or

more different CA instances will appear at the same publication point.

Manifest processing is to be performed separately for each CA instance,

guided by the SIA id-ad-rpkiManifest URI in each CA certificate.

Note also that the processing described here will be performed using

locally cached files if an RP does not detect newer versions of the files

in the RPKI repository system.



6.2 Acquiring a Manifest for a CA

Acquire the manifest identified by the SIA id-ad-rpkiManifest URI

in the CA certificate. If an RP cannot retrieve a manifest using this

URI, or if the manifest is not valid (Section 4.4), an RP SHOULD examine

the most recent, cached manifest matching this URI. If that manifest is

current (Section 4.4) proceed to 6.3. If the publication point
does not contain a valid manifest, and the cached manifest is not current,

proceed to 6.7.


6.3 Detecting Stale and or Prematurely-issued Manifests

Check that the current time (translated to UTC) is between
thisUpdate and nextUpdate. If the current time lies within this interval,

proceed to 6.4. If the current time is earlier than thisUpdate, the CA

has made an error. If the RP cache contains a current manifest, use that 
manifest instead and issue a warning. If an RP has no access to a 
current manifest, processing stops and a warning MUST be issued. If the 
current

time is later than nextUpdate, then the manifest is stale. If the RP 
cache contains a current manifest, use that manifest instead and issue a 
warning.

If no current manifest is available, proceed to 6.7.


6.4 Acquiring Files Referenced by a Manifest

Acquire all files enumerated in the manifest (fileList) from

the publication point. This includes the CRL, each object containing an

EE certificate issued by the C, and all subordinate CA and EE certificates.

If there are files listed in the manifest that cannot be retrieved from

the publication point, or if they fail the validity tests specified in

[RFC6488], the RP SHOULD examine its cache to determine if these files

are available locally. If _all_ of the missing/invalid files are available

from the RP’s cache, i.e., each file name matches the list extracted from

the manifest, the RP SHOULD use the cached files to replace those missing

from the publication point, and proceed to 6.5. However, if _any_ of the 
missing/invalid files cannot be replaced in this fashion, then proceed 
to 6.7.


6.5 Matching File Names and Hashes

Verify that the hash value of every file listed in the
manifest matches the value obtained by hashing the file acquired from the
publication point or local cache. If the computed hash value of a file

listed on the manifest does not match the hash value contained in the

manifest, then an RP SHOULD examine its local cache to determine if the

same file is available. The RP SHOULD use cached files to replace any

(damaged) downloaded files, so long as the hash of the cached file matches

the hash from the manifest. If _any_ of the files with hash mismatches

cannot be replaced in this fashion, proceed to 6.7. Otherwise proceed to 
6.6.


6.6 Out of Scope Manifest Entries

If a current manifest contains entries for objects that are not
within the scope of the manifest (Section 2), then the out-of-scope

entries MUST be disregarded.



6.7 Termination of Processing

If an RP cannot acquire a current, valid manifest, or acquire current,

valid instances of all of the objects enumerated in a current valid

manifest, then processing of the signed objects associated with the CA

has failed. The RP MUST issue a warning indicating the reason(s) for 
termination of processing with regard to this CA.

Termination or processing means that all of the ROAs and subordinate 
certificates (CA and EE) MUST be considered invalid. This implies that

the RP MUST not try to acquire and validate _subordinate_ signed objects,

until the next interval when the RP is scheduled to process data for

this part of the RPKI repository system.


--------------9F5EDA4898811B7F4B18B094
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    
I made some more revisions, adding a
        paragraph to the overview, and a section explaining what I meant
        by termination of manifest processing.

    
have a good weekend,

    
Steve

    
-----

    


    

    

    

    
6. 
        Relying Party Use of Manifests

    
 

    
Each RP must determine
        which signed
        objects it will use for

    
validating assertions
        about INRs and
        their use (e.g., which ROAs to

    
use in the construction
        of route
        filters). Manifests are designed 

    
to allow an RP to detect
        manipulation
        of repository data and/or 

    
errors by a CA or
        repository manager.
        Unless all of the files 

    
enumerated in a manifest
        can be
        obtained by an RP (either from a 

    
publication point or
        from a local
        cache), an RP MUST ignore the

    
data associated with the
        publication
        point. This stringent response

    
is needed to prevent an
        RP from
        misinterpreting data associated with

    
a publication point, and
        thus possibly
        treating invalid routes as

    
valid, or vice versa.

    
 

    
The processing described
        below is designed
        to cause all RPs with 

    
access to the same local
        cache and RPKI
        repository data to achieve 

    
the same results with
        regard to
        validation of RPKI data. However, in

    
operation, different RPs
        will access
        repositories at different times,

    
and some RPs may
        experience local cache
        failures, so there is no 

    
guarantee that all RPs
        will achieve the
        same results with regard to 

    
validation of RPKI data

    
 

    
Note that there is a
        “chicken and egg”
        relationship between the 

        manifest and the CRL for a given CA instance. If the EE
        certificate 

        for the current manifest is revoked, i.e., it appears in the
        current CRL,

    
then the CA or
        publication point
        manager has made a serious error. In this 

    
case all signed objects
        associated with
        the CA instance MUST be ignored. 

    
Similarly, if the CRL is
        not listed on
        a valid, current manifest, all 

    
signed objects
        associated with the CA
        instance MUST be ignored, because 

    
the CRL is considered
        missing. 

    
 

    
The primary locator for
        the CRL issued
        by a CA is the URI contained in the CRLDP contained in the CA’s
        certificate. An
        RP MUST use this URI to 

    
retrieve the CRL and use
        that CRL to
        determine if the EE certificate in 

    
the manifest is revoked.
        The manifest provides
        an RP with a means to

    
verify that the CRL at
        the indication
        location is current.

    
 

    
 

    
6.1. Manifest Processing
        Overview

        

        For a given publication point, an RP MUST perform a series of
        tests to

    
determine which signed
        object files at
        the publication point are

    
acceptable. The tests
        described below
        are to be performed using the 

    
manifest identified by
        the id-ad-rpkiManifest
        URI extracted from a CA certificate’s SIA. The files referenced
        by the manifest
        MUST be 

    
be located at the
        publication point
        specified by the id-ad-caRepository 

    
URI from the (same)
        certificate’s SIA.
        If the manifest and files it

    
references do not reside
        at the same
        publication point, an RP MUST ???

    
 

    
A manifest SHOULD contain exactly
        one CRL (.crl)
        file and it MUST be at 

    
the location specified in the CRLDP
        in the CA
        certificate. If more than 

    
one .crl file appears in
        the manifest,
        only file names matching the CRL specified by the CRLDP will be
        processed. If
        more than one .crl entry 

    
appears in the manifest,
        and matches
        the CRLDP, the first one encountered 

    
MUST be used.  Any
        other .crl files MUST be ignored and a warning MUST be issued.

    
 

    
Note that, during CA key
        rollover
        [RFC6489], signed objects for two or 

    
more different CA
        instances will appear
        at the same publication point. 

    
Manifest processing is
        to be performed
        separately for each CA instance, 

    
guided by the SIA
        id-ad-rpkiManifest
        URI in each CA certificate.

    
 

    
Note also that the
        processing described
        here will be performed using 

    
locally cached files if
        an RP does not
        detect newer versions of the files

    
in the RPKI repository
        system.

    


        

        6.2 Acquiring a Manifest for a CA

    
 

    
Acquire the manifest
        identified by the
        SIA id-ad-rpkiManifest URI

    
in the CA certificate.
        If an RP cannot
        retrieve a manifest using this 

    
URI, or if the manifest
        is not valid
        (Section 4.4), an RP SHOULD examine 

    
the most recent, cached
        manifest
        matching this URI. If that manifest is 

    
current (Section 4.4)
        proceed to 6.3. If
        the publication point 

        does not contain a valid manifest, and the cached manifest is
        not current,

    
proceed to 6.7.

        

      

    


        6.3 Detecting Stale and or Prematurely-issued Manifests

    
 

    
Check that the current
        time (translated
        to UTC) is between 

        thisUpdate and nextUpdate. If the current time lies within this
        interval, 

    
proceed to 6.4. If the
        current time is
        earlier than thisUpdate, the CA 

    
has made an error. If
        the RP cache
        contains a current manifest, use that manifest instead and issue
        a warning. If
        an RP has no access to a current manifest, processing stops and
        a warning MUST
        be issued. If the current 

    
time is later than
        nextUpdate, then the
        manifest is stale. If the RP cache contains a current manifest,
        use that
        manifest instead and issue a warning.

    
If no current manifest
        is available, proceed
        to 6.7.

        

      

    


        6.4 Acquiring Files Referenced by a Manifest

    
 

    
Acquire all files
        enumerated in the
        manifest (fileList) from 

    
the publication point.
        This includes
        the CRL, each object containing an 

    
EE certificate issued by
        the C, and all
        subordinate CA and EE certificates. 

    
If  there are files listed in the
        manifest that cannot
        be retrieved from 

    
the publication point,
        or if they fail
        the validity tests specified in 

    
[RFC6488], the RP SHOULD
        examine its
        cache to determine if these files 

    
are available locally.
        If all of
        the missing/invalid files are available

    
from the RP’s cache,
        i.e., each file name
        matches the list extracted from 

    
the manifest, the RP
        SHOULD use the
        cached files to replace those missing 

    
from the publication
        point, and proceed
        to 6.5. However, if any of the missing/invalid files
        cannot be replaced
        in this fashion, then proceed to 6.7.

    


        6.5 Matching File Names and Hashes

    
 

    
Verify that the hash
        value of every
        file listed in the 

        manifest matches the value obtained by hashing the file acquired
        from the 

        publication point or local cache. If the computed hash value of
        a file 

    
listed on the manifest
        does not match
        the hash value contained in the 

    
manifest, then an RP
        SHOULD examine its
        local cache to determine if the

    
same file is available.
        The RP SHOULD
        use cached files to replace any 

    
(damaged) downloaded
        files, so long as
        the hash of the cached file matches 

    
the hash from the
        manifest. If any
        of the files with hash mismatches 

    
cannot be replaced in
        this fashion, proceed
        to 6.7. Otherwise proceed to 6.6.

        

      

    


        6.6 Out of Scope Manifest Entries

    
 

    
If a current manifest
        contains entries
        for objects that are not 

        within the scope of the manifest (Section 2), then the
        out-of-scope 

    
entries MUST be
        disregarded. 

    


        

      

    
6.7 Termination of Processing

    
 

    
If an RP cannot acquire a current,
        valid manifest,
        or acquire current, 

    
valid instances of all of the
        objects enumerated in
        a current valid 

    
manifest, then processing of the
        signed objects
        associated with the CA

    
has failed. The RP MUST issue a
        warning indicating
        the reason(s) for termination of processing with regard to this
        CA. 

    
 

    
Termination or processing means that
        all of the
        ROAs and subordinate certificates (CA and EE) MUST be considered
        invalid. This
        implies that 

    
the RP MUST not try to acquire and
        validate subordinate
        signed objects, 

    
until the next interval when the RP
        is scheduled to
        process data for 

    
this part of the RPKI repository
        system.

        

      

    

      

  


--------------9F5EDA4898811B7F4B18B094--


From nobody Fri May  8 07:53:13 2020
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 254F43A0B6A for ; Fri,  8 May 2020 07:53:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 AFsu4M5RbUQJ for ; Fri,  8 May 2020 07:53:06 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.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 BD7093A0B71 for ; Fri,  8 May 2020 07:53:05 -0700 (PDT)
Received: from [IPv6:2001:981:4b52:1:f47f:88a8:9ce1:c5a8] (unknown [IPv6:2001:981:4b52:1:f47f:88a8:9ce1:c5a8]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 9FF3C2F24C; Fri,  8 May 2020 16:53:02 +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=1588949582; bh=XI0AJzMb3By7mp3wh3INoI7iHumcKXPg9NOG2aU8hhI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=K+vGAxJmLtc1wodsk04QUjumWp7gQgthrRYsEyyWhNB8L0eXZqwYsBAXKXrqR7Lyy uf2KQ7idPk5/g4bC243cT0EFFiJOfz0kfsURVL4XXvkjGimSTQbZ2C5p7WHVy8ZXdD HdEQOaGPRS6DbxrCvbar55MYYVrj4g90/xPAtr7Q=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Tim Bruijnzeels 
In-Reply-To: <75d43357-c378-c9f9-3610-84840fca8255@verizon.net>
Date: Fri, 8 May 2020 16:53:02 +0200
Cc: "sidrops@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <708AF319-17BC-4BED-B020-C04D1BCADC0B@nlnetlabs.nl>
References: <75d43357-c378-c9f9-3610-84840fca8255.ref@verizon.net> <75d43357-c378-c9f9-3610-84840fca8255@verizon.net>
To: Stephen Kent 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [Sidrops] once again, with feeling ...
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, 08 May 2020 14:53:11 -0000

Hi Steve, all,

I did not have time yet to read everything, so a quick comment only for =
now.. below.

Have a great weekend!
Tim

> On 8 May 2020, at 16:38, Stephen Kent =
 wrote:
>=20
> I made some more revisions, adding a paragraph to the overview, and a =
section explaining what I meant by termination of manifest processing.
>=20
> have a good weekend,
>=20
> Steve
>=20
> -----
>=20
>=20
>=20
>=20
> 6.  Relying Party Use of Manifests
> =20
> 
> =20
> The primary locator for the CRL issued by a CA is the URI contained in =
the CRLDP contained in the CA=E2=80=99s certificate.

That would be the CRL issued by the parent to this CA, no?

> An RP MUST use this URI to=20
> retrieve the CRL and use that CRL to determine if the EE certificate =
in=20
> the manifest is revoked. The manifest provides an RP with a means to
> verify that the CRL at the indication location is current.

I thought that we would expect that the CRLDP of the MFT EE is used, and =
that this URI matches the id-ad-caRepository SIA in the issuing CA =
certificate + the name of the one and only '.crl' entry in the manifest =
content.



From nobody Fri May  8 08:25:30 2020
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 7460A3A0B56 for ; Fri,  8 May 2020 08:25:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgrHtYuVW3my for ; Fri,  8 May 2020 08:25:26 -0700 (PDT)
Received: from sonic317-26.consmr.mail.bf2.yahoo.com (sonic317-26.consmr.mail.bf2.yahoo.com [74.6.129.81]) (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 009763A0410 for ; Fri,  8 May 2020 08:25:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1588951524; bh=d4wpc4/k3E25eZKvAvxtQXDKABC1d8xGiuDoiQ6/CS4=;  h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject;  b=m5ImdcihtZqP2S51n90aC1aDFdak1jN1OYkXwe+G4knik5QAo2fTeHMyNPLCMUbmZyclt0N63hMuWwb1LMt1/zUdCLGuWoC2wWdfHfvdMEalI/rHv/2w+cmjKSeDfFgNFCWbc2PxztIzGKB08XxYEo6LOYQLKNRfi9QxdBTcY6G3SZOCTpWT+MLZqLzplYkYfKIIZf2Gi8j3TxwnTPDiOKQpPGHtktGb/hSL+iYhRs8ato0X/LdPyPSvAgxT0r1edZTFqjas+WikVYQxeLK0QTHBYsFtN+dOnmyTYJTOCBZTdVAq/slXTjCSwtgP5CKBH/YQ3KHScaFzLoh/KlVYgw==
X-YMail-OSG: eTCvtEsVM1kcS06Sa1Ry1umPLtmIPjoyRoYr8p12n7o7YSTqKMtR5jIMZSA2qVn t9e6tXRryunmUcSi.TMYb9ybuN4cK_o9yk4v_je1NyucnfHrJJiY7PSi19jao9jbWYwHBSRW89Gp InZBoQ3LxjU.SjHScYmqXmYqad8eEEpgshkS2bGP8iWRJznddDsjsyWc5yZ6tQLwSOmhKObq.x1l rioW7dg779gyO77T_Ho8osao7CSIvm9eYp6anmwpT7yXwNLoyGynav1U736CO9DHwIbBs418zrrL pK4vcMSaOaiuv4aagkGH23yoNAsMBR8u1D4nY_S89XwYqWoTFFQk2uxDm4HwDax2oRuUZlbDVwbZ VWOvcjRes_h5tWv2MFa0eCwDSAgPZhUxYt5c3T35SJYH9kLCVTMaArblW_5DbdVf4hK6.u8DoQZx Cxk_b_3GFcQtgrWD1.63CzKtol35Bdkd6Yr0rxe31uAYT78S3kTEyrQI_rqLO_hZt.pyxIn.Ju6N QDUsqyw9ztCA66aTbLKrzL.FBKy.aK3L7HOXepP36YH_S_prqRcYx7jdlBokdmGFslC5PocZW9hM cu.tdaBN_G0YjweQ7yzi_APj_KJm2TB6TRmzNtkZvhxmoQFiHXvu4cGadu4DA3xfbgvsdt5lOwiC aiD_aToOQoME0vwyb9juzsHChBXe6gHTR1WmnKrAnq.5WDoAGTmUnv8BDY__DmyM_oh07PRLu3Fa Al9zA6lnzzuzyW_Pc8r7QTD7Z2v137CUdoDiOmRbdno81Q2kiBPk_Be5KzLovTB7sUU8Z1XqVozd qjqo0Y0h9GpVMHELZNaqa6a3.ts0othwkE3OxBtfYLi1wpKd08ZPB7f6m9Rx0jDDqje75wvrw87v 4GSQFOxxRWRDWup.Pae4tfH3sn08mJzL0TY8kJAcwXWFDe_4Cd5_EZ_ZIor4Gr_bNbAImNZCjWfF Ytdtyj75PT6SXVPuKxKfP8BwXH4LDXDtJ2xgEaBlhIJJ16rc5WyDRku4KgmbgZN1StGMBJwFsHs2 USoXdVNzrUCUPosT_RQIz9Gi1icwmvjA39.x0yRdwc1eIBXHUZSqfsg8kEjyplN063f9C83IprLz jsvMALtT71Rc9XfZFxy_w1NhfJq7QBuDXR_oxOu2H54FuGChblKjkKWEdodxlQa9GgaM3tD904vH GDrHl6LFAVkR0E1o7ZaOvDSvQJ4PsGZ1Inyaen50UVrLOHvNvrtzbXcPF9w3ubFyNvGub6K5Qu8w TwfAPgyF.iP4oh4cXsZqAEPO4m1jd_DMS6_u5ARtdBH1hnR0U9gvAAASV2Mjm7FfK6XF2g2nkiTO 1gw_gYzx.9S91h6Pquk49z1VTMwsaJQ5DUofczF4km61LGExBgzwpNxSWzn7ZNISs8apMgGrIfHi IbnTAAP2re2d1u7EMl.MNi99LzLb8bw--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Fri, 8 May 2020 15:25:24 +0000
Received: by smtp423.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID dba5023271ca73000d4764a19513ea4a;  Fri, 08 May 2020 15:25:20 +0000 (UTC)
To: Tim Bruijnzeels 
Cc: "sidrops@ietf.org" 
References: <75d43357-c378-c9f9-3610-84840fca8255.ref@verizon.net> <75d43357-c378-c9f9-3610-84840fca8255@verizon.net> <708AF319-17BC-4BED-B020-C04D1BCADC0B@nlnetlabs.nl>
From: Stephen Kent 
Message-ID: 
Date: Fri, 8 May 2020 11:25:20 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <708AF319-17BC-4BED-B020-C04D1BCADC0B@nlnetlabs.nl>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.15902 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] once again, with feeling ...
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, 08 May 2020 15:25:28 -0000

Tim,
>
>> 6.  Relying Party Use of Manifests
>>   
>> 
>>   
>> The primary locator for the CRL issued by a CA is the URI contained in the CRLDP contained in the CA’s certificate.
> That would be the CRL issued by the parent to this CA, no?
Whoops. My bad. I should refer to the CRLDP in the manifest being 
fetched, not in the CA cert. I will fix that.
>
>> An RP MUST use this URI to
>> retrieve the CRL and use that CRL to determine if the EE certificate in
>> the manifest is revoked. The manifest provides an RP with a means to
>> verify that the CRL at the indication location is current.
> I thought that we would expect that the CRLDP of the MFT EE is used, and that this URI matches the id-ad-caRepository SIA in the issuing CA certificate + the name of the one and only '.crl' entry in the manifest content.

Yes, we want to compare the CRLDP in the manifest's EE cert against the 
SIA URI from the CA cert. I'll revise this text.

Thanks for noticing these errors. Rev 4 will be posted immediately.

Steve



From nobody Fri May  8 08:25:36 2020
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 8D7BC3A0410 for ; Fri,  8 May 2020 08:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vJYdhWRiFT7 for ; Fri,  8 May 2020 08:25:26 -0700 (PDT)
Received: from sonic317-26.consmr.mail.bf2.yahoo.com (sonic317-26.consmr.mail.bf2.yahoo.com [74.6.129.81]) (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 00A3C3A0A22 for ; Fri,  8 May 2020 08:25:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1588951524; bh=d4wpc4/k3E25eZKvAvxtQXDKABC1d8xGiuDoiQ6/CS4=;  h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject;  b=m5ImdcihtZqP2S51n90aC1aDFdak1jN1OYkXwe+G4knik5QAo2fTeHMyNPLCMUbmZyclt0N63hMuWwb1LMt1/zUdCLGuWoC2wWdfHfvdMEalI/rHv/2w+cmjKSeDfFgNFCWbc2PxztIzGKB08XxYEo6LOYQLKNRfi9QxdBTcY6G3SZOCTpWT+MLZqLzplYkYfKIIZf2Gi8j3TxwnTPDiOKQpPGHtktGb/hSL+iYhRs8ato0X/LdPyPSvAgxT0r1edZTFqjas+WikVYQxeLK0QTHBYsFtN+dOnmyTYJTOCBZTdVAq/slXTjCSwtgP5CKBH/YQ3KHScaFzLoh/KlVYgw==
X-YMail-OSG: eTCvtEsVM1kcS06Sa1Ry1umPLtmIPjoyRoYr8p12n7o7YSTqKMtR5jIMZSA2qVn t9e6tXRryunmUcSi.TMYb9ybuN4cK_o9yk4v_je1NyucnfHrJJiY7PSi19jao9jbWYwHBSRW89Gp InZBoQ3LxjU.SjHScYmqXmYqad8eEEpgshkS2bGP8iWRJznddDsjsyWc5yZ6tQLwSOmhKObq.x1l rioW7dg779gyO77T_Ho8osao7CSIvm9eYp6anmwpT7yXwNLoyGynav1U736CO9DHwIbBs418zrrL pK4vcMSaOaiuv4aagkGH23yoNAsMBR8u1D4nY_S89XwYqWoTFFQk2uxDm4HwDax2oRuUZlbDVwbZ VWOvcjRes_h5tWv2MFa0eCwDSAgPZhUxYt5c3T35SJYH9kLCVTMaArblW_5DbdVf4hK6.u8DoQZx Cxk_b_3GFcQtgrWD1.63CzKtol35Bdkd6Yr0rxe31uAYT78S3kTEyrQI_rqLO_hZt.pyxIn.Ju6N QDUsqyw9ztCA66aTbLKrzL.FBKy.aK3L7HOXepP36YH_S_prqRcYx7jdlBokdmGFslC5PocZW9hM cu.tdaBN_G0YjweQ7yzi_APj_KJm2TB6TRmzNtkZvhxmoQFiHXvu4cGadu4DA3xfbgvsdt5lOwiC aiD_aToOQoME0vwyb9juzsHChBXe6gHTR1WmnKrAnq.5WDoAGTmUnv8BDY__DmyM_oh07PRLu3Fa Al9zA6lnzzuzyW_Pc8r7QTD7Z2v137CUdoDiOmRbdno81Q2kiBPk_Be5KzLovTB7sUU8Z1XqVozd qjqo0Y0h9GpVMHELZNaqa6a3.ts0othwkE3OxBtfYLi1wpKd08ZPB7f6m9Rx0jDDqje75wvrw87v 4GSQFOxxRWRDWup.Pae4tfH3sn08mJzL0TY8kJAcwXWFDe_4Cd5_EZ_ZIor4Gr_bNbAImNZCjWfF Ytdtyj75PT6SXVPuKxKfP8BwXH4LDXDtJ2xgEaBlhIJJ16rc5WyDRku4KgmbgZN1StGMBJwFsHs2 USoXdVNzrUCUPosT_RQIz9Gi1icwmvjA39.x0yRdwc1eIBXHUZSqfsg8kEjyplN063f9C83IprLz jsvMALtT71Rc9XfZFxy_w1NhfJq7QBuDXR_oxOu2H54FuGChblKjkKWEdodxlQa9GgaM3tD904vH GDrHl6LFAVkR0E1o7ZaOvDSvQJ4PsGZ1Inyaen50UVrLOHvNvrtzbXcPF9w3ubFyNvGub6K5Qu8w TwfAPgyF.iP4oh4cXsZqAEPO4m1jd_DMS6_u5ARtdBH1hnR0U9gvAAASV2Mjm7FfK6XF2g2nkiTO 1gw_gYzx.9S91h6Pquk49z1VTMwsaJQ5DUofczF4km61LGExBgzwpNxSWzn7ZNISs8apMgGrIfHi IbnTAAP2re2d1u7EMl.MNi99LzLb8bw--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Fri, 8 May 2020 15:25:24 +0000
Received: by smtp423.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID dba5023271ca73000d4764a19513ea4a;  Fri, 08 May 2020 15:25:20 +0000 (UTC)
To: Tim Bruijnzeels 
Cc: "sidrops@ietf.org" 
References: <75d43357-c378-c9f9-3610-84840fca8255.ref@verizon.net> <75d43357-c378-c9f9-3610-84840fca8255@verizon.net> <708AF319-17BC-4BED-B020-C04D1BCADC0B@nlnetlabs.nl>
From: Stephen Kent 
Message-ID: 
Date: Fri, 8 May 2020 11:25:20 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <708AF319-17BC-4BED-B020-C04D1BCADC0B@nlnetlabs.nl>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.15902 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] once again, with feeling ...
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, 08 May 2020 15:25:29 -0000

Tim,
>
>> 6.  Relying Party Use of Manifests
>>   
>> 
>>   
>> The primary locator for the CRL issued by a CA is the URI contained in the CRLDP contained in the CA’s certificate.
> That would be the CRL issued by the parent to this CA, no?
Whoops. My bad. I should refer to the CRLDP in the manifest being 
fetched, not in the CA cert. I will fix that.
>
>> An RP MUST use this URI to
>> retrieve the CRL and use that CRL to determine if the EE certificate in
>> the manifest is revoked. The manifest provides an RP with a means to
>> verify that the CRL at the indication location is current.
> I thought that we would expect that the CRLDP of the MFT EE is used, and that this URI matches the id-ad-caRepository SIA in the issuing CA certificate + the name of the one and only '.crl' entry in the manifest content.

Yes, we want to compare the CRLDP in the manifest's EE cert against the 
SIA URI from the CA cert. I'll revise this text.

Thanks for noticing these errors. Rev 4 will be posted immediately.

Steve



From nobody Fri May  8 08:37:00 2020
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 17DFE3A0BDC for ; Fri,  8 May 2020 08:36:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sa8eBVtRxSL for ; Fri,  8 May 2020 08:36:48 -0700 (PDT)
Received: from sonic315-13.consmr.mail.bf2.yahoo.com (sonic315-13.consmr.mail.bf2.yahoo.com [74.6.134.123]) (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 D7F293A0C3E for ; Fri,  8 May 2020 08:36:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1588952186; bh=N2diQ0iZpcgE7cpny4RVYvU/Qe240EWn7I/PEFZMnUE=;  h=To:From:Subject:Date:References:From:Subject; b=fnmSahI0pYYVKq55KVkFsU/nJ/Kw3UEok3RFJsmLFmogJ98pUVmVXPT2XUTWI/PJ7Uv3rkfvY7rYJ5QDbSVeL6c/RO8RcT/rt1tM4DfIEi6IxuSgnnygXyjxqfi3zO6nwbehy9wYheeTDiSjjvPNXfvTzWc2zagLt3AIyD1vI1rqWV4bmKlHhIfIA23U5FpDlJdiIXwG253hREssRlUgGUzYvgrZdAKaukV+GbYd4cnIPAipmT1nQg05Bqs6IzWxFgmT79JDiKIJfUwHqhN3fhTpsM1FVWZPdHXDvqbZnZ/Vb+/chzbDBXIjZt4m8JyilhxuGw4PknYfbQFIQIY+ew==
X-YMail-OSG: 6nLK_3EVM1nZW0ZW9S1.MlE9gQ6AydDRH9EBos4_Ca.9ZFOI0QG0MfSpGOGhURR l_tOKgLPgY3bWn6sMOK0cFsTlpimpQJSJyezhEA0BdVxcSIuq50jfDq5Uh1mFvj4q5EDxZ70.M8b mp5q3ky9yPqCz2m4ifIpfraD0dTnU66IktiyrHqlbfv3.BQM4iGlaNduwPT_6V.BS.T7umulyaVq 8Dx8eHo2uiu8sDTVlfwGndc.z8rwWomzpW3x5zF5DBbcWkmr_i1fC.b8RqolSjdSX80qAJvhufVk SLx_x5Ge9YT8YdXusok_k7J61TxAgaLl6HyQJ5SDbkIkoc.WYy_.e1ERvCgYbmE79_Q8h340ufLt R2ae73EwPXv_kEsNES2G4P7lIyEYdpKc5ikyE9TEUcUvYseILL1LG7s7RXFvcst18_d29hLvq841 D25IYKRkIYExrpZJUefi0hjuYPpv0WZ0XJv0e1aUkbaFQ8UvYsPqHJlAx_guE238lc5_8ij46ihx RKku3uMwFSMzEPK3cV4weI5qqw70AV0j7M8I4mzoR9kmbwmtIcZsUnhZg4O_QguaoLN1fX9EHhTK .sEyR6pbqMrat6gu3OyFBlCKQujHDhzo30OQdDUJuaCsavNWElJIYaidGNmY6ZjgAuySh1WoegRp 8XwzHbYkgIOc4f2Ubf3g_cAe0FLs1uRIcNf4ymI695VsK25AOC9vN.HKTrBZpjC8VrkLjMKqrpO7 YQKoKpc9g4nU1cRMEF_UPaEKg05.0CzKtwWPqW.ALKZA6uQvNiP3GAye5_B42WZtWMtd4eAMZlWf gzTFtJ9V4npwFjbG.Kee1rjDWcfjJNR8yzlIy81.7wzoQop2FfkmN.vEYEgU5K0lrTEVrtB8UMpc 6fYy2W62FLIO53By650R.oJJDiM80vkqSizraZwyVu2mCVLVV1LX2Tz14v.5MPQO3uN1J1.eOffS k2T9fxGsN5D8znlZXuIK2YY2qL8DGuEM75JixW7fI78OZ9T88HiR39nDw5DqRUY9sc2XXvipZNfZ DsX_WygZmbyps7xAPcBNZ6r0_tt.PrxJ3XibkSV36eTxNyPSq41LnkKJFvXVRAvNe2aZY_He7emu 17T68ttoKVTXQ3A4RYjufoGsajqBqHWlSLYYwlwaQ_SqVlj8wUlcQcJnDnXQT_l6YInI.hf7wUqW K7DCg.vCvwD.Y52l3LMCuSgelxcDDgu4PzM3E.cYIT2taiUl7iP3vTySoTg5B8EAKQPXwLGeDkLm N9CvBJ6HaNnb8A1naq_cNo1VEv9Rpf26s.rBtzRpZh2E9rhs1KnbrMVzcqmjdE2RWr8smwWgemtX 61SgyJ1dz7KBA83R.J54n0SB.w17KGF3DB_QLe8rx8eHzfklPNz4vTSVGW5io3nHQqR_TJx5i3zv ZzviLkzsrvt0ViclmkNvlR5bO
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Fri, 8 May 2020 15:36:26 +0000
Received: by smtp409.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4e9a89c6d75e4bfaabdf55619e9f1d1d;  Fri, 08 May 2020 15:26:22 +0000 (UTC)
To: "sidrops@ietf.org" 
From: Stephen Kent 
Message-ID: 
Date: Fri, 8 May 2020 11:26:22 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------59CB60713A5E16EBECBC2572"
Content-Language: en-US
References: 
X-Mailer: WebService/1.1.15902 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
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, 08 May 2020 15:36:57 -0000

This is a multi-part message in MIME format.
--------------59CB60713A5E16EBECBC2572
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

6.Relying Party Use of Manifests

Each RP must determine which signed objects it will use for

validating assertions about INRs and their use (e.g., which ROAs to

use in the construction of route filters). Manifests are designed

to allow an RP to detect manipulation of repository data and/or

errors by a CA or repository manager. Unless _all_ of the files

enumerated in a manifest can be obtained by an RP (either from a

publication point or from a local cache), an RP MUST ignore the

data associated with the publication point. This stringent response

is needed to prevent an RP from misinterpreting data associated with

a publication point, and thus possibly treating invalid routes as

valid, or vice versa.

The processing described below is designed to cause all RPs with

access to the same local cache and RPKI repository data to achieve

the same results with regard to validation of RPKI data. However, in

operation, different RPs will access repositories at different times,

and some RPs may experience local cache failures, so there is no

guarantee that all RPs will achieve the same results with regard to

validation of RPKI data

Note that there is a “chicken and egg” relationship between the
manifest and the CRL for a given CA instance. If the EE certificate
for the current manifest is revoked, i.e., it appears in the current CRL,

then the CA or publication point manager has made a serious error. In this

case all signed objects associated with the CA instance MUST be ignored.

Similarly, if the CRL is not listed on a valid, current manifest, all

signed objects associated with the CA instance MUST be ignored, because

the CRL is considered missing.

6.1. Manifest Processing Overview

For a given publication point, an RP MUST perform a series of tests to

determine which signed object files at the publication point are

acceptable. The tests described below are to be performed using the

manifest identified by the id-ad-rpkiManifest URI extracted from a CA 
certificate’s SIA. _All_ of the files referenced by the manifest MUST be

be located at the publication point specified by the id-ad-caRepository

URI from the (same) certificate’s SIA. If the manifest and the files it

references do not reside at the same publication point, an RP MUST *???*

**

A manifest SHOULD contain exactly one CRL (.crl) file and it MUST be at

the location specified in the CRLDP in the manifest’s EE certificate.

If more than one .crl file appears in the manifest, only file names

matching the CRL specified by the CRLDP will be processed. If more than

one .crl entry appears in the manifest, and matches the CRLDP, the first

one encountered MUST be used. Any other .crl files MUST be ignored and a 
warning MUST be issued.

Note that, during CA key rollover [RFC6489], signed objects for two or

more different CA instances will appear at the same publication point.

Manifest processing is to be performed separately for each CA instance,

guided by the SIA id-ad-rpkiManifest URI in each CA certificate.

Note also that the processing described here will be performed using

locally cached files if an RP does not detect newer versions of the files

in the RPKI repository system.



6.2 Acquiring a Manifest for a CA

Acquire the manifest identified by the SIA id-ad-rpkiManifest URI

in the CA certificate. If an RP cannot retrieve a manifest using this

URI, or if the manifest is not valid (Section 4.4), an RP SHOULD examine

the most recent, cached manifest matching this URI. If that manifest is

current (Section 4.4) proceed to 6.3. If the publication point
does not contain a valid manifest, and the cached manifest is not current,

proceed to 6.7.


6.3 Detecting Stale and or Prematurely-issued Manifests

Check that the current time (translated to UTC) is between
thisUpdate and nextUpdate. If the current time lies within this interval,

proceed to 6.4. If the current time is earlier than thisUpdate, the CA

has made an error. If the RP cache contains a current manifest, use that 
manifest instead and issue a warning. If an RP has no access to a 
current manifest, processing stops and a warning MUST be issued. If the 
current

time is later than nextUpdate, then the manifest is stale. If the RP 
cache contains a current manifest, use that manifest instead and issue a 
warning.

If no current manifest is available, proceed to 6.7.


6.4 Acquiring Files Referenced by a Manifest

Acquire all files enumerated in the manifest (fileList) from

the publication point. This includes the CRL, each object containing an

EE certificate issued by the C, and all subordinate CA and EE certificates.

If there are files listed in the manifest that cannot be retrieved from

the publication point, or if they fail the validity tests specified in

[RFC6488], the RP SHOULD examine its cache to determine if these files

are available locally. If _all_ of the missing/invalid files are available

from the RP’s cache, i.e., each file name matches the list extracted from

the manifest, the RP SHOULD use the cached files to replace those missing

from the publication point, and proceed to 6.5. However, if _any_ of the 
missing/invalid files cannot be replaced in this fashion, then proceed 
to 6.7.


6.5 Matching File Names and Hashes

Verify that the hash value of every file listed in the
manifest matches the value obtained by hashing the file acquired from the
publication point or local cache. If the computed hash value of a file

listed on the manifest does not match the hash value contained in the

manifest, then an RP SHOULD examine its local cache to determine if the

same file is available. The RP SHOULD use cached files to replace any

(damaged) downloaded files, so long as the hash of the cached file matches

the hash from the manifest. If _any_ of the files with hash mismatches

cannot be replaced in this fashion, proceed to 6.7. Otherwise proceed to 
6.6.


6.6 Out of Scope Manifest Entries

If a current manifest contains entries for objects that are not
within the scope of the manifest (Section 2), then the out-of-scope

entries MUST be disregarded.



6.7 Termination of Processing

If an RP cannot acquire a current, valid manifest, or acquire current,

valid instances of all of the objects enumerated in a current valid

manifest, then processing of the signed objects associated with the CA

has failed. The RP MUST issue a warning indicating the reason(s) for 
termination of processing with regard to this CA.

Termination or processing means that all of the ROAs and subordinate 
certificates (CA and EE) MUST be considered invalid. This implies that

the RP MUST not try to acquire and validate _subordinate_ signed objects,

until the next interval when the RP is scheduled to process data for

this part of the RPKI repository system.


--------------59CB60713A5E16EBECBC2572
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    

    

    
6. 
        Relying Party Use of Manifests

    
 

    
Each RP must determine
        which signed
        objects it will use for

    
validating assertions
        about INRs and
        their use (e.g., which ROAs to

    
use in the construction
        of route
        filters). Manifests are designed 

    
to allow an RP to detect
        manipulation
        of repository data and/or 

    
errors by a CA or
        repository manager.
        Unless all of the files 

    
enumerated in a manifest
        can be
        obtained by an RP (either from a 

    
publication point or
        from a local
        cache), an RP MUST ignore the

    
data associated with the
        publication
        point. This stringent response

    
is needed to prevent an
        RP from
        misinterpreting data associated with

    
a publication point, and
        thus possibly
        treating invalid routes as

    
valid, or vice versa.

    
 

    
The processing described
        below is designed
        to cause all RPs with 

    
access to the same local
        cache and RPKI
        repository data to achieve 

    
the same results with
        regard to
        validation of RPKI data. However, in

    
operation, different RPs
        will access
        repositories at different times,

    
and some RPs may
        experience local cache
        failures, so there is no 

    
guarantee that all RPs
        will achieve the
        same results with regard to 

    
validation of RPKI data

    
 

    
Note that there is a
        “chicken and egg”
        relationship between the 

        manifest and the CRL for a given CA instance. If the EE
        certificate 

        for the current manifest is revoked, i.e., it appears in the
        current CRL,

    
then the CA or
        publication point
        manager has made a serious error. In this 

    
case all signed objects
        associated with
        the CA instance MUST be ignored. 

    
Similarly, if the CRL is
        not listed on
        a valid, current manifest, all 

    
signed objects
        associated with the CA
        instance MUST be ignored, because 

    
the CRL is considered
        missing. 

    
 

    
 

    
 

    
6.1. Manifest Processing
        Overview

        

        For a given publication point, an RP MUST perform a series of
        tests to

    
determine which signed
        object files at
        the publication point are

    
acceptable. The tests
        described below
        are to be performed using the 

    
manifest identified by
        the id-ad-rpkiManifest
        URI extracted from a CA certificate’s SIA. All of the
        files referenced
        by the manifest MUST be 

    
be located at the
        publication point
        specified by the id-ad-caRepository 

    
URI from the (same)
        certificate’s SIA.
        If the manifest and the files it

    
references do not reside
        at the same
        publication point, an RP MUST ???

    
 

    
A manifest SHOULD contain exactly
        one CRL (.crl)
        file and it MUST be at 

    
the location specified in the CRLDP
        in the
        manifest’s EE certificate.

    
If more than one .crl
        file appears in
        the manifest, only file names 

    
matching the CRL
        specified by the CRLDP
        will be processed. If more than 

    
one .crl entry appears
        in the manifest,
        and matches the CRLDP, the first 

    
one encountered MUST be
        used.  Any
        other .crl files MUST be ignored and a warning MUST be issued.

    
 

    
Note that, during CA key
        rollover
        [RFC6489], signed objects for two or 

    
more different CA
        instances will appear
        at the same publication point. 

    
Manifest processing is
        to be performed
        separately for each CA instance, 

    
guided by the SIA
        id-ad-rpkiManifest
        URI in each CA certificate.

    
 

    
Note also that the
        processing described
        here will be performed using 

    
locally cached files if
        an RP does not
        detect newer versions of the files

    
in the RPKI repository
        system.

    


        

        6.2 Acquiring a Manifest for a CA

    
 

    
Acquire the manifest
        identified by the
        SIA id-ad-rpkiManifest URI

    
in the CA certificate.
        If an RP cannot
        retrieve a manifest using this 

    
URI, or if the manifest
        is not valid
        (Section 4.4), an RP SHOULD examine 

    
the most recent, cached
        manifest
        matching this URI. If that manifest is 

    
current (Section 4.4)
        proceed to 6.3. If
        the publication point 

        does not contain a valid manifest, and the cached manifest is
        not current,

    
proceed to 6.7.

        

      

    


        6.3 Detecting Stale and or Prematurely-issued Manifests

    
 

    
Check that the current
        time (translated
        to UTC) is between 

        thisUpdate and nextUpdate. If the current time lies within this
        interval, 

    
proceed to 6.4. If the
        current time is
        earlier than thisUpdate, the CA 

    
has made an error. If
        the RP cache
        contains a current manifest, use that manifest instead and issue
        a warning. If
        an RP has no access to a current manifest, processing stops and
        a warning MUST
        be issued. If the current 

    
time is later than
        nextUpdate, then the
        manifest is stale. If the RP cache contains a current manifest,
        use that
        manifest instead and issue a warning.

    
If no current manifest
        is available, proceed
        to 6.7.

        

      

    


        6.4 Acquiring Files Referenced by a Manifest

    
 

    
Acquire all files
        enumerated in the
        manifest (fileList) from 

    
the publication point.
        This includes
        the CRL, each object containing an 

    
EE certificate issued by
        the C, and all
        subordinate CA and EE certificates. 

    
If  there are files listed in the
        manifest that cannot
        be retrieved from 

    
the publication point,
        or if they fail
        the validity tests specified in 

    
[RFC6488], the RP SHOULD
        examine its
        cache to determine if these files 

    
are available locally.
        If all of
        the missing/invalid files are available

    
from the RP’s cache,
        i.e., each file name
        matches the list extracted from 

    
the manifest, the RP
        SHOULD use the
        cached files to replace those missing 

    
from the publication
        point, and proceed
        to 6.5. However, if any of the missing/invalid files
        cannot be replaced
        in this fashion, then proceed to 6.7.

    


        6.5 Matching File Names and Hashes

    
 

    
Verify that the hash
        value of every
        file listed in the 

        manifest matches the value obtained by hashing the file acquired
        from the 

        publication point or local cache. If the computed hash value of
        a file 

    
listed on the manifest
        does not match
        the hash value contained in the 

    
manifest, then an RP
        SHOULD examine its
        local cache to determine if the

    
same file is available.
        The RP SHOULD
        use cached files to replace any 

    
(damaged) downloaded
        files, so long as
        the hash of the cached file matches 

    
the hash from the
        manifest. If any
        of the files with hash mismatches 

    
cannot be replaced in
        this fashion, proceed
        to 6.7. Otherwise proceed to 6.6.

        

      

    


        6.6 Out of Scope Manifest Entries

    
 

    
If a current manifest
        contains entries
        for objects that are not 

        within the scope of the manifest (Section 2), then the
        out-of-scope 

    
entries MUST be
        disregarded. 

    


        

      

    
6.7 Termination of Processing

    
 

    
If an RP cannot acquire a current,
        valid manifest,
        or acquire current, 

    
valid instances of all of the
        objects enumerated in
        a current valid 

    
manifest, then processing of the
        signed objects
        associated with the CA

    
has failed. The RP MUST issue a
        warning indicating
        the reason(s) for termination of processing with regard to this
        CA. 

    
 

    
Termination or processing means that
        all of the
        ROAs and subordinate certificates (CA and EE) MUST be considered
        invalid. This
        implies that 

    
the RP MUST not try to acquire and
        validate subordinate
        signed objects, 

    
until the next interval when the RP
        is scheduled to
        process data for 

    
this part of the RPKI repository
        system.

        

      

    

      

  


--------------59CB60713A5E16EBECBC2572--


From nobody Fri May  8 09:58:25 2020
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 28D2B3A0B2E for ; Fri,  8 May 2020 09:58:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfXTj_8wm2TE for ; Fri,  8 May 2020 09:58:02 -0700 (PDT)
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700068.outbound.protection.outlook.com [40.107.70.68]) (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 18FA43A0B43 for ; Fri,  8 May 2020 09:58:01 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M+t/7W+ELzug/CYEuGg9MIDRZ1oK0/FJQsEC/qX/eKdgMzyx1252qxBvjnAEN477YBCSYWgfIL2ElTpC0NUdJaK+O3BT00iCctTzmp8D71b9t3MAf4JylFWV4nLTf4GI1XgTCrBy+57kgl1bVXdVP09mgI0oL8mmXdL/QwTcb/zU1X+G43sn0z7ttCuZrYte9ktFTSiJtQnL4FztOKAfGtcPSfs/OUcFR5nzBCuu2Qi54c0usCxqjH3tcJ7gDmWxlHJcdV8zRnC+5kUQj06hmjHX6SNMZLvK5B4huJKqdOaA5QgosIEMeQHS1KZ/F1MpFdz4heNcdwsJsosNjE/zhQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QwEWEyN2SkK42wsk7hv01r59Fjs03ekt2xp4IzV5+f8=; b=DAJcceutG+R3hsJbhGRSQGTqqHpIBvBWZUkVCAwDVJwsFcMewdr6ElKDtqnG98Avw+EVYMe76CzQwhbGlt4pESlMEtZF9uq15/VsTHCB18uE45cOTcZXbhQAIx97Fk2NCegeDa7MvVc/F02caIxCzdy5PgS6t2oOsE8DDj0gfCgYOp2T52p4X0tpTluxwwiu14u4/6XbgDSX50DCUeqkx/P79LoGiUvGuHDJPhEK/7a3Dp+VsqM1xB79cLVKtK/rWk6Z+IiWJIev49+cjX3jdS2oIP0hm3VShmX2eLsfMKOX1XNMgpRpzBnqKxJlrPsKJDGIeJNHlkLYtgS4cqoo8g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QwEWEyN2SkK42wsk7hv01r59Fjs03ekt2xp4IzV5+f8=; b=pHEM00swmu0wy+MDxZmrTOiVK1iCXvEocwT6+QgZLW6P3vVqut84UjddBW/MYMuwH3v3/Yryj4jK/vND0+fLQoOtNviEl2Ud6g7k12GoOnFYJaESL7Dh389f3rQIOspaEreaYQbCNflk1LqDSuZh7ZWcimqeLIO6gEqXY/1On5M=
Received: from BYAPR18MB2534.namprd18.prod.outlook.com (2603:10b6:a03:12e::29) by BYAPR18MB2568.namprd18.prod.outlook.com (2603:10b6:a03:137::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20; Fri, 8 May 2020 16:57:59 +0000
Received: from BYAPR18MB2534.namprd18.prod.outlook.com ([fe80::280e:b668:2003:aa8]) by BYAPR18MB2534.namprd18.prod.outlook.com ([fe80::280e:b668:2003:aa8%7]) with mapi id 15.20.2958.035; Fri, 8 May 2020 16:57:59 +0000
From: Keyur Patel 
To: SIDR Operations WG 
Thread-Topic: WG Adoption call for draft-ymbk-sidrops-rpki-rov-timing-00.txt - ENDS 05/22/2020  (May 22 2020)
Thread-Index: AQHWJVnT4Fw3r79hrkO8NYABWyGQYQ==
Date: Fri, 8 May 2020 16:57:59 +0000
Message-ID: <26C7F369-AA1A-430C-850D-985A3D5DA850@arrcus.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.36.20041300
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arrcus.com;
x-originating-ip: [2601:646:8700:a6f0:31c8:e8a1:88ca:2934]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4ba63e87-7cb0-416c-c22c-08d7f370f677
x-ms-traffictypediagnostic: BYAPR18MB2568:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:4303;
x-forefront-prvs: 039735BC4E
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: QrHhzX7T1CaMozkPymf/WoVZT5AygWLTH7sDC9JGMTUbSJAEKcvbbmbq7E2kpa/JqXOMaoCUg3+5UAPsL5xGlwPtYJJe19GIkmcrglIX5C4hocjwPJBJpn7XRMlYaEBCAjA+8AqYAR0NMAlbwDC1JmbCD0t23YlNK9jCqt5Rvb9LjHL7glwoQMHhGeI21rhvjs4DGe3DyTjwHluQo4x4RtapHQkzYzeXDwxa+l68vRLZKWWTPEP/rDTZYW7si6Vk7IoySGdXxOSherl11vOYYz0NINN5Qw5xSVIVk0VBJzmYCK/bN4/NmccNCW9VISUQg/p1QE8BLPPZMxjfpbV9xvWn0y4V8rD3MRuxFGr8YtDkXc/EXXfKp1C1+hvL9a1cIJvd2fT7cIHq4yObEBGDhxx8BSu08ZCGieBdGAzGTi1NHp1A7HNQZWWcYjyAYAWXTxU7c3AE70EZ17BYuJ9PDQ5CnuFvpOTT5ZfmExmg5gTl+ZR/LShCebZKBeDfoEFPo1wMw+XS4PaoI4Z8AAtolshPcpskJ88A0xgUODbhF3KeU3hpUxo/vii5RwJMWTufKz3mxEdbaQSQ9pFXYwIgrrBm7lOeFq8gWzZpCg5iyS0=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BYAPR18MB2534.namprd18.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(376002)(346002)(396003)(39830400003)(366004)(136003)(33430700001)(71200400001)(86362001)(6916009)(508600001)(83290400001)(33440700001)(966005)(83310400001)(83280400001)(8936002)(8676002)(83300400001)(9326002)(33656002)(83320400001)(2616005)(6486002)(5660300002)(316002)(66946007)(76116006)(6512007)(64756008)(66556008)(66476007)(66446008)(6506007)(186003)(36756003)(4744005)(2906002); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: gVS23s0UwSOE5pW1jODH3fm1/K9knZsWQADLmPZ7Jfk0IV0+Ha6PpvQJmNH46EVsQ5LAVdaQqD4aUKukuyxMxmAigEKXBW+DikGeFNLeKJQI3fcMSKk/++Zr2X0/eaAWl7dNBaFU3+EzfS8igAL+qv9qY7Fvamc9So3BEBnYhy1P6mOvQ2+2ermA002mPcSsgNSEjGkZW64FIYw7NA6Si4JlH1p9R1p8cIwFmX1sJSrMk0Kkvdqs2NsS5eY+N4BzjCy11rXZfCa/Y+r6ceAgpfmLnNbKXIQPk08UYmEsRq4wi91HbhxYTS6zbgAbPqH10PLmEDCzisrpJuH1HqZV9OitT8pXHcB37WGzOXDq6FvPJDwZYlWcjmc0lF20QylsGeXL9rZAhha1DuLx1HaiNyR1mTBfRtAnyhy0kGh9qgce1Umh2Ommtao5AFbUy6DKRZht5rdcFJjB7Y+eR1+ohtbPX2XZmGm4dlMWcvKeuekSxsqHAukM/IAErfr6Qhnufjz6flvxNUS/cx224KKfTjOYytkIvne+Uj7EN1JuemGG1yMpZcJOJ5xOldbXAVuc
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_26C7F369AA1A430C850D985A3D5DA850arrcuscom_"
MIME-Version: 1.0
X-OriginatorOrg: arrcus.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4ba63e87-7cb0-416c-c22c-08d7f370f677
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2020 16:57:59.1355 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ykNBn7zs/ubgDWNvBB/JUiwy/Uin7G7R7ApP3exGxRDiOtUQUjqfO0JYbE4Oaq9LcJLjxMeGspEwKguQOPDRfQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2568
Archived-At: 
Subject: [Sidrops] WG Adoption call for draft-ymbk-sidrops-rpki-rov-timing-00.txt - ENDS 05/22/2020 (May 22 2020)
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, 08 May 2020 16:58:05 -0000

--_000_26C7F369AA1A430C850D985A3D5DA850arrcuscom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgRm9sa3MsDQoNCg0KDQpUaGUgYXV0aG9ycyBoYXZlIHJlcXVlc3RlZCBTSURST1BTIHdvcmtp
bmcgZ3JvdXAgYWRvcHRpb24gY2FsbCBvZiDigJxUaW1pbmcgUGFyYW1ldGVycyBpbiB0aGUgUlBL
SSBiYXNlZCBSb3V0ZSBPcmlnaW4gVmFsaWRhdGlvbiBTdXBwbHkgQ2hhaW7igJ0sICBodHRwczov
L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteW1iay1zaWRyb3BzLXJwa2ktcm92LXRpbWluZy0w
MC4NCg0KDQoNClBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIGxpc3QuIFRoaXMgYWRv
cHRpb24gY2FsbCB3aWxsIGNvbmNsdWRlIG9uIE1heSAyMiwgMjAyMC4NCg0KDQoNClJlZ2FyZHMs
DQoNCk5hdGhhbGllLCBDaHJpcyAmIEtleXVyDQoNCg==

--_000_26C7F369AA1A430C850D985A3D5DA850arrcuscom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv
dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg
TmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21w
b3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl
eHQ7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQ
cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s
aW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQou
TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6
MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT
ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g
MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0
eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIj
OTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cHJlPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMjEyNTI5Ij5IaSBGb2xrcyw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs
YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImNhcmV0LWNvbG9yOiBy
Z2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQt
YWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzst
d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMyMTI1MjkiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iY2FyZXQtY29sb3I6
IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4
dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRv
Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzIxMjUyOSI+VGhlIGF1dGhvcnMgaGF2ZSByZXF1ZXN0ZWQgU0lEUk9Q
UyB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIGNhbGwgb2Yg4oCcPC9zcGFuPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjpibGFjayI+VGltaW5nIFBhcmFtZXRlcnMgaW4gdGhlIFJQS0kgYmFzZWQgUm91dGUg
T3JpZ2luIFZhbGlkYXRpb24gU3VwcGx5IENoYWluPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMjEyNTI5Ij7igJ0sICZuYnNwO2h0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC15
bWJrLXNpZHJvcHMtcnBraS1yb3YtdGltaW5nLTAwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIxMjUyOSI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxl
PSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3Jw
aGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6
ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2lu
ZzowcHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5Ij5QbGVhc2Ugc2VuZCB5b3VyIGNv
bW1lbnRzIHRvIHRoZSBsaXN0LiBUaGlzIGFkb3B0aW9uIGNhbGwgd2lsbCBjb25jbHVkZSBvbiBN
YXkgMjIsIDIwMjAuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2Zv
bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dp
ZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0
cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MjEyNTI5Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7
Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7
d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQt
c3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMyMTI1MjkiPlJlZ2FyZHMsPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAs
IDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0
YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10
ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMjEyNTI5Ij5OYXRoYWxpZSwgQ2hyaXMgJmFtcDsgS2V5dXI8L3NwYW4+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_26C7F369AA1A430C850D985A3D5DA850arrcuscom_--


From nobody Fri May  8 10:03:10 2020
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 131393A0B6E for ; Fri,  8 May 2020 10:03:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 hfCrgjlYZbP2 for ; Fri,  8 May 2020 10:03:04 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4171F3A0B0B for ; Fri,  8 May 2020 10:03:02 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id EBEDA5C014F for ; Fri,  8 May 2020 13:03:01 -0400 (EDT)
Received: from imap1 ([10.202.2.51]) by compute2.internal (MEProxy); Fri, 08 May 2020 13:03:01 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=mXdN5NY36O87zlD723/PD+Il2Xvqh7fAF/D2feYpK 1U=; b=oYn+de6CUqSmyWWGP73thwZEKP0EKH/UOOkpG4FmWaZnbXflcdyvt5oNO kcRaOGdZtHfMX8BvpojexWkOxX9IJllW/osaa8WcgOn5zOMC0NJMnBb5oaGiIIOl 6Z0Q9ZIFShH78mey/SKot65h3QOeGyFItsYsvaxTAUsMIeKIyBBKcGjjRS4B+CfE 7W8ytsTnsSOt50BwYJOHjPoWFNTRy7bdGVRSM0lEBTRRApwRsYVsu+SgqpDTbUqF Kh0/412lSz/qC+7JthuHAAcbk6EoQ7Tfxrhh+xrR+pdfIk7TJkqpf3VJdyvRaq+w HcDhu/GhnOcmio7j5uh3As+8O0Xfg==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrkeefgdegvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedflfhosgcuufhnihhjuggvrhhsfdcuoehjohgssehsohgs ohhrnhhoshhtrdhnvghtqeenucggtffrrghtthgvrhhnpeegveettefhhffghffhfffgle fhudejtedvkeegkedvhefhffeifefgvedugefhvdenucffohhmrghinhepihgvthhfrdho rhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepjh hosgesshhosghorhhnohhsthdrnhgvth
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4C928C200A4; Fri,  8 May 2020 13:03:01 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-413-g750b809-fmstable-20200507v1
Mime-Version: 1.0
Message-Id: <8ba998d5-91ff-4d5b-a7b7-dee0410f63bc@www.fastmail.com>
In-Reply-To: <26C7F369-AA1A-430C-850D-985A3D5DA850@arrcus.com>
References: <26C7F369-AA1A-430C-850D-985A3D5DA850@arrcus.com>
Date: Fri, 08 May 2020 19:02:41 +0200
From: "Job Snijders" 
To: sidrops@ietf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Sidrops]  =?utf-8?q?WG_Adoption_call_for_draft-ymbk-sidrops-rpki?= =?utf-8?q?-rov-timing-00=2Etxt_-_ENDS_05/22/2020_=28May_22_2020=29?=
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, 08 May 2020 17:03:07 -0000

Hi,

On Fri, May 8, 2020, at 18:57, Keyur Patel wrote:
>  Hi Folks, =C2=A0The authors have requested SIDROPS working group adop=
tion=20
> call of =E2=80=9CTiming Parameters in the RPKI based Route Origin Vali=
dation=20
> Supply Chain=E2=80=9D,=20
> =C2=A0https://tools.ietf.org/html/draft-ymbk-sidrops-rpki-rov-timing-0=
0.=20
> =C2=A0Please send your comments to the list. This adoption call will=20=

> conclude on May 22, 2020. =C2=A0Regards, Nathalie, Chris & Keyur=20

I support adoption (as minor co-author).

I think it is useful for the industry to put out recommendations and sha=
pe expectations about RPKI propagation times.

Kind regards,

Job


From nobody Fri May  8 10:06:00 2020
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 B5CB43A0F97 for ; Fri,  8 May 2020 10:05:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id up3GZqiwlIGD for ; Fri,  8 May 2020 10:05:42 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 633953A0DF0 for ; Fri,  8 May 2020 10:05:18 -0700 (PDT)
X-Envelope-To: sidrops@ietf.org
Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id 048H5DMP014808 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 May 2020 18:05:13 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local
To: Keyur Patel 
Cc: SIDR Operations WG 
References: <26C7F369-AA1A-430C-850D-985A3D5DA850@arrcus.com>
From: Nick Hilliard 
Message-ID: 
Date: Fri, 8 May 2020 18:05:12 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.14
MIME-Version: 1.0
In-Reply-To: <26C7F369-AA1A-430C-850D-985A3D5DA850@arrcus.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Sidrops] WG Adoption call for draft-ymbk-sidrops-rpki-rov-timing-00.txt - ENDS 05/22/2020 (May 22 2020)
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, 08 May 2020 17:05:56 -0000

Keyur Patel wrote on 08/05/2020 17:57:
> The authors have requested SIDROPS working group adoption call of 
> “Timing Parameters in the RPKI based Route Origin Validation Supply 
> Chain”,  https://tools.ietf.org/html/draft-ymbk-sidrops-rpki-rov-timing-00.
> 
> Please send your comments to the list. This adoption call will conclude 
> on May 22, 2020.

this is operationally important - it should be adopted.

Nick


From nobody Fri May  8 10:34:04 2020
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 6A61F3A0E26 for ; Fri,  8 May 2020 10:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rar0c6Dc0PMW for ; Fri,  8 May 2020 10:33:56 -0700 (PDT)
Received: from out20-99.mail.aliyun.com (out20-99.mail.aliyun.com [115.124.20.99]) (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 66C5C3A0E22 for ; Fri,  8 May 2020 10:33:54 -0700 (PDT)
X-Alimail-AntiSpam: AC=CONTINUE; BC=0.07436293|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_alarm|0.0196736-0.000310973-0.980015; FP=9743990311076002568|1|1|2|0|-1|-1|-1; HT=e01a16368; MF=madi@rpstir.net; NM=1; PH=DS; RN=2; RT=2; SR=0; TI=SMTPD_---.HVNXly8_1588959227; 
Received: from 192.168.3.24(mailfrom:madi@rpstir.net fp:SMTPD_---.HVNXly8_1588959227) by smtp.aliyun-inc.com(10.147.41.137); Sat, 09 May 2020 01:33:49 +0800
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Di Ma 
In-Reply-To: 
Date: Sat, 9 May 2020 01:33:29 +0800
Cc: "sidrops@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <38D78A3D-BB4A-47B6-9507-14C116BC3FE2@rpstir.net>
References:  
To: Stephen Kent 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
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, 08 May 2020 17:34:01 -0000

Steve,

Thanks for your efforts for writing MFT update and reflecting the =
feedback from the mailing list.

I am fine with it except the re-use of previous local cache.

I find it is hard to implement the logic about retrieving objects from =
local cache with RPSTIR2.=20

As I replied to Robert in your discussion with him, in terms of =
synchronization, RPSTIR2 keeps its incumbent local version exactly the =
same with global repositories.

Although RPSTIR2 keeps the historic versions locally, they are stored =
for diagnose and analysis (maybe to trigger SLURM)

If some RP can retrieve missing objects while others can not, data =
inconsistence will occur among different RPs.

I think we just need to keep RP in alignment with PP and then can =
perform some analysis and diagnose (if necessary) to ascertain errors =
(RFC 8211) to give warning or make use of SLURM (RFC8416) if the RP =
operator is confident enough that he catch the wrong data and knows how =
to remedy locally.

To sum up, I would like to see :

1) RPs are encouraged to store historic versions locally especially the =
validated RTR-output

2) If the RP finds some missing objects (not in the CRL, still in the =
MFT) , it is suggested to issue warning to operators and SLURM can be =
used by the historic data.

I therefore really look forwards to hearing from folks of other RP =
software to comment on this.

Di

> 2020=E5=B9=B45=E6=9C=888=E6=97=A5 23:26=EF=BC=8CStephen Kent =
 =E5=86=99=E9=81=93=EF=BC=9A
>=20
>=20
> 6.  Relying Party Use of Manifests
> =20
> Each RP must determine which signed objects it will use for
> validating assertions about INRs and their use (e.g., which ROAs to
> use in the construction of route filters). Manifests are designed=20
> to allow an RP to detect manipulation of repository data and/or=20
> errors by a CA or repository manager. Unless all of the files=20
> enumerated in a manifest can be obtained by an RP (either from a=20
> publication point or from a local cache), an RP MUST ignore the
> data associated with the publication point. This stringent response
> is needed to prevent an RP from misinterpreting data associated with
> a publication point, and thus possibly treating invalid routes as
> valid, or vice versa.
> =20
> The processing described below is designed to cause all RPs with=20
> access to the same local cache and RPKI repository data to achieve=20
> the same results with regard to validation of RPKI data. However, in
> operation, different RPs will access repositories at different times,
> and some RPs may experience local cache failures, so there is no=20
> guarantee that all RPs will achieve the same results with regard to=20
> validation of RPKI data
> =20
> Note that there is a =E2=80=9Cchicken and egg=E2=80=9D relationship =
between the=20
> manifest and the CRL for a given CA instance. If the EE certificate=20
> for the current manifest is revoked, i.e., it appears in the current =
CRL,
> then the CA or publication point manager has made a serious error. In =
this=20
> case all signed objects associated with the CA instance MUST be =
ignored.=20
> Similarly, if the CRL is not listed on a valid, current manifest, all=20=

> signed objects associated with the CA instance MUST be ignored, =
because=20
> the CRL is considered missing.=20
> =20
> =20
> =20
> 6.1. Manifest Processing Overview
>=20
> For a given publication point, an RP MUST perform a series of tests to
> determine which signed object files at the publication point are
> acceptable. The tests described below are to be performed using the=20
> manifest identified by the id-ad-rpkiManifest URI extracted from a CA =
certificate=E2=80=99s SIA. All of the files referenced by the manifest =
MUST be=20
> be located at the publication point specified by the =
id-ad-caRepository=20
> URI from the (same) certificate=E2=80=99s SIA. If the manifest and the =
files it
> references do not reside at the same publication point, an RP MUST ???
> =20
> A manifest SHOULD contain exactly one CRL (.crl) file and it MUST be =
at=20
> the location specified in the CRLDP in the manifest=E2=80=99s EE =
certificate.
> If more than one .crl file appears in the manifest, only file names=20
> matching the CRL specified by the CRLDP will be processed. If more =
than=20
> one .crl entry appears in the manifest, and matches the CRLDP, the =
first=20
> one encountered MUST be used.  Any other .crl files MUST be ignored =
and a warning MUST be issued.
> =20
> Note that, during CA key rollover [RFC6489], signed objects for two or=20=

> more different CA instances will appear at the same publication point.=20=

> Manifest processing is to be performed separately for each CA =
instance,=20
> guided by the SIA id-ad-rpkiManifest URI in each CA certificate.
> =20
> Note also that the processing described here will be performed using=20=

> locally cached files if an RP does not detect newer versions of the =
files
> in the RPKI repository system.
>=20
>=20
> 6.2 Acquiring a Manifest for a CA
> =20
> Acquire the manifest identified by the SIA id-ad-rpkiManifest URI
> in the CA certificate. If an RP cannot retrieve a manifest using this=20=

> URI, or if the manifest is not valid (Section 4.4), an RP SHOULD =
examine=20
> the most recent, cached manifest matching this URI. If that manifest =
is=20
> current (Section 4.4) proceed to 6.3. If the publication point=20
> does not contain a valid manifest, and the cached manifest is not =
current,
> proceed to 6.7.
>=20
>=20
> 6.3 Detecting Stale and or Prematurely-issued Manifests
> =20
> Check that the current time (translated to UTC) is between=20
> thisUpdate and nextUpdate. If the current time lies within this =
interval,=20
> proceed to 6.4. If the current time is earlier than thisUpdate, the CA=20=

> has made an error. If the RP cache contains a current manifest, use =
that manifest instead and issue a warning. If an RP has no access to a =
current manifest, processing stops and a warning MUST be issued. If the =
current=20
> time is later than nextUpdate, then the manifest is stale. If the RP =
cache contains a current manifest, use that manifest instead and issue a =
warning.
> If no current manifest is available, proceed to 6.7.
>=20
>=20
> 6.4 Acquiring Files Referenced by a Manifest
> =20
> Acquire all files enumerated in the manifest (fileList) from=20
> the publication point. This includes the CRL, each object containing =
an=20
> EE certificate issued by the C, and all subordinate CA and EE =
certificates.=20
> If  there are files listed in the manifest that cannot be retrieved =
from=20
> the publication point, or if they fail the validity tests specified in=20=

> [RFC6488], the RP SHOULD examine its cache to determine if these files=20=

> are available locally. If all of the missing/invalid files are =
available
> from the RP=E2=80=99s cache, i.e., each file name matches the list =
extracted from=20
> the manifest, the RP SHOULD use the cached files to replace those =
missing=20
> from the publication point, and proceed to 6.5. However, if any of the =
missing/invalid files cannot be replaced in this fashion, then proceed =
to 6.7.
>=20
> 6.5 Matching File Names and Hashes
> =20
> Verify that the hash value of every file listed in the=20
> manifest matches the value obtained by hashing the file acquired from =
the=20
> publication point or local cache. If the computed hash value of a file=20=

> listed on the manifest does not match the hash value contained in the=20=

> manifest, then an RP SHOULD examine its local cache to determine if =
the
> same file is available. The RP SHOULD use cached files to replace any=20=

> (damaged) downloaded files, so long as the hash of the cached file =
matches=20
> the hash from the manifest. If any of the files with hash mismatches=20=

> cannot be replaced in this fashion, proceed to 6.7. Otherwise proceed =
to 6.6.
>=20
>=20
> 6.6 Out of Scope Manifest Entries
> =20
> If a current manifest contains entries for objects that are not=20
> within the scope of the manifest (Section 2), then the out-of-scope=20
> entries MUST be disregarded.=20
>=20
>=20
> 6.7 Termination of Processing
> =20
> If an RP cannot acquire a current, valid manifest, or acquire current,=20=

> valid instances of all of the objects enumerated in a current valid=20
> manifest, then processing of the signed objects associated with the CA
> has failed. The RP MUST issue a warning indicating the reason(s) for =
termination of processing with regard to this CA.=20
> =20
> Termination or processing means that all of the ROAs and subordinate =
certificates (CA and EE) MUST be considered invalid. This implies that=20=

> the RP MUST not try to acquire and validate subordinate signed =
objects,=20
> until the next interval when the RP is scheduled to process data for=20=

> this part of the RPKI repository system.
>=20
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
>=20


From nobody Fri May  8 11:01:18 2020
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 80F4C3A0ECC for ; Fri,  8 May 2020 11:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujyJ2sNQDLqP for ; Fri,  8 May 2020 11:01:13 -0700 (PDT)
Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (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 4EDD53A0EC2 for ; Fri,  8 May 2020 11:01:12 -0700 (PDT)
Received: by mail-wr1-f44.google.com with SMTP id i15so2898926wrx.10 for ; Fri, 08 May 2020 11:01:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=InJMDz6mkHC/kT22zDuc9ADV9Nu9wuy8RGUrGlnfJ+I=; b=lDHFK6MeSAhwZONneD6i7Yk2NH/w6Oekjdmf5FNUPdyLiFC1F0Tdc1SH07aApI5la2 s1yZuBtN8ZbPAOmHzo/xAPBZqQJxxDpQdwFkLj3EzQiMAWtIUlqiAQgtu0e4/V9nahiJ fOlhYeGPgAf6SZjetNWA50Wi2gIA/Cay21So0hwdebH0X2aIKHSovzynySRrF6PG8l/z hqbfn+KgOQ9tinEflaRtFXIMI+HS4eLG9oRzm9C7ghks8dLk2EnHhSB9izk0CtaZzFNW N0BKFhJw1BT/S8O+aH0FtT08n9901Lqd7Tnu/ABhHHHk1DC0fqddTbEi5cC7gHebodzL ZTZw==
X-Gm-Message-State: AGi0Pua/tMk0JtN6fRxEg3Ge9fSd4J3GlAcSQV8qPknmAXU0lb6HwLR3 Zlk7MZ8rBYRBxBFYAEfmvxg8YTWnVVg=
X-Google-Smtp-Source: APiQypJ4hhAxa9dTtiY/DnIPdDiFSgpS8BpNJOWF81S34NvUAR2N7GgthbkH1NpAQe4s/MyHr8iN5Q==
X-Received: by 2002:a5d:690a:: with SMTP id t10mr4233759wru.225.1588960841412;  Fri, 08 May 2020 11:00:41 -0700 (PDT)
Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id g10sm3857030wrx.4.2020.05.08.11.00.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 May 2020 11:00:40 -0700 (PDT)
Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id c8be7ca4; Fri, 8 May 2020 18:00:39 +0000 (UTC)
Date: Fri, 8 May 2020 18:00:39 +0000
From: Job Snijders 
To: Di Ma , sidrops@ietf.org
Message-ID: <20200508180039.GA18937@vurt.meerval.net>
References:   <38D78A3D-BB4A-47B6-9507-14C116BC3FE2@rpstir.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <38D78A3D-BB4A-47B6-9507-14C116BC3FE2@rpstir.net>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: 
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
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, 08 May 2020 18:01:17 -0000

Dear Di Ma,

On Sat, May 09, 2020 at 01:33:29AM +0800, Di Ma wrote:
> Thanks for your efforts for writing MFT update and reflecting the
> feedback from the mailing list.
> 
> I am fine with it except the re-use of previous local cache.
>
> I find it is hard to implement the logic about retrieving objects from
> local cache with RPSTIR2. 

Can you elaborate on why it is hard in RSTPIR2? I am not familiar with
this implementation and can perhaps learn from it, or offer suggestions.

> As I replied to Robert in your discussion with him, in terms of
> synchronization, RPSTIR2 keeps its incumbent local version exactly the
> same with global repositories.

An RP can't know if it is in sync with the global repository. The trust
derives from the pre-obtained RPKI TALs, through the X509 validation
procedure and outputs Validated ROA Payloads.

In this process the data that can be *least* trusted is what came in via
the untrusted network channel (be it rsync or RRDP). Withholding or
corruption by issuing 'withdraws' (RRDP)  or '--delete' (rsync) cannot
be trusted at all. With this in mind, one really really aught to
reconstruct the original publication point's repository, suppplementing
it with locally cached data as much as possible.

> Although RPSTIR2 keeps the historic versions locally, they are stored
> for diagnose and analysis (maybe to trigger SLURM)
> 
> If some RP can retrieve missing objects while others can not, data
> inconsistence will occur among different RPs.

This already always is the case, and will not change. RPs pull from the
CA's publication point from different places on the Internet, at
different times.

> I think we just need to keep RP in alignment with PP and then can
> perform some analysis and diagnose (if necessary) to ascertain errors
> (RFC 8211) to give warning or make use of SLURM (RFC8416) if the RP
> operator is confident enough that he catch the wrong data and knows
> how to remedy locally.

How will the RP stay in alignment with the PP when the RP is under
attack? Intercepting and corrupting rsync connections is trivial and the
RRDP protocol does not offer protections against unauthorised
modification of the data presented to the RP.

> To sum up, I would like to see :
> 
> 1) RPs are encouraged to store historic versions locally especially
> the validated RTR-output

> 2) If the RP finds some missing objects (not in the CRL, still in the
> MFT) , it is suggested to issue warning to operators and SLURM can be
> used by the historic data.

What is the 'timing' of the process you describe under (2)? I cannot
imagine any manual intervention in the validation process to scale for
the purpose of the Internet routing system. Perhaps I'm
misunderstanding.

> I therefore really look forwards to hearing from folks of other RP
> software to comment on this.

It is my intention to provide the working group with an implementation
report of OpenBSD's current rpki-client version in relation to the text
that Stephen Kent provided today as 'rev 4'. I hope to be able to do
that next week. My report will be usable as a template for other
implementation maintainers. Comparing and sharing implementation notes
is fun, stay tuned!

Kind regards,

Job


From nobody Sat May  9 16:44:49 2020
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 8E3AA3A0C12; Sat,  9 May 2020 16:44:17 -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.129.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: sidrops@ietf.org
Message-ID: <158906785736.20107.17484732335682046394@ietfa.amsl.com>
Date: Sat, 09 May 2020 16:44:17 -0700
Archived-At: 
Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rpkimaxlen-04.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 09 May 2020 23:44:18 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIDR Operations WG of the IETF.

        Title           : The Use of Maxlength in the RPKI
        Authors         : Yossi Gilad
                          Sharon Goldberg
                          Kotikalapudi Sriram
                          Job Snijders
                          Ben Maddison
	Filename        : draft-ietf-sidrops-rpkimaxlen-04.txt
	Pages           : 12
	Date            : 2020-05-09

Abstract:
   This document recommends ways to reduce forged-origin attack surface
   by prudently limiting the address space that is included in Route
   Origin Authorizations (ROAs).  One recommendation is to avoid using
   the maxLength attribute in ROAs except in some specific cases.  The
   recommendations complement and extend those in RFC 7115.  The
   document also discusses creation of ROAs for facilitating Distributed
   Denial of Service (DDoS) mitigation services.  Considerations related
   to ROAs and origin validation for the case of destination-based
   Remote Triggered Black Hole (RTBH) filtering are also highlighted.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpkimaxlen/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sidrops-rpkimaxlen-04
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpkimaxlen-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rpkimaxlen-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/



From nobody Sun May 10 11:52:11 2020
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 AA6FD3A0B1D for ; Sun, 10 May 2020 11:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNqkjHYxrEYj for ; Sun, 10 May 2020 11:52:08 -0700 (PDT)
Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 08C403A0B1B for ; Sun, 10 May 2020 11:52:08 -0700 (PDT)
Received: by mail-ot1-x32e.google.com with SMTP id i27so5778385ota.7 for ; Sun, 10 May 2020 11:52:08 -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=QZ73AEHc4VqzAUms6gaqjV08xpZa0eXlG2qUSrL2RTk=; b=Jm9eY6fhwexnCZFE3PmFdqNeg79yXCWSc6lIKOjZv51nXh6lg3QL0Z5Buz36UUrUWy m4EIW/AOxqYqVOvA+MqghWelCDRk3nQhmCLN4c9IN71J3RRVYyE6s8kjqMgWzmwIzcSZ u4x3OmGv77YT/nXP7NDyojooVcu05fTxVkCdsEhN6WfDUmYFcNMqh58LOMzqKMutfWbh +ooKR0mZ0O+LX8KQcToPnbvoJBH449hV7M+mMzpTyMwdlFh0SVt3C0a1t7hLYw5B+qLZ W+i5f8Z0tcX6cNB2clhKj/Q//9kWrvCdHnazEmk7SORsR228nid2yWbVU2NT+MYFGc6p nAPQ==
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=QZ73AEHc4VqzAUms6gaqjV08xpZa0eXlG2qUSrL2RTk=; b=gjg8Eg1L8dBdVNr0EiPbxL82WXtssOTw/haYOaW9eafwHnaNJkyWSFuLx7ZIT7vhV2 ul8VP/btAYb75MECt3L++wwqbYeDfBMntIVesYRxOTFax7G6trrU8jHgX0NuNlNunWle v+ZQx4Sn2u6hSl8HjmUSanCxttg2k1uURw6AgjZgjUmRdH7p3VYlOVhNdUnuOlkMVuCc sl8YtSWdZwV46vSXStNUN6fIad1j1eOH6XWSVJu/5iNJ/4Wu1xAPZQDnBV4BaiEZo5rc aUWkfcDIamFQQZ+r6EJTB925S4bn5y8iyphKV51EMtYPMx7brU48InCWX+TDu0/90dKI BCaA==
X-Gm-Message-State: AGi0PuZupECSNVccY1BCzqB6117413PQztVMVuCheQlv/pDGSpiKKFr9 0Blzf/w93OkL+wV++nEv3rVC72e3TFiyRSv4hNI=
X-Google-Smtp-Source: APiQypJ52QEXkFDSItw/8j6ft71/kS4OlEfmkQSK59or9xIeXhEP51NTlVYWJ9w0Og5LQYP4OiUvpvOJfDqSbAqjSEI=
X-Received: by 2002:a05:6830:1e9c:: with SMTP id n28mr9216260otr.27.1589136727196;  Sun, 10 May 2020 11:52:07 -0700 (PDT)
MIME-Version: 1.0
References:   
In-Reply-To: 
From: Alexander Azimov 
Date: Sun, 10 May 2020 21:51:56 +0300
Message-ID: 
To: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" 
Cc: "rv@nic.dtag.de" , SIDR Operations WG 
Content-Type: multipart/alternative; boundary="0000000000001fc91605a54fbace"
Archived-At: 
Subject: Re: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04
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: Sun, 10 May 2020 18:52:10 -0000

--0000000000001fc91605a54fbace
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Yunan,

Please see my comments below.

=D1=81=D1=80, 6 =D0=BC=D0=B0=D1=8F 2020 =D0=B3. =D0=B2 10:12, Guyunan (Yuna=
n Gu, IP Technology Research Dept.
NW) :

> Hi Alex,
>
>
>
> Thanks for the elaboration, which totally makes sense to me. A suggestion
> here, the description of how to deal with the P2P relation using ASPA (ju=
st
> as what you described below) can be added to the draft for clarification.
>
>
>
> Further, Section 5.2 says:
>
> When route is received from provider or RS it may have both Upstream
>
>    and Downstream paths, where a Downstream follows an Upstream path.
>
>
>
> The =E2=80=9Cdownstream=E2=80=9D refers to both P2C path and P2P path, ri=
ght? If so, I
> suggest to change the usage of =E2=80=9Cdownstream=E2=80=9D to =E2=80=9Cn=
on-upstream=E2=80=9D or similar
> wording to avoid confusion.
>
I do agree, this part isn't clear. I'll try to rephrase it.


> Another point to confirm with you about Section 5.2:
>
> Additional caution should be exercised when processing prefixes that
>
>    are received from transparent IXes, as they don't add their ASN in
>
>    the ASPATH.
>
>
>
> To my understanding, that in this draft, you assume by default that RS
> prepends its own ASN to the AS_Path, right?
>
No, there is no such assumption.


> And a final question about Section 7 Siblings (Complex Relations),
> regardless of the current description of what sibling relation is, do we
> think that sibling ASes are ASes that belong to the same operator? So any
> type of transition is free of charge?
>
Speaking about ASPA, we are speaking about peering relations, without any
guess about the business between parties.
And from what I know - siblings are also spread among small networks, so
this term is not strictly bound to the same administrative domain.

--0000000000001fc91605a54fbace
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Yunan,

Please see m=
y comments below.

=D1=81=D1=80, 6 =D0=BC=D0=B0=D1=8F 2020 =D0=B3. =D0=
=B2 10:12, Guyunan (Yunan Gu, IP Technology Research Dept. NW) <guyunan@huawei.com>:











Hi Alex,


=C2=A0


Thanks for the elaboration, which totally ma=
kes sense to me. A suggestion here, the description of how to deal with the=
 P2P relation using ASPA (just as what
 you described below) can be added to the draft for clarification. <=
u>


=C2=A0


Further, Section 5.2 says:


When route is received from provider or RS it ma=
y have both Upstream


=C2=A0=C2=A0 and Downstream paths, where a Downs=
tream follows an Upstream path.


=C2=A0


The =E2=80=9Cdownstream=E2=80=9D refers to b=
oth P2C path and P2P path, right? If so, I suggest to change the usage of =
=E2=80=9Cdownstream=E2=80=9D to =E2=80=9Cnon-upstream=E2=80=9D or similar w=
ording to avoid
 confusion.
I do agree, this part i=
sn't clear. I'll try to rephrase it.
=C2=A0


Another point to confirm with you about Sect=
ion 5.2:


Additional caution should be exercised when proc=
essing prefixes that


=C2=A0=C2=A0 are received from transparent IXes,=
 as they don't add their ASN in


=C2=A0=C2=A0 the ASPATH.

=C2=A0


To my understanding, that in this draft, you=
 assume by default that RS prepends its own ASN to the AS_Path, right? =C2=
=A0
No, there is no such assumption=
.
=C2=A0
<=
div lang=3D"EN-US">


And a final question about Section 7 Sibling=
s (Complex Relations), regardless of the current description of what siblin=
g relation is, do we think that sibling
 ASes are ASes that belong to the same operator? So any type of transition =
is free of charge?
Speaking about A=
SPA, we are speaking about peering relations, without any guess about the b=
usiness between parties.=C2=A0
And from what I know - siblings ar=
e also spread among small networks,=C2=A0so this term is not strictly bound=
 to the same=C2=A0administrative=C2=A0domain.


--0000000000001fc91605a54fbace--


From nobody Sun May 10 18:26:10 2020
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 017BF3A0C7E for ; Sun, 10 May 2020 18:26:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dhlnq8RruPxw for ; Sun, 10 May 2020 18:26:06 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 D00853A0C7C for ; Sun, 10 May 2020 18:26:05 -0700 (PDT)
Received: from lhreml744-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 95EF1B59658354033D53; Mon, 11 May 2020 02:26:03 +0100 (IST)
Received: from lhreml744-chm.china.huawei.com (10.201.108.194) by lhreml744-chm.china.huawei.com (10.201.108.194) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 11 May 2020 02:26:03 +0100
Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by lhreml744-chm.china.huawei.com (10.201.108.194) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Mon, 11 May 2020 02:26:02 +0100
Received: from DGGEML532-MBX.china.huawei.com ([169.254.8.202]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0487.000; Mon, 11 May 2020 09:25:57 +0800
From: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" 
To: Alexander Azimov 
CC: "rv@nic.dtag.de" , SIDR Operations WG 
Thread-Topic: question on draft-ietf-sidrops-aspa-verification-04
Thread-Index: AdYdy08vebzctU/sRBSjzmRHyKjH2ACpL0yAALmBBzAA2L1MAAAdy1hg
Date: Mon, 11 May 2020 01:25:56 +0000
Message-ID: 
References:    
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.108.203.151]
Content-Type: multipart/alternative; boundary="_000_C01B0098369B2D4391851938DA6700B717A28020DGGEML532MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04
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, 11 May 2020 01:26:08 -0000

--_000_C01B0098369B2D4391851938DA6700B717A28020DGGEML532MBXchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgQWxleCwNCg0KVGhhbmtzIGEgbG90IGZvciB0aGUgcmVwbHkuIFBsZWFzZSBmaW5kIG15IGZ1
cnRoZXIgY29tbWVudHMgaW5saW5lLg0KDQpGcm9tOiBBbGV4YW5kZXIgQXppbW92IFttYWlsdG86
YS5lLmF6aW1vdkBnbWFpbC5jb21dDQpTZW50OiBNb25kYXksIE1heSAxMSwgMjAyMCAyOjUyIEFN
DQpUbzogR3V5dW5hbiAoWXVuYW4gR3UsIElQIFRlY2hub2xvZ3kgUmVzZWFyY2ggRGVwdC4gTlcp
IDxndXl1bmFuQGh1YXdlaS5jb20+DQpDYzogcnZAbmljLmR0YWcuZGU7IFNJRFIgT3BlcmF0aW9u
cyBXRyA8c2lkcm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBxdWVzdGlvbiBvbiBkcmFmdC1p
ZXRmLXNpZHJvcHMtYXNwYS12ZXJpZmljYXRpb24tMDQNCg0KSGkgWXVuYW4sDQoNClBsZWFzZSBz
ZWUgbXkgY29tbWVudHMgYmVsb3cuDQoNCtGB0YAsIDYg0LzQsNGPIDIwMjAg0LMuINCyIDEwOjEy
LCBHdXl1bmFuIChZdW5hbiBHdSwgSVAgVGVjaG5vbG9neSBSZXNlYXJjaCBEZXB0LiBOVykgPGd1
eXVuYW5AaHVhd2VpLmNvbTxtYWlsdG86Z3V5dW5hbkBodWF3ZWkuY29tPj46DQpIaSBBbGV4LA0K
DQpUaGFua3MgZm9yIHRoZSBlbGFib3JhdGlvbiwgd2hpY2ggdG90YWxseSBtYWtlcyBzZW5zZSB0
byBtZS4gQSBzdWdnZXN0aW9uIGhlcmUsIHRoZSBkZXNjcmlwdGlvbiBvZiBob3cgdG8gZGVhbCB3
aXRoIHRoZSBQMlAgcmVsYXRpb24gdXNpbmcgQVNQQSAoanVzdCBhcyB3aGF0IHlvdSBkZXNjcmli
ZWQgYmVsb3cpIGNhbiBiZSBhZGRlZCB0byB0aGUgZHJhZnQgZm9yIGNsYXJpZmljYXRpb24uDQoN
CkZ1cnRoZXIsIFNlY3Rpb24gNS4yIHNheXM6DQpXaGVuIHJvdXRlIGlzIHJlY2VpdmVkIGZyb20g
cHJvdmlkZXIgb3IgUlMgaXQgbWF5IGhhdmUgYm90aCBVcHN0cmVhbQ0KICAgYW5kIERvd25zdHJl
YW0gcGF0aHMsIHdoZXJlIGEgRG93bnN0cmVhbSBmb2xsb3dzIGFuIFVwc3RyZWFtIHBhdGguDQoN
ClRoZSDigJxkb3duc3RyZWFt4oCdIHJlZmVycyB0byBib3RoIFAyQyBwYXRoIGFuZCBQMlAgcGF0
aCwgcmlnaHQ/IElmIHNvLCBJIHN1Z2dlc3QgdG8gY2hhbmdlIHRoZSB1c2FnZSBvZiDigJxkb3du
c3RyZWFt4oCdIHRvIOKAnG5vbi11cHN0cmVhbeKAnSBvciBzaW1pbGFyIHdvcmRpbmcgdG8gYXZv
aWQgY29uZnVzaW9uLg0KSSBkbyBhZ3JlZSwgdGhpcyBwYXJ0IGlzbid0IGNsZWFyLiBJJ2xsIHRy
eSB0byByZXBocmFzZSBpdC4NCg0KQW5vdGhlciBwb2ludCB0byBjb25maXJtIHdpdGggeW91IGFi
b3V0IFNlY3Rpb24gNS4yOg0KQWRkaXRpb25hbCBjYXV0aW9uIHNob3VsZCBiZSBleGVyY2lzZWQg
d2hlbiBwcm9jZXNzaW5nIHByZWZpeGVzIHRoYXQNCiAgIGFyZSByZWNlaXZlZCBmcm9tIHRyYW5z
cGFyZW50IElYZXMsIGFzIHRoZXkgZG9uJ3QgYWRkIHRoZWlyIEFTTiBpbg0KICAgdGhlIEFTUEFU
SC4NCg0KVG8gbXkgdW5kZXJzdGFuZGluZywgdGhhdCBpbiB0aGlzIGRyYWZ0LCB5b3UgYXNzdW1l
IGJ5IGRlZmF1bHQgdGhhdCBSUyBwcmVwZW5kcyBpdHMgb3duIEFTTiB0byB0aGUgQVNfUGF0aCwg
cmlnaHQ/DQpObywgdGhlcmUgaXMgbm8gc3VjaCBhc3N1bXB0aW9uLg0KDQpZdW5hbjogQWxsIHJp
Z2h0LCBzbyBsZXTigJlzIGFzc3VtZSBpbiBvbmUgY2FzZSwgdGhlIElYUCBkb2VzIG5vdCBwcmVw
ZW5kIGl0cyBvd24gQVNOLCBtZWFuaW5nIHRoZSBSUyBhbmQgb25lIG9mIGl0cyBSUyBjbGllbnRz
IHJlY2VpdmVzIHRoZSBzYW1lIEFTX1BhdGgsIHJpZ2h0PyBBY2NvcmRpbmcgdG8gU2VjdGlvbiA1
LjEgKHNlZSBiZWxvdykgYW5kIFNlY3Rpb24gNS4yIChzZWUgYmVsb3cpLCBJ4oCZbSB3b25kZXJp
bmcgd2h5IHRoZSBkZXRlY3Rpb24gcnVsZXMgYXJlIGRpZmZlcmVudCBmb3IgdGhpcyBSUyAob2Jl
eWluZyBTZWN0aW9uIDUuMSkgYW5kIHRoaXMgUlMgY2xpZW50IChvYmV5aW5nIFNlY3Rpb24gNS4y
KSByZWdhcmRpbmcgdGhlIHNhbWUgQVNfUGF0aC4NCg0KU2VjdGlvbiA1LjENCiAgIFdoZW4gYSBy
b3V0ZSBpcyByZWNlaXZlZCBmcm9tIGEgY3VzdG9tZXIsIGEgbGl0ZXJhbCBwZWVyLCBvciBieSBh
IFJTDQogICBhdCBhbiBJWCwgZWFjaCBwYWlyIChBUyhJLTEpLCBBUyhJKSkgTVVTVCBiZWxvbmcg
dG8gY3VzdG9tZXItcHJvdmlkZXINCiAgIG9yIHNpYmxpbmcgcmVsYXRpb25zaGlwLg0KU2VjdGlv
biA1LjINCiAgV2hlbiByb3V0ZSBpcyByZWNlaXZlZCBmcm9tIHByb3ZpZGVyIG9yIFJTIGl0IG1h
eSBoYXZlIGJvdGggVXBzdHJlYW0NCiAgIGFuZCBEb3duc3RyZWFtIHBhdGhzLCB3aGVyZSBhIERv
d25zdHJlYW0gZm9sbG93cyBhbiBVcHN0cmVhbSBwYXRoLg0KDQpBbmQgYSBmaW5hbCBxdWVzdGlv
biBhYm91dCBTZWN0aW9uIDcgU2libGluZ3MgKENvbXBsZXggUmVsYXRpb25zKSwgcmVnYXJkbGVz
cyBvZiB0aGUgY3VycmVudCBkZXNjcmlwdGlvbiBvZiB3aGF0IHNpYmxpbmcgcmVsYXRpb24gaXMs
IGRvIHdlIHRoaW5rIHRoYXQgc2libGluZyBBU2VzIGFyZSBBU2VzIHRoYXQgYmVsb25nIHRvIHRo
ZSBzYW1lIG9wZXJhdG9yPyBTbyBhbnkgdHlwZSBvZiB0cmFuc2l0aW9uIGlzIGZyZWUgb2YgY2hh
cmdlPw0KU3BlYWtpbmcgYWJvdXQgQVNQQSwgd2UgYXJlIHNwZWFraW5nIGFib3V0IHBlZXJpbmcg
cmVsYXRpb25zLCB3aXRob3V0IGFueSBndWVzcyBhYm91dCB0aGUgYnVzaW5lc3MgYmV0d2VlbiBw
YXJ0aWVzLg0KQW5kIGZyb20gd2hhdCBJIGtub3cgLSBzaWJsaW5ncyBhcmUgYWxzbyBzcHJlYWQg
YW1vbmcgc21hbGwgbmV0d29ya3MsIHNvIHRoaXMgdGVybSBpcyBub3Qgc3RyaWN0bHkgYm91bmQg
dG8gdGhlIHNhbWUgYWRtaW5pc3RyYXRpdmUgZG9tYWluLg0KDQpZdW5hbjogd2VsbCwgSeKAmW0g
dHJ5aW5nIHRvIHVuZGVyc3RhbmQgd2hhdCBpdCBtZWFucyBieSDigJxzaWJsaW5n4oCdLiBZb3Vy
IGRyYWZ0IGRlZmluZXMgaG93IEFTUEEgcmVjb3JkcyBhcmUgY3JlYXRlZCBmb3Ig4oCcc2libGlu
Z+KAnSByZWxhdGlvbnMsIGJ1dCBubyBwcmVjaXNlIGRlZmluaXRpb24gaXMgZ2l2ZW4gKG9ubHkg
ZXhhbXBsZXMpLiBJIHVuZGVyc3RhbmQgSXQgaXMgYSBjb21wbGV4IHJlbGF0aW9uLCBhcyBzdGF0
ZWQgaW4gdGhlIGRyYWZ0LCBidXQgc3RpbGwsIEnigJltIGNvbmZ1c2VkIG9mIHRoZSBhY3R1YWwg
cGVlcmluZyByZWxhdGlvbnMgd2hlbiB3ZSB0YWxrIGFib3V0IOKAnHNpYmxpbmfigJ0uIENhbiB5
b3UgbWF5YmUgcHJvdmlkZSBhIG1vcmUgc3BlY2lmaWMgdGV4dCBkZWZpbml0aW9uPw0KDQoNCg==

--_000_C01B0098369B2D4391851938DA6700B717A28020DGGEML532MBXchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ
cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu
ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs
aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K
Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29y
ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0
IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9
DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2
OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg
Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg
djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd
LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs
ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEFsZXgsPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgYSBsb3QgZm9yIHRoZSByZXBseS4gUGxlYXNl
IGZpbmQgbXkgZnVydGhlciBjb21tZW50cyBpbmxpbmUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQWxleGFuZGVyIEF6
aW1vdiBbbWFpbHRvOmEuZS5hemltb3ZAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1v
bmRheSwgTWF5IDExLCAyMDIwIDI6NTIgQU08YnI+DQo8Yj5Ubzo8L2I+IEd1eXVuYW4gKFl1bmFu
IEd1LCBJUCBUZWNobm9sb2d5IFJlc2VhcmNoIERlcHQuIE5XKSAmbHQ7Z3V5dW5hbkBodWF3ZWku
Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gcnZAbmljLmR0YWcuZGU7IFNJRFIgT3BlcmF0aW9ucyBX
RyAmbHQ7c2lkcm9wc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IHF1ZXN0
aW9uIG9uIGRyYWZ0LWlldGYtc2lkcm9wcy1hc3BhLXZlcmlmaWNhdGlvbi0wNDxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBZdW5hbiw8bzpwPjwvbzpwPjwv
cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBzZWUgbXkgY29tbWVudHMg
YmVsb3cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPtGB0YAsIDYg0LzQsNGPIDIwMjAg0LMuINCyIDEwOjEyLCBHdXl1bmFuIChZdW5hbiBHdSwg
SVAgVGVjaG5vbG9neSBSZXNlYXJjaCBEZXB0LiBOVykgJmx0OzxhIGhyZWY9Im1haWx0bzpndXl1
bmFuQGh1YXdlaS5jb20iPmd1eXVuYW5AaHVhd2VpLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s
aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu
OHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBBbGV4LDwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgdGhlIGVsYWJvcmF0
aW9uLCB3aGljaCB0b3RhbGx5IG1ha2VzIHNlbnNlIHRvIG1lLiBBIHN1Z2dlc3Rpb24gaGVyZSwg
dGhlIGRlc2NyaXB0aW9uIG9mDQogaG93IHRvIGRlYWwgd2l0aCB0aGUgUDJQIHJlbGF0aW9uIHVz
aW5nIEFTUEEgKGp1c3QgYXMgd2hhdCB5b3UgZGVzY3JpYmVkIGJlbG93KSBjYW4gYmUgYWRkZWQg
dG8gdGhlIGRyYWZ0IGZvciBjbGFyaWZpY2F0aW9uLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RnVydGhlciwgU2VjdGlvbiA1LjIgc2F5czo8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs
YWNrIj5XaGVuIHJvdXRlIGlzIHJlY2VpdmVkIGZyb20gcHJvdmlkZXIgb3IgUlMgaXQgbWF5IGhh
dmUgYm90aCBVcHN0cmVhbTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhbmQgRG93bnN0cmVhbSBw
YXRocywgd2hlcmUgYSBEb3duc3RyZWFtIGZvbGxvd3MgYW4gVXBzdHJlYW0gcGF0aC48L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUg4oCcZG93bnN0cmVh
beKAnSByZWZlcnMgdG8gYm90aCBQMkMgcGF0aCBhbmQgUDJQIHBhdGgsIHJpZ2h0PyBJZiBzbywg
SSBzdWdnZXN0IHRvIGNoYW5nZSB0aGUgdXNhZ2UNCiBvZiDigJxkb3duc3RyZWFt4oCdIHRvIOKA
nG5vbi11cHN0cmVhbeKAnSBvciBzaW1pbGFyIHdvcmRpbmcgdG8gYXZvaWQgY29uZnVzaW9uLjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkbyBhZ3JlZSwgdGhpcyBwYXJ0IGlzbid0IGNsZWFy
LiBJJ2xsIHRyeSB0byByZXBocmFzZSBpdC48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6
bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g
Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFu
b3RoZXIgcG9pbnQgdG8gY29uZmlybSB3aXRoIHlvdSBhYm91dCBTZWN0aW9uIDUuMjo8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs
YWNrIj5BZGRpdGlvbmFsIGNhdXRpb24gc2hvdWxkIGJlIGV4ZXJjaXNlZCB3aGVuIHByb2Nlc3Np
bmcgcHJlZml4ZXMgdGhhdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhcmUgcmVjZWl2ZWQgZnJv
bSB0cmFuc3BhcmVudCBJWGVzLCBhcyB0aGV5IGRvbid0IGFkZCB0aGVpciBBU04gaW48L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs
YWNrIj4mbmJzcDsmbmJzcDsgdGhlIEFTUEFUSC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEIj5UbyBteSB1bmRlcnN0YW5kaW5nLCB0aGF0IGluIHRoaXMgZHJh
ZnQsIHlvdSBhc3N1bWUgYnkgZGVmYXVsdCB0aGF0IFJTIHByZXBlbmRzIGl0cyBvd24gQVNOIHRv
IHRoZQ0KIEFTX1BhdGgsIHJpZ2h0PyAmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5v
LCB0aGVyZSBpcyBubyBzdWNoIGFzc3VtcHRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPll1bmFuOiBBbGwgcmlnaHQsIHNvIGxldOKAmXMgYXNzdW1l
IGluIG9uZSBjYXNlLCB0aGUgSVhQIGRvZXMgbm90IHByZXBlbmQgaXRzIG93biBBU04sIG1lYW5p
bmcgdGhlIFJTIGFuZCBvbmUgb2YgaXRzIFJTIGNsaWVudHMgcmVjZWl2ZXMgdGhlIHNhbWUgQVNf
UGF0aCwgcmlnaHQ/DQogQWNjb3JkaW5nIHRvIFNlY3Rpb24gNS4xIChzZWUgYmVsb3cpIGFuZCBT
ZWN0aW9uIDUuMiAoc2VlIGJlbG93KSwgSeKAmW0gd29uZGVyaW5nIHdoeSB0aGUgZGV0ZWN0aW9u
IHJ1bGVzIGFyZSBkaWZmZXJlbnQgZm9yIHRoaXMgUlMgKG9iZXlpbmcgU2VjdGlvbiA1LjEpIGFu
ZCB0aGlzIFJTIGNsaWVudCAob2JleWluZyBTZWN0aW9uIDUuMikgcmVnYXJkaW5nIHRoZSBzYW1l
IEFTX1BhdGguICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MTEuNTVwdCI+DQo8
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90Oztjb2xvcjpibGFjayI+U2VjdGlvbiA1LjEgJm5ic3A7PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjExLjU1cHQiPg0KPHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBXaGVuIGEgcm91dGUgaXMgcmVjZWl2ZWQgZnJv
bSBhIGN1c3RvbWVyLCBhIGxpdGVyYWwgcGVlciwgb3IgYnkgYSBSUzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxMS41NXB0Ij4NCjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYXQgYW4gSVgsIGVhY2ggcGFpciAoQVMoSS0x
KSwgQVMoSSkpIE1VU1QgYmVsb25nIHRvIGN1c3RvbWVyLXByb3ZpZGVyPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjExLjU1cHQiPg0KPHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBvciBzaWJsaW5nIHJlbGF0aW9uc2hpcC48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6
MTEuNTVwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+U2VjdGlvbiA1LjIgPG86cD4NCjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MTEuNTVwdCI+
DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7V2hlbiByb3V0ZSBpcyByZWNlaXZl
ZCBmcm9tIHByb3ZpZGVyIG9yIFJTIGl0IG1heSBoYXZlIGJvdGggVXBzdHJlYW08bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MTEuNTVwdCI+
DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFuZCBEb3duc3RyZWFtIHBhdGhz
LCB3aGVyZSBhIERvd25zdHJlYW0gZm9sbG93cyBhbiBVcHN0cmVhbSBwYXRoLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxMS41NXB0Ij4N
CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND
Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy
Z2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFuZCBhIGZpbmFsIHF1ZXN0aW9uIGFib3V0IFNl
Y3Rpb24gNyBTaWJsaW5ncyAoQ29tcGxleCBSZWxhdGlvbnMpLCByZWdhcmRsZXNzIG9mIHRoZSBj
dXJyZW50IGRlc2NyaXB0aW9uDQogb2Ygd2hhdCBzaWJsaW5nIHJlbGF0aW9uIGlzLCBkbyB3ZSB0
aGluayB0aGF0IHNpYmxpbmcgQVNlcyBhcmUgQVNlcyB0aGF0IGJlbG9uZyB0byB0aGUgc2FtZSBv
cGVyYXRvcj8gU28gYW55IHR5cGUgb2YgdHJhbnNpdGlvbiBpcyBmcmVlIG9mIGNoYXJnZT88L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNwZWFraW5nIGFib3V0IEFTUEEsIHdlIGFyZSBzcGVha2lu
ZyBhYm91dCBwZWVyaW5nIHJlbGF0aW9ucywgd2l0aG91dCBhbnkgZ3Vlc3MgYWJvdXQgdGhlIGJ1
c2luZXNzIGJldHdlZW4gcGFydGllcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBmcm9tIHdoYXQgSSBrbm93IC0gc2libGluZ3Mg
YXJlIGFsc28gc3ByZWFkIGFtb25nIHNtYWxsIG5ldHdvcmtzLCZuYnNwO3NvIHRoaXMgdGVybSBp
cyBub3Qgc3RyaWN0bHkgYm91bmQgdG8gdGhlIHNhbWUmbmJzcDthZG1pbmlzdHJhdGl2ZSZuYnNw
O2RvbWFpbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+WXVuYW46IHdlbGws
IEnigJltIHRyeWluZyB0byB1bmRlcnN0YW5kIHdoYXQgaXQgbWVhbnMgYnkg4oCcc2libGluZ+KA
nS4gWW91ciBkcmFmdCBkZWZpbmVzIGhvdyBBU1BBIHJlY29yZHMgYXJlIGNyZWF0ZWQgZm9yIOKA
nHNpYmxpbmfigJ0gcmVsYXRpb25zLCBidXQgbm8gcHJlY2lzZSBkZWZpbml0aW9uDQogaXMgZ2l2
ZW4gKG9ubHkgZXhhbXBsZXMpLiBJIHVuZGVyc3RhbmQgSXQgaXMgYSBjb21wbGV4IHJlbGF0aW9u
LCBhcyBzdGF0ZWQgaW4gdGhlIGRyYWZ0LCBidXQgc3RpbGwsIEnigJltIGNvbmZ1c2VkIG9mIHRo
ZSBhY3R1YWwgcGVlcmluZyByZWxhdGlvbnMgd2hlbiB3ZSB0YWxrIGFib3V0IOKAnHNpYmxpbmfi
gJ0uIENhbiB5b3UgbWF5YmUgcHJvdmlkZSBhIG1vcmUgc3BlY2lmaWMgdGV4dCBkZWZpbml0aW9u
PyAmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_C01B0098369B2D4391851938DA6700B717A28020DGGEML532MBXchi_--


From nobody Sun May 10 23:22:25 2020
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 D14403A083B for ; Sun, 10 May 2020 23:22:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOt8PronLUpv for ; Sun, 10 May 2020 23:22:17 -0700 (PDT)
Received: from out20-37.mail.aliyun.com (out20-37.mail.aliyun.com [115.124.20.37]) (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 55E303A0839 for ; Sun, 10 May 2020 23:22:14 -0700 (PDT)
X-Alimail-AntiSpam: AC=CONTINUE; BC=0.103883|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_system_inform|0.0517443-0.00273874-0.945517; FP=0|0|0|0|0|-1|-1|-1; HT=e01a16378; MF=madi@rpstir.net; NM=1; PH=DS; RN=2; RT=2; SR=0; TI=SMTPD_---.HWiXbi8_1589178126; 
Received: from 192.168.218.230(mailfrom:madi@rpstir.net fp:SMTPD_---.HWiXbi8_1589178126) by smtp.aliyun-inc.com(10.147.40.7); Mon, 11 May 2020 14:22:07 +0800
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Di Ma 
In-Reply-To: <20200508180039.GA18937@vurt.meerval.net>
Date: Mon, 11 May 2020 14:21:45 +0800
Cc: sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <38D78A3D-BB4A-47B6-9507-14C116BC3FE2@rpstir.net> <20200508180039.GA18937@vurt.meerval.net>
To: Job Snijders 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
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, 11 May 2020 06:22:20 -0000

Job,

> 2020=E5=B9=B45=E6=9C=889=E6=97=A5 02:00=EF=BC=8CJob Snijders =
 =E5=86=99=E9=81=93=EF=BC=9A
>=20
> Dear Di Ma,
>=20
> On Sat, May 09, 2020 at 01:33:29AM +0800, Di Ma wrote:
>> Thanks for your efforts for writing MFT update and reflecting the
>> feedback from the mailing list.
>>=20
>> I am fine with it except the re-use of previous local cache.
>>=20
>> I find it is hard to implement the logic about retrieving objects =
from
>> local cache with RPSTIR2.=20
>=20
> Can you elaborate on why it is hard in RSTPIR2? I am not familiar with
> this implementation and can perhaps learn from it, or offer =
suggestions.

When I say hard, I mean I cannot estimate when =E2=80=98a specific =
object=E2=80=99 will be retrieved from a specific historic version of =
local cache.=20

And we don=E2=80=99t know then we need to cache all the historic =
versions in case of missing objects.=20

And it is even worse when the missing stuff is Resource Certificate, the =
SIA of which will affect where the RP to find the subordinate =
repository. This happens in the middle of sync. Accordingly the RP will =
use a well-designed algorithm to search all the historic versions =
efficiently.

I am not saying we cannot do that but this is really deserves an effort.

I really look forwards to seeing your big idea or suggestions:-)

>=20
>> As I replied to Robert in your discussion with him, in terms of
>> synchronization, RPSTIR2 keeps its incumbent local version exactly =
the
>> same with global repositories.
>=20
> An RP can't know if it is in sync with the global repository. The =
trust
> derives from the pre-obtained RPKI TALs, through the X509 validation
> procedure and outputs Validated ROA Payloads.
>=20
> In this process the data that can be *least* trusted is what came in =
via
> the untrusted network channel (be it rsync or RRDP). Withholding or
> corruption by issuing 'withdraws' (RRDP)  or '--delete' (rsync) cannot
> be trusted at all. With this in mind, one really really aught to
> reconstruct the original publication point's repository, =
suppplementing
> it with locally cached data as much as possible.
>=20
>> Although RPSTIR2 keeps the historic versions locally, they are stored
>> for diagnose and analysis (maybe to trigger SLURM)
>>=20
>> If some RP can retrieve missing objects while others can not, data
>> inconsistence will occur among different RPs.
>=20
> This already always is the case, and will not change. RPs pull from =
the
> CA's publication point from different places on the Internet, at
> different times.


I have to admit that keep all the RP throughout the Internet keep in =
pace for sync is over-ideal.=20


>=20
>> I think we just need to keep RP in alignment with PP and then can
>> perform some analysis and diagnose (if necessary) to ascertain errors
>> (RFC 8211) to give warning or make use of SLURM (RFC8416) if the RP
>> operator is confident enough that he catch the wrong data and knows
>> how to remedy locally.
>=20
> How will the RP stay in alignment with the PP when the RP is under
> attack? Intercepting and corrupting rsync connections is trivial and =
the
> RRDP protocol does not offer protections against unauthorised
> modification of the data presented to the RP.

I am considering deploying multiple RP instances by diversifying its =
locations to avoid MITM attack.=20

>=20
>> To sum up, I would like to see :
>>=20
>> 1) RPs are encouraged to store historic versions locally especially
>> the validated RTR-output
>=20
>> 2) If the RP finds some missing objects (not in the CRL, still in the
>> MFT) , it is suggested to issue warning to operators and SLURM can be
>> used by the historic data.
>=20
> What is the 'timing' of the process you describe under (2)? I cannot
> imagine any manual intervention in the validation process to scale for
> the purpose of the Internet routing system. Perhaps I'm
> misunderstanding.

I expect this work this way:

1) A missing object found;
2) Warning issued to RP operator, indicating which VRP will be adversely =
affected and providing suggested SLURM Assertion;
3) SLURM acknowledged to add this Assertion to the validated cache =
affected by the missing object (ROA for example)

>=20
>> I therefore really look forwards to hearing from folks of other RP
>> software to comment on this.
>=20
> It is my intention to provide the working group with an implementation
> report of OpenBSD's current rpki-client version in relation to the =
text
> that Stephen Kent provided today as 'rev 4'. I hope to be able to do
> that next week. My report will be usable as a template for other
> implementation maintainers. Comparing and sharing implementation notes
> is fun, stay tuned!

Always glad to see someone sharing RP implementation notes :-)

Di



From nobody Mon May 11 04:17:30 2020
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 E88693A08E1 for ; Mon, 11 May 2020 04:17:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flFlxpt1uQEv for ; Mon, 11 May 2020 04:17:22 -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 310DD3A087B for ; Mon, 11 May 2020 04:17:22 -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 1jY6Qx-0000xd-KC for sidrops@ietf.org; Mon, 11 May 2020 11:17:19 +0000
Date: Mon, 11 May 2020 04:17:16 -0700
Message-ID: 
From: Randy Bush 
To: SIDR Operations WG 
In-Reply-To: <20200511125957.09b5f5e5@glaurung.nlnetlabs.nl> 
References:    <20200511123331.5c2d604a@glaurung.nlnetlabs.nl> <73D1F29B-7F54-4022-975C-477B3A9E7CC5@psg.com> <20200511125957.09b5f5e5@glaurung.nlnetlabs.nl>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=ISO-8859-7
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Sidrops] nlnet rp and rsync
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, 11 May 2020 11:17:28 -0000

turning a private discussion public, with consent of course

it turns out that, to quote tim

> Routinator has had support for RRDP since version 0.6.0, released in
> September 2019.
>=20
> If it finds an RRDP SIA and successfully synchronizes the publication
> point once, it will whitelist the RRDP SIA URI and it will no longer
> fall back to rsync where this URI occurs on CA certificates. As long
> as the synchronization has not been successful it will fall back to
> rsync.

to which i then said

> that seem a potential violation of spec.  if the PP RRDP service then
> fails, it really MUST fall back to the mandatory to implement rsync.
>=20
>> As long as the synchronization has not been successful it will fall
>> back to rsync.
>=20
> s/As long as/If/

to which martin said

> Can you point me to where it says that? Section 3.4.5 of RFC 8182 is
> pretty indifferent about it.

to which i said

> among other places, 6481 s3
>=20
>      *  The publication repository MUST be available using rsync
>         [RFC5781] [RSYNC].  Support of additional retrieval mechanisms
>         is the choice of the repository operator.  The supported
>         retrieval mechanisms MUST be consistent with the accessMethod
>         element value(s) specified in the SIA of the associated CA or
>         EE certificate.

to which martin responded

> This talks about what the publication point has to offer, not what a
> cache has to use. In particular, it says that the publication point
> musn=A2t advertise RRDP unless it actually offers RRDP. Which means that
> as a cache I can rely on RRDP being available.
>=20
> Forcing a cache to use rsync instead of RRDP is a downgrade attack and
> should be handled accordingly.

at which point i said it is time to take this to the wg.  so here we go.

imiho, 6481 makes it very clear that rsync is currently the mandatory to
implement protocol (yes i am a coauthor of a draft trying to eventially
change that).  i contend that this is MTI by both the publisher and by
the client.

randy


From nobody Mon May 11 07:13:23 2020
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 614B13A0B02 for ; Mon, 11 May 2020 07:13:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RJ2xOt9sCot for ; Mon, 11 May 2020 07:13:18 -0700 (PDT)
Received: from hrabosky.cbbtier3.att.net (braeburn.org [12.0.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6693A0A98 for ; Mon, 11 May 2020 07:13:18 -0700 (PDT)
Received: from oz.mt.att.com (zoe.cbbtier3.att.net [12.0.1.45]) by hrabosky.cbbtier3.att.net (Postfix) with ESMTP id 771B238FA2 for ; Mon, 11 May 2020 14:13:17 +0000 (UTC)
Received: by oz.mt.att.com (Postfix, from userid 1000) id 691D35641353; Mon, 11 May 2020 10:13:17 -0400 (EDT)
X-Mailer: emacs 25.2.2 (via feedmail 11-beta-1 I); VM 8.2.0b under 25.2.2 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-ID: <24249.23930.126312.2484@oz.mt.att.com>
Date: Mon, 11 May 2020 10:13:14 -0400
From: Jay Borkenhagen 
To: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" 
Cc: SIDR Operations WG 
In-Reply-To: 
References:     
Reply-To: Jay Borkenhagen 
X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3  D198 7DED 6648 2308 D3C0 
Archived-At: 
Subject: Re: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04
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, 11 May 2020 14:13:22 -0000

Guyunan (Yunan Gu, IP Technology Research Dept. NW) writes:

 > > And a final question about Section 7 Siblings (Complex Relations),=
 regardless of the current description of what sibling relation is, do =
we think that sibling ASes are ASes that belong to the same operator=3F=
 So any type of transition is free of charge=3F
 > Speaking about ASPA, we are speaking about peering relations, withou=
t any guess about the business between parties.
 > And from what I know - siblings are also spread among small networks=
, so this term is not strictly bound to the same administrative domain.=

 >=20
 > Yunan: well, I=E2=80=99m trying to understand what it means by =E2=80=
=9Csibling=E2=80=9D. Your draft defines how ASPA records are created fo=
r =E2=80=9Csibling=E2=80=9D relations, but no precise definition is giv=
en (only examples). I understand It is a complex relation, as stated in=
 the draft, but still, I=E2=80=99m confused of the actual peering relat=
ions when we talk about =E2=80=9Csibling=E2=80=9D. Can you maybe provid=
e a more specific text definition=3F
 >=20

Hi Yunan,

I also find the term 'siblings' to be confusing and potentially
misleading in the ASPA context, since it implies common parentage.  I
believe that there is one and only one such 'complex relation' to be
called out in ASPA verification, and that would be accurately
described as 'mutual transit': ASes mutually agreeing to send prefixes
received from each other to their peers and upstreams.

Would your request for clarification be met by the draft replacing its=20=

use of the term 'siblings' with 'mutual transit'=3F

Thanks.

=09=09=09=09=09=09Jay B.


From nobody Mon May 11 07:44:13 2020
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 8A9883A09AE for ; Mon, 11 May 2020 07:44:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=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 kePRsHne3ll1 for ; Mon, 11 May 2020 07:44:05 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7B73A0B8E for ; Mon, 11 May 2020 07:44:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5FC10300B3F for ; Mon, 11 May 2020 10:44:02 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qn3_kzROwDFV for ; Mon, 11 May 2020 10:44:00 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 49CF43004AF for ; Mon, 11 May 2020 10:44:00 -0400 (EDT)
From: Russ Housley 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Mon, 11 May 2020 10:44:01 -0400
References:    <20200511123331.5c2d604a@glaurung.nlnetlabs.nl> <73D1F29B-7F54-4022-975C-477B3A9E7CC5@psg.com> <20200511125957.09b5f5e5@glaurung.nlnetlabs.nl> 
To: SIDR Operations WG 
In-Reply-To: 
Message-Id: 
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: 
Subject: Re: [Sidrops] nlnet rp and rsync
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, 11 May 2020 14:44:09 -0000

The repository MUST be available by rsync, and it MAY also be available =
using other protocols.

A client can use any of the protocols that it wants, but it seems like =
unnecessary fragility to pick an alternate and then refuse to consider =
rsync.  This seem counter to a graceful transition, especially if there =
is a transition from RRDP to RRDP2 in the distant future.

Russ


> On May 11, 2020, at 7:17 AM, Randy Bush  wrote:
>=20
> turning a private discussion public, with consent of course
>=20
> it turns out that, to quote tim
>=20
>> Routinator has had support for RRDP since version 0.6.0, released in
>> September 2019.
>>=20
>> If it finds an RRDP SIA and successfully synchronizes the publication
>> point once, it will whitelist the RRDP SIA URI and it will no longer
>> fall back to rsync where this URI occurs on CA certificates. As long
>> as the synchronization has not been successful it will fall back to
>> rsync.
>=20
> to which i then said
>=20
>> that seem a potential violation of spec.  if the PP RRDP service then
>> fails, it really MUST fall back to the mandatory to implement rsync.
>>=20
>>> As long as the synchronization has not been successful it will fall
>>> back to rsync.
>>=20
>> s/As long as/If/
>=20
> to which martin said
>=20
>> Can you point me to where it says that? Section 3.4.5 of RFC 8182 is
>> pretty indifferent about it.
>=20
> to which i said
>=20
>> among other places, 6481 s3
>>=20
>>     *  The publication repository MUST be available using rsync
>>        [RFC5781] [RSYNC].  Support of additional retrieval mechanisms
>>        is the choice of the repository operator.  The supported
>>        retrieval mechanisms MUST be consistent with the accessMethod
>>        element value(s) specified in the SIA of the associated CA or
>>        EE certificate.
>=20
> to which martin responded
>=20
>> This talks about what the publication point has to offer, not what a
>> cache has to use. In particular, it says that the publication point
>> musn=E2=80=99t advertise RRDP unless it actually offers RRDP. Which =
means that
>> as a cache I can rely on RRDP being available.
>>=20
>> Forcing a cache to use rsync instead of RRDP is a downgrade attack =
and
>> should be handled accordingly.
>=20
> at which point i said it is time to take this to the wg.  so here we =
go.
>=20
> imiho, 6481 makes it very clear that rsync is currently the mandatory =
to
> implement protocol (yes i am a coauthor of a draft trying to =
eventially
> change that).  i contend that this is MTI by both the publisher and by
> the client.
>=20
> randy
>=20
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops


From nobody Mon May 11 10:33:34 2020
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 A66A43A0B47 for ; Mon, 11 May 2020 10:33:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQi8xL5Dbjv1 for ; Mon, 11 May 2020 10:33:24 -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 71AE83A0854 for ; Mon, 11 May 2020 10:33:24 -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 1jYCIq-0001yN-Uq; Mon, 11 May 2020 17:33:21 +0000
Date: Mon, 11 May 2020 10:33:20 -0700
Message-ID: 
From: Randy Bush 
To: Russ Housley 
Cc: SIDR Operations WG 
In-Reply-To: 
References:    <20200511123331.5c2d604a@glaurung.nlnetlabs.nl> <73D1F29B-7F54-4022-975C-477B3A9E7CC5@psg.com> <20200511125957.09b5f5e5@glaurung.nlnetlabs.nl>  
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [Sidrops] nlnet rp and rsync
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, 11 May 2020 17:33:32 -0000

rrdp is more fragile.  e.g. the nlnet labs client (rightly, imiho)
checks the full certificate chain.  if any piece of the chain expires,
is CRLed, ... the client does not go to rsync.  bam!

falling back to rsync is not a 'downgrade' in that the rpki uses an
object, not transport, security model.  well, until the last hop to the
router, and you can see the transport security section from hell in rfc
8210.

the goal in rrdp was to make the rpki more, not less reliable.  we found
the nllnet labs misfeature in the wild when CA data were no longer
fetched.  imiho not good.

randy


From nobody Mon May 11 15:20:04 2020
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 940B03A0D67 for ; Mon, 11 May 2020 15:20:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fi7V0LbugGd6 for ; Mon, 11 May 2020 15:19:59 -0700 (PDT)
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 B0D823A0D66 for ; Mon, 11 May 2020 15:19:59 -0700 (PDT)
Received: by mail-il1-x132.google.com with SMTP id i16so10302086ils.12 for ; Mon, 11 May 2020 15:19:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5W1rC3ItsYsB4Izp0GRwekkN06DU5ZM6MEoaQzWUo0I=; b=u4eegw2WEDVzys0MvMyRVOzR7m/39yq+rznD1prJHDO9b2oIWsqLcbGT5O7zACNu6a NmRRy63eu68fxXt0Iy03SwKorI6jdknFWlo7OO0u1Dp42ihPew67Wy8q/TKtYvglYZOD SV3w92n76uN+3R+CWBduyn7Xk+FnNPVbd5bKPUSWMBwmRKynKAAzETFCsxiWCmdk0vm1 27iIPI+w3Ebqwib0Seq0tnrkUjurcrNZhGZs61wb1GJY4kSVui2KqDdr42TqPZPkg+0s U14A1f8uCOe6N3hRkwhDIUmyeTqTIWRDjKhQ4QWcev1mJwJrsEgzO/XPxnnUVFmO9+tf JHNg==
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=5W1rC3ItsYsB4Izp0GRwekkN06DU5ZM6MEoaQzWUo0I=; b=WJPhcVW30ujyiL3KrxNAFuFYoSfW2yOhMqKDcrMeoqSIR1KYX7eroKePB8B026DqkP FD/RclfPaRUuC61pOkV67H9+GRXEpBMsPirVz+ZycBA/S/i7UkLXNgZFwPVqd+6L/mpK 3qAaGSJwHtCV5X3bilfR2b20Kx2CKxuaIyfG1R1sww6TrhtTJCP8E8a6tJ31RwWlMSKB BXjfWdb8UaWV1q7Sr6HWvN1LClqR5xnhZ9GJuas2YEpsK4103UkDljdfVklmzlo6MDWE Sa2R21lhBzVwwzmbir/GxTsbZzUtIAEoZzvg48aeHR0momePPfogaChIYpDYDScLibPX NtLg==
X-Gm-Message-State: AGi0Pub6trkI90EEYG9HKT3EkinYPEmLL8ymYca7Nya4IFmVz5qo1wFG lUi2SlbbDSuizonJU6LpZ7OAhArEiu1yaQWSczzVmFfS
X-Google-Smtp-Source: APiQypJmG5wWd6gdqoRC0ytcIxJetfRsP1fZmX42flVaRM6E1jZpoCFDW/Zd/G1iUD4W7SHZPdmsayYLMJ+svdaA5/c=
X-Received: by 2002:a05:6e02:80e:: with SMTP id u14mr19772623ilm.176.1589235598348;  Mon, 11 May 2020 15:19:58 -0700 (PDT)
MIME-Version: 1.0
References:    <20200511123331.5c2d604a@glaurung.nlnetlabs.nl> <73D1F29B-7F54-4022-975C-477B3A9E7CC5@psg.com> <20200511125957.09b5f5e5@glaurung.nlnetlabs.nl>   
In-Reply-To: 
From: George Michaelson 
Date: Tue, 12 May 2020 08:19:46 +1000
Message-ID: 
To: Randy Bush 
Cc: Russ Housley , SIDR Operations WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [Sidrops] nlnet rp and rsync
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, 11 May 2020 22:20:03 -0000

I agree in the current spec, its MTI.

I also believe the intent of the deprecate-rsync draft remains: Remove
this dependency.

If this means we need to discuss the implications of channel security
and TLS on deployment, and specify the certificate chain validation
requirements on publication points and clients, thats what we need to
do.

But, until deprecate-rsync is adopted and published, the current
specification I feel is clear: you must support rsync, both sides of
the equation.

All the discussions on validation clarifications go to 'removing
objects' -What is the nature of transport security failings, if not to
permit removal of objects? And, if an object can be occluded or
removed because of a lack of channel security, what does this mean in
terms of denial of service attacks?

-George

On Tue, May 12, 2020 at 3:33 AM Randy Bush  wrote:
>
> rrdp is more fragile.  e.g. the nlnet labs client (rightly, imiho)
> checks the full certificate chain.  if any piece of the chain expires,
> is CRLed, ... the client does not go to rsync.  bam!
>
> falling back to rsync is not a 'downgrade' in that the rpki uses an
> object, not transport, security model.  well, until the last hop to the
> router, and you can see the transport security section from hell in rfc
> 8210.
>
> the goal in rrdp was to make the rpki more, not less reliable.  we found
> the nllnet labs misfeature in the wild when CA data were no longer
> fetched.  imiho not good.
>
> randy
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops


From nobody Tue May 12 00:12:08 2020
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 436873A0C93 for ; Tue, 12 May 2020 00:12:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JN_BcDk0XRo for ; Tue, 12 May 2020 00:12:06 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 CCDFC3A09FA for ; Tue, 12 May 2020 00:12:05 -0700 (PDT)
Received: from lhreml701-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 312C77C604D9EAB0FC8B for ; Tue, 12 May 2020 08:12:04 +0100 (IST)
Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 12 May 2020 08:12:03 +0100
Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Tue, 12 May 2020 08:12:03 +0100
Received: from DGGEML532-MBX.china.huawei.com ([169.254.8.202]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0487.000; Tue, 12 May 2020 15:11:59 +0800
From: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" 
To: Jay Borkenhagen 
CC: SIDR Operations WG 
Thread-Topic: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04
Thread-Index: AdYdy08vebzctU/sRBSjzmRHyKjH2ACpL0yAALmBBzAA2L1MAAAdy1hgAArDfQAANA3jsA==
Date: Tue, 12 May 2020 07:11:58 +0000
Message-ID: 
References:      <24249.23930.126312.2484@oz.mt.att.com>
In-Reply-To: <24249.23930.126312.2484@oz.mt.att.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.108.203.151]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 07:12:07 -0000

SGkgSmF5LA0KDQoibXV0dWFsIHRyYW5zaXQiIHNvdW5kcyBsaWtlIGEgcHJvcGVyIHRlcm0gdG8g
bWUgYW5kIHRvIGJlIHVzZWQgaGVyZSENCg0KQlIsDQpZdW5hbg0KDQotLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KRnJvbTogSmF5IEJvcmtlbmhhZ2VuIFttYWlsdG86amF5YkBicmFlYnVybi5v
cmddIA0KU2VudDogTW9uZGF5LCBNYXkgMTEsIDIwMjAgMTA6MTMgUE0NClRvOiBHdXl1bmFuIChZ
dW5hbiBHdSwgSVAgVGVjaG5vbG9neSBSZXNlYXJjaCBEZXB0LiBOVykgPGd1eXVuYW5AaHVhd2Vp
LmNvbT4NCkNjOiBTSURSIE9wZXJhdGlvbnMgV0cgPHNpZHJvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0
OiBSZTogW1NpZHJvcHNdIHF1ZXN0aW9uIG9uIGRyYWZ0LWlldGYtc2lkcm9wcy1hc3BhLXZlcmlm
aWNhdGlvbi0wNA0KDQpHdXl1bmFuIChZdW5hbiBHdSwgSVAgVGVjaG5vbG9neSBSZXNlYXJjaCBE
ZXB0LiBOVykgd3JpdGVzOg0KDQogPiA+IEFuZCBhIGZpbmFsIHF1ZXN0aW9uIGFib3V0IFNlY3Rp
b24gNyBTaWJsaW5ncyAoQ29tcGxleCBSZWxhdGlvbnMpLCByZWdhcmRsZXNzIG9mIHRoZSBjdXJy
ZW50IGRlc2NyaXB0aW9uIG9mIHdoYXQgc2libGluZyByZWxhdGlvbiBpcywgZG8gd2UgdGhpbmsg
dGhhdCBzaWJsaW5nIEFTZXMgYXJlIEFTZXMgdGhhdCBiZWxvbmcgdG8gdGhlIHNhbWUgb3BlcmF0
b3I/IFNvIGFueSB0eXBlIG9mIHRyYW5zaXRpb24gaXMgZnJlZSBvZiBjaGFyZ2U/DQogPiBTcGVh
a2luZyBhYm91dCBBU1BBLCB3ZSBhcmUgc3BlYWtpbmcgYWJvdXQgcGVlcmluZyByZWxhdGlvbnMs
IHdpdGhvdXQgYW55IGd1ZXNzIGFib3V0IHRoZSBidXNpbmVzcyBiZXR3ZWVuIHBhcnRpZXMuDQog
PiBBbmQgZnJvbSB3aGF0IEkga25vdyAtIHNpYmxpbmdzIGFyZSBhbHNvIHNwcmVhZCBhbW9uZyBz
bWFsbCBuZXR3b3Jrcywgc28gdGhpcyB0ZXJtIGlzIG5vdCBzdHJpY3RseSBib3VuZCB0byB0aGUg
c2FtZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4uDQogPg0KID4gWXVuYW46IHdlbGwsIEnigJltIHRy
eWluZyB0byB1bmRlcnN0YW5kIHdoYXQgaXQgbWVhbnMgYnkg4oCcc2libGluZ+KAnS4gWW91ciBk
cmFmdCBkZWZpbmVzIGhvdyBBU1BBIHJlY29yZHMgYXJlIGNyZWF0ZWQgZm9yIOKAnHNpYmxpbmfi
gJ0gcmVsYXRpb25zLCBidXQgbm8gcHJlY2lzZSBkZWZpbml0aW9uIGlzIGdpdmVuIChvbmx5IGV4
YW1wbGVzKS4gSSB1bmRlcnN0YW5kIEl0IGlzIGEgY29tcGxleCByZWxhdGlvbiwgYXMgc3RhdGVk
IGluIHRoZSBkcmFmdCwgYnV0IHN0aWxsLCBJ4oCZbSBjb25mdXNlZCBvZiB0aGUgYWN0dWFsIHBl
ZXJpbmcgcmVsYXRpb25zIHdoZW4gd2UgdGFsayBhYm91dCDigJxzaWJsaW5n4oCdLiBDYW4geW91
IG1heWJlIHByb3ZpZGUgYSBtb3JlIHNwZWNpZmljIHRleHQgZGVmaW5pdGlvbj8NCiA+IA0KDQpI
aSBZdW5hbiwNCg0KSSBhbHNvIGZpbmQgdGhlIHRlcm0gJ3NpYmxpbmdzJyB0byBiZSBjb25mdXNp
bmcgYW5kIHBvdGVudGlhbGx5IG1pc2xlYWRpbmcgaW4gdGhlIEFTUEEgY29udGV4dCwgc2luY2Ug
aXQgaW1wbGllcyBjb21tb24gcGFyZW50YWdlLiAgSSBiZWxpZXZlIHRoYXQgdGhlcmUgaXMgb25l
IGFuZCBvbmx5IG9uZSBzdWNoICdjb21wbGV4IHJlbGF0aW9uJyB0byBiZSBjYWxsZWQgb3V0IGlu
IEFTUEEgdmVyaWZpY2F0aW9uLCBhbmQgdGhhdCB3b3VsZCBiZSBhY2N1cmF0ZWx5IGRlc2NyaWJl
ZCBhcyAnbXV0dWFsIHRyYW5zaXQnOiBBU2VzIG11dHVhbGx5IGFncmVlaW5nIHRvIHNlbmQgcHJl
Zml4ZXMgcmVjZWl2ZWQgZnJvbSBlYWNoIG90aGVyIHRvIHRoZWlyIHBlZXJzIGFuZCB1cHN0cmVh
bXMuDQoNCldvdWxkIHlvdXIgcmVxdWVzdCBmb3IgY2xhcmlmaWNhdGlvbiBiZSBtZXQgYnkgdGhl
IGRyYWZ0IHJlcGxhY2luZyBpdHMgdXNlIG9mIHRoZSB0ZXJtICdzaWJsaW5ncycgd2l0aCAnbXV0
dWFsIHRyYW5zaXQnPw0KDQpUaGFua3MuDQoNCgkJCQkJCUpheSBCLg0KDQo=


From nobody Tue May 12 02:45:29 2020
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 E11E33A0D37 for ; Tue, 12 May 2020 02:45:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33l6IVL64eBr for ; Tue, 12 May 2020 02:45:26 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.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 132353A0D31 for ; Tue, 12 May 2020 02:45:25 -0700 (PDT)
Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id D138D33EFF; Tue, 12 May 2020 11:45:22 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com
Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com
Date: Tue, 12 May 2020 11:45:21 +0200
From: Martin Hoffmann 
To: Russ Housley 
Cc: SIDR Operations WG 
Message-ID: <20200512114521.5787a957@glaurung.nlnetlabs.nl>
In-Reply-To: 
References:    <20200511123331.5c2d604a@glaurung.nlnetlabs.nl> <73D1F29B-7F54-4022-975C-477B3A9E7CC5@psg.com> <20200511125957.09b5f5e5@glaurung.nlnetlabs.nl>  
Organization: Open Netlabs
X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Sidrops] nlnet rp and rsync
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 09:45:28 -0000

Russ Housley wrote:
>=20
> A client can use any of the protocols that it wants, but it seems
> like unnecessary fragility to pick an alternate and then refuse to
> consider rsync.  This seem counter to a graceful transition,
> especially if there is a transition from RRDP to RRDP2 in the distant
> future.

The decision to not fall back to rsync if RRDP succeeded once was
actually made with publication point operators in mind. With most
relying party software now supporting RRDP and preferring it over
rsync, an operator will see most traffic via RRDP and only very small
amounts on rsync. Given that unlike with HTTP where lots of tooling and
services for reliable, scalable operation exist, you are basically on
your own with rsync, they are likely to only provide a minimum service.
Now, if the RRDP service becomes unavailable for whatever reason, all
relying parties hitting the rsync service is not going to end well.

Since the absolute majority of these RRDP failures are of a transient
nature and will be resolved by the next validation run, just skipping
the publication point this time seems a reasonable choice. This could
probably be improved by remember how many times it failed and switching
back to rsync after, say, five failures, but I am not sure this is
worth the effort.

As an aside, switching between rsync and RRDP isn=E2=80=99t free. Because an
RRDP server can essentially publish objects for any rsync URI it wants,
you have to keep separate trees for rsync and each and every RRDP
server. So falling back to rsync actually means either downloading the
full copy or updating a severely outdated copy. It=E2=80=99s not that big a
deal in the grand scheme of things but worth noting.

Kind regards,
Martin


From nobody Tue May 12 02:53:12 2020
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 3ED313A0D48 for ; Tue, 12 May 2020 02:53:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1id1ujTQ9tG5 for ; Tue, 12 May 2020 02:53:09 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0: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 B8CBF3A0D44 for ; Tue, 12 May 2020 02:53:09 -0700 (PDT)
Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 45F1133F23; Tue, 12 May 2020 11:53:07 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com
Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com
Date: Tue, 12 May 2020 11:53:06 +0200
From: Martin Hoffmann 
To: Randy Bush 
Cc: Russ Housley , SIDR Operations WG 
Message-ID: <20200512115306.04c6085a@glaurung.nlnetlabs.nl>
In-Reply-To: 
References:    <20200511123331.5c2d604a@glaurung.nlnetlabs.nl> <73D1F29B-7F54-4022-975C-477B3A9E7CC5@psg.com> <20200511125957.09b5f5e5@glaurung.nlnetlabs.nl>   
Organization: Open Netlabs
X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Sidrops] nlnet rp and rsync
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 09:53:11 -0000

Randy Bush wrote:
> rrdp is more fragile.  e.g. the nlnet labs client (rightly, imiho)
> checks the full certificate chain.  if any piece of the chain expires,
> is CRLed, ... the client does not go to rsync.  bam!

I would argue that operating an rsync server is much more fragile in
practice, simply because operators have much less experience with it.
As opposed to keeping an HTTPS server up and running which is absolutely
essential to each and every Internet operation now.=20

If a certificate appears on a CRL, there is probably a good reason for
it and perhaps the service shouldn=E2=80=99t be trusted anymore.

> falling back to rsync is not a 'downgrade' in that the rpki uses an
> object, not transport, security model.

It has been demonstrated that by maliciously withholding RPKI objects
you can cause damage to the routing system, so we should perhaps
revisit the choice of not relying on transport security.

> the goal in rrdp was to make the rpki more, not less reliable.  we
> found the nllnet labs misfeature in the wild when CA data were no
> longer fetched.  imiho not good.

Was that a permanent issue or did the CA in question fix their RRDP
service in due time? From what I am seeing, the current shift to reject
stale manifests and CRLs will cause much more issue.

Kind regards,
Martin


From nobody Tue May 12 06:08:44 2020
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 202483A08C9 for ; Tue, 12 May 2020 06:08:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.599
X-Spam-Level: 
X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ir-MMMpyKSu for ; Tue, 12 May 2020 06:08:39 -0700 (PDT)
Received: from sonic309-13.consmr.mail.bf2.yahoo.com (sonic309-13.consmr.mail.bf2.yahoo.com [74.6.129.123]) (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 263F33A092F for ; Tue, 12 May 2020 06:08:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1589288906; bh=0X93pePTInN3llSk8HR4qL62ftxClofe1p8DIjIBzwQ=;  h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=uMm3uZD0DV7TSHWb+2wUfjrheFge29Yr8KyB51TTErnyAsLCvtJB81Vjk4RaU12H0dan4N5crqBZd6bFnl0yoOxUXm2n3NICWfZS+RKH4q1xRPpcx9B3GhOE2f/OOu2rVXnTLQz74RLpfeRHN1mSrJOOkgaecMNFGBEgIvygKfb8hNUvqLUP7IW7tgvb+TTlzGW7kA3TJvn41n0I2hV9qrEljvwUGeJaefDJto6C7XoANF6vM8pG4pgDzDkldUWIz706AbMxHi22IR/fakEt17GDdGcIpNn6+F+bnWPTy4NpWyXQvwW2BA/7tkleYkNqYFtAqTKRuFdi2clvw1OGTQ==
X-YMail-OSG: h_P.q3AVM1mlrRWK3_WVPbJxI03AnRubSivx2sYFNi5ck0uzzNl7NQNaRvMHW_A 2WNctfa1vORI2WN.V.6q9c1XJbGU8fcsfHJTuTMcgXkKpZwDZLtvdGPjej6nEuvaoNIEAeMK5DUO tVFiVi.pvQ9tY3v9i_QoN3Zp13JkcGVGX9dby3i7eSomBNEubhzzQk2ADY47ekc1OKtQ3gizLzkz rltT.iKtESQpVFV0QMMB0yPRec.RSUZivSKJnCNhyUBYw5IyZWJsq_v4Rc0inFTpDYuZkT0XoP27 jTn.J6CwzHQ05uZc_tJymJC1RMD.sohl2jsnAklKd7Ux3JwFMULCazSmmmPU2gbLxwjNSltoHMcm C1mdqggRlfqWjMgNECu7XiB0YK0L392nOJBQcPNId2asKP6ZBgOd3L0ZtGqrN98jEQLU9fl8Js3m kDxvjppch9KMn.EiGDhaoreeXf5IOZgaNYDdiTYQp96OnfCM_qo03ZNQABKPBgX3oJld9m0hO6wZ _4OuWtr8m0ikoTSjgb.9lsW6xU9hhmNt_uDpw76JcwLFMmqJjDBEDOyn2ucxVbE5LpDGSy.4LgNn ebeCyTKCoXkcrKmfy6VNvReJp2BG7iuRRcou9jYk2G7ix4zrgrIwQoJ6TOF1fUIZb53u3aefg.pO GxsqYyOTlJKwYxPzTCO7tXjlzEmo0W0hZXK5bF7cL8YQPQLlziGrDtYezLaYSgLtS.5_XUg29Mdw XKdNRaAynIpVwYnDq61U3jv.FDCfrMjrsll.2.MpFdlbcR80zTWZv8e2_xlK7q7CySIToepIL39k CUwl9CSogM7HbWQwSFf7mws2QUuNlzv2jydhvMiymtvT20zeAcE1SIqCKzeAtyUb7YT6WxoNIeiD EuaRKj5f6rhSwbuwKxVJUNRuEar0uIx_YRHA_sFO3xJ91Iob6XpBpFiZ8GpbA1A9kiB3o5QN.4M7 1r3VDMXOlN_4VtCkfE1kxy1ehAF.vk3WvP.teMxhleAqGpjHhNzPM6poruZ0KZLxYIxMEbL5yWsX XtoydaVJ1cdNXMa60ic62HQG2YMo1kWn8SWauUnuax3qqekjYGBiR9OpvTdS0LCTe7UHSDprWOml nxMOWaQO5eXtferG37r1aTk4DZCkRgxjhtDqJFRrnW8rAiAO5s4NSTewsC1RNYWZe2HIXE664j2N 1QCSQ8BadcZqgT8l3viyU0ZpeKZzaTYd2t4txwymyjvwgQ46lkHncaVbDpSgccS0bAEIqJMinMQ8 jdd.1aXpooBOBExLBP2W8l4I18jXmSCYdm0u824l1AWMZi1hFxo0A.ZQuC56nSEbWx7D.9D5A2NE aVhw.hi7WMHs2gica96VORED_IEoVcqHVGoRuGM7T_E9neJqUDBUv90G9FTPmad2gBWAXIyQAypT VEh2ZIBqanA--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Tue, 12 May 2020 13:08:26 +0000
Received: by smtp401.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 05b35075bf6bcac5ce634307a49e489f;  Tue, 12 May 2020 13:08:21 +0000 (UTC)
To: sidrops@ietf.org
References:    <20200511123331.5c2d604a@glaurung.nlnetlabs.nl> <73D1F29B-7F54-4022-975C-477B3A9E7CC5@psg.com> <20200511125957.09b5f5e5@glaurung.nlnetlabs.nl> 
From: Stephen Kent 
Message-ID: 
Date: Tue, 12 May 2020 09:08:20 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=iso-8859-7; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Mailer: WebService/1.1.15904 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] nlnet rp and rsync
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 13:08:42 -0000

Randy,

Another observation on this topic: the current, posted versions of the 
CPS for RIPE, APNIC, ARIN, LACNICand AFRINIC refer only to rsync, not RRDP.

Steve




From nobody Tue May 12 07:07:24 2020
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 5E0043A0A52 for ; Tue, 12 May 2020 07:07:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBsCaSHay5lM for ; Tue, 12 May 2020 07:07:20 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 569113A0A68 for ; Tue, 12 May 2020 07:06:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 95FCD300B3C for ; Tue, 12 May 2020 10:06:21 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id p6x20XbCW2bs for ; Tue, 12 May 2020 10:06:20 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 134B8300A91; Tue, 12 May 2020 10:06:19 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
From: Russ Housley 
In-Reply-To: <20200512114521.5787a957@glaurung.nlnetlabs.nl>
Date: Tue, 12 May 2020 10:06:21 -0400
Cc: SIDR Operations WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <20200511123331.5c2d604a@glaurung.nlnetlabs.nl> <73D1F29B-7F54-4022-975C-477B3A9E7CC5@psg.com> <20200511125957.09b5f5e5@glaurung.nlnetlabs.nl>   <20200512114521.5787a957@glaurung.nlnetlabs.nl>
To: Martin Hoffmann 
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: 
Subject: Re: [Sidrops] nlnet rp and rsync
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 14:07:22 -0000

Martin:

>> A client can use any of the protocols that it wants, but it seems
>> like unnecessary fragility to pick an alternate and then refuse to
>> consider rsync.  This seem counter to a graceful transition,
>> especially if there is a transition from RRDP to RRDP2 in the distant
>> future.
>=20
> The decision to not fall back to rsync if RRDP succeeded once was
> actually made with publication point operators in mind. With most
> relying party software now supporting RRDP and preferring it over
> rsync, an operator will see most traffic via RRDP and only very small
> amounts on rsync. Given that unlike with HTTP where lots of tooling =
and
> services for reliable, scalable operation exist, you are basically on
> your own with rsync, they are likely to only provide a minimum =
service.
> Now, if the RRDP service becomes unavailable for whatever reason, all
> relying parties hitting the rsync service is not going to end well.
>=20
> Since the absolute majority of these RRDP failures are of a transient
> nature and will be resolved by the next validation run, just skipping
> the publication point this time seems a reasonable choice. This could
> probably be improved by remember how many times it failed and =
switching
> back to rsync after, say, five failures, but I am not sure this is
> worth the effort.

That seems like a desirable improvement.

> As an aside, switching between rsync and RRDP isn=E2=80=99t free. =
Because an
> RRDP server can essentially publish objects for any rsync URI it =
wants,
> you have to keep separate trees for rsync and each and every RRDP
> server. So falling back to rsync actually means either downloading the
> full copy or updating a severely outdated copy. It=E2=80=99s not that =
big a
> deal in the grand scheme of things but worth noting.

I understand that rsync and RRDP offer a very different interface; =
however, rsync is still the mandatory-to-implement protocol.  And, you =
clearly already have the code in place to support it.

Russ


From nobody Tue May 12 13:41:01 2020
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 79A293A0ACB for ; Tue, 12 May 2020 13:41:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jafkCWQ4S3nv for ; Tue, 12 May 2020 13:40:59 -0700 (PDT)
Received: from khatovar.hactrn.net (khatovar.hactrn.net [IPv6:2001:418:8006::30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6E933A0AF8 for ; Tue, 12 May 2020 13:40:58 -0700 (PDT)
Received: from minas-ithil.hactrn.net (c-73-47-196-134.hsd1.ma.comcast.net [73.47.196.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id 7FDD2139A8 for ; Tue, 12 May 2020 20:40:56 +0000 (UTC)
Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 7A03220156D8FC for ; Tue, 12 May 2020 16:41:26 -0400 (EDT)
Date: Tue, 12 May 2020 16:41:26 -0400
From: Rob Austein 
To: SIDR Operations WG 
In-Reply-To: 
References:    <20200511123331.5c2d604a@glaurung.nlnetlabs.nl> <73D1F29B-7F54-4022-975C-477B3A9E7CC5@psg.com> <20200511125957.09b5f5e5@glaurung.nlnetlabs.nl> 
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20200512204126.7A03220156D8FC@minas-ithil.hactrn.net>
Archived-At: 
Subject: Re: [Sidrops] nlnet rp and rsync
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 20:41:00 -0000

FWIW: I believe that the intent of the WG at the time we wrote the
current specification was that rsync be mandatory to implement for
both CA and RP.  As others have noted, the somewhat misnamed
"deprecate-rsync" draft is about changing that, which is fine if
that's the direction we want to go, but for now I think an RP is
required at least to attempt to fall back to rsync when RRDP fails.


From nobody Tue May 12 14:12:52 2020
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 89E5B3A0BD4 for ; Tue, 12 May 2020 14:12:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDs9Fcu2jfqQ for ; Tue, 12 May 2020 14:12:50 -0700 (PDT)
Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5743A0BCF for ; Tue, 12 May 2020 14:12:47 -0700 (PDT)
Received: from minas-ithil.hactrn.net (c-73-47-196-134.hsd1.ma.comcast.net [73.47.196.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id C9A88139A0 for ; Tue, 12 May 2020 21:12:45 +0000 (UTC)
Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 4C2CD20156DBC4 for ; Tue, 12 May 2020 17:13:14 -0400 (EDT)
Date: Tue, 12 May 2020 17:13:14 -0400
From: Rob Austein 
To: sidrops@ietf.org
In-Reply-To: 
References:  
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=ISO-8859-7
Content-Transfer-Encoding: quoted-printable
Message-Id: <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net>
Archived-At: 
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 May 2020 21:12:52 -0000

On Fri, 08 May 2020 11:26:22 -0400, Stephen Kent wrote:
...
> A manifest SHOULD contain exactly one CRL (.crl) file and it MUST be
> at the location specified in the CRLDP in the manifest=A2s EE
> certificate.  If more than one .crl file appears in the manifest,
> only file names matching the CRL specified by the CRLDP will be
> processed. If more than one .crl entry appears in the manifest, and
> matches the CRLDP, the first one encountered MUST be used.  Any
> other .crl files MUST be ignored and a warning MUST be issued.

I went back and looked at how my RP code handled this.  One can very
quickly get lost in the weeds here, but briefly: I start with a set of
"candidate manifests" and a set of "candidate CRLs", and keep pruning
those sets down with one form of validity check after another
(signatures and hashes must match, timestamps must be sane, URIs must
match, yada yada).  If, at the end of this I still have more than one
candidate CRL, I don't necessarily pick the first CRL in the manifest:
instead, I sort the candidates by CRL Number, thisUpdate, and time at
which I retrieved that CRL object (in descending order of preference,
so the timestamps only matter if CRL Number is identical, etc), and
use this to pick the "most recent" valid CRL.

YMMV, but this arguably yields a more useful result in this screwball
situation.  That said, this is (obviously) more complex to describe
and to implement, so may not be worth it, given that this should never
be happening in the first place.

If one wants a simplified version of this algorithm that stays within
the confines of a single manifest, one could do the sort by CRL
Number, then thisUpdate, then position in the manifest.

--Rob


From nobody Wed May 13 01:31:51 2020
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 03A783A0FB9; Wed, 13 May 2020 01:31:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 J874iRegrQiy; Wed, 13 May 2020 01:31:48 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0: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 88A593A0FB3; Wed, 13 May 2020 01:31:48 -0700 (PDT)
Received: from [IPv6:2001:981:4b52:1:bc2c:d6fa:cbdd:1589] (unknown [IPv6:2001:981:4b52:1:bc2c:d6fa:cbdd:1589]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 613E535738; Wed, 13 May 2020 10:31:46 +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=1589358706; bh=UlluyH+wFzqKad52Gxcs4L4MMptAxxiSFmjxvxGP5ZI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=yXNm/PMR4WYt6BjYrJSKzPrBLM3U8i1MXMDA5SiMBETRFGeGocxpL1OfAFXOCexXa cw7y3adxocrvNWKiOUGJ4/wVI7LjYNnFG3RN650m043WIatYOhQ2vjNrd0R5p/hABr cSC8/VvDK+cKHk/gh+bAosO/jyRf5yka59r3e4uY=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Tim Bruijnzeels 
In-Reply-To: 
Date: Wed, 13 May 2020 10:31:45 +0200
Cc: Melchior Aelmans , Oleg Muravskiy , SIDROps Chairs , SIDR Operations WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: <9DF82E8B-5A6A-4522-8C6C-066CF6B16E4E@nlnetlabs.nl>
References: <29748EA5-6016-4E6D-9261-A069F7431390@nlnetlabs.nl> <7CF309AA-0B5F-4FE8-80E8-5E041CA21CF1@ripe.net>  
To: Alexander Azimov 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [Sidrops] Adopt draft-sidrops-bruijnzeels-deprecate-rsync?
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, 13 May 2020 08:31:50 -0000

Hi,

> On 5 May 2020, at 22:56, Alexander Azimov  =
wrote:
>=20
> I support adoption while its naming may lead to confusion.=20
> As discussed during the interim, the draft does not suggest =
depreciation of rsync.

I think it does. But maybe the text or the presentation I did (or both) =
were not clear.

It currently says that rsync URIs will remain in use, because we need =
names. Replacing these URIs with something else that does not suggest =
rysnc - e.g. URNs (RFC8141) to be transport agnostic, or even https - =
would introduce a breaking change that will require *all* RP software to =
change first before any CA can start to include these alternate URI/Ns. =
This will make the whole thing much harder, and I am not convinced yet =
that that is worth is. Hence the XML NS analogy. You will see rsync URIs =
but they are really just name and scope (for the directories) without a =
guarantee that something is available.

Other than that it says that eventually the rsync repository MAY still =
be available. It's not a SHOULD, not even a RECOMMENDED. It simply does =
not forbid it and it mentions that there may still be uses for this =
outside of the operational validation context. In the context of RPKI =
validation it says clearly that it MUST NOT be depended on. However, if =
people here want to bury the rsync repo completely for other purposes as =
well then I am perfectly fine with changing that.

Tim



From nobody Wed May 13 02:22:51 2020
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 70AFC3A0FFD for ; Wed, 13 May 2020 02:22:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 KKj1qxIZoGBd for ; Wed, 13 May 2020 02:22:48 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0: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 1D5623A0FF8 for ; Wed, 13 May 2020 02:22:48 -0700 (PDT)
Received: from [IPv6:2001:981:4b52:1:bc2c:d6fa:cbdd:1589] (unknown [IPv6:2001:981:4b52:1:bc2c:d6fa:cbdd:1589]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 2A2DC3585C; Wed, 13 May 2020 11:22:45 +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=1589361765; bh=JMD3qSoWJWvufS600dW3NsEPAS3VxC4hj7cyy4BcBnM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=YF6rRqzUKPpMhtz1ynP0WFDVYGar4l/o/lRbMbH5QU8WV3b48zyxyqV3U5wMGbVsY yLbfivT1O6ydVTCXXZ0k80hvgdJCaS6561ir5iEqtobFBiSvqdLFMDdLY1QauoKP3E PlpKvz797dFIUQ/IQ4rGXZgzDfVKf09/skvq0QPM=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Tim Bruijnzeels 
In-Reply-To: <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net>
Date: Wed, 13 May 2020 11:22:44 +0200
Cc: sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net>
To: Rob Austein 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
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, 13 May 2020 09:22:50 -0000

Hi,

> On 12 May 2020, at 23:13, Rob Austein  wrote:
>=20
> On Fri, 08 May 2020 11:26:22 -0400, Stephen Kent wrote:
> ...
>> A manifest SHOULD contain exactly one CRL (.crl) file and it MUST be
>> at the location specified in the CRLDP in the manifest=E2=80=99s EE
>> certificate.  If more than one .crl file appears in the manifest,
>> only file names matching the CRL specified by the CRLDP will be
>> processed. If more than one .crl entry appears in the manifest, and
>> matches the CRLDP, the first one encountered MUST be used.  Any
>> other .crl files MUST be ignored and a warning MUST be issued.
>=20
> I went back and looked at how my RP code handled this.  One can very
> quickly get lost in the weeds here, but briefly: I start with a set of
> "candidate manifests" and a set of "candidate CRLs", and keep pruning
> those sets down with one form of validity check after another
> (signatures and hashes must match, timestamps must be sane, URIs must
> match, yada yada).  If, at the end of this I still have more than one
> candidate CRL, I don't necessarily pick the first CRL in the manifest:
> instead, I sort the candidates by CRL Number, thisUpdate, and time at
> which I retrieved that CRL object (in descending order of preference,
> so the timestamps only matter if CRL Number is identical, etc), and
> use this to pick the "most recent" valid CRL.
>=20
> YMMV, but this arguably yields a more useful result in this screwball
> situation.  That said, this is (obviously) more complex to describe
> and to implement, so may not be worth it, given that this should never
> be happening in the first place.
>=20
> If one wants a simplified version of this algorithm that stays within
> the confines of a single manifest, one could do the sort by CRL
> Number, then thisUpdate, then position in the manifest.

To the best of my knowledge there has never been any RPKI CA =
implementation which will use more than one .crl per manifest. So, can't =
we just simplify life and make sure that no one does in future?

It won't break any existing code, we just need to make it clear to new =
CA implementers that they should not needlessly complicate life for =
themselves and everybody else.

Tim



From nobody Wed May 13 03:53:47 2020
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 AD4783A1033 for ; Wed, 13 May 2020 03:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3yMWLdyjGs8 for ; Wed, 13 May 2020 03:53:44 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0: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 112753A1031 for ; Wed, 13 May 2020 03:53:43 -0700 (PDT)
Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 8E2AB359F1; Wed, 13 May 2020 12:53:41 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com
Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com
Date: Wed, 13 May 2020 12:53:41 +0200
From: Martin Hoffmann 
To: Rob Austein 
Cc: SIDR Operations WG 
Message-ID: <20200513125341.1ab3c222@glaurung.nlnetlabs.nl>
In-Reply-To: <20200512204126.7A03220156D8FC@minas-ithil.hactrn.net>
References:    <20200511123331.5c2d604a@glaurung.nlnetlabs.nl> <73D1F29B-7F54-4022-975C-477B3A9E7CC5@psg.com> <20200511125957.09b5f5e5@glaurung.nlnetlabs.nl>  <20200512204126.7A03220156D8FC@minas-ithil.hactrn.net>
Organization: Open Netlabs
X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Sidrops] nlnet rp and rsync
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, 13 May 2020 10:53:46 -0000

Rob Austein wrote:
> FWIW: I believe that the intent of the WG at the time we wrote the
> current specification was that rsync be mandatory to implement for
> both CA and RP.  As others have noted, the somewhat misnamed
> "deprecate-rsync" draft is about changing that, which is fine if
> that's the direction we want to go, but for now I think an RP is
> required at least to attempt to fall back to rsync when RRDP fails.

This particular case has its very own section in RFC 8182, section
3.4.5. This section does explicitly not require to fall back to rsync
and leaves it to the relying party software whether it wants to try any
other method or not. My, purely subjective, reading of its tone is
that it even suggests not to bother.

Kind regards,
Martin


From nobody Wed May 13 06:53:26 2020
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 286393A0B5C for ; Wed, 13 May 2020 06:53:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCzdBwh22WJb for ; Wed, 13 May 2020 06:53:24 -0700 (PDT)
Received: from sonic302-2.consmr.mail.bf2.yahoo.com (sonic302-2.consmr.mail.bf2.yahoo.com [74.6.135.41]) (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 E8AE33A0B62 for ; Wed, 13 May 2020 06:53:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1589378002; bh=Fn+58ZPG9Nq1nHCgC7YacMn+gZJTR1kNIfUoLy6gK5I=;  h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=i4mYTr3cmeRK6cOwPhzFgeGlLQMKdQbbTsvr7aBDQItpiyAWhoCu5GWZ9MtHyXVllaXW7fh3k0v+lpsg8ULQBHyXO6zQJtToh4CjIW9rnpU9qP5oQ+DfmRn0uwoa5eeb1tsTV5BCReeFOdLAQmY15ZebCuQOVeRoMG5jAWkUl472DAUqCUeHsxNMejt2pSVjWl3sjbfFQ6nNw4rZgMrENoRn/nFuF3XcKb5epbtc0m4ePbuk7VF9WVVB/MYBjbwkZVj1Ug8XYs2dWx/wpzq5o8DrP/G6ge6Y7dt47HqvX1AUVLrtli1eaHKa5AxOlmK8t5pymWJGZKv7pLmppTFiMQ==
X-YMail-OSG: jrCbmZUVM1naJnI6pzvkIHll2MjCgtiwXJhQ.dIKtrT_79CNMuRystO70ll_mpc _YMtsXVusTbmx.M4PpLhOiqkqaS1.PYbk4G30tOn5u33mP9xkYLuE2ic.69SDwNVY_V7aQ0p3m1K XK5ZZv8E9PFEtI2L595rNAbOtDuEKVqom.AOuRJN0lKY.eUAzFbPsierQfLdXG0dqEf_oUvSb4n8 6A343yJx.Jz4VX2uQSAabIb5WCMSzch9ELTnXIoLXScJN0Mw5Y1UYGQKvEjPhl1hBQSSkQ3hsVBG ultq8AgtOOqVJX0qEpDXoofSeJqpeog7N3__DhZ9Ac4t1v6nQ_D0_rBUmCajof4x4nKxDITDRSj3 6RZAXdmDxM3XUdHBvV0HWfi7pvGEMOMnK2nPecj8yQBn94Gg0gILl7HIPrtpaa3BI4Gzg2RPTg4d v7sps2G4Ho7_S.WdYrVu22cVqWKfZaJaXrPU9BcsxYV6pEtwaKBbhUKbIPv7ZTA53aDKhtQ7FQYp 9tpUGDda4O4rq8HdYTPl2PJ0X0VGAlRpiIGPlTEyXx5G2mO1oBGgDl.WvzAsYxeJ58SJRkvnjLXn WtVejC__8EgLL8299O6eoqUyUtGIIlOTW2sjEfxZ2wNtzgJeaix16xzKojiqemvgF_gKFCLdWPp_ 93t_1Gn3AutYa4DhfLXukZCdxTf45.lY1KnQrYOV8UAEVfPWW2_Dhh7Lk56gkKnXe2ODtzr4Ydu5 AS._UiCRLgcddWDWeS3uInkUskLAxhePjDh.1eFvn76DHFsMZC5ZX1etXw0os6zSut4vOFE2AHiC i9Gz0tfJjrgpwgiUL4rS8UKKUcrBGPtNbalefm4leA2RnSx3sUTjSCFdwBnD5SeknMwAmC8s_gxY 1.NXx_lIfUhq_6EMX2JBSwnBQgKC7srKcZPs5MHfqLUrL.NRT2rTN6w9x9owZ2oRsKqcY7j619pF dlaV4Tk61POB7yr9bosuzfsZOfhqTeKCtAsP1HhHz6jZudB.kTxhFncS_ShH24GvTsqbiIk2jqJM Il_4KEMeTTRaBCt00gaNMf1EVmYRWKn3xfS5uNs.elxBcqWtntOHComnCL_Q13hgBbAhu4iTN_eH Irjp4O_.CugCE5VA6udBLG2OqW_8mk8zPUDJIvA9Cj_0Mq5T8kqaeCer2bzxFOOpdW5mxRXsyovX b32v7Ba_u6HgDjKoMyHMihydQGxzmj1PIUbsaBs5kLdLZw4GP94nIPWauxOaAdbNr4H5zfXHmFxE P9ni0mrJ3LIqOQ7L2Q60FwCHNOwJvLBA.FXi7CmR51e0R..DTtASD7Bd8jXnAs8E60u4Ny1qbKaY GAv2YVXDBhWNXHWryHXb9QRMuXMUem0zxFS7ItMkww6sATMgogZH44jbPk2dF7Kt0PDh.JFs70pV .dOuK9DzAIMbADHJwqznh1FOtam9WWiYtc8hfqbJqcAK60JKBw4jedi0N
Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Wed, 13 May 2020 13:53:22 +0000
Received: by smtp404.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a0298c21b5fd48a9c4ce54403157cf2c;  Wed, 13 May 2020 13:53:18 +0000 (UTC)
To: sidrops@ietf.org
References:   <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net>
From: Stephen Kent 
Message-ID: <73b88326-d537-93eb-b0d0-a0a82507081c@verizon.net>
Date: Wed, 13 May 2020 09:53:18 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net>
Content-Type: text/plain; charset=iso-8859-7; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.15904 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
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, 13 May 2020 13:53:25 -0000

Rob,
> On Fri, 08 May 2020 11:26:22 -0400, Stephen Kent wrote:
> ...
>> A manifest SHOULD contain exactly one CRL (.crl) file and it MUST be
>> at the location specified in the CRLDP in the manifest�s EE
>> certificate.  If more than one .crl file appears in the manifest,
>> only file names matching the CRL specified by the CRLDP will be
>> processed. If more than one .crl entry appears in the manifest, and
>> matches the CRLDP, the first one encountered MUST be used.  Any
>> other .crl files MUST be ignored and a warning MUST be issued.
> I went back and looked at how my RP code handled this.  One can very
> quickly get lost in the weeds here, but briefly: I start with a set of
> "candidate manifests" and a set of "candidate CRLs", and keep pruning
> those sets down with one form of validity check after another
> (signatures and hashes must match, timestamps must be sane, URIs must
> match, yada yada).  If, at the end of this I still have more than one
> candidate CRL, I don't necessarily pick the first CRL in the manifest:
> instead, I sort the candidates by CRL Number, thisUpdate, and time at
> which I retrieved that CRL object (in descending order of preference,
> so the timestamps only matter if CRL Number is identical, etc), and
> use this to pick the "most recent" valid CRL.
>
> YMMV, but this arguably yields a more useful result in this screwball
> situation.  That said, this is (obviously) more complex to describe
> and to implement, so may not be worth it, given that this should never
> be happening in the first place.
>
> If one wants a simplified version of this algorithm that stays within
> the confines of a single manifest, one could do the sort by CRL
> Number, then thisUpdate, then position in the manifest.
>
I will revise the text describing how to handle this case, based on WG 
consensus. Your approach is very robust, but also complex. Since there 
should be only one CRL in the manifest, and since Tim says that no RPKI 
CA generates more than� one, I tend to favor a simple requirement here, 
but ...

Steve


From nobody Wed May 13 07:05:22 2020
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 3C2BA3A0B83 for ; Wed, 13 May 2020 07:05:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeRbPhF6-eRK for ; Wed, 13 May 2020 07:05:19 -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 E1BCF3A0A04 for ; Wed, 13 May 2020 07:05:18 -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 1jYs0Z-00030S-Ty; Wed, 13 May 2020 14:05:16 +0000
Date: Wed, 13 May 2020 07:05:15 -0700
Message-ID: 
From: Randy Bush 
To: Stephen Kent 
Cc: sidrops@ietf.org
In-Reply-To: <73b88326-d537-93eb-b0d0-a0a82507081c@verizon.net>
References:   <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net> <73b88326-d537-93eb-b0d0-a0a82507081c@verizon.net>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
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, 13 May 2020 14:05:20 -0000

> I will revise the text describing how to handle this case, based on WG
> consensus. Your approach is very robust, but also complex. Since there
> should be only one CRL in the manifest, and since Tim says that no
> RPKI CA generates more than=EF=BF=BD one, I tend to favor a simple
> requirement here, but ...

indeed no ca SHOULD push more than one CRL.  but i do not think i would
recommend not defending against it.

randy


From nobody Wed May 13 07:32:20 2020
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 E9CBD3A0C7F for ; Wed, 13 May 2020 07:32:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 w1LIkoTn0MIO for ; Wed, 13 May 2020 07:32:17 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.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 B5EC93A0C80 for ; Wed, 13 May 2020 07:32:17 -0700 (PDT)
Received: from [IPv6:2001:981:4b52:1:bc2c:d6fa:cbdd:1589] (unknown [IPv6:2001:981:4b52:1:bc2c:d6fa:cbdd:1589]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 8979335EC3; Wed, 13 May 2020 16:32:15 +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=1589380335; bh=ty3RaBkKcKPgDG0GltDl4MQQk+MJyHPb4rOi7/VzycE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=HD93BHqx7IjXqJCnx5+4UZJPuk+yRMEUtsXlFGbl5Awg8CM+GvRZeLIYk2pNwKkky KPv7cK5DgbMhtLiNgk/iQ45h1PkcM7wzY7ClCruEhjWFqzxRlb4m5zCbeZJ7ZUfjRl 2dW1dlxEJrJo2aQmmoYWXvDEBxLdWrjQVbjDUY5o=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Tim Bruijnzeels 
In-Reply-To: 
Date: Wed, 13 May 2020 16:32:15 +0200
Cc: Stephen Kent , sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <70BC4878-93D3-4331-A887-AF693B7CC9AA@nlnetlabs.nl>
References:   <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net> <73b88326-d537-93eb-b0d0-a0a82507081c@verizon.net> 
To: Randy Bush 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
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, 13 May 2020 14:32:19 -0000

> On 13 May 2020, at 16:05, Randy Bush  wrote:
>=20
>> I will revise the text describing how to handle this case, based on =
WG
>> consensus. Your approach is very robust, but also complex. Since =
there
>> should be only one CRL in the manifest, and since Tim says that no
>> RPKI CA generates more than=EF=BF=BD one, I tend to favor a simple
>> requirement here, but ...
>=20
> indeed no ca SHOULD push more than one CRL.  but i do not think i =
would
> recommend not defending against it.

In my opinion there should be a MUST include one and only one CRL. Then =
offending MFTs can be considered broken, and there is no defensive code =
needed.

I don't see how this could be an issue for CAs given that none include =
more than one CRL on MFTs until now. But if other CA implementers =
disagree then I would be very happy to hear about it.

Tim

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


From nobody Wed May 13 07:36:09 2020
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 28D953A0C7F for ; Wed, 13 May 2020 07:36:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxE-ndh4ctAc for ; Wed, 13 May 2020 07:36:05 -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 A4F183A0C80 for ; Wed, 13 May 2020 07:36:05 -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 1jYsUM-00037b-Bg; Wed, 13 May 2020 14:36:02 +0000
Date: Wed, 13 May 2020 07:36:01 -0700
Message-ID: 
From: Randy Bush 
To: Tim Bruijnzeels 
Cc: Stephen Kent , sidrops@ietf.org
In-Reply-To: <70BC4878-93D3-4331-A887-AF693B7CC9AA@nlnetlabs.nl>
References:   <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net> <73b88326-d537-93eb-b0d0-a0a82507081c@verizon.net>  <70BC4878-93D3-4331-A887-AF693B7CC9AA@nlnetlabs.nl>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
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, 13 May 2020 14:36:08 -0000

> In my opinion there should be a MUST include one and only one
> CRL. Then offending MFTs can be considered broken, and there is no
> defensive code needed.

you are talking to someone who thought that rsync MTI spec was
sufficient

my mother would recommend a bit of focus on defensive, not offensive,
programing.  do not na=EFvely trust the input.  assume that some QA geek
is gonna throw a fuzz test at you.

randy


From nobody Wed May 13 09:12:56 2020
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 2D4CF3A0A29 for ; Wed, 13 May 2020 09:12:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYUJQi0PWSln for ; Wed, 13 May 2020 09:12:54 -0700 (PDT)
Received: from sonic313-13.consmr.mail.bf2.yahoo.com (sonic313-13.consmr.mail.bf2.yahoo.com [74.6.133.123]) (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 AACBF3A1086 for ; Wed, 13 May 2020 09:12:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1589386322; bh=4sQNkYNmWh/pEAnxGJjUoiuYvCwCemejrWaD5FHqe2A=;  h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=HJtKbQ1QV8Gmq3/VLZkoHQAlD4R4H0zE2kaQNkSc1d8SaoK9fEwECjvNwEaFDUkBLdsShw4ufxGtZc9uBN82M5M9GiI0HZtRFJpDXuS/0q2YP2AeCAYG08eem9/qilCD0TCYuUWGwyzWzNY5ooj3JEHaoeueHmjvUp+Kb4/KdNg3nFePMobyCqLyUlhddX0JCzY6k8HYPojLk11FgzEqwfNEeiJ6RmRSSdrMSvqKwjZCJWJ0EmUnHMY6oO9HS37DfeaFou62SrDz8ojJDQ1ZRcNFmTN9bRTlJrinm3E1ZQNhSDiC0ViUwV2Wmknvf5MB2D/jncYWiamgGHUhAbZWLQ==
X-YMail-OSG: _x6lXIUVM1nj4xngmvYiHFBA9qcs4UML3UkT7kFPe87drOdDJTJ.2cdyuK0xCY1 vYZgBJUxmZ_7K7BBxOeCvtGxUQtd2vL7_vBnsQw9SZ7hVpiO3lL4nzjIHjT6bF84SxvEYMksoU4J cavs9.PO4A_88VG9C5yQ9wJM90SaO6iqUP0bvr6Q.JosOHo_PG0D6bUoT9EN2daC2uKPnCinmUjF XvkXymFrN6mrnoxN1ILXHpdb67zh.5DhYwh38gsjDB9P_SI7ICRf4YgM2P4Mhuwr9tS0GeyA4mID 7.H0MnnKTRqbPD_.7vPBmWmZYE4Q9swXSV1Oi5bEW0eYevEyYxxhBKeYOsJ1z4Fh9drBC0NAklYB i8jncYP3R8FyuJdYhCEUwmX7kOwMNlbXhgvqfJDkyAUZQiuvIHngKMbqxdOwnvX1rr2MBNYdKJWM 6_uxSWyfzTDcktkBhqZWhfiG96kE4WTSjuoKYU23mU5OskY1UeeQqnRONrHJIBIY6O3G4_zAt44C xbrHEq0j8V9mhZBaHWbgLAE9Fxq46noGUeOp.urCz_O1WLlRVorIkaUJdXpZWzoL4CS6tYFdET6H 7ALoHwctRpRcx6gwSzz.z8fEcr4gO1oWbvtXIvvRksbEw.jWlBesIg79Us9Qke__uQWNFfKZLb9y Yt68U.J5skrXE3t5VHzPIm_ki.gE9emrbZZU_fTKEjS9aQjc2Ry6jXvhr4BFrPjlor0ydYYDc8Yb 6UpaSKkK33aNu.CfPCUjIJUw88wF2.ROJn_d1Tu7lytakJIEleQk5Z1cokL_1mQeH8i8.AnhTxCQ 7msB9pnQGkWZptowxWePW1tJEVjVRMr.2W6F84VXkE0.mXBRsh143_Sc30wI55uDTLg2tv.h8PPr EcJ7ef4rj6oiNifpMmOErONcYfR6fX_f1FJUOgN_f1iSXB3a1Ws9r_ePwOHmMR5tf0xiD2BzE4.L HenfLBemlCaGewAo6qw.3TMx3TE46F.4o0jaoMeGEVFE20ezTMR4ABcZwmzfB2sr_OEQom4SCK.F KSa4HiVMn52j_PsJrPOnZFhFLi0JsvsqfnLonYdTHTBLYcehpVBt3sCEDkdcEV..TJ3U_fBb8aCz WSjcwKjJ8OVolOBYuZtCdPWbCavLFAqdDRb09hJTHFSX9liANVdek0LrnfN4467MRGGQ6w7xBWsp 40DTML8vX.eFLIhslrFF55j5Yq_hFjAl9kWDrDwrVL73CBSnwuyytD6nVN88mf7qABjxU5k4Fozr ZVWHVERl0EAt10XZLm72yVYr.tXwYTEp7cD8uG1GcH8X8ite4yVm0GLP4jVhSMXi_QAgbLzpeE5l 95.ePg2S9eaAv_qplJy273GV2.1Y_wrVcRT2Eaa2Kqov10VS4ZOZy1ealZREQtZB9ftCcrUybOkt Inc1NS_3jan8Gdet_QJcgyIibG5bI9zIvjHv8OSM.Wk3t2dMvTa.aWeYqefp2Eg--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Wed, 13 May 2020 16:12:02 +0000
Received: by smtp403.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 61c4d041b28c72b3a64eb8a8cd8ec437;  Wed, 13 May 2020 16:11:57 +0000 (UTC)
To: "sidrops@ietf.org" 
References:   <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net> <73b88326-d537-93eb-b0d0-a0a82507081c@verizon.net> 
From: Stephen Kent 
Message-ID: <076ad9b0-ea5d-47a4-52f7-8b913dc6c1ae@verizon.net>
Date: Wed, 13 May 2020 12:11:56 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.15904 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
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, 13 May 2020 16:12:55 -0000

Guys,
>> I will revise the text describing how to handle this case, based on WG
>> consensus. Your approach is very robust, but also complex. Since there
>> should be only one CRL in the manifest, and since Tim says that no
>> RPKI CA generates more than??? one, I tend to favor a simple
>> requirement here, but ...
> indeed no ca SHOULD push more than one CRL.  but i do not think i would
> recommend not defending against it.
>
> randy

I think we all agree that the revised Section 6 text needs to 
accommodate the possibility that a manifest will list more than one CRL, 
even though this OUGHT NOT happen (see RFC 6919). The only question?? is 
how hard do we require an RP to work if it encounters more than one CRL. 
I prefer a simple approach to selecting one, and a mandatory warning. 
Rob has offered a more sophisticated, and complex approach, based on his 
working RP code.

I await a consensus from the WG.

Steve


From nobody Wed May 13 09:21:20 2020
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 93C883A1033 for ; Wed, 13 May 2020 09:21:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wei2KtWoxTM3 for ; Wed, 13 May 2020 09:21:17 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0: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 5B7A73A1030 for ; Wed, 13 May 2020 09:21:16 -0700 (PDT)
Received: from grisu.home.partim.org (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id C9348360FB; Wed, 13 May 2020 18:21:13 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com
Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com
Date: Wed, 13 May 2020 18:21:13 +0200
From: Martin Hoffmann 
To: Stephen Kent 
Cc: "sidrops@ietf.org" 
Message-ID: <20200513182113.21e08e83@grisu.home.partim.org>
In-Reply-To: <076ad9b0-ea5d-47a4-52f7-8b913dc6c1ae@verizon.net>
References:   <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net> <73b88326-d537-93eb-b0d0-a0a82507081c@verizon.net>  <076ad9b0-ea5d-47a4-52f7-8b913dc6c1ae@verizon.net>
Organization: Open Netlabs
X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
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, 13 May 2020 16:21:19 -0000

Stephen Kent wrote:
> 
> I think we all agree that the revised Section 6 text needs to 
> accommodate the possibility that a manifest will list more than one
> CRL, even though this OUGHT NOT happen (see RFC 6919). The only
> question?? is how hard do we require an RP to work if it encounters
> more than one CRL. I prefer a simple approach to selecting one, and a
> mandatory warning. Rob has offered a more sophisticated, and complex
> approach, based on his working RP code.

I would prefer a simple solution. Either that multiple CRLs make the
manifest invalid or as long as a CRL is listed on a manifest and the
manifest hash as well as its signatures and times check out, it can be
referenced and used. The latter is what Routinator does now.

Kind regards,
Martin


From nobody Wed May 13 09:33:07 2020
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 309023A0E01 for ; Wed, 13 May 2020 09:32:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FLLzCc9Z3g0 for ; Wed, 13 May 2020 09:32:56 -0700 (PDT)
Received: from out20-63.mail.aliyun.com (out20-63.mail.aliyun.com [115.124.20.63]) (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 079523A0D5B for ; Wed, 13 May 2020 09:32:51 -0700 (PDT)
X-Alimail-AntiSpam: AC=CONTINUE; BC=0.1080928|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_regular_dialog|0.220448-0.000482922-0.779069; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03298; MF=madi@rpstir.net; NM=1; PH=DS; RN=2; RT=2; SR=0; TI=SMTPD_---.HY5PrXY_1589387562; 
Received: from 192.168.3.24(mailfrom:madi@rpstir.net fp:SMTPD_---.HY5PrXY_1589387562) by smtp.aliyun-inc.com(10.147.42.241); Thu, 14 May 2020 00:32:44 +0800
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Di Ma 
In-Reply-To: <076ad9b0-ea5d-47a4-52f7-8b913dc6c1ae@verizon.net>
Date: Thu, 14 May 2020 00:32:20 +0800
Cc: "sidrops@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <5994380C-4DEF-4EBC-8707-69AF0E4F1617@rpstir.net>
References:   <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net> <73b88326-d537-93eb-b0d0-a0a82507081c@verizon.net>  <076ad9b0-ea5d-47a4-52f7-8b913dc6c1ae@verizon.net>
To: Stephen Kent 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
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, 13 May 2020 16:33:06 -0000

I am in favor of Steve=E2=80=99s preference on behalf of RPSITR 2 =
implementation.

If we don=E2=80=99t place strict constraint on the RPKI provisioning =
side, we will see more inconsistence among RPs.

Di

> 2020=E5=B9=B45=E6=9C=8814=E6=97=A5 00:11=EF=BC=8CStephen Kent =
 =E5=86=99=E9=81=93=EF=BC=9A
>=20
> Guys,
>>> I will revise the text describing how to handle this case, based on =
WG
>>> consensus. Your approach is very robust, but also complex. Since =
there
>>> should be only one CRL in the manifest, and since Tim says that no
>>> RPKI CA generates more than??? one, I tend to favor a simple
>>> requirement here, but ...
>> indeed no ca SHOULD push more than one CRL.  but i do not think i =
would
>> recommend not defending against it.
>>=20
>> randy
>=20
> I think we all agree that the revised Section 6 text needs to =
accommodate the possibility that a manifest will list more than one CRL, =
even though this OUGHT NOT happen (see RFC 6919). The only question?? is =
how hard do we require an RP to work if it encounters more than one CRL. =
I prefer a simple approach to selecting one, and a mandatory warning. =
Rob has offered a more sophisticated, and complex approach, based on his =
working RP code.
>=20
> I await a consensus from the WG.
>=20
> Steve
>=20
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops


From nobody Thu May 14 00:36:06 2020
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 E8A603A0400 for ; Thu, 14 May 2020 00:36:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 5VFkOx0k3s4n for ; Thu, 14 May 2020 00:36:01 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.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 15CF63A03F6 for ; Thu, 14 May 2020 00:35:52 -0700 (PDT)
Received: from [IPv6:2001:981:4b52:1:edc9:447a:8576:9b98] (unknown [IPv6:2001:981:4b52:1:edc9:447a:8576:9b98]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 4282937389; Thu, 14 May 2020 09:35:50 +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=1589441750; bh=oSuLmQoAJOLsq2OA6jgvgfwX0o23I/DUoDrZlcJiuIQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=XnaXwaauu81oXU4hSEtTeykOmMttSjljMi7WZoCREhWHMDhE1kc5UpjQwtfUhs4AG tHtlErUGPsUCgersqKjE5Eeb0ZuEm41Zbw9xPHeotcaBqUlEjVsBqlQpQNb7t8D1s4 NT8u1BdWWk+8Y6g0F/8j/zwBtwTckbt7ESE3xKS0=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Tim Bruijnzeels 
In-Reply-To: <076ad9b0-ea5d-47a4-52f7-8b913dc6c1ae@verizon.net>
Date: Thu, 14 May 2020 09:35:49 +0200
Cc: "sidrops@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net> <73b88326-d537-93eb-b0d0-a0a82507081c@verizon.net>  <076ad9b0-ea5d-47a4-52f7-8b913dc6c1ae@verizon.net>
To: Stephen Kent 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
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, 14 May 2020 07:36:04 -0000

Hi,

> On 13 May 2020, at 18:11, Stephen Kent =
 wrote:
>=20
> Guys,
>>> I will revise the text describing how to handle this case, based on =
WG
>>> consensus. Your approach is very robust, but also complex. Since =
there
>>> should be only one CRL in the manifest, and since Tim says that no
>>> RPKI CA generates more than??? one, I tend to favor a simple
>>> requirement here, but ...
>> indeed no ca SHOULD push more than one CRL.  but i do not think i =
would
>> recommend not defending against it.
>>=20
>> randy
>=20
> I think we all agree that the revised Section 6 text needs to =
accommodate the possibility that a manifest will list more than one CRL, =
even though this OUGHT NOT happen (see RFC 6919). The only question?? is =
how hard do we require an RP to work if it encounters more than one CRL. =
I prefer a simple approach to selecting one, and a mandatory warning. =
Rob has offered a more sophisticated, and complex approach, based on his =
working RP code.

What may not have been clear from my earlier message is that I agree =
that in today's world it's worth supporting the possibility of more than =
one .crl like Rob A. has done.

That said, we are looking to improve things here, and reducing corner =
cases is good.

This is about the number of current .crl files on a manifest, not about =
files that may still linger in the repository under the directory - e.g. =
for other keys. Even if it is not explicit, RFC 6480 certainly points at =
having one CRL per keypair. And 6 out of 6 independent CA =
implementations have done exactly that. Therefore I think it would be =
perfectly safe to add a requirement in the MFT RFC update that there =
MUST be one CRL only. This will simplify things greatly for RPs.

If not, then indeed we need to have a discussion about how to deal =
properly with multiple CRLS. E.g. do you check *all* of them for each =
issued certificate, or do you only check the CRL matching the CRLDP of =
that certificate? I would also be very curious to know which use case =
warrants having this complexity.

Tim





>=20
> I await a consensus from the WG.
>=20
> Steve
>=20
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops


From nobody Thu May 14 11:14:00 2020
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 77EA13A0B0C for ; Thu, 14 May 2020 11:13:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjgk1C_XHfiy for ; Thu, 14 May 2020 11:13:57 -0700 (PDT)
Received: from sonic317-26.consmr.mail.bf2.yahoo.com (sonic317-26.consmr.mail.bf2.yahoo.com [74.6.129.81]) (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 195223A0766 for ; Thu, 14 May 2020 11:13:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1589480036; bh=DMxfkgggEahhx1oQnYLvFCr9rbonzYuf+w1ku1LkeQc=;  h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=QdZX+kl2IAHXN1xslN0FZ98uW3eKBMH6hSwL0dag85VVEst5OZG9hUNBDUgV70hT8ewYjljolrRHFx8+f7KTdrNZ3BfbJk++lHazDMooQPPhPF/+Bk1MkW2ZC7LcBXmy7iHTCu8HZZegJQ+Cc6lXUL4vmFj41bxwQl962UkbSP1VFMjWSrfn4I8+fIgyGR3AYR3kdmUCZASQpSGHu14FyLmodx0vX96qU3/mmVPFfGE1RsROM966h/58Z2+QYibS0+K7QTWb+84JfrEzNYJ+w4sYu5Dichds4eCNfnBm1BVOQx3Q5DQ0bFzUV/BpGPCxofvYPwynMDqs0EAxl2cuaQ==
X-YMail-OSG: SZbzRaoVM1koxq_8u.jQUv1kR9g43cDW3NclZDGi.r87rjx3RIA4HsG.S1575iR VJ0MLi0UuJiYdEqkJbztdDUvkQILRtQUz995peDYMfJmiNe86rZAYIuvi050yepHw3zJwudmKdTu wActXTptzUy8YyEZrJ6f3W8uQes3knnp_DSbOX6D_g7Zs0lDnrIlseKy_CUjlq7jaQzetsdfzjTZ eYeaJaWdhzxlLaSQdWfaLinRnGze4d4EHVaYSD8j9qSq49Tmq44H.xMguh6P4J8RSQPrcKcOji_8 A9AHQe4PoOj8xXoll9MhwxwCzvMyVWPdU1q3YBdhiT_rwNlBGPsxVrXut8zAk_EBSJhmZmYtDuk8 H2K57vxLlTI.ZwuH0u4awBXB8KqZ9yGVQWG6hXUl2eC4nB1MjyZE9FYECbzBLmPHJVjO3VD4VlWb s.JDiZJjtRCj1osxb.m37Br_SU2oKGFhLe5gVmU8XLE6GgfHKJK15iZiRQmW4NWqZO9CPtojq5EH 6zQiIi5IarluiEYRTzU9JUkUWi27.t_OxXg2Dz57hMofsC3n2.wk_X2LzYUMb8NRuyDFU2C9KtO9 .6ibJ.i1mA5zNDc7vFx1120ZZBUGGn8.1LLKuqLQsB0JmN9Mfof5uWFYj_RgCo6O.YXuyu2gZIU3 j98butsrYxGH7mdqDQ5_L3ePdW47slz9wZuZ1r1jqDQW1OeA_RBPTeW5FVRgcfdEfpr1ksFG57sD xV2MtjD71d4YxOel6hWr26W0voYf2FB_xQxEcYMHeR6TMysmRYDBp7o2C3JX6VF8jw4q1OMC2YP9 dAq6XruE.WXj6AI38iXkjv0Au89eRHu_vTUTDB0uvDIXyjIgttDBDldi8tySDEBkn6yiWIuMLEzP Z6OPPLrsQDtfzu3rY0OIpoKkqhACpAvvGaQSielhSG7BEg0g8TDWvLTrpV3GkU_BYTKC_XoVFYcp LfewfvGweOwup1tw2po1odMpAw2MUQxg41eoN9DBt1ZDSspLP3WaPv7eucZFvW5XDC8BXfwCfNBQ BQCyBxdixJB78YUq4uNxHk0SVPtvzTxpkOckvUb9_qF6FxEt11f.m_AGN7dakN6T3r15KmP7NKPK BA.0IQaBgxn5MLVjfX7Q7Y17mns7ODh3y3NnYd6iV1EOSC7KBqRKuLfcbtF64Gv3mO_6iTHlCSp_ VDEsRMkEvY5rBOewH5WDoctzCkM6b9Un10Ckzc6kIxwvSyRLX_WcIWhuhnEpBWWUx215p31g_38b 4avCu29XbARSf2x4y08GxPN0jQVHkgAqj6e7U67lfR67IJI128Qvd7tk688efdVGBggxX6fQQEUY j132qMz66cinG.eBKWdxVzoy3qMJCtOWfBXmgSfR6g5s0y8YtBWGAgEKXVPrwjuMk8P7J4L7LP4o GpaCMv2t5BbGHDm6UGMz5SukqIYagOTAQslErIid1ExOVrX57Kev4
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Thu, 14 May 2020 18:13:56 +0000
Received: by smtp403.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 34645cecae602f4a58ab7b7e7342451a;  Thu, 14 May 2020 18:13:52 +0000 (UTC)
To: sidrops@ietf.org
References:   <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net> <73b88326-d537-93eb-b0d0-a0a82507081c@verizon.net>  <076ad9b0-ea5d-47a4-52f7-8b913dc6c1ae@verizon.net> 
From: Stephen Kent 
Message-ID: <156c83ba-d4d8-8baa-7f87-a2600cb9c19a@verizon.net>
Date: Thu, 14 May 2020 14:13:48 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Mailer: WebService/1.1.15941 hermes_aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
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, 14 May 2020 18:13:59 -0000

Tim,
> ...
> What may not have been clear from my earlier message is that I agree that in today's world it's worth supporting the possibility of more than one .crl like Rob A. has done.
>
> That said, we are looking to improve things here, and reducing corner cases is good.
>
> This is about the number of current .crl files on a manifest, not about files that may still linger in the repository under the directory - e.g. for other keys.
I agree that the focus of this discussion is files listed on a specific 
manifest. If a CA has a different key, and thus a different cert, the 
CRL issued under that key will be on a different manifest, and thus is 
not part of the concern here.
> Even if it is not explicit, RFC 6480 certainly points at having one CRL per keypair. And 6 out of 6 independent CA implementations have done exactly that. Therefore I think it would be perfectly safe to add a requirement in the MFT RFC update that there MUST be one CRL only. This will simplify things greatly for RPs.
One CRL per manifest is my goal as well.
> If not, then indeed we need to have a discussion about how to deal properly with multiple CRLS. E.g. do you check *all* of them for each issued certificate, or do you only check the CRL matching the CRLDP of that certificate? I would also be very curious to know which use case warrants having this complexity.

My suggestion is the KISS approach - first .crl file that has a valid 
hash is the one to use, and others are ignored. That's less forgiving 
than what Rob accommodates, but being forgiving here might take pressure 
of a CA to do its job properly.

Steve


From nobody Fri May 15 00:08:48 2020
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 C4F0E3A07A1 for ; Fri, 15 May 2020 00:08:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtmqOrbUrcSR for ; Fri, 15 May 2020 00:08:45 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0: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 3773F3A07A0 for ; Fri, 15 May 2020 00:08:45 -0700 (PDT)
Received: from grisu.home.partim.org (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 9B03F118B4; Fri, 15 May 2020 09:08:40 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com
Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com
Date: Fri, 15 May 2020 09:08:40 +0200
From: Martin Hoffmann 
To: Stephen Kent 
Cc: sidrops@ietf.org
Message-ID: <20200515090840.12a9464a@grisu.home.partim.org>
In-Reply-To: <156c83ba-d4d8-8baa-7f87-a2600cb9c19a@verizon.net>
References:   <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net> <73b88326-d537-93eb-b0d0-a0a82507081c@verizon.net>  <076ad9b0-ea5d-47a4-52f7-8b913dc6c1ae@verizon.net>  <156c83ba-d4d8-8baa-7f87-a2600cb9c19a@verizon.net>
Organization: Open Netlabs
X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
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, 15 May 2020 07:08:47 -0000

Stephen Kent wrote:
> Tim,
>
> > If not, then indeed we need to have a discussion about how to deal
> > properly with multiple CRLS. E.g. do you check *all* of them for
> > each issued certificate, or do you only check the CRL matching the
> > CRLDP of that certificate? I would also be very curious to know
> > which use case warrants having this complexity. =20
>=20
> My suggestion is the KISS approach - first .crl file that has a valid=20
> hash is the one to use, and others are ignored. That's less forgiving=20
> than what Rob accommodates, but being forgiving here might take
> pressure of a CA to do its job properly.

I=E2=80=99m not sure it really does. Rather, it will lead to strange looking
issues: If the wrong CRL accidentally made it onto the manifest and it
comes first, all objects are invalid even though everything sort of
looks fine. This may even come and go if a CA reorders the CRLs when
it reissues the manifest[0]. If all CRLs are referenced by objects, some
objects suddenly are invalid while others aren=E2=80=99t.

I think invalidating the manifest with a clear warning is the more
straightforward approach and much easier to debug.

Kind regards,
Martin

[0] That may happen if it is file system based and just adds files as
    they appear when reading the directory without sorting the file
    names first.


From nobody Fri May 15 02:18:12 2020
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 4073B3A07C8 for ; Fri, 15 May 2020 02:18:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbJ4DItbnVOy for ; Fri, 15 May 2020 02:18:07 -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 8D72E3A07BF for ; Fri, 15 May 2020 02:18:07 -0700 (PDT)
Received: from bufobufo.ripe.net ([193.0.23.13]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jZWTm-00077F-30; Fri, 15 May 2020 11:18:06 +0200
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::36a]) by bufobufo.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jZWTl-0001o5-Vb; Fri, 15 May 2020 11:18:05 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Oleg Muravskiy 
In-Reply-To: <20200515090840.12a9464a@grisu.home.partim.org>
Date: Fri, 15 May 2020 11:18:05 +0200
Cc: Stephen Kent , sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2F7B5AE6-8250-4937-B246-12F6F1C978CD@ripe.net>
References:   <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net> <73b88326-d537-93eb-b0d0-a0a82507081c@verizon.net>  <076ad9b0-ea5d-47a4-52f7-8b913dc6c1ae@verizon.net>  <156c83ba-d4d8-8baa-7f87-a2600cb9c19a@verizon.net> <20200515090840.12a9464a@grisu.home.partim.org>
To: Martin Hoffmann 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-ACL-Warn: Delaying message
X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b742b2b50bb3707312f22078de4085f7d83
Archived-At: 
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
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, 15 May 2020 09:18:10 -0000

On 15 May 2020, at 09:08, Martin Hoffmann  =
wrote:
>=20
> Stephen Kent wrote:
>> Tim,
>>=20
>>> If not, then indeed we need to have a discussion about how to deal
>>> properly with multiple CRLS. E.g. do you check *all* of them for
>>> each issued certificate, or do you only check the CRL matching the
>>> CRLDP of that certificate? I would also be very curious to know
>>> which use case warrants having this complexity. =20
>>=20
>> My suggestion is the KISS approach - first .crl file that has a valid=20=

>> hash is the one to use, and others are ignored. That's less forgiving=20=

>> than what Rob accommodates, but being forgiving here might take
>> pressure of a CA to do its job properly.
>=20
> I=E2=80=99m not sure it really does. Rather, it will lead to strange =
looking
> issues: If the wrong CRL accidentally made it onto the manifest and it
> comes first, all objects are invalid even though everything sort of
> looks fine. This may even come and go if a CA reorders the CRLs when
> it reissues the manifest[0]. If all CRLs are referenced by objects, =
some
> objects suddenly are invalid while others aren=E2=80=99t.
>=20
> I think invalidating the manifest with a clear warning is the more
> straightforward approach and much easier to debug.

I tend to agree with this approach. It will keep RFC and validator=E2=80=99=
s code simple and force CAs to fix their bugs.

Oleg=


From nobody Fri May 15 02:38:47 2020
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 8C66F3A084F for ; Fri, 15 May 2020 02:38:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CVFY-lK9mvO for ; Fri, 15 May 2020 02:38:44 -0700 (PDT)
Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D63213A084D for ; Fri, 15 May 2020 02:38:43 -0700 (PDT)
Received: from allealle.ripe.net ([193.0.23.12]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jZWni-000BV1-DI for sidrops@ietf.org; Fri, 15 May 2020 11:38:42 +0200
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::4dd]) by allealle.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jZWni-0003mW-99; Fri, 15 May 2020 11:38:42 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Mikhail Puzanov 
In-Reply-To: <2F7B5AE6-8250-4937-B246-12F6F1C978CD@ripe.net>
Date: Fri, 15 May 2020 11:38:41 +0200
Cc: sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3BA5C557-E5C7-448B-86CC-539BA921E439@ripe.net>
References:   <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net> <73b88326-d537-93eb-b0d0-a0a82507081c@verizon.net>  <076ad9b0-ea5d-47a4-52f7-8b913dc6c1ae@verizon.net>  <156c83ba-d4d8-8baa-7f87-a2600cb9c19a@verizon.net> <20200515090840.12a9464a@grisu.home.partim.org> <2F7B5AE6-8250-4937-B246-12F6F1C978CD@ripe.net>
To: Oleg Muravskiy 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
X-ACL-Warn: Delaying message
X-RIPE-Signature: e2494821e8eb7112beaeaa277e8c25e0b764c6f7fd51a44148e4d8bec2c8752d
Archived-At: 
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
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, 15 May 2020 09:38:47 -0000

Agree.

RIPE NCC=E2=80=99s validator 2 implemented somewhat complicated logic =
for=20
picking up =E2=80=9Cthe latest valid manifest with the latest valid =
CRL=E2=80=9D
and in the validator 3 it had been changed to a much simpler version
=E2=80=9Cpick up the latest manifest, validate it, and makes sure it has=20=

a hash pointing to a valid CRL=E2=80=9D.

In the last 2 years of running both versions we have not seen any=20
discrepancies in the results reported by them that would be attributed=20=

to this specific change of the algorithm. So for all (99.9% of?)=20
practical purposes, nailing it down to =E2=80=9Cmanifest MUST include =
exactly=20
one hash pointing to a CRL=E2=80=9D would be preferable. Let alone it =
would=20
allow for simpler and more efficient RP code.

--
Mikhail Puzanov,
Senior Software Engineer,
RIPE NCC


> On 15 May 2020, at 11:18, Oleg Muravskiy  wrote:
>=20
> On 15 May 2020, at 09:08, Martin Hoffmann  =
wrote:
>>=20
>> Stephen Kent wrote:
>>> Tim,
>>>=20
>>>> If not, then indeed we need to have a discussion about how to deal
>>>> properly with multiple CRLS. E.g. do you check *all* of them for
>>>> each issued certificate, or do you only check the CRL matching the
>>>> CRLDP of that certificate? I would also be very curious to know
>>>> which use case warrants having this complexity. =20
>>>=20
>>> My suggestion is the KISS approach - first .crl file that has a =
valid=20
>>> hash is the one to use, and others are ignored. That's less =
forgiving=20
>>> than what Rob accommodates, but being forgiving here might take
>>> pressure of a CA to do its job properly.
>>=20
>> I=E2=80=99m not sure it really does. Rather, it will lead to strange =
looking
>> issues: If the wrong CRL accidentally made it onto the manifest and =
it
>> comes first, all objects are invalid even though everything sort of
>> looks fine. This may even come and go if a CA reorders the CRLs when
>> it reissues the manifest[0]. If all CRLs are referenced by objects, =
some
>> objects suddenly are invalid while others aren=E2=80=99t.
>>=20
>> I think invalidating the manifest with a clear warning is the more
>> straightforward approach and much easier to debug.
>=20
> I tend to agree with this approach. It will keep RFC and validator=E2=80=
=99s code simple and force CAs to fix their bugs.
>=20
> Oleg
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops


From nobody Fri May 15 07:33:02 2020
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 5AEBF3A0A49 for ; Fri, 15 May 2020 07:33:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Ff-PZpOdp6tX for ; Fri, 15 May 2020 07:32:59 -0700 (PDT)
Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21D3E3A099E for ; Fri, 15 May 2020 07:32:59 -0700 (PDT)
Received: by mail-oi1-x232.google.com with SMTP id c12so2399805oic.1 for ; Fri, 15 May 2020 07:32:59 -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=yNnSbszmjdz5ijAFGXP9OpgS6cxapkczHfGA51gOaII=; b=TQHb2au877fiVy65mYRofgvS8LpWaYrX21f/rK83fYYE/+vgGsLJ7lRxJTw0SsM1q7 uzq/8zPr/YEZSk84QCG2ZemxxRNQKrfhLJyusB1ZW6esbTzjdxiUM/gPJ95IdYqBa+5q 3vJqwOdq+QiEdoeTdTRMKeazTh+F1diaENOEQI4sBo2wF/Szy5fteCcBTh4GOtUH3SJ/ nvLqLkNgSoHxFxqoFSVYhIR6i3dF3dpE3ATMK59LCLK6m0aHUF/N5Bqezhz9T+eA2gLl EjkZmskXa9LtcpYuhMB0SURfHkdbXZMjihxc5zkGkK53/jIZ+Ld8zxBkKUr9/zy1Lhte rZRw==
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=yNnSbszmjdz5ijAFGXP9OpgS6cxapkczHfGA51gOaII=; b=OcLyRGcmelpswGI8S+RVv4jMJ/b7752feko0Lm6FJgHsUQT+ZZX/iGdktCBReoujD7 hEV0UaojI6DWYgex5zDafBWEPla2L84pqWHMZibA4mql8pH/9LL03fRnQC8KrT2ux6mn f31OG++KPljIN/emoFVJtfvrkNeyvCzLOEMBR0wxwOWD3MjnitCPJJC7w0e0cdKNd/73 vsAE7bLmcq2sqCzChJ+sz7WIMoyguKjcJJ+/k/Butnzx5GYQS2wrkLKo4u1Jr+6zJFtw YEH8EegZL/RR5jhqPlprr5Fp1zEkuaqDIYmHNSd+ZS2luz+pZ6JnLV6jRHUNf2As1GG5 ccSw==
X-Gm-Message-State: AOAM5316Y15PYFW2gSTvpneF7KfYXE+iGqqO2I3xA6NiX4GeN//CBqv/ WLi0ZPqOWJNFL+Ph+1PAd3hQKtv7mBflLhItwKs=
X-Google-Smtp-Source: ABdhPJzfqTKrbn8qM3MDpy5Ywe6gH45K2WtERdSB+9UAjEKxQCW4ZTPflO0eSmg4Wzrd3KV13jE0dxbYPHfl2pUw8T0=
X-Received: by 2002:aca:318f:: with SMTP id x137mr2442131oix.4.1589553178309;  Fri, 15 May 2020 07:32:58 -0700 (PDT)
MIME-Version: 1.0
References:      <24249.23930.126312.2484@oz.mt.att.com> 
In-Reply-To: 
From: Alexander Azimov 
Date: Fri, 15 May 2020 17:32:47 +0300
Message-ID: 
To: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" 
Cc: Jay Borkenhagen , SIDR Operations WG 
Content-Type: multipart/alternative; boundary="0000000000008b791705a5b0b079"
Archived-At: 
Subject: Re: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04
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, 15 May 2020 14:33:00 -0000

--0000000000008b791705a5b0b079
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Jay, Yunan,

Thank you for the suggestion. The mutual transit sounds good to me too.

Yunan: All right, so let=E2=80=99s assume in one case, the IXP does not pre=
pend its
> own ASN, meaning the RS and one of its RS clients receives the same
> AS_Path, right? According to Section 5.1 (see below) and Section 5.2 (see
> below), I=E2=80=99m wondering why the detection rules are different for t=
his RS
> (obeying Section 5.1) and this RS client (obeying Section 5.2) regarding
> the same AS_Path.

I think I got your point. You are asking why can't we process prefixes from
RS likewise prefixes from peers, right?

The reason is that I've tried to describe the policy that will be
applicable in general, so it covers the worst-case scenario when IX places
it ASN in the path. It possible to say that we can apply one policy if IX
is present and another policy if it is not, but this will
introduce additional complexity with operational dependencies on IX
configuration.


--=20
Best regards,
Alexander Azimov

--0000000000008b791705a5b0b079
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Jay, Yunan,

Thank you =
for the=C2=A0suggestion. The mutual transit=C2=A0sounds good to me too.

Yunan: All right, so let=E2=80=99s assume in one case, the IXP does no=
t prepend its own ASN, meaning the RS and one of its RS clients receives th=
e same AS_Path, right? According to Section 5.1 (see below) and Section 5.2=
 (see below), I=E2=80=99m wondering why the detection rules are different f=
or this RS (obeying Section 5.1) and this RS client (obeying Section 5.2) r=
egarding the same AS_Path.=C2=A0
I think I got your=
 point. You are asking why can't we process prefixes from RS likewise p=
refixes from peers,=C2=A0right?

The reason is that=
 I've tried to describe the policy that will be applicable in general, =
so it covers the worst-case scenario when IX places it ASN in the path. It =
possible to say that we can apply one policy if IX is present and another=
=C2=A0policy if it is not, but this will introduce=C2=A0additional complexi=
ty with operational dependencies on IX configuration.


-- 
Best regards,Alexander Azimov


--0000000000008b791705a5b0b079--


From nobody Fri May 15 19:31:30 2020
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 D72993A08B2 for ; Fri, 15 May 2020 19:31:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.ad.jp header.b=ZqcCyFV8; dkim=pass (1024-bit key) header.d=nic.ad.jp header.b=ZqcCyFV8
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 FDJq0XHFcu3J for ; Fri, 15 May 2020 19:31:26 -0700 (PDT)
Received: from dist7.nic.ad.jp (dist7.nic.ad.jp [IPv6:2001:dc2:1000:2004::7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F563A08B1 for ; Fri, 15 May 2020 19:31:25 -0700 (PDT)
To: sidrops@ietf.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nic.ad.jp; s=nic; t=1589596283; bh=YuFpQqCGgYXtWVMBKMpQluXt+H6HRDO+Nl4FLxqKr5I=; h=From:Subject:Date; b=ZqcCyFV89N9/G5m6ogig6bian4fk9uOWUSBHJMs+FWlej4+aVj1qAB7p42pl23Q6E 4fb+J4xovEm1/L/SGRyEOuf+QOhCttNajFa57yP0OHF9rAA0bBZRLtFneM2Hrdf0XY khJdPjbPxZ2G6/yBqwBMYfQjhyJNSsGetqmp2or0=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nic.ad.jp; s=nic; t=1589596283; bh=YuFpQqCGgYXtWVMBKMpQluXt+H6HRDO+Nl4FLxqKr5I=; h=From:Subject:Date; b=ZqcCyFV89N9/G5m6ogig6bian4fk9uOWUSBHJMs+FWlej4+aVj1qAB7p42pl23Q6E 4fb+J4xovEm1/L/SGRyEOuf+QOhCttNajFa57yP0OHF9rAA0bBZRLtFneM2Hrdf0XY khJdPjbPxZ2G6/yBqwBMYfQjhyJNSsGetqmp2or0=
From: Taiji Kimura 
Message-ID: 
Date: Sat, 16 May 2020 11:31:19 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Sidrops] Hardware failure on rpki-repository.nic.ad.jp
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 May 2020 02:31:29 -0000

Hello,

Due to hardware failure (power supply error), JPNIC's RPKI repository
system had been offline from 23:29 15th May to 10:01 16th May.

Apologies for your inconvenience.

 -- kimura taiji


From nobody Tue May 19 16:43:06 2020
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 855E53A041D for ; Tue, 19 May 2020 16:43:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level: 
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ns6bX5JN4YaL for ; Tue, 19 May 2020 16:43:04 -0700 (PDT)
Received: from sonic310-15.consmr.mail.bf2.yahoo.com (sonic310-15.consmr.mail.bf2.yahoo.com [74.6.135.125]) (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 5E4033A041A for ; Tue, 19 May 2020 16:43:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1589931783; bh=ptBULF6mRl4w7twYqqbCNJV10YrL9mhIEpEgZB6ae84=;  h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject;  b=auuuj4t1YZ6FgFypfNZjdhatkghFVjE8Lpk/OCIQggkJu43askyG9Hc9wOjjnPZaOMzurgMakPf++T126Bk80nBa83pOYgSJs336d6ZIlLMF4y+MNVsSW4nrw2MFqb8GDT3iAT4Wfz76I/fSa7ba2WtfbPBYlCLNxJ1HOT0eL+LObtBic4rTKxQ/wUtouB2lOMbXWXC0+oKQebZ+WHW3o14HZxJuIQB65uSq56zyTtIYtYpTsQkblZAG7B6OgHEO32PX59xXRy2XOzzgF3z2M4I6OeNNFrvS+m46RYWS0SiHgDuw5rzXRve6Ni97HQQYLNyJi1P5KRiwPi1lId/ZhQ==
X-YMail-OSG: xvMRQlQVM1lhhD1ihFmSs7EdQtHYMYhSYGATYCi35t218EDdsNR0c0JwL4roqVm A69JTlJJlq5w36lqKGQ4CshJ2ImwEA317vs7K6Wn5tCnuiha3pFC487xjzqRYrmYCmD7JTtt4LSY TPOD_1cy1rnLQrDRlQ2z.ksZtYKw2OU1Crhrw.y10MDjICtQocA6RMy1qY2DyBLdBWFkO.qjjsgc JyvanzE9zCswNrXC9DIAlORL2NQSiFvlyAz3UkhKTieBt1yFq6WggsNwgtp9gu_VgpdCHyoyjHkq 8II6h5fn7sL916K4cp1AwG12X.xJXgc_YHsMPmPk8c7QU.a6KkG020OevvkcF58XWr5kVLMFfjyV OUWD.5lwiYRv4c1vC8HSMASb.mfuZaGeqIfigN7Vg9e_toZ_f7RPFppNNJJHY.C9uUgtWx0Pvfn0 k_yhcG.aJNpAq9CzROxfW4eirgY6_snBKIKI05K4ZKa0UrIW7zmSxlrCTkzryhvDOcZqd4SmV_mn U6J7OdwihjDwVM5l41b0zNrRHSVaJKJJR5_zw0umu5YBH.7gcaLSAqajme5zZY9vRYHoSe_eLsMw 3B6r9zPn8VRm39LQfiddBGbTKwC_BziC_qJB0_u1snMfkEeNhSsGIejvkCKu7ZfyhXU0BeJOo2Qz 1x4pLc_o8mgs_FBuBj60MR6we6cxzEuBHscKaTgxCBd2DJ.DEM1PcsvjecXcYEc.1H1v54Rq_aEf jHwWCt61W9QYlaK5IC6MmbdKsT2lsIAPcFvWACGuxMXNRVxB8_cYUahhPL9h9zcVjPAWA4_F4IDy HHibv_8Md6ZqEc7DNy94O3vkHOteuW63vWJOYo_mA8bm8bxSXX8RNktaFCzbnT4IcI9gGO8K.8pE CcXP7zhJEMtMtVsDLDIhsEtRmx4YqavVRXmo92R22Sec78uwLk80OhunlnNFXLsx0wDyBeVMtxP3 02b7bSrdRdPihTnUk0Z4Rex5.B6Q_EcstQgptbeMtxr38S6hom9FwmH9ck9mQF764sEaVecVj8dH 69ShhSfhXv5wITTe6YqvEPvx2jRmDB8ub89RNZa6KOOsfzAyWmdfMBYlF6LlI6TY8.2qjPsbhJMu NmiTy9fvhC_zOLukLId5YXC.xKFkbp9rJ.dY4yaG0pR8_Y2LlmG2J8oeA7xZW_n6hbYs.u.NQAwX rYxUM6X3dbBuOo5DROJqWh7CHS0sIIazRvM8Rbg4tA_JpYL4eWGkMxh8MINnzRYvb6SidGmn3S8a kd00fzQxo7_YV.EUTVvsa2cOg9WuQCaCKcoo.JhF_D8Ke7IfiyJ4s.8iTG3s50fWUj9m5xmkoODF mZQGKNGg3X9b2kWCMqJ5v2iA9TBFaz.ihltdsCcrkeOsufQEog7tVLiplmk083675ejGvJyxOLd2 SZB.PVhQQjZJ29cL_8cc7Kl68
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Tue, 19 May 2020 23:43:03 +0000
Received: by smtp418.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 65da7e6560ec3cb402ee12a3d9ed9cda;  Tue, 19 May 2020 23:42:57 +0000 (UTC)
To: Martin Hoffmann 
Cc: sidrops@ietf.org
References:   <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net> <73b88326-d537-93eb-b0d0-a0a82507081c@verizon.net>  <076ad9b0-ea5d-47a4-52f7-8b913dc6c1ae@verizon.net>  <156c83ba-d4d8-8baa-7f87-a2600cb9c19a@verizon.net> <20200515090840.12a9464a@grisu.home.partim.org>
From: Stephen Kent 
Message-ID: <97899f4b-a10e-9e78-2fc7-3984b0a155f2@verizon.net>
Date: Tue, 19 May 2020 19:42:56 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <20200515090840.12a9464a@grisu.home.partim.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.15960 hermes_aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 May 2020 23:43:06 -0000

Martin,
> Stephen Kent wrote:
>> Tim,
>>
>>> If not, then indeed we need to have a discussion about how to deal
>>> properly with multiple CRLS. E.g. do you check *all* of them for
>>> each issued certificate, or do you only check the CRL matching the
>>> CRLDP of that certificate? I would also be very curious to know
>>> which use case warrants having this complexity.
>> My suggestion is the KISS approach - first .crl file that has a valid
>> hash is the one to use, and others are ignored. That's less forgiving
>> than what Rob accommodates, but being forgiving here might take
>> pressure of a CA to do its job properly.
> I’m not sure it really does. Rather, it will lead to strange looking
> issues: If the wrong CRL accidentally made it onto the manifest and it
> comes first, all objects are invalid even though everything sort of
> looks fine. This may even come and go if a CA reorders the CRLs when
> it reissues the manifest[0]. If all CRLs are referenced by objects, some
> objects suddenly are invalid while others aren’t.
>
> I think invalidating the manifest with a clear warning is the more
> straightforward approach and much easier to debug.
>
> Kind regards,
> Martin
>
> [0] That may happen if it is file system based and just adds files as
>      they appear when reading the directory without sorting the file
>      names first.

I'm not sure what to make of your message.

I don 't see a specific proposal here.

Steve


From nobody Tue May 19 16:43:14 2020
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 808F53A041C for ; Tue, 19 May 2020 16:43:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level: 
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTVgNmyvZj_T for ; Tue, 19 May 2020 16:43:04 -0700 (PDT)
Received: from sonic310-15.consmr.mail.bf2.yahoo.com (sonic310-15.consmr.mail.bf2.yahoo.com [74.6.135.125]) (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 4E0903A0418 for ; Tue, 19 May 2020 16:43:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1589931783; bh=ptBULF6mRl4w7twYqqbCNJV10YrL9mhIEpEgZB6ae84=;  h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject;  b=auuuj4t1YZ6FgFypfNZjdhatkghFVjE8Lpk/OCIQggkJu43askyG9Hc9wOjjnPZaOMzurgMakPf++T126Bk80nBa83pOYgSJs336d6ZIlLMF4y+MNVsSW4nrw2MFqb8GDT3iAT4Wfz76I/fSa7ba2WtfbPBYlCLNxJ1HOT0eL+LObtBic4rTKxQ/wUtouB2lOMbXWXC0+oKQebZ+WHW3o14HZxJuIQB65uSq56zyTtIYtYpTsQkblZAG7B6OgHEO32PX59xXRy2XOzzgF3z2M4I6OeNNFrvS+m46RYWS0SiHgDuw5rzXRve6Ni97HQQYLNyJi1P5KRiwPi1lId/ZhQ==
X-YMail-OSG: xvMRQlQVM1lhhD1ihFmSs7EdQtHYMYhSYGATYCi35t218EDdsNR0c0JwL4roqVm A69JTlJJlq5w36lqKGQ4CshJ2ImwEA317vs7K6Wn5tCnuiha3pFC487xjzqRYrmYCmD7JTtt4LSY TPOD_1cy1rnLQrDRlQ2z.ksZtYKw2OU1Crhrw.y10MDjICtQocA6RMy1qY2DyBLdBWFkO.qjjsgc JyvanzE9zCswNrXC9DIAlORL2NQSiFvlyAz3UkhKTieBt1yFq6WggsNwgtp9gu_VgpdCHyoyjHkq 8II6h5fn7sL916K4cp1AwG12X.xJXgc_YHsMPmPk8c7QU.a6KkG020OevvkcF58XWr5kVLMFfjyV OUWD.5lwiYRv4c1vC8HSMASb.mfuZaGeqIfigN7Vg9e_toZ_f7RPFppNNJJHY.C9uUgtWx0Pvfn0 k_yhcG.aJNpAq9CzROxfW4eirgY6_snBKIKI05K4ZKa0UrIW7zmSxlrCTkzryhvDOcZqd4SmV_mn U6J7OdwihjDwVM5l41b0zNrRHSVaJKJJR5_zw0umu5YBH.7gcaLSAqajme5zZY9vRYHoSe_eLsMw 3B6r9zPn8VRm39LQfiddBGbTKwC_BziC_qJB0_u1snMfkEeNhSsGIejvkCKu7ZfyhXU0BeJOo2Qz 1x4pLc_o8mgs_FBuBj60MR6we6cxzEuBHscKaTgxCBd2DJ.DEM1PcsvjecXcYEc.1H1v54Rq_aEf jHwWCt61W9QYlaK5IC6MmbdKsT2lsIAPcFvWACGuxMXNRVxB8_cYUahhPL9h9zcVjPAWA4_F4IDy HHibv_8Md6ZqEc7DNy94O3vkHOteuW63vWJOYo_mA8bm8bxSXX8RNktaFCzbnT4IcI9gGO8K.8pE CcXP7zhJEMtMtVsDLDIhsEtRmx4YqavVRXmo92R22Sec78uwLk80OhunlnNFXLsx0wDyBeVMtxP3 02b7bSrdRdPihTnUk0Z4Rex5.B6Q_EcstQgptbeMtxr38S6hom9FwmH9ck9mQF764sEaVecVj8dH 69ShhSfhXv5wITTe6YqvEPvx2jRmDB8ub89RNZa6KOOsfzAyWmdfMBYlF6LlI6TY8.2qjPsbhJMu NmiTy9fvhC_zOLukLId5YXC.xKFkbp9rJ.dY4yaG0pR8_Y2LlmG2J8oeA7xZW_n6hbYs.u.NQAwX rYxUM6X3dbBuOo5DROJqWh7CHS0sIIazRvM8Rbg4tA_JpYL4eWGkMxh8MINnzRYvb6SidGmn3S8a kd00fzQxo7_YV.EUTVvsa2cOg9WuQCaCKcoo.JhF_D8Ke7IfiyJ4s.8iTG3s50fWUj9m5xmkoODF mZQGKNGg3X9b2kWCMqJ5v2iA9TBFaz.ihltdsCcrkeOsufQEog7tVLiplmk083675ejGvJyxOLd2 SZB.PVhQQjZJ29cL_8cc7Kl68
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Tue, 19 May 2020 23:43:03 +0000
Received: by smtp418.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 65da7e6560ec3cb402ee12a3d9ed9cda;  Tue, 19 May 2020 23:42:57 +0000 (UTC)
To: Martin Hoffmann 
Cc: sidrops@ietf.org
References:   <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net> <73b88326-d537-93eb-b0d0-a0a82507081c@verizon.net>  <076ad9b0-ea5d-47a4-52f7-8b913dc6c1ae@verizon.net>  <156c83ba-d4d8-8baa-7f87-a2600cb9c19a@verizon.net> <20200515090840.12a9464a@grisu.home.partim.org>
From: Stephen Kent 
Message-ID: <97899f4b-a10e-9e78-2fc7-3984b0a155f2@verizon.net>
Date: Tue, 19 May 2020 19:42:56 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <20200515090840.12a9464a@grisu.home.partim.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.15960 hermes_aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 May 2020 23:43:06 -0000

Martin,
> Stephen Kent wrote:
>> Tim,
>>
>>> If not, then indeed we need to have a discussion about how to deal
>>> properly with multiple CRLS. E.g. do you check *all* of them for
>>> each issued certificate, or do you only check the CRL matching the
>>> CRLDP of that certificate? I would also be very curious to know
>>> which use case warrants having this complexity.
>> My suggestion is the KISS approach - first .crl file that has a valid
>> hash is the one to use, and others are ignored. That's less forgiving
>> than what Rob accommodates, but being forgiving here might take
>> pressure of a CA to do its job properly.
> I’m not sure it really does. Rather, it will lead to strange looking
> issues: If the wrong CRL accidentally made it onto the manifest and it
> comes first, all objects are invalid even though everything sort of
> looks fine. This may even come and go if a CA reorders the CRLs when
> it reissues the manifest[0]. If all CRLs are referenced by objects, some
> objects suddenly are invalid while others aren’t.
>
> I think invalidating the manifest with a clear warning is the more
> straightforward approach and much easier to debug.
>
> Kind regards,
> Martin
>
> [0] That may happen if it is file system based and just adds files as
>      they appear when reading the directory without sorting the file
>      names first.

I'm not sure what to make of your message.

I don 't see a specific proposal here.

Steve


From nobody Tue May 19 22:32:41 2020
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 EC8323A3A8C for ; Tue, 19 May 2020 22:32:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SRpttFM9s-J for ; Tue, 19 May 2020 22:32:37 -0700 (PDT)
Received: from out20-111.mail.aliyun.com (out20-111.mail.aliyun.com [115.124.20.111]) (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 AF7523A3A89 for ; Tue, 19 May 2020 22:32:34 -0700 (PDT)
X-Alimail-AntiSpam: AC=CONTINUE; BC=0.2959157|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_social|0.200959-0.0147545-0.784287; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03295; MF=madi@rpstir.net; NM=1; PH=DS; RN=1; RT=1; SR=0; TI=SMTPD_---.Hb.kedz_1589952743; 
Received: from 192.168.218.230(mailfrom:madi@rpstir.net fp:SMTPD_---.Hb.kedz_1589952743) by smtp.aliyun-inc.com(10.147.42.198); Wed, 20 May 2020 13:32:24 +0800
From: Di Ma 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: 
Date: Wed, 20 May 2020 13:31:54 +0800
To: SIDR Operations WG 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: [Sidrops] Distributing RPKI Validated Cache in JSON over HTTPS
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, 20 May 2020 05:32:40 -0000

Hi, folks

I briefed a method for RPKI inter-cache synchronization called =
Distributing RPKI Validated Cache in JSON over HTTPS and our =
implementation with RPSTIR2 in IETF 106 Singapore meeting.

After that we were drafting a document that tries to specify the =
standardized way to do so, as I promised :-)

We realized that the document should focus on the necessary minimum =
information for data exchange not the detailed interaction and signaling =
which I believe can leave to different private implementations.=20

This document is therefore intended to define a method for transferring =
RPKI validated cache by making use of SLURM.

Looking forwards to your comments.

https://datatracker.ietf.org/doc/draft-madi-sidrops-rush/

Di



From nobody Wed May 20 00:53:57 2020
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 91B1D3A3B47 for ; Wed, 20 May 2020 00:53:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NB1xtK2NRDtq for ; Wed, 20 May 2020 00:53:54 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 C4D5E3A3B46 for ; Wed, 20 May 2020 00:53:53 -0700 (PDT)
Received: from lhreml740-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 6B70E992BE5D8ABFFBEB; Wed, 20 May 2020 08:53:49 +0100 (IST)
Received: from lhreml740-chm.china.huawei.com (10.201.108.190) by lhreml740-chm.china.huawei.com (10.201.108.190) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 20 May 2020 08:53:49 +0100
Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml740-chm.china.huawei.com (10.201.108.190) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Wed, 20 May 2020 08:53:48 +0100
Received: from DGGEML532-MBX.china.huawei.com ([169.254.8.202]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0487.000; Wed, 20 May 2020 15:53:45 +0800
From: Guyunan 
To: Alexander Azimov 
CC: Jay Borkenhagen , SIDR Operations WG 
Thread-Topic: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04
Thread-Index: AdYdy08vebzctU/sRBSjzmRHyKjH2ACpL0yAALmBBzAA2L1MAAAdy1hgAArDfQAANA3jsACVy1GAAP3RyoA=
Date: Wed, 20 May 2020 07:53:45 +0000
Message-ID: 
References:      <24249.23930.126312.2484@oz.mt.att.com>  
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.108.203.151]
Content-Type: multipart/alternative; boundary="_000_C01B0098369B2D4391851938DA6700B717A35EC8DGGEML532MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04
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, 20 May 2020 07:53:56 -0000

--_000_C01B0098369B2D4391851938DA6700B717A35EC8DGGEML532MBXchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QWxleCwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkZyb206IEFsZXhhbmRlciBBemltb3YgW21h
aWx0bzphLmUuYXppbW92QGdtYWlsLmNvbV0NClNlbnQ6IEZyaWRheSwgTWF5IDE1LCAyMDIwIDEw
OjMzIFBNDQpUbzogR3V5dW5hbiA8Z3V5dW5hbkBodWF3ZWkuY29tPg0KQ2M6IEpheSBCb3JrZW5o
YWdlbiA8amF5YkBicmFlYnVybi5vcmc+OyBTSURSIE9wZXJhdGlvbnMgV0cgPHNpZHJvcHNAaWV0
Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1NpZHJvcHNdIHF1ZXN0aW9uIG9uIGRyYWZ0LWlldGYtc2lk
cm9wcy1hc3BhLXZlcmlmaWNhdGlvbi0wNA0KDQpKYXksIFl1bmFuLA0KDQpUaGFuayB5b3UgZm9y
IHRoZSBzdWdnZXN0aW9uLiBUaGUgbXV0dWFsIHRyYW5zaXQgc291bmRzIGdvb2QgdG8gbWUgdG9v
Lg0KDQpZdW5hbjogQWxsIHJpZ2h0LCBzbyBsZXTigJlzIGFzc3VtZSBpbiBvbmUgY2FzZSwgdGhl
IElYUCBkb2VzIG5vdCBwcmVwZW5kIGl0cyBvd24gQVNOLCBtZWFuaW5nIHRoZSBSUyBhbmQgb25l
IG9mIGl0cyBSUyBjbGllbnRzIHJlY2VpdmVzIHRoZSBzYW1lIEFTX1BhdGgsIHJpZ2h0PyBBY2Nv
cmRpbmcgdG8gU2VjdGlvbiA1LjEgKHNlZSBiZWxvdykgYW5kIFNlY3Rpb24gNS4yIChzZWUgYmVs
b3cpLCBJ4oCZbSB3b25kZXJpbmcgd2h5IHRoZSBkZXRlY3Rpb24gcnVsZXMgYXJlIGRpZmZlcmVu
dCBmb3IgdGhpcyBSUyAob2JleWluZyBTZWN0aW9uIDUuMSkgYW5kIHRoaXMgUlMgY2xpZW50IChv
YmV5aW5nIFNlY3Rpb24gNS4yKSByZWdhcmRpbmcgdGhlIHNhbWUgQVNfUGF0aC4NCkkgdGhpbmsg
SSBnb3QgeW91ciBwb2ludC4gWW91IGFyZSBhc2tpbmcgd2h5IGNhbid0IHdlIHByb2Nlc3MgcHJl
Zml4ZXMgZnJvbSBSUyBsaWtld2lzZSBwcmVmaXhlcyBmcm9tIHBlZXJzLCByaWdodD8NCg0KWXVu
YW46IFJpZ2h0Lg0KDQpUaGUgcmVhc29uIGlzIHRoYXQgSSd2ZSB0cmllZCB0byBkZXNjcmliZSB0
aGUgcG9saWN5IHRoYXQgd2lsbCBiZSBhcHBsaWNhYmxlIGluIGdlbmVyYWwsIHNvIGl0IGNvdmVy
cyB0aGUgd29yc3QtY2FzZSBzY2VuYXJpbyB3aGVuIElYIHBsYWNlcyBpdCBBU04gaW4gdGhlIHBh
dGguIEl0IHBvc3NpYmxlIHRvIHNheSB0aGF0IHdlIGNhbiBhcHBseSBvbmUgcG9saWN5IGlmIElY
IGlzIHByZXNlbnQgYW5kIGFub3RoZXIgcG9saWN5IGlmIGl0IGlzIG5vdCwgYnV0IHRoaXMgd2ls
bCBpbnRyb2R1Y2UgYWRkaXRpb25hbCBjb21wbGV4aXR5IHdpdGggb3BlcmF0aW9uYWwgZGVwZW5k
ZW5jaWVzIG9uIElYIGNvbmZpZ3VyYXRpb24uDQoNCll1bmFuOiBTbyBsZXQgbWUgdHJ5IHRvIGNs
ZWFyIHRoaW5ncyB1cCBoZXJlLiBEbyB5b3UgbWVhbiB0aGVyZSBhcmUgcG9zc2libHkgdHdvIGNh
c2VzOiAxLiBJWFAgQVNOIGlzIHBsYWNlZCBpbiB0aGUgcGF0aCAyLiBJWFAgQVNOIGlzIG5vdCBw
bGFjZWQgaW4gdGhlIHBhdGg/IEZvciBjYXNlIDIsIHRoZSBoYW5kbGluZyBpcyBzdXBwb3NlZCB0
byBiZSB0aGUgc2FtZSBhcyBwcm9jZXNzaW5nIHByZWZpeGVzIGZyb20gcGVlcnMsIHJpZ2h0PyBG
b3IgY2FzZSAxLCB3aGF0IGlzIHRoZSBwb3NzaWJsZSBoYW5kaW5nIHByb2NlZHVyZT8gUmVtb3Zp
bmcgdGhlIElYUCBBU04gZmlyc3QgYW5kIHRoZW4gdHJlYXQgbGlrZSBwcmVmaXhlcyBmcm9tIHBl
ZXJzPw0KDQoNCi0tDQpCZXN0IHJlZ2FyZHMsDQpBbGV4YW5kZXIgQXppbW92DQo=

--_000_C01B0098369B2D4391851938DA6700B717A35EC8DGGEML532MBXchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ
cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVu
ZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y
ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdE
O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl
OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30N
CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t
W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt
YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N
CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh
PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv
ZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xh
c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RCI+QWxleCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPlBsZWFzZSBzZWUgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi
PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbGV4YW5kZXIgQXppbW92IFttYWls
dG86YS5lLmF6aW1vdkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXkg
MTUsIDIwMjAgMTA6MzMgUE08YnI+DQo8Yj5Ubzo8L2I+IEd1eXVuYW4gJmx0O2d1eXVuYW5AaHVh
d2VpLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEpheSBCb3JrZW5oYWdlbiAmbHQ7amF5YkBicmFl
YnVybi5vcmcmZ3Q7OyBTSURSIE9wZXJhdGlvbnMgV0cgJmx0O3NpZHJvcHNAaWV0Zi5vcmcmZ3Q7
PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbU2lkcm9wc10gcXVlc3Rpb24gb24gZHJhZnQtaWV0
Zi1zaWRyb3BzLWFzcGEtdmVyaWZpY2F0aW9uLTA0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkpheSwgWXVuYW4sPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFuayB5b3UgZm9yIHRoZSZuYnNwO3N1Z2dlc3Rpb24uIFRo
ZSBtdXR1YWwgdHJhbnNpdCZuYnNwO3NvdW5kcyBnb29kIHRvIG1lIHRvby48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6
c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0
OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPll1bmFuOiBBbGwgcmlnaHQsIHNvIGxldOKAmXMgYXNzdW1l
IGluIG9uZSBjYXNlLCB0aGUgSVhQIGRvZXMgbm90IHByZXBlbmQgaXRzIG93biBBU04sIG1lYW5p
bmcgdGhlIFJTIGFuZCBvbmUgb2YgaXRzIFJTIGNsaWVudHMgcmVjZWl2ZXMgdGhlIHNhbWUgQVNf
UGF0aCwgcmlnaHQ/DQogQWNjb3JkaW5nIHRvIFNlY3Rpb24gNS4xIChzZWUgYmVsb3cpIGFuZCBT
ZWN0aW9uIDUuMiAoc2VlIGJlbG93KSwgSeKAmW0gd29uZGVyaW5nIHdoeSB0aGUgZGV0ZWN0aW9u
IHJ1bGVzIGFyZSBkaWZmZXJlbnQgZm9yIHRoaXMgUlMgKG9iZXlpbmcgU2VjdGlvbiA1LjEpIGFu
ZCB0aGlzIFJTIGNsaWVudCAob2JleWluZyBTZWN0aW9uIDUuMikgcmVnYXJkaW5nIHRoZSBzYW1l
IEFTX1BhdGguJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgSSBnb3QgeW91ciBwb2ludC4gWW91IGFy
ZSBhc2tpbmcgd2h5IGNhbid0IHdlIHByb2Nlc3MgcHJlZml4ZXMgZnJvbSBSUyBsaWtld2lzZSBw
cmVmaXhlcyBmcm9tIHBlZXJzLCZuYnNwO3JpZ2h0PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj5ZdW5hbjogUmlnaHQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSByZWFzb24gaXMgdGhhdCBJJ3ZlIHRy
aWVkIHRvIGRlc2NyaWJlIHRoZSBwb2xpY3kgdGhhdCB3aWxsIGJlIGFwcGxpY2FibGUgaW4gZ2Vu
ZXJhbCwgc28gaXQgY292ZXJzIHRoZSB3b3JzdC1jYXNlIHNjZW5hcmlvIHdoZW4gSVggcGxhY2Vz
IGl0IEFTTiBpbiB0aGUgcGF0aC4gSXQgcG9zc2libGUgdG8gc2F5IHRoYXQgd2UgY2FuIGFwcGx5
IG9uZSBwb2xpY3kgaWYgSVggaXMgcHJlc2VudCBhbmQgYW5vdGhlciZuYnNwO3BvbGljeQ0KIGlm
IGl0IGlzIG5vdCwgYnV0IHRoaXMgd2lsbCBpbnRyb2R1Y2UmbmJzcDthZGRpdGlvbmFsIGNvbXBs
ZXhpdHkgd2l0aCBvcGVyYXRpb25hbCBkZXBlbmRlbmNpZXMgb24gSVggY29uZmlndXJhdGlvbi48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEIj5ZdW5hbjogU28gbGV0IG1lIHRyeSB0byBjbGVhciB0aGluZ3MgdXAg
aGVyZS4gRG8geW91IG1lYW4gdGhlcmUgYXJlIHBvc3NpYmx5IHR3byBjYXNlczogMS4gSVhQIEFT
TiBpcyBwbGFjZWQgaW4gdGhlIHBhdGggMi4gSVhQIEFTTiBpcyBub3QgcGxhY2VkIGluIHRoZSBw
YXRoPw0KIEZvciBjYXNlIDIsIHRoZSBoYW5kbGluZyBpcyBzdXBwb3NlZCB0byBiZSB0aGUgc2Ft
ZSBhcyBwcm9jZXNzaW5nIHByZWZpeGVzIGZyb20gcGVlcnMsIHJpZ2h0PyBGb3IgY2FzZSAxLCB3
aGF0IGlzIHRoZSBwb3NzaWJsZSBoYW5kaW5nIHByb2NlZHVyZT8gUmVtb3ZpbmcgdGhlIElYUCBB
U04gZmlyc3QgYW5kIHRoZW4gdHJlYXQgbGlrZSBwcmVmaXhlcyBmcm9tIHBlZXJzPzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsZXhhbmRlciBBemltb3Y8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_C01B0098369B2D4391851938DA6700B717A35EC8DGGEML532MBXchi_--


From nobody Wed May 20 01:16:00 2020
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 83FA03A3B75 for ; Wed, 20 May 2020 01:15:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C700Fo4JzxTf for ; Wed, 20 May 2020 01:15:48 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0: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 3715D3A3B9D for ; Wed, 20 May 2020 01:15:44 -0700 (PDT)
Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 8BF76185C3; Wed, 20 May 2020 10:15:42 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com
Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com
Date: Wed, 20 May 2020 10:15:41 +0200
From: Martin Hoffmann 
To: Stephen Kent 
Cc: sidrops@ietf.org
Message-ID: <20200520101541.7f8a0afb@glaurung.nlnetlabs.nl>
In-Reply-To: <97899f4b-a10e-9e78-2fc7-3984b0a155f2@verizon.net>
References:   <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net> <73b88326-d537-93eb-b0d0-a0a82507081c@verizon.net>  <076ad9b0-ea5d-47a4-52f7-8b913dc6c1ae@verizon.net>  <156c83ba-d4d8-8baa-7f87-a2600cb9c19a@verizon.net> <20200515090840.12a9464a@grisu.home.partim.org> <97899f4b-a10e-9e78-2fc7-3984b0a155f2@verizon.net>
Organization: Open Netlabs
X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
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, 20 May 2020 08:15:59 -0000

Stephen Kent wrote:
> Martin,
> > Stephen Kent wrote: =20
> >> Tim,
> >> =20
> >>> If not, then indeed we need to have a discussion about how to deal
> >>> properly with multiple CRLS. E.g. do you check *all* of them for
> >>> each issued certificate, or do you only check the CRL matching the
> >>> CRLDP of that certificate? I would also be very curious to know
> >>> which use case warrants having this complexity. =20
> >> My suggestion is the KISS approach - first .crl file that has a
> >> valid hash is the one to use, and others are ignored. That's less
> >> forgiving than what Rob accommodates, but being forgiving here
> >> might take pressure of a CA to do its job properly. =20
> > I=E2=80=99m not sure it really does. Rather, it will lead to strange lo=
oking
> > issues: If the wrong CRL accidentally made it onto the manifest and
> > it comes first, all objects are invalid even though everything sort
> > of looks fine. This may even come and go if a CA reorders the CRLs
> > when it reissues the manifest[0]. If all CRLs are referenced by
> > objects, some objects suddenly are invalid while others aren=E2=80=99t.
> >
> > I think invalidating the manifest with a clear warning is the more
> > straightforward approach and much easier to debug.
> >
> > Kind regards,
> > Martin
> >
> > [0] That may happen if it is file system based and just adds files
> > as they appear when reading the directory without sorting the file
> >      names first. =20
>=20
> I'm not sure what to make of your message.
>=20
> I don 't see a specific proposal here.

My apologies if this was cryptic. I just wanted to caution against
devising complicated heuristics to try and salvage a manifest with
multiple CRLs.

As I elsewhere already voiced my preference for your proposal to simply
invalidate the manifest if there are multuple CRLs, you can safely
ignore the message, though ...

Kind regards,
Martin


From nobody Thu May 21 08:52:11 2020
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 8698C3A02BB for ; Thu, 21 May 2020 08:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.6
X-Spam-Level: 
X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiziICIugqTb for ; Thu, 21 May 2020 08:52:07 -0700 (PDT)
Received: from sonic315-13.consmr.mail.bf2.yahoo.com (sonic315-13.consmr.mail.bf2.yahoo.com [74.6.134.123]) (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 6A9C73A017E for ; Thu, 21 May 2020 08:52:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1590076326; bh=/RJ7dmomsGBEiY9RLks3sGXlkg61Z9a5f8MeJjibQ64=;  h=To:From:Subject:Date:References:From:Subject; b=QLBv0XNBKR/x0spNRtUi5SFH9Z/HE0XZVQ80JcN9Npx69lWVqDuw7k4F2s0K+V0y65ENMgzlHDmWufNiJhZIG0m76Kx7qDbG0Ry6eJYObQCi+0lUji+KpOOFs14nhVqSbaOoH1levk2KBuwzmKMmT5wGLk184/Azx3HRHJg2D8rmIWHs3qh1C9Pc0kClcPcUyBDxtCuP1S6YguAx4MYVewe6p3bzdTivrLGyxY77ErZQK+xgwB0FpF5jVpqE4DgUlg9PkkHRNSmkdiwvZDOe4vbVPLrQpBr0+b359Z69G94e6LjXg5RBwek2Ee+bi4sjWZqrcTfLzklNcLPS3r+Taw==
X-YMail-OSG: 1hW1eRAVM1ktsEeIMp9GOjqragEwwACX0uP5dvM.1B.fk5q9fuKYk_q6aOrKYpn ssg1TusQrC.tV.X6Hjna4bk4OaujwhD5YRM42w0c_dk9tZWllrqcw0x.ZjR68Mr758AAtBgTiyYz caG8SRJxzSy4ayCwI6kKtfSpFNEi2wSdtI2A72IMQZwUv.IzpXirFAxebLkaHh2ILXvBaTfV2pRh Qph5wlVONe0.rf_eNv9mv0kQDrMS8UiNvSeqlL0gCh9c1iGzC3hBV0d5eWni.fadIVqPrPqvQcFt MuE4P6JnjMCmMKK0yL0OReKtD5dKWt144DE7KjGLp0wK3pWrT4HgQS_5s5F.SpuD1yfimzBZ9.T8 QDqNI0KfwhbACPxFYloY8L_h6p1lkjs6pY6EoCLGd6OOBK515.dqWGHqcuVK9zGmZhKqvCT1K6IM YeThT379o6IOoN0M0MukLX6CgRJkbC.2CtVKHGJUcGiHBQ0MqbBw_gh097CRGxzQK_IIAJt4L6uV 36YaxZ_c3h21OyuddJGRskI6pUD61aDgi1N31bc8x8ELMPY.sjAp983lYBy417_mgj8jItflRg2e ZeI4x02XIFo9lbbC70QPZIGrANEzw9ubhJdn.4VFiybhpp2QKFsjREIoibmG6pRzEfdTN9O6U_Er bZK2hXsyhDvVj1V.pc.y.fHW5Yxt77eqb21imn9PwbJFK8e6BiMUlAkb18323B73kdtJB35J7Nwx WmNrRaVfjOU8Vv1Yq_QGETRfR5Ih_h2HnLWwGRDmuYxvkiGFTJq9oo5.pAzNeIW6vPtsBeubPrAV 6s0LFlOdp2Dxy8B0GeC1h7Rv1K7KkfRcYC4PGMl2jRk156Do4bv1qaWi4XbgR4QO64rtdHn8efrc XiGG.JungbLCglJpbmXgL5KWt3cLn7Yae9zImbrQ66O0MKf4JccHLkAbqtM0Ulo0CeketXBl25n6 7dGT07iD8gsgd4E1.6YV8d_9izn_LwzcBdQ4TfIbiKs2K87XXt3IqvYt9ahzKG23NlD.TM9xQqnI Trc_P5qS_sek881vvYC6Iob5O4zQQA1f2pjLWrhFJyS3pl9s7fJg.6A5u8vqT2.2OusEUW1Fzotg RRNExBgz8rEVGp6JP3mtXMQEAjhOBY6glCvAuWeesaNzb0j6b602owYUVSJbK_iyu4i5vDXnXDvY w1Mi5RSyKSmEz813ejGbkHEubtnoykNJfTeFqM78NN1XOG_ffrzElaCaYzmdeyq9kIpsYidBnekn 4PDa88GWDkkOSpVcc273LbN9lFSq_2Hx6cKAtZtYCnaw_8w_YV7H.AO1ZL9axKk1PVcbIjdozVsq .eD8ygvgal8_ELDzf5NcDv6Wr8j0i7fNKwS7Ggv40hsF0YfCNdwpktCD8fAaOsWK8fV.w5Ix5sn0 gM.szy3YKCGXQH9SsqJrNSy81Hw--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Thu, 21 May 2020 15:52:06 +0000
Received: by smtp428.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d9eefae1a99134b4c68a1671d9943aa1;  Thu, 21 May 2020 15:51:57 +0000 (UTC)
To: "sidrops@ietf.org" 
From: Stephen Kent 
Message-ID: <0365f842-ff05-b252-2fc7-f6f408fc52e3@verizon.net>
Date: Thu, 21 May 2020 11:51:55 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------C4F812C7C6171EEADADC0B30"
Content-Language: en-US
References: <0365f842-ff05-b252-2fc7-f6f408fc52e3.ref@verizon.net>
X-Mailer: WebService/1.1.15960 hermes_aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: [Sidrops] 6486 bis
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, 21 May 2020 15:52:09 -0000

This is a multi-part message in MIME format.
--------------C4F812C7C6171EEADADC0B30
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

It seems the list prefers a KISS approach to the issue of multiple CRLs 
in a manifest. So, absent any additional suggestions, I'll plan to post 
a revised version of 6486 with the version 4 text that I posted to the 
list last week.

Thanks,

Steve


--------------C4F812C7C6171EEADADC0B30
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    
It seems the list prefers a KISS approach to
        the issue of multiple CRLs in a manifest. So, absent any
        additional suggestions, I'll plan to post a revised version of
        6486 with the version 4 text that I posted to the list last
        week.

    
Thanks,

    
Steve

    

  


--------------C4F812C7C6171EEADADC0B30--


From nobody Sun May 24 17:18:28 2020
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 E11163A0E2C for ; Sun, 24 May 2020 17:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uh3gcdNLSWt2 for ; Sun, 24 May 2020 17:18:22 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 766EA3A0E28 for ; Sun, 24 May 2020 17:18:21 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id q129so7998695iod.6 for ; Sun, 24 May 2020 17:18:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I1SKsTlLd2QWY8jBPm0zFjwU4ReEICy5aQtPY5K5LwQ=; b=cGZVVbH84c4Py/kvgpxMFjeNdVRx9fzY5K0mFeOvO9KtgvK7hBsI6Z39tNv+TZSknQ JeeZTyv8SSF7q6i4iQdHiPOKWiQ1+Qf0EMmbf4bxKbSUOcOlOUONmBn7IgXsjJDFvGN+ u7W3LQTrhvks7lvm0PbWS9kSXmoFz3NO5r74INZiy4DXEtlmD2aTGJW5x6DcmaE53NCW 1XURkktTQgftYVbuISZVjyTjIefdaaTytUeKb+3IBSkm35m5FxgzGXtW1GGrzlal8LAT DeZBp1On0krM38G+1DBAm8cwTxhKMYdK1YPyprqV978ePAjXB+7zPLPd9DGI9rxYUw2o yTRg==
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=I1SKsTlLd2QWY8jBPm0zFjwU4ReEICy5aQtPY5K5LwQ=; b=jjs/1YbI34rHk19jILCPOW8Angq/0gf1kM/2vdeqT6V5GXyw3Jj45o5rdlspw4M7F1 p9XjHaDTbtttYkTC+Y0Z7Ktb9V9QRSTDBy6XyCdkyGKy/o/M6yowWwiKNwZWEUo7xg+1 QD4NdKM226Xsu1CtFSXjqhnhOOA3MGNI+Z06j8wEu1/AoLEBQM8v7+HDi64JpRd6Bxtn zdQwhWKhCB0akS7s1rs89nKjeCddF2Z8Eu10Iqb9UbTxNuJ9G20Yu8bYvWaYvZf+luHp WETO4g3Xyl8O94TTV/0DMVsah/nLi33vCL4/Q/HQ2WYkI9k23txiNTsMn/kRRIq+LhBC HHvQ==
X-Gm-Message-State: AOAM533kB1a+SZu++oJtZMSWd+A22euPIMCdl+b1uym56SJGZukKiTdQ fi5iToJt1E7lKVocjnPEMIFW5+DjS0N4iLOPUJvdAgAT
X-Google-Smtp-Source: ABdhPJy67/eFsIVM9Cl3NwMSGX08ftiaN70cp2I/ZciRU/jV8enep+mQLENXS9zwDZ6wh0Chmz/1e8lEtv9KsOUbRbU=
X-Received: by 2002:a5e:dd07:: with SMTP id t7mr3447566iop.21.1590365900170; Sun, 24 May 2020 17:18:20 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: George Michaelson 
Date: Mon, 25 May 2020 10:18:08 +1000
Message-ID: 
To: Di Ma 
Cc: SIDR Operations WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [Sidrops] Distributing RPKI Validated Cache in JSON over HTTPS
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, 25 May 2020 00:18:26 -0000

I think its useful to document use of secured transport to fetch data.

The problem I retain in this, is the lack of strong cryptographic
validity checks on the semantic intent of the assertions themselves.

The beauty of RPKI was always the ability to demonstrate the binding
of authority (delegated) to say what was to be done with some
resource.

SLURM doesn't honour that behaviour. Inside your own IGP, its a
representation of your 'must-haves' including other peoples things,
but between IGPs, transferred over the external boundary, I worry a
LOT about "what it means"

And that goes for 'SLURM for AS0 from the RIR too' btw.

-G

On Wed, May 20, 2020 at 3:32 PM Di Ma  wrote:
>
> Hi, folks
>
> I briefed a method for RPKI inter-cache synchronization called Distributing RPKI Validated Cache in JSON over HTTPS and our implementation with RPSTIR2 in IETF 106 Singapore meeting.
>
> After that we were drafting a document that tries to specify the standardized way to do so, as I promised :-)
>
> We realized that the document should focus on the necessary minimum information for data exchange not the detailed interaction and signaling which I believe can leave to different private implementations.
>
> This document is therefore intended to define a method for transferring RPKI validated cache by making use of SLURM.
>
> Looking forwards to your comments.
>
> https://datatracker.ietf.org/doc/draft-madi-sidrops-rush/
>
> Di
>
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops


From nobody Sun May 24 19:33:25 2020
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 C75013A07F4 for ; Sun, 24 May 2020 19:33:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjM-_Oz141xf for ; Sun, 24 May 2020 19:33:21 -0700 (PDT)
Received: from out20-37.mail.aliyun.com (out20-37.mail.aliyun.com [115.124.20.37]) (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 965713A07EE for ; Sun, 24 May 2020 19:33:17 -0700 (PDT)
X-Alimail-AntiSpam: AC=CONTINUE; BC=0.08055069|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_social|0.045464-0.0161111-0.938425; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03295; MF=madi@rpstir.net; NM=1; PH=DS; RN=2; RT=2; SR=0; TI=SMTPD_---.Hd6n0aE_1590373984; 
Received: from 192.168.218.230(mailfrom:madi@rpstir.net fp:SMTPD_---.Hd6n0aE_1590373984) by smtp.aliyun-inc.com(10.147.40.44); Mon, 25 May 2020 10:33:05 +0800
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Di Ma 
In-Reply-To: 
Date: Mon, 25 May 2020 10:32:31 +0800
Cc: SIDR Operations WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  
To: George Michaelson 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Sidrops] Distributing RPKI Validated Cache in JSON over HTTPS
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, 25 May 2020 02:33:24 -0000

George,

Thanks for your comments.

I comprehend your concern is about the authenticity of the SLURM file =
provider.

In RUSH exchange, SLURM file receiver chooses SLURM file sender as its =
Local Trust Anchor at its discretion.

I agree with your statement that RUSH can work well within IGP as this =
document says:

"The primary use of RUSH is to distribute RPKI validated cache within an =
ISP or an ICP composed of a number of ASes.  "

And maybe there is a usecase as described in this document:

"A small site or enterprise network MAY also use RUSH by synchronizing =
with a third-party RPKI cache provider over networks.=E2=80=9D

In short RUSH is intended to make use of SLURM Filters to do subtraction =
and SLURM Assertions to do addition, in order to keep two cache =
synchronized.

And the trust in SLURM file sender is configured by  SLURM file receiver =
out-of-band and can be verified during HTTPS exchange.

I think  RUSH can work well for 'SLURM for AS0 from the RIR=E2=80=99  =
:-)

Di


> 2020=E5=B9=B45=E6=9C=8825=E6=97=A5 08:18=EF=BC=8CGeorge Michaelson =
 =E5=86=99=E9=81=93=EF=BC=9A
>=20
> I think its useful to document use of secured transport to fetch data.
>=20
> The problem I retain in this, is the lack of strong cryptographic
> validity checks on the semantic intent of the assertions themselves.
>=20
> The beauty of RPKI was always the ability to demonstrate the binding
> of authority (delegated) to say what was to be done with some
> resource.
>=20
> SLURM doesn't honour that behaviour. Inside your own IGP, its a
> representation of your 'must-haves' including other peoples things,
> but between IGPs, transferred over the external boundary, I worry a
> LOT about "what it means"
>=20
> And that goes for 'SLURM for AS0 from the RIR too' btw.
>=20
> -G
>=20
> On Wed, May 20, 2020 at 3:32 PM Di Ma  wrote:
>>=20
>> Hi, folks
>>=20
>> I briefed a method for RPKI inter-cache synchronization called =
Distributing RPKI Validated Cache in JSON over HTTPS and our =
implementation with RPSTIR2 in IETF 106 Singapore meeting.
>>=20
>> After that we were drafting a document that tries to specify the =
standardized way to do so, as I promised :-)
>>=20
>> We realized that the document should focus on the necessary minimum =
information for data exchange not the detailed interaction and signaling =
which I believe can leave to different private implementations.
>>=20
>> This document is therefore intended to define a method for =
transferring RPKI validated cache by making use of SLURM.
>>=20
>> Looking forwards to your comments.
>>=20
>> https://datatracker.ietf.org/doc/draft-madi-sidrops-rush/
>>=20
>> Di
>>=20
>>=20
>> _______________________________________________
>> Sidrops mailing list
>> Sidrops@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidrops
>=20
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops


From nobody Tue May 26 11:54:36 2020
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 A75993A0ED6 for ; Tue, 26 May 2020 11:54:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQ6VnGDcp4aG for ; Tue, 26 May 2020 11:54:30 -0700 (PDT)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2065.outbound.protection.outlook.com [40.107.244.65]) (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 C8F673A0ED2 for ; Tue, 26 May 2020 11:54:30 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GHJmhGM4H/XV1Ys+XC6W5OPNEPWcf1ef3MIX3lH9rAMMpnuReRBu9Ac18m2yg4FfTy8+v8E8SCYQ3kmz2PASoOR06q2atXsANPdOHER5QQbpWooUx+vxmLufKnnJWOuiDRiPfYXh41DWTfuRb5VVJWCkxahZHTgYnRdJta3XBW6Emb4T1zKgLsIowr+SYlrA078ha+19Nrq4x4MbdJ7IzuUYtcdpBQ6LIbr3GZKcrVsS/1eJUn8VJmyb73pWf6ift4pkGPtv35nf+JUX+0Ttb1TA6Zdg0SLxFwQYTcaLfqGlySNUjfRZSCxb5Ba0RqJP6uojhys85hfxsIanc9oWkQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qOGCH9f/b+kU9ryC2wkN9o/kTX8S2ORPtUTP8h6f3UY=; b=cFg4WOTKEvdT3BDMG4wdddRuAZ13xVAPPZxUSpmoBeClaO1YW4/8MFONyer1tLZaOE6Sf0I6O/YLPtUAsbGiQngMjvWm0bAFJb/1hG7T5LMRH5a3VYrdwTnTC4yzpncZhA5cuteUscpM9lRCyd+Awt8zFNtiQTs4bd0lYGGyIFkS97GkoaiFdhj88CbK6HPyS5wqkTYco2onL6tRi2u8bXkwJBuz9jp1CCm+pKLYeKRIVcvCfIJffh2H+3pgVqWBEdwiDRmqSUUGqWx1jYpiNOS1snZHIHrC3SzbyMl6dVgEYzJFlOhGpfCZX/hEyb+WX6kKgI/+Sau0Bgqgx3l4JA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qOGCH9f/b+kU9ryC2wkN9o/kTX8S2ORPtUTP8h6f3UY=; b=umuEV+M3hzvD/TL9YqexRJHh9goq/R9AsTEOhxo2Un+jg0VhHH/79c9t2ktA31ajmz+aEPTgoskDXz+I2aXxnJBtfwEUxBjkont5zo+l2z3o0SWUE3QLigeD293ispl7H9j6A2jOsagy0+AQv/xV0xE9T1wnWs1HFX/9h28ACbI=
Received: from BYAPR18MB2534.namprd18.prod.outlook.com (2603:10b6:a03:12e::29) by BYAPR18MB2885.namprd18.prod.outlook.com (2603:10b6:a03:10e::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.24; Tue, 26 May 2020 18:54:29 +0000
Received: from BYAPR18MB2534.namprd18.prod.outlook.com ([fe80::280e:b668:2003:aa8]) by BYAPR18MB2534.namprd18.prod.outlook.com ([fe80::280e:b668:2003:aa8%7]) with mapi id 15.20.3021.029; Tue, 26 May 2020 18:54:29 +0000
From: Keyur Patel 
To: SIDR Operations WG 
Thread-Topic: Closed -  WG Adoption call for draft-ymbk-sidrops-rpki-rov-timing-00.txt - ENDS 05/22/2020  (May 22 2020)
Thread-Index: AQHWM48VtqXTD9VP2UiH3hcMvmL1jw==
Date: Tue, 26 May 2020 18:54:29 +0000
Message-ID: <9E221839-E2DE-4A18-83DF-E2BC82C8F248@arrcus.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.36.20041300
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arrcus.com;
x-originating-ip: [70.234.233.187]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 523d8d48-f136-4214-fa1f-08d801a63847
x-ms-traffictypediagnostic: BYAPR18MB2885:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:2958;
x-forefront-prvs: 041517DFAB
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: A1lDEcKrsiLEyzYpw43zPNXuaPnREbFSVzDf5sBMou6d+rIvGcq2CglYdLtxW5dA9HHb2JdauUvGTjD1G88VUoGD/Gs97ABChkSLwSdk1CmlHtqL71A7MsAnCnLWtcy3L2bbWioyTKAEX/dZ81arBcoqLYfk2SO2bKDSA6oeEsoguj9tqhRhuxlWZbWkgDWgBRXqoGc3xRAQSeMAm/4/hcnTz80CyfWXSfgiMsmlsuqsqkeNjYlfsdxwFEc6qTSTrC4mIgYhOvAqM5PItB5bgjez53jJTcQ4iRR3GhISMthUPWAe2fsWgnWZ8XRzxlwQFkXm131hIYbmvT7t1/44akUKloxGVjQD0iqPgwSFikbW0dOIKYSOrLbdwhTOUwOyuCZUKg7/Xi3te2nKiZVFmA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BYAPR18MB2534.namprd18.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(136003)(39830400003)(376002)(396003)(366004)(346002)(71200400001)(2616005)(8936002)(36756003)(33656002)(4744005)(8676002)(508600001)(316002)(2906002)(966005)(86362001)(6916009)(6486002)(6512007)(66446008)(64756008)(66556008)(66476007)(76116006)(66946007)(53546011)(186003)(26005)(6506007)(5660300002); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: +WyhqzPuTjLfuUIv8kGqmjKc+UvJCpEjxCRR1R2T8JXlvlGG+1BoaP/rn9DhxTwfRgNlmu20qG1BnEZVnmzzcb6riCd8mCfvyURuWskwOibi64huOW4IrEY0mZdb/cmiSXu7lxeHrjelDYGzzOW2Z5Gr1XOqkWgOmUpVFrBsrJkQPf9ukm34HbdPdqZ3WLpCXmqeF8yOJa8WgKxtxTQt/k0eZWAgXlHftknDW+y/XPAWYCExxW+fEPDmwSGMSfHAvwFhFIv1jVSLn4IKqTtuIJ/3ZlDxuYUCMeGDapHUwTsW8B0Lz/ZW0nK83Kx6lLAPsRd7AM6ETxaaRMbkKrPrj5/7wO4bX25mnkAYzThtMsS7tsB7aAhzkiIKmd0gi/BPJ+rzMavB1wQUpkoZvtKvj3mWnWe5vCSAXAbMoPjcfLHYR5BO2JyOdB4+U1S43RciNY5ZgkMsRORGq/48thC3EI7e3LpDo4zePs5V3coY+Pf+YGXoadBATyPs2QzTbJC6
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_9E221839E2DE4A1883DFE2BC82C8F248arrcuscom_"
MIME-Version: 1.0
X-OriginatorOrg: arrcus.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 523d8d48-f136-4214-fa1f-08d801a63847
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2020 18:54:29.1546 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: SnIz+SV9UIPsQETw5j4XlamuIKSQqVyLcdaFYdRsygOqOlerd65c9Rl6ocZHU2JA82Q/Jx/2bIzKY6BCKIbbmA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2885
Archived-At: 
Subject: [Sidrops] Closed - WG Adoption call for draft-ymbk-sidrops-rpki-rov-timing-00.txt - ENDS 05/22/2020 (May 22 2020)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2020 18:54:35 -0000

--_000_9E221839E2DE4A1883DFE2BC82C8F248arrcuscom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Rm9sa3MsDQoNClRoZSB3b3JraW5nIGdyb3VwIGNhbGwgaGFzIGVuZGVkIHdpdGggYSB3ZWFrIHN1
cHBvcnQgZm9yIGFkb3B0aW9uIG9mIHRoZSBkcmFmdC4gVGhlIGF1dGhvcnMgYXJlIHJlcXVlc3Rl
ZCB0byBzdWJtaXQgdGhlIC0wMCB3ZyBkcmFmdC4NCg0KUmVnYXJkcywNCk5hdGhhbGllLCBDaHJp
cyAmIEtleXVyDQoNCg0KRnJvbTogS2V5dXIgUGF0ZWwgPGtleXVyQGFycmN1cy5jb20+DQpEYXRl
OiBGcmlkYXksIE1heSA4LCAyMDIwIGF0IDk6NTcgQU0NClRvOiBTSURSIE9wZXJhdGlvbnMgV0cg
PHNpZHJvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBXRyBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC15
bWJrLXNpZHJvcHMtcnBraS1yb3YtdGltaW5nLTAwLnR4dCAtIEVORFMgMDUvMjIvMjAyMCAoTWF5
IDIyIDIwMjApDQoNCg0KSGkgRm9sa3MsDQoNCg0KDQpUaGUgYXV0aG9ycyBoYXZlIHJlcXVlc3Rl
ZCBTSURST1BTIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gY2FsbCBvZiDigJxUaW1pbmcgUGFyYW1l
dGVycyBpbiB0aGUgUlBLSSBiYXNlZCBSb3V0ZSBPcmlnaW4gVmFsaWRhdGlvbiBTdXBwbHkgQ2hh
aW7igJ0sICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteW1iay1zaWRyb3BzLXJw
a2ktcm92LXRpbWluZy0wMC4NCg0KDQoNClBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhl
IGxpc3QuIFRoaXMgYWRvcHRpb24gY2FsbCB3aWxsIGNvbmNsdWRlIG9uIE1heSAyMiwgMjAyMC4N
Cg0KDQoNClJlZ2FyZHMsDQoNCk5hdGhhbGllLCBDaHJpcyAmIEtleXVyDQoNCg==

--_000_9E221839E2DE4A1883DFE2BC82C8F248arrcuscom_
Content-Type: text/html; charset="utf-8"
Content-ID: <1525AE01BC06224D994E31B029B0EFC6@namprd18.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv
dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg
TmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M
IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N
CnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z
b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw
LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu
OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk
U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r
PSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZvbGtz
LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlIHdvcmtpbmcg
Z3JvdXAgY2FsbCBoYXMgZW5kZWQgd2l0aCBhIHdlYWsgc3VwcG9ydCBmb3IgYWRvcHRpb24gb2Yg
dGhlIGRyYWZ0LiBUaGUgYXV0aG9ycyBhcmUgcmVxdWVzdGVkIHRvIHN1Ym1pdCB0aGUgLTAwIHdn
IGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UmVnYXJk
cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+TmF0aGFsaWUsIENocmlzICZhbXA7IEtleXVyPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg
MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9
ImNvbG9yOmJsYWNrIj5LZXl1ciBQYXRlbCAmbHQ7a2V5dXJAYXJyY3VzLmNvbSZndDs8YnI+DQo8
Yj5EYXRlOiA8L2I+RnJpZGF5LCBNYXkgOCwgMjAyMCBhdCA5OjU3IEFNPGJyPg0KPGI+VG86IDwv
Yj5TSURSIE9wZXJhdGlvbnMgV0cgJmx0O3NpZHJvcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3Vi
amVjdDogPC9iPldHIEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXltYmstc2lkcm9wcy1ycGtpLXJv
di10aW1pbmctMDAudHh0IC0gRU5EUyAwNS8yMi8yMDIwIChNYXkgMjIgMjAyMCk8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5Ij5IaSBGb2xrcyw8L3NwYW4+
PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7
Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7
d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQt
c3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMyMTI1MjkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iY2Fy
ZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6
IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRq
dXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIxMjUyOSI+VGhlIGF1dGhvcnMgaGF2ZSByZXF1ZXN0
ZWQgU0lEUk9QUyB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIGNhbGwgb2Yg4oCcPC9zcGFuPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGltaW5nIFBhcmFtZXRlcnMgaW4gdGhlIFJQS0kgYmFz
ZWQgUm91dGUgT3JpZ2luIFZhbGlkYXRpb24gU3VwcGx5IENoYWluPC9zcGFuPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMjEyNTI5Ij7igJ0sICZuYnNwO2h0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC15bWJrLXNpZHJvcHMtcnBraS1yb3YtdGltaW5nLTAwLjwvc3Bhbj48bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIxMjUyOSI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDAp
O2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0
O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0
LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMjEyNTI5Ij5QbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0LiBUaGlzIGFk
b3B0aW9uIGNhbGwgd2lsbCBjb25jbHVkZSBvbiBNYXkgMjIsIDIwMjAuPC9zcGFuPjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFy
aWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czog
YXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13
aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImNhcmV0LWNvbG9y
OiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3Rl
eHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0
bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMyMTI1MjkiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBz
OiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Vi
a2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4
O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5Ij5OYXRoYWxp
ZSwgQ2hyaXMgJmFtcDsgS2V5dXI8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_9E221839E2DE4A1883DFE2BC82C8F248arrcuscom_--


From nobody Tue May 26 18:45:38 2020
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 2068E3A0CF6; Tue, 26 May 2020 18:45:36 -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: 7.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: sidrops@ietf.org
Message-ID: <159054393600.25756.2022895389535334132@ietfa.amsl.com>
Date: Tue, 26 May 2020 18:45:36 -0700
Archived-At: 
Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-rov-timing-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: Wed, 27 May 2020 01:45:36 -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           : Timing Parameters in the RPKI based Route Origin Validation Supply Chain
        Authors         : Randy Bush
                          Jay Borkenhagen
                          Tim Bruijnzeels
                          Job Snijders
	Filename        : draft-ietf-sidrops-rpki-rov-timing-00.txt
	Pages           : 8
	Date            : 2020-05-26

Abstract:
   This document explores, and makes recommendations for, timing of
   Resource Public Key Infrastructure publication of ROV data, their
   propagation, and their use in Relying Parties and routers.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-rov-timing/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sidrops-rpki-rov-timing-00
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rov-timing-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 Thu May 28 23:52:56 2020
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 810793A091F for ; Thu, 28 May 2020 23:52:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgkBaXSaHVlk for ; Thu, 28 May 2020 23:52:51 -0700 (PDT)
Received: from out20-74.mail.aliyun.com (out20-74.mail.aliyun.com [115.124.20.74]) (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 970BB3A0920 for ; Thu, 28 May 2020 23:52:48 -0700 (PDT)
X-Alimail-AntiSpam: AC=CONTINUE; BC=0.06769614|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_regular_dialog|0.276629-0.0251491-0.698222; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03307; MF=madi@rpstir.net; NM=1; PH=DS; RN=2; RT=2; SR=0; TI=SMTPD_---.HfF8IiV_1590735158; 
Received: from 192.168.218.230(mailfrom:madi@rpstir.net fp:SMTPD_---.HfF8IiV_1590735158) by smtp.aliyun-inc.com(10.147.41.137); Fri, 29 May 2020 14:52:39 +0800
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Di Ma 
In-Reply-To: 
Date: Fri, 29 May 2020 14:52:37 +0800
Cc: SIDR Operations WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   
To: George Michaelson 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Sidrops] Distributing RPKI Validated Cache in JSON over HTTPS
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, 29 May 2020 06:52:55 -0000

George,

I would like to add some clarifications after I notice you and Randy=E2=80=
=99s discussions re (SLURM file for Unallocated and Unassigned RIPE NCC =
Address Space) in RIPE routing WG mailing list.

I think the key point is the scope of the SLURM file receiver.

RUSH is designed to deliver SLURM file (validated cache) to =
=E2=80=9Csubscribers=E2=80=9D . That is, the scope of RUSH usage is =
convergent.=20

If A subscribes to X for RUSH, A has got a trust in X in terms of =
authenticity of SLURM file source and data integrity could be therefore =
protected by HTTPS.

And X is not responsible for Z if A diffuses the very SLURM file to Z =
which is not a subscriber to X.=20

Let me also take the discussion to ROA 0 via SLURM.

ROA 0 information in fact is not LOCAL but global although the policy =
proposal for RIPE is to make use of SLURM, which is intended to =
propagate over networks (maybe via CDN).  I guess this is the reason why =
it causes concerns for ROA 0-SLURM integrity.=20

However, I envisage if RIPE make ROA 0 info only available to a =
convergent scope by employing subscription mechanism via RUSH/web =
download.=20

Di



> 2020=E5=B9=B45=E6=9C=8825=E6=97=A5 10:32=EF=BC=8CDi Ma =
 =E5=86=99=E9=81=93=EF=BC=9A
>=20
> George,
>=20
> Thanks for your comments.
>=20
> I comprehend your concern is about the authenticity of the SLURM file =
provider.
>=20
> In RUSH exchange, SLURM file receiver chooses SLURM file sender as its =
Local Trust Anchor at its discretion.
>=20
> I agree with your statement that RUSH can work well within IGP as this =
document says:
>=20
> "The primary use of RUSH is to distribute RPKI validated cache within =
an ISP or an ICP composed of a number of ASes.  "
>=20
> And maybe there is a usecase as described in this document:
>=20
> "A small site or enterprise network MAY also use RUSH by synchronizing =
with a third-party RPKI cache provider over networks.=E2=80=9D
>=20
> In short RUSH is intended to make use of SLURM Filters to do =
subtraction and SLURM Assertions to do addition, in order to keep two =
cache synchronized.
>=20
> And the trust in SLURM file sender is configured by  SLURM file =
receiver out-of-band and can be verified during HTTPS exchange.
>=20
> I think  RUSH can work well for 'SLURM for AS0 from the RIR=E2=80=99  =
:-)
>=20
> Di
>=20
>=20
>> 2020=E5=B9=B45=E6=9C=8825=E6=97=A5 08:18=EF=BC=8CGeorge Michaelson =
 =E5=86=99=E9=81=93=EF=BC=9A
>>=20
>> I think its useful to document use of secured transport to fetch =
data.
>>=20
>> The problem I retain in this, is the lack of strong cryptographic
>> validity checks on the semantic intent of the assertions themselves.
>>=20
>> The beauty of RPKI was always the ability to demonstrate the binding
>> of authority (delegated) to say what was to be done with some
>> resource.
>>=20
>> SLURM doesn't honour that behaviour. Inside your own IGP, its a
>> representation of your 'must-haves' including other peoples things,
>> but between IGPs, transferred over the external boundary, I worry a
>> LOT about "what it means"
>>=20
>> And that goes for 'SLURM for AS0 from the RIR too' btw.
>>=20
>> -G
>>=20
>> On Wed, May 20, 2020 at 3:32 PM Di Ma  wrote:
>>>=20
>>> Hi, folks
>>>=20
>>> I briefed a method for RPKI inter-cache synchronization called =
Distributing RPKI Validated Cache in JSON over HTTPS and our =
implementation with RPSTIR2 in IETF 106 Singapore meeting.
>>>=20
>>> After that we were drafting a document that tries to specify the =
standardized way to do so, as I promised :-)
>>>=20
>>> We realized that the document should focus on the necessary minimum =
information for data exchange not the detailed interaction and signaling =
which I believe can leave to different private implementations.
>>>=20
>>> This document is therefore intended to define a method for =
transferring RPKI validated cache by making use of SLURM.
>>>=20
>>> Looking forwards to your comments.
>>>=20
>>> https://datatracker.ietf.org/doc/draft-madi-sidrops-rush/
>>>=20
>>> Di
>>>=20
>>>=20
>>> _______________________________________________
>>> Sidrops mailing list
>>> Sidrops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sidrops
>>=20
>> _______________________________________________
>> Sidrops mailing list
>> Sidrops@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidrops
>=20
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops


From nobody Sun May 31 01:59:14 2020
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 7DE603A136D for ; Sun, 31 May 2020 01:59:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEW0knLv1XFu for ; Sun, 31 May 2020 01:59:11 -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 74C403A136C for ; Sun, 31 May 2020 01:59:11 -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 1jfJo9-0005xj-6D; Sun, 31 May 2020 08:59:05 +0000
Date: Sun, 31 May 2020 01:59:05 -0700
Message-ID: 
From: Randy Bush 
To: Di Ma 
Cc: George Michaelson , SIDR Operations WG 
In-Reply-To: 
References:    
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [Sidrops] Distributing RPKI Validated Cache in JSON over HTTPS
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: Sun, 31 May 2020 08:59:13 -0000

di

i am a bit undlear here.  could you walk me through an example, starting
with what i trust?  e.g. am i trusting a dns name?  a tls cert ca?  ...

thanks.

randy


From nobody Sun May 31 20:40:55 2020
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 43AA53A0C3F for ; Sun, 31 May 2020 20:40:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYXKTj8bP_qh for ; Sun, 31 May 2020 20:40:52 -0700 (PDT)
Received: from out20-38.mail.aliyun.com (out20-38.mail.aliyun.com [115.124.20.38]) (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 B9A833A0B30 for ; Sun, 31 May 2020 20:40:50 -0700 (PDT)
X-Alimail-AntiSpam: AC=CONTINUE; BC=0.0791467|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_regular_dialog|0.0226426-0.00707572-0.970282; FP=0|0|0|0|0|-1|-1|-1; HT=e01a16384; MF=madi@rpstir.net; NM=1; PH=DS; RN=3; RT=3; SR=0; TI=SMTPD_---.HgUsisx_1590982842; 
Received: from 192.168.218.230(mailfrom:madi@rpstir.net fp:SMTPD_---.HgUsisx_1590982842) by smtp.aliyun-inc.com(10.147.41.231); Mon, 01 Jun 2020 11:40:42 +0800
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Di Ma 
In-Reply-To: 
Date: Mon, 1 Jun 2020 11:40:38 +0800
Cc: George Michaelson , SIDR Operations WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: <2AE9AF6A-504E-458F-9004-128E198B1EA2@rpstir.net>
References:     
To: Randy Bush 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Sidrops] Distributing RPKI Validated Cache in JSON over HTTPS
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, 01 Jun 2020 03:40:54 -0000

Randy,

We need to differentiate two uses-cases.

1) Use SLURM file to update validated cache (VRP) over networks within a =
bailiwick

2) Use SLURM file to broadcast Unallocated and Unassigned RIPE NCC =
Address Space (ROA0)

As in case 1, I think it is typically sorta inter-cache within an ISP =
who does not want to see multiple RP instances bringing inconsistency. =
It just uses one RP to do sync and validation and then uses RUSH to do =
sync among cache servers in its networks. so the trust can be =
established easily in this convergent scope of those cache servers.  And =
share-key for instance can be used as TRUST to employ IPSec to implement =
authentication of SLURM file transferred between two cache server.=20

As in case 2, I think what RPs should trust is who is authoritative for =
ROA0. Although SLURM file itself has got no protection for data =
integrity there are workaround. If you are going to download from RIPE =
NCC you just need to make your browser/client to trust web PKI cert of =
RIPE.=20

In short, I think RUSH is competent for case 1 and could be used for =
case 2 which needs more discussions in RIPE community :-)

Di=20


> 2020=E5=B9=B45=E6=9C=8831=E6=97=A5 16:59=EF=BC=8CRandy Bush =
 =E5=86=99=E9=81=93=EF=BC=9A
>=20
> di
>=20
> i am a bit undlear here.  could you walk me through an example, =
starting
> with what i trust?  e.g. am i trusting a dns name?  a tls cert ca?  =
...
>=20
> thanks.
>=20
> randy