Re: [Sidrops] trying to limit RP processing variability

Stephen Kent <stkent@verizon.net> Fri, 03 April 2020 17:27 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 43AAC3A0951 for <sidrops@ietfa.amsl.com>; Fri, 3 Apr 2020 10:27:21 -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 VGm9EpRCRYum for <sidrops@ietfa.amsl.com>; Fri, 3 Apr 2020 10:27:18 -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 D9CE73A094E for <sidrops@ietf.org>; Fri, 3 Apr 2020 10:27:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1585934836; bh=r6+xwiEEG2BubVJIMjB+vxegJasWzLXUZswSPspcDXY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=nC7KiTbfDqDquj+/BnQOpTckzV4PkAbU964ZSsALVRCOGsNE43eUyZQOab4tXpwdStE1Hkqcn7/GEHx+LY3+SNWV4Clo6/5ECpHGfSow72c/Ixo3x4K5a/ZaP1y5CriBP8Smd7gnvX+6ftYzo/Fwzoi3+yfN64a403AmunTUMZxF1GgJkxjZQ07RnIe5EQ6OyJBwwt4NUxQnYAJNY9kZaOWuw8Npsdjd5287SctKpm54TOjwlCHzba5336MVKYJQYrCo7aI+lAolHOC/eTlxF4gBIIYFRZRJutwG16TrDcDINldMVRGWR0iAw8QMx06zrNKnXZq3zMvAkwDxLVZ8Zg==
X-YMail-OSG: NkucQv8VM1mqKLQKzLgzDVFzOr.1FtglE4YbYleh_MCaMNXSR.nnBA1er9xB8r. aVd8thDJOvdhWVnpspuGV.U2z5XS1yOZzU5edii2e6AiSeP8meJaKpxqt08JS3CzcWP5dwqt2Ax7 GnQdRptNCT3ENkBuIyYmNGwlOPEwj8AcKRrTp0UPbiNo1Ps5QXqY79AF5AiV5xJ_71oHlGgvw3Mr Gj3HLMwX9kGKQVA_0XLkSicrGbAQx_GiHQBVBQWbtb.3BQ6VPYYt483_XdyvPFDlOnJLHwkkwbu7 OMPfOtY7pEZ0pi_g9Txm.W.myKhaKwT_.4I_9XGNVeqXpJvD6n_v0WM4Hk9_KDEdkePvkbcA_8GS On0CrabrLchTZ4zE3aXxNbXhctpkUkWh.uU2bGvSVjG60JkY_0USYLx8INVjzJiex_0R7NvZZE3T JkbUNdbgWKcF1qCaJcu45dkGVnOuHuttBo5LW7D3XXDKquBP_l_BO.uLGpYsdpnqm2IvAjH4TxSR klPtju9CiTMaFGpn4YSDALI3BenciVMOiJtOHpoUAhJ_8Pjay5TC4PvubLQXkpFaOfLZWjzt7Rx6 OKALZQ2UJ7h2raRH7tkm1D6UwM8HSnqSE5wgGOPngPaofNieDDRzAHAr9CywVeWRUV.KhzRZlmRy fLohRh26PaAjRZqAMniZFyjoJHTsOvPBEOiJxIzIsoC9Zyz_YJIfDsWcr6PMVMclRDXqmqy1PMfQ p0581Uqv7VL1Nd9JUXxGuzmToM07eHO9zGg3lstKoJfccizP6nM.ALAqBWbK_Qu_2Xuy3XP.rGUD 0EAvo5sznhV4ptzeofMeX.RqoHTVJTt1jzFky59zXaRyLYiWJdeXxPWjjWWfzbdcGiNPkx0r7U2B Uijo6oMWT4PbKZi7bJkor2nb5tCk0VgKTFF04LatcCUogyyxX559THdNb.n2QklNCvASdfq1z0yh sehUfr4J_LQC6s6NB4px6zrzAObP8E2055e4rIGMpGfyzjAn3Mo5_DMs.xkeRt5C7KG10R_mPHWk XfZV_ZG64CyU5jFbUXeMEaCTpMBAVENr81P0OdgK5tYpMZFb7tdav9Ye86VLsX6FFipRcojl3hN3 3SrN53lPvmqi0WkFWWCD.vi5t.LBzBE4YDm10giJlSQQw2MiHW349XOuI7pOeeXN7358nqOlBmuW .AVEcCygT.OjcGHhwtoI4QVGzRrAbQvrUCnH__APbRRf4bZokshfsySnf4oGcaW_nEPDKWVdwFJY P2El3rSpncHwxyMurAXyq7IOlzJH1M6tOTN_yOrC_bq_Mo2QH1g79wINhFnWjdhjlhB1Agwlj4uK ZJLf.S_l57qdZph4_w4oICC29wbznKBAzYZxAe9KzFd101FDehSpDalqugNeFp4btqu.pkvlJKR8 BqQd8e55U0pjPI_jY5LY4FsyhqBYQVlOj
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Fri, 3 Apr 2020 17:27:16 +0000
Received: by smtp424.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f20071974ca103ca917ce5f82d55aeff; Fri, 03 Apr 2020 17:27:15 +0000 (UTC)
To: Job Snijders <job@ntt.net>
Cc: "sidrops@ietf.org" <sidrops@ietf.org>
References: <a9448e54-320f-300c-d4f9-d01aca2b6ef4.ref@verizon.net> <a9448e54-320f-300c-d4f9-d01aca2b6ef4@verizon.net> <20200403162647.GH60268@vurt.meerval.net>
From: Stephen Kent <stkent@verizon.net>
Message-ID: <c39af2ec-28a9-0b93-65f5-5f2aa445445b@verizon.net>
Date: Fri, 3 Apr 2020 13:27:14 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200403162647.GH60268@vurt.meerval.net>
Content-Type: multipart/alternative; boundary="------------2293205DBF3BCBC59959813F"
Content-Language: en-US
X-Mailer: WebService/1.1.15620 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/ZvD1gy30nogtXGPD3-zpGkmF2NM>
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: Fri, 03 Apr 2020 17:27:22 -0000

Job,
> Dear Stephen,
>
> Thank you for spearheading this initiative. It is helpful to see the
> various permuations for which a decision tree needs to be constructed
> laid out in this way.
>
> On Fri, Apr 03, 2020 at 11:40:10AM -0400, Stephen Kent wrote:
>> *Terminology*
>>
>> Valid: a signed object (other than a certificate or CRL) is deemed
>> *valid* if it is encoded in a fashion consistent with the relevant
>> RPKI RFCs (i.e., 6482, 6486, 6487, 6488, 6493) and the signed object’s
>> signature can be verified consistent with RFC 6488.
>>
>> Current: A CRL or Manifest is *current* if the current date & time is
>> before the Next Update date and the CRLNumber (or ManifestNumber) is
>> greater than any prior, valid CRLs or Manifests processed by the RP.
>>
>> Stale: A CRL or Manifest is stale if the current date & time is later
>> than the Next Update date. A stale CRL or Manifest is not “expired”
>> it’s just not as current as it is supposed to be. The case analysis
>> below examines what to do when a Manifest, or CRL, or both are stale.
>>
>> 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.
>>
>> Corrupted: if an object named in a Manifest, is available for download
>> from a PP, but it’s hash does not match the corresponding value in the
>> Manifest, the object is termed *corrupted* and the object SHOULD be
>> ignored.
> Can you also provide a definition for your use of the word 'invalid'? I
> see the phrase used in the case analysis permutations.

I would call a signed object invalid if it is syntactically broken 
(e.g., bad ASN.1 encoding), or if the signature cannot be validated as 
specified in RFC 6488. This is just another way of saying that it fails 
either of the  criteria cited in definition of *valid*.

Steve