Re: [Sidrops] 6486bis: Failed Fetches

Stephen Kent <stkent@verizon.net> Thu, 27 August 2020 15:07 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 C03AD3A0D69 for <sidrops@ietfa.amsl.com>; Thu, 27 Aug 2020 08:07:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.049
X-Spam-Level:
X-Spam-Status: No, score=-3.049 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, NICE_REPLY_A=-0.948, 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 0HoRNtHvtm7S for <sidrops@ietfa.amsl.com>; Thu, 27 Aug 2020 08:07:55 -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 4210F3A0D55 for <sidrops@ietf.org>; Thu, 27 Aug 2020 08:07:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1598540874; bh=psrHXBF9aFDTiLVy6oBvG5NQYeOOkbqx8TWihTlRcKU=; h=Subject:From:To:References:Date:In-Reply-To:From:Subject; b=CjRk3MvLN8ipW+Fs8Go9V7Qra7KUcL+xVMzXhS22VI5knufYNFK1DKsWoDaKQeIRahoEG/Q0X8OTNXUti0I9+01xPX/VzJeLnmZG5kNvLaVdvjFw6yTnyI+ukqa75jEzMfO/iq0+HQ2acxLHBqejJITBIlMXOWWskgWwBj4QZH9kl8bZozXdpC9kC9D9bgb7YtbQU+xkpknppBi5WZ2zu3mKz6x1DUAtZNt09c58z7NGSAPdnQtYvCybnqHPhNotC6zLO8tY/lt0XPRTAhFygON1fMCkZtWXCIsMPdgxT3w2K3o+hwDFHuEMW00OsEiV0Ir5xGuwk60JopEhlPlX6w==
X-YMail-OSG: _ZOdvU0VM1kNOEJmc1z3dEiOKXSw4yWcUt9qr.tQt0ByN9THawh.XA8Sj9PeLnK fLW8RIoP3kURq2HniMddLrVxDCtMeigd.TojHGlJlKfjFiJ5yxiiglhu.lbjm7KJMMpVF2414qKa VhhoYq1Ywl.D9nbJjYPEGV9YqX5OnrsXxEFaOp9McPrmdOXkZfd0tx2CUyiV_zwRKgf_rzQQW1Wc DCt6KKUmcy0tNlwdb0vj5DhcS0z.fbhVCJjQodWbDhRQ0jJULH1yxwAvVQBk.kXH.bYhVonIguAg .EszNrTqHs8I7U4gcgr.vXC9grqyJu_OSvB81NbqI8qHm2_o7O2ydDQhXLLWz9JcXopzHB0nPBD2 G2oPNxGoifBm_FQNHX82kDmQd_v79y2iXiQvOOMctmxA7NZD1ozeQlpzqYExeREg.9p6DbvSs9aK M6U2VT8.5V7XeZOBhfiZxosMEx500xtRRrs_XJrJF9BW8qeMsyZ0Yd9xWloWpS1fA6yFYCesUgvj 6nIOZbhjiysLbvMtI_JrZTjBEU_QqbEwD4J5lpb11SnV9UF9Kr6EWYKzuUBmmrV4iF64C8AVtW1p WgQtBr624ZWLlFkKAFKUF3WHPn5yGRlt4GF6iz11MuSgDKDTQdeu2nWUdDyUt_7PhRP12ltS0sAt HSxt3BkJ7cIPMDaWr63DayXJCwm1aAdFSPJSNjroGnLcr_BW3ep3c5Gec1mO37mH6sjYzsKPpZ5K xzy7rGbOpBXNltz7LlvRzdZALzMpWTeNViY3otMJtgu43eE9BPecn8SFYAVyn47JMINSpUbntjWs ZJLJUcCQzPuYRuHvMk7Yr06GnolV0ecIkbVq6xNDFVcsj6ENQzUfBkNwhbJ6IBvICJdDTsIbGx3g 61MszWZZGC2M65BKJwzKLBL8OVoL1Tv36..h7r7_gvenNfZCYC_jbpWidjwUkgrQe0ipuHbJlY5o L3cApy7wcBWuBvceWU24ILiTANlztw.SGECmv9U98QeyJc58vZMJEgX.Ozvuw9rxBHtHR5hY6LcV 1CDrneRBL8WS_9RFETLuFXo7ZgNhOe2LgtjZ8pwvfp78NN5sQZR26RebRiI6v8tGN_RepgFQDYy2 uwj6JIaPftIjxfpLsP24bgh6Bg1oDHyV8sXl1gmTtVGfA1ek3NhOts0tV0Z4Lxs_x4VfAYr5Ch02 tC5a5dcjcPpYUaBVNClvEeBR3ktCxEKykLraJ6Dr599OAcsPW2g0iavtSKh7R9loL7omvq.1J.P0 exOI1MiA8BTkMMqLBA9UT0AGhCogJkZWan85g5xQ6dLDsAs.ssQu.mw8S.qpDjlpXpC5GkRCDlAA gP1fDV7NDwfO7lvQgAmxwzTGEDh3XmUGr2ZCjKDDb8E0TrejqBPyNmwAJtI7vLYIvj3MByaS_vk9 1oDGHw2l675ey6vxgLRUsffeBJxCKhH6JOmvIweQlhWaQIQl0T8yyn59eh2pgmYZyd3Ty4F.B1Hl B8WYIOvZukezZvgZm.ujSLyGBzAOmW4an273Ww04D4_mw5mHR65ztvi.GLol385gh8w--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Thu, 27 Aug 2020 15:07:54 +0000
Received: by smtp401.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ec463013e9f0de4b2ed1942291634c15; Thu, 27 Aug 2020 15:07:51 +0000 (UTC)
From: Stephen Kent <stkent@verizon.net>
To: sidrops@ietf.org
References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <c1a8fffb-9106-d08e-4254-44ddf1a0115a@verizon.net> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> <b71c9c88-fb10-b037-d06a-910711e51e04@verizon.net>
Message-ID: <cf7030be-adc4-dde4-7eda-516339fd6c91@verizon.net>
Date: Thu, 27 Aug 2020 11:07:50 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <b71c9c88-fb10-b037-d06a-910711e51e04@verizon.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.16455 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/nNv2n6Gwqr0EG8rjmwFOHFVmGzs>
Subject: Re: [Sidrops] 6486bis: Failed Fetches
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, 27 Aug 2020 15:07:57 -0000

Martin,
> ...
>>> "not update anymore" is not how I would state the result. This fetch
>>> will fail. Because a failed fetch will be reported to the RP
>>> operations staff, hopefully they will contact the cognizant entity
>>> for the pub point in question, causing the error to be fixed. Them a
>>> subsequent fetch can succeed.
>> That seems like an overly optimistic approach to the issue. Assume the
>> problem is created by a bug or, worse, design oversight in the CA
>> software. The turnaround from discovering the issue to deploying a fix
>> can easily be weeks with some vendors. During all that time, not only
>> can no ROAs be updated and may child CA certificates slowly expire, the
>> entire CA’s data will not be available at all for any newly deployed
>> relying parties. With containerised deployment, this is quite a serious
>> issue.
>>
>> As a consequence, this approach will make the routing system less
>> secure for, I’d like to argue, no actual gain.

When I the WG chairs tell me that I misunderstood the WG consensus re 
strict correctness then I will revisit this topic. However, the recent 
messages from Mikael and Job suggest that your perception of WG 
consensus is not accurate. This issue is one that needs to be decided by 
network operators, not by developers of RP software. I agree with the 
observations made by Mikael and Job, i.e., that requiring strict 
conformance with manifest rules is the preferred approach.


>>>> You could argue “Don’t do that, then” but this approach doesn’t make
>>>> the RPKI more robust but rather makes it break more easily on simple
>>>> oversights.
>>> My sense of the WG discussion was that the majority of  folks chose
>>> to prioritize correctness over robustness, and I made numerous
>>> changes to the text to reflect that.
>> I disagree with the blanket assessment that this approach makes RPKI more
>> correct. To switch to the example I should have used in the first place:
>> Ignoring a broken GBR object when producing a list of VRPs does not
>> make the list less correct. In fact, the opposite is true: Ignoring the
>> CA or updates to the CA because of a broken GBR makes this list less
>> correct.

I suspect we disagree on what constitutes "correct." A correctly 
functioning CA does not publish objects with bad signatures or format 
errors, use certs that have expired, does not fail to replace expired or 
stale objects, does not include objects at pub points that are not on 
the manifest, etc.

>
>>> ...
>> You absolutely have to deal with this issue in 6486bis in its current
>> strict form. Any introduction of a new object type will permanently
>> break CAs that use these objects when validated with a relying party
>> software that is not aware of this type. I don’t think this is
>> acceptable, as it effectively blocks the introduction of new types
>> pretty much forever.

No, it does not. What I suggested is that when a new object is proposed, 
it is the responsibility of the those proposing the new object to 
explain how it will be incrementally deployed. That explanation belongs 
in the RFC defining the new object, and in an updated version of 6486 
will need to be generated. We have no good examples of new objects that 
provide a basis for describing how to accommodate incremental 
deployment, and thus no basis for defining such mechanisms at this time. 
It might be the case that a new object will be defined that requires the 
CA to maintain a separate pub point using some newly-defined SIA 
pointer, indicting that the new pub point contains the new object and 
thus RPs that don't know how to process the object MUST NOT follow that 
pointer. There will need to be agreement on how long a CA MUST maintain 
the old pub point, etc. But, absent a concrete example of a new object 
type that warrants this sort of effort it is premature to write a spec.


>>> Instead I believe it
>>> makes sense for any new object proposed for inclusion in the RPKI
>>> repository system to address this question as part of its
>>> documentation; it's not clear that a uniform approach is appropriate,
>>> i.e., one size may not fit all. 6486 can be updated to reflect the
>>> processing approach proposed for any new objects.
>> It seems to me that the best approach is to simply ignore unknown
>> objects. We could argue whether they can be ignored completely or
>> whether one should at least check their manifest hash. Personally, I
>> think completely ignoring is the better approach as I don’t see any
>> benefit in rejecting a CA because someone swapped out an object I don’t
>> care about.
>
>
In X.509 certs we mark extensions as critical, or not. An extension 
marked as critical will cause a cert to be rejected by an RP that does 
not know how to process that extension. One might revise the generic 
signed object definition (RFC 6488)  introduce a similar flag. But, 
first, we would have to figure out how to incrementally deploy the new 
signed object format, with a new version number, etc. I hope you see why 
this approach to incremental deployment of new object types probably 
would entail more that a revision of 6486.


>> Ultimately, I feel we’ve swung the pendulum way too far to the other
>> side. The RPKI isn’t a single data set that needs to synchronized in
>> full but it consists of multiple data sets that can be treated as
>> independent: currently these are VRPs, router keys, and GBRs. If I use
>> the RPKI for route origin validation, I don’t need to synchronize the
>> router keys or GBRs. Why does it improve route origin validation if
>> available and correctly signed data is skipped because of issues with
>> irrelevant data?

The RPKI was designed to support origin validation first, and BGPsec 
second. The set of objects that were defined are intended to support 
these two functions. If the WG decides to extend the set of supported 
functions it needs to take a hard look at a wide range of RFCs that will 
be affected, not just 6486.

Steve