[Sidrops] trying to limit RP processing variability

Stephen Kent <stkent@verizon.net> Fri, 03 April 2020 15:40 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 D36243A19A3 for <sidrops@ietfa.amsl.com>; Fri, 3 Apr 2020 08:40:19 -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, HTML_MESSAGE=0.001, 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 VqiMMPss0qY2 for <sidrops@ietfa.amsl.com>; Fri, 3 Apr 2020 08:40:18 -0700 (PDT)
Received: from sonic305-2.consmr.mail.bf2.yahoo.com (sonic305-2.consmr.mail.bf2.yahoo.com [74.6.133.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 C4C393A142D for <sidrops@ietf.org>; Fri, 3 Apr 2020 08:40:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1585928416; bh=fqXzk5tRK0r2aGPCXTyngXM2nWat6R+69SEMtabkEVY=; h=To:From:Subject:Date:References:From:Subject; b=YYoDpFjLy5xq52lYdyrut8C++QfMoZNr2ns7HI29pMam0VJno6D1mvYaD5ZTcU5J4ac/iTmyb6D1MsdJaV264aTaHUnt9A7ReNXGJHE/B1ikFY9bARi0bSKolklGQWX5J2XM7XUOfXY82OM2KzedintoO/EqJnHr0dc63aXvjSjHPxJnVPlT5GUkdIJKN9BVJi0DtEKpZBlTO7uJm0wTQFz7jPhEKVgIR2+qIRrYVHtnsLHxjQQ3IJWUhThy42dprHPUNzLgcbErdh3ckpmg8951V8zFNxQTkkM9qXI974D9f8ouqJqugGEq3ga+tDSZoDlHbE+JhulR6s6tPOzqWA==
X-YMail-OSG: U.80sL8VM1nuvDSz32MT3spGpWnu_zf5Gqi05SnMggxqX8csucRMqsOcczsiqfO ZVkuC782xDr9H_XxCC3AkyCAShVTxjv.blOQlT5Bz4DQi4naa64mbSS79zwtc5Q9oozkK1eMH2LP CdME8mnDDtnR3ETCvC_l.AIrQwLLVJYF2AuVlj8D9Ur5A4VobkQ6cxTG0kPQlmd6pFhrdBmKiozY 5ZBC_FP1bFS5Z6O0_2isT0dpMYvpL12cSewuiZMv113a8.vLdVMyzzNq4k6b.0qKEARyq0rCmm6W fBVs.y012XHn3Ubzmw_rv5Zd6T9MY.KNxZyLufOjn_G3JYWI1C1FUKiiFE53oEf9BS3jph8O6gS6 s_wiNhOWp9oZjg9z4sLKEI8fFHNLKCIHFIKsxjcROFQJVKbM1y.NsP5h8SXEeuv3YTRA4oHlbspJ 0guoV6_K7.WAMpMU0qWj22vb11AQODvAR3Doaj690dL9WzB5SvY2QxA0WhJZygoN86oy8Tv197Ft ni2hMLI3P05_PAmwR9B0xRqUWmA8HKWQrXKChq6oCJwNSlRSzD5.WDcT7jSI13ZD_xUQ_Ll0K8v6 N.qThmf3A9icxh5Ovd4oJjs3tpqGbOSKeJcfhKb3YpJjBE0Qi5uGRxUFgNYP6aM8WTX5Mgoz03Hn yimeKvOTvz3LiihHW4_Q78mILnpMW3OJLx.Dix0FMkjs3n9PdUr0L3bWXSZ8nBC194R3LyRTigHX TJDmeaFQi.cp2pGHl.FC.gznFwFMadlBbxTBtp2OilTZaHtUDtuNBB_.aweETLFEBxl3UxZHnPXb WcGq.knCMk29JMRBBXnM.6hTXEC4TPDZkx21ZyMFpSRNHKAg5vNdHdYyOlQ8Q_qac1263uSDoxmh aLAA8XBXk0qRFe5Uh.XyM3vi7I493aFMlhobuHq2SYqoWgk._SxBCoYu323Yl3N5Dd.QzmRHr84a o8UvfFPaDtjxjQ3PvmBlxqYjojcwDWcz.LJKqphzvQFf_zHEhaxG4Q2B79BjS6e0uUEgyu2s1wmJ wLYVdOb59D2dM3wbm_ryEDYRrWaVy5FQ17rw7dH7J8K_r3FOVrfOlRpSuK3UCktnVVlu159lAAWj v4LrhdKS5xeCnv5jBlAIR3mAf.L9JHi1O7XLzvLScO6HDs8qH7JBcYObzv27Urv4fqG1RGDUkDfk 1HN2QZ3ppCKC9WlyN4OKJ2Zc6QRAIFfjBu5fII.XoSyV0uDIezaEOBkSZQ32Mry2_L.Gu4Ib7vg3 U_M2juMTrRycVlSFFIknASjiLrFQh.rSjjhn77ZhhGuwuH7gj_163y.WZ8rssaHmnVYJlJHUm.C6 xp4SKCOzElm35laYEZy.TOnTPH7VBCh73zZme7vRzLp63kBic9FHKKNpERSqVxIxtJJ3N0d4k6dF GJM_56PE74V9LG.BC9HGqxoaqKxhVUMccz4xGCyUUBlVMQb3zR1VFMPeUQmic
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Fri, 3 Apr 2020 15:40:16 +0000
Received: by smtp432.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 453cfff583cfc07fd06b3a244539a6f9; Fri, 03 Apr 2020 15:40:11 +0000 (UTC)
To: "sidrops@ietf.org" <sidrops@ietf.org>
From: Stephen Kent <stkent@verizon.net>
Message-ID: <a9448e54-320f-300c-d4f9-d01aca2b6ef4@verizon.net>
Date: Fri, 03 Apr 2020 11:40:10 -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
Content-Type: multipart/alternative; boundary="------------88C38A45D98F9F60FD000D8E"
Content-Language: en-US
References: <a9448e54-320f-300c-d4f9-d01aca2b6ef4.ref@verizon.net>
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/rKW8Zf0uh1Q8BqrPrh2bsXI5Gh8>
Subject: [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 15:40:20 -0000

                                    *Overview *


A publication point (PP) in an RPKI repository contains the following 
elements:

1.CA certificates (optional, present only for subordinate CAs)

2.EE certificates (optional, present only for routers)

3.CRL (usually one)

4.ROAs

5.Manifest (usually one)

6.Ghostbusters record (one, optional)

*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.

*Case analysis*

If we can agree to ignore any objects at a PP that do not appear on the 
current manifest, the case analysis is easier. (The discussion of 
corrupted objects above addresses the case where an object is named on 
the Manifest, but the hash does not match.)


Below is a proposed outline for the cases. The group needs to decide 
what action is to be taken in each case.



1.Manifest present, valid, current

1.1.CRL present, valid, current

1.2.CRL present, stale

1.3.CRL present, invalid

1.4.CRL missing

2.Manifest present, valid, stale

2.1.CRL present, valid, current

2.2.CRL present, stale

2.3.CRL present, invalid

2.4.CRL missing

3.Manifest present, but invalid

3.1.CRL present, valid, current

3.2.CRL present, stale

3.3.CRL present, invalid

3.4.CRL missing

4.Manifest not present

4.1.CRL present, valid, current

4.2.CRL present, stale

4.3.CRL present, invalid

4.4.CRL missing