Re: [Sidrops] trying to limit RP processing variability

Stephen Kent <stkent@verizon.net> Thu, 16 April 2020 14:54 UTC

Return-Path: <stkent@verizon.net>
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 739513A0A54 for <sidrops@ietfa.amsl.com>; Thu, 16 Apr 2020 07:54:35 -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 9o2b209bpoDx for <sidrops@ietfa.amsl.com>; Thu, 16 Apr 2020 07:54:33 -0700 (PDT)
Received: from sonic308-1.consmr.mail.bf2.yahoo.com (sonic308-1.consmr.mail.bf2.yahoo.com [74.6.130.40]) (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 8DD6F3A0A5F for <sidrops@ietf.org>; Thu, 16 Apr 2020 07:54:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1587048872; bh=ONo8xY9KKuVAcsVaMX8pVTfbzsfZLPmWOnBYU8lkte8=; h=From:Subject:To:References:Date:In-Reply-To:From:Subject; b=NhlkXw8LSMHxLgQhhZOIsNCwnm9kv281PBkXt6cacQy/gCgTvh4gPOj8l9PLTehH2YwykhYKAfn4UITd7h90ETqxaLr0C5TZLsaWECeDKa4ZfjmgY2ym0Bh/oLS851EpI8RIOzvegcCQXAsnYvo6CpZdSjGYtIp/G02NrqrtkqckaVgX06KVrGjw1uk+LnUIPQUnaQueLtvUDoMlY9p3F2W4qw0l3606iYJtdQKp0c9/9FH0/7jDWGr4u86RBThiCt2ePWQchxWq+3kUJI9dCXvjmYm9Pzk2RybOsUMUTMy3nXLAhNDpNiOl0xMjLO0cA7gl52SVmAta1oj+kCbt0Q==
X-YMail-OSG: Z61OuXoVM1lgkyC0rsSoD.QK.z_2_HTYJrH1U5SKOcHDSNtFp.JlJzOs.6Akky_ PTvGndDpOunnOeUCMjvs7w2esF1_MY0IgL6oX0c8nMBVdxXrOlJvCbS45qGU4PC93oIDsMFeTvhP J9Sj66l7G4Ea73KcsUXznwl.Bcdsbgz8svMYxbq9DlpBX.S41MKFX0OtJZgfqdW8VkhOcFbwitrL yD14YelrnaWEbX9iNMjMeXKur84o9ntXW.jXKp.LGd16fy8z.2BsZTzLiEXiWVN.Pd3SGXHP6Oyo 6P9lJiJh47I0G6unpOJebfOIFxmd9JwFlGFsCB8o5Xsp0gHWnxSpHHqpkf3Ai_e68GLjbUKLAraM O4RS9w_uSA8q7HnmSA7TxVqeN6seMKKlIX90VzkpCJVVsTqw5eV_Am9wr_BF6vZNx8kKOzMq1EnT cLhlhAkZHQoONItBvbVc9y1BtpRobttqLvkTpmTu.q4O7FYMw2USL.kk4cp.M2QiVO5BxJ1jjOgQ MNjRQ_sPHuLU4C59claYvSGCOj.w865obT2bkDh0yXRJ.cOoBhVVisnTPa0rjqDG4wEvCwrb.bVy eXazRckTFeUFbnZjxVR95PqGq5E2n5T..kvYfNd7n_6__NRuJx6YKcFWFX8SIQZHojeQp2sE3KJH CcG55l_5aE.MkbAvqG5zMOIhV0bTeogo52faS6Lwhnk0qUw7pa74HvvrUAm61Ocz6YafxX2mGzsg pr60nHLvSuDQ6A3RH6DCKoaFRsn46l8jV51Tdp_uWzCJAvZlaDZOHgwkwNCcAnJKLZCUs6tr42O5 3lqr2PqXD1X6G9ZyXtlGekxzYja0Uq.BDiGHH81BsZ91zydsrpHkXvMyU_VeyqzGzc6FG6.wpGdD aadJo42fHCfr_10NDsnsvxYbjb3Ob_f1GlGmpunbs6G4x1Lvq5Qg0cds_IoPkNJkxo5HqlO.tqjX 8hRMAr.7adUZGJZL5Smhy8Tc4MlL3UO0fytdNGccJ_D7NFy5IcHLOTqgXhH9PUqeba5v992E3vHK 8D29YwmFHwOUgaYbCXI8vXSuTYBYN11CU.lzV5vh8JKlYazafvh7.MtI6BXtqrnHWTwaouqL._0G YE_CnrY54H4kPGrWjuzF1lljQNSmEz4jbM84K5lj.PsN8xCPgARvHNS8yC06U1WHedaUI0uumGxr TKUKrH.tQFcGdI1KjRy4SNR2n92KG8BLIsLetKFoA8jQ3_1XlWDb1v6EiLuFJ0v2_ESDzLxnOEDu syGI7LbhJcqVnVWd6xtWuVbA3nkJeHyvz2TuY0vQNygYVcg7UyYsZfps_fM_26rkdD.Reg2pEnLC aAzAp6oD94xV_0SVrhtZV.8EuRuyAWyebJ_K_pn5zaL9Dvut4FkqO_Ol4uzbCKFVEnG8ZRW5bWFR N4py9WzZj6ZpK4i4TtnRAjl8oGtvhFhndRDLocpjePbPnIkdT
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.bf2.yahoo.com with HTTP; Thu, 16 Apr 2020 14:54:32 +0000
Received: by smtp419.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a62d714b92a8d88f69184d6ac30aeed4; Thu, 16 Apr 2020 14:54:27 +0000 (UTC)
From: Stephen Kent <stkent@verizon.net>
To: sidrops@ietf.org
References: <a9448e54-320f-300c-d4f9-d01aca2b6ef4.ref@verizon.net> <a9448e54-320f-300c-d4f9-d01aca2b6ef4@verizon.net> <20200415150141.016d021d@glaurung.nlnetlabs.nl>
Message-ID: <e7f329ae-4878-2311-a61f-15946cb46a39@verizon.net>
Date: Thu, 16 Apr 2020 10:54:26 -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: <20200415150141.016d021d@glaurung.nlnetlabs.nl>
Content-Type: multipart/alternative; boundary="------------3112700256D8E9606752CE21"
Content-Language: en-US
X-Mailer: WebService/1.1.15651 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/uO0wyjXfC00DNuyUhQzgqe_hglQ>
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 <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Apr 2020 14:54:36 -0000

Martin,
> Stephen Kent wrote:
>>                                      *Overview *
>>
> [...]
>> *Terminology*
>>
>> Missing: an object named in a Manifest, but not available for
>> download from a PP, is termed *missing*. An RP has no obvious way to
>> acquire missing objects, but operators SHOULD be warned about which
>> objects are missing.
> Since "missing" seems to be the opposite of the "present" in the case
> overview below, I think we need to more precisely define the meaning
> for both manifests and CRLs.
>
> I would define the meaning of "manifest missing": the manifest
> referenced in the CA certificate is not available for download from a
> PP. That leads to the case where there is a valid manifest at the PP
> but it is not the one on the CA certificate.
>
> "CRL missing" is a little more complicated, since there is two places
> where CRLs are referenced: in the manifest and in the EE certificates
> of signed objects. So we also have the case where a CRL in an EE
> certificate isn’t actually mentioned in the manifest.

I don't think I follow your reasoning here.

For CA A, there is one PP where all of the signed objects issued by A 
live, ignoring the cases of key rollover or algorithm transition 
(Section 2 of RFC 6481, especially Figure 1). This PP contains the ROAs, 
a manifest, and a CRL, router certs, and any subordinate CA certs. The 
CRL that lives here would contain an entry for a cert associated with a 
manifest if that cert were revoked, and the manifest contains an entry 
for the CRL. If one were to encounter a CRL that contained an entry for 
the EE cert in the manifest, that would indicate an error by the CA.

>     1.Manifest present, valid, current
>
> If there is a present, valid, and current manifest, the CRL can safely
> be ignored for all objects.
Tim has suggested that, but to do so would make the RPKI not consistent 
with RFC 5280.
> In order to avoid using partial sets of information, the entire content
> of the PP is ignored if any object is missing, corrupted, or invalid.
This is not consistent with your suggestion that the CRL can safely be 
ignored.
> Presumably this chould only be limited to objects of the same type,
> i.e., if there is a least one missing, corrupted, or invalid ROA,
> discard all ROAs.
I'm not sure why the group-oriented approach is useful, expect perhaps 
for ROAs. Why would one elect to ignore some router certs if one were 
missing?
> If the aim is to avoid risking accidentally marking routes as invalid,
> this should probably also extend to all information published by child
> CAs.
is the concern here that ROAs issued by a subordinate CA might be 
treated differently if there is a missing ROA associated with the parent?
>> 2.Manifest present, valid, stale
> Not sure about this one. Naively I would say "use as above but warn."
> There’s also an option to distinguish based on the transport protocol
> used for synchronizing the PP: ignore if rsync is used, use but warn if
> RRDP is used.
I'm in favor of warning here, but others, I believe, have suggested, 
that we try to make the outcome independent of the use of rsync vs. RRDP.
>> 3.Manifest present, but invalid
> The entire PP is ignored.
So, it's OK to ignore a CRL that is invalid, but not a manifest. 
Personally I believe that if a CA cannot manage to correctly generate 
both a CRL and a manifest, it has a serious operational problem.
>> 4.Manifest not present
> The entire PP is ignored.
>
> This essentially ignores the CRL for any object published within the
> repository and essentially moves its role over to the manifest. The CRL
> would still be considered for objects published outside the repository,
> such as the proposed Resource Tagged Assertions.

A missing manifest is a serious concern, but I would consider using 
cached, still valid objects for the PP, and insisting on contacting the 
CA or PP maintainer.

Steve