Re: [Sidrops] 6486bis: Failed Fetches

Stephen Kent <stkent@verizon.net> Sat, 05 September 2020 18:14 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 A54E63A0AF5 for <sidrops@ietfa.amsl.com>; Sat, 5 Sep 2020 11:14:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.048
X-Spam-Level:
X-Spam-Status: No, score=-3.048 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, 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 avNbmyx60MYD for <sidrops@ietfa.amsl.com>; Sat, 5 Sep 2020 11:14: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 02F463A09C0 for <sidrops@ietf.org>; Sat, 5 Sep 2020 11:14:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1599329687; bh=RTRJAkdTG8Jja342KVk6egAtoiB+HZ/MD1XPVQc9eag=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=QBZgxkuXVHwwfjhYbCm7T4dsW4aAwsjFIPU61c31C5U8WgOSfOblhYPJ74gEBVNP0QICqzqCvHdIlT+lvs8ky/5bZvKrXgsE0lAfq8I1QC+WTg6RMat4AYHeh5T0uO5QTECiSdN9OXbJSAtND4DhLm4iYDW8aNafJuChmnrCwJWWvH9A2p62SIZofJAQMC8VtA+NOEby5H9XES3qlZhDZsfMA/voXFPKIKq6BTYWYcFsKy/5K0f790GE8m3m1jZS91IokGOvBaQ1m6GNUi+qvXbnDxFqgdQB7W6Oi3i6uzPNhXb4tQNI244p1WNiRTl/vuZ6pSyDH7z50MFqktyilg==
X-YMail-OSG: Sm9RiUoVM1lzc_jnMiPnJRBo9d1LWAZ7yCsnEEeB5QobZ0r3SWMcnMUSBmilGxy yTyv6RIrguEeLydPJK64VSf2BvDBA7bK6j7qxyMBmfwiiRSBHydnBp4JAA8RpQjJPid3zo_8i4H7 GpmjMh5ref53PGna87kuj_paIFw0ORfaCgZ0x95rkGBYZMLQ0S1vTo49UZOrCUdMg13UhmBbyA.d AnvKgwUtGREaGl5V8EhcUBTl98IQL13UO25mH2ITtlgewaSAkOGQqmb_uXd6lqPOb83tRCPLi7Zy gjgjXJ3qAsw.xO_AHcnW1_C0evia0tK5RDuP2JDvWBzrpc92KwS6uU6w5pWLlpVYC4sw9SzEu36r 08J24URQ_pGdVuEcu0piESs_wdXTCaiRXM1KfQuFhNmP9Y.rSGQtXDOC5fMm7dKhAiyFZ6TIlmOa Q1nzHs5q_zglqVib5FRSgmrRQ..kadDDLB5HAOAZ8Cp01IsHICBYqtW6OmwqpTSr2UK4hKG9VRJe 9UqJW9f4z8A01N1FMqfSDDm_9LNAAPcd1R_DQEPScHOhPpmrE9UdIl2dlJf3HB_60J3FYyvlfW50 bOrF8zKrq38ZRQ2okvg8RwsHent7ZoMmrZdMFrdpd1TsaKerdP8yLXqQfh.to8Ue65.eWzI0E.De qJDJETHsKL.0AxXZ97Di9UItoKxj1RwRlPxNvMTF6WEX6c_02ey..U9PZxcSsQHv.v1Q6EYShMWy VRgGy1oqBHZdiRJXXKHOuOP3Am2e7Fw.juGMYsZh5Zx_maSLC6txhR25z3KBiXychUTXKfNjHPJN WPbsBLqI4m_ThfOI7sJEOomhzawp62tuPbGg78c7fFvQPbGhivOn5HpM0AQg2fz4MKALeumkh9gL SMnVcciWxsVUUlJVTtO5ItWHnHfxUDRqLZeCrgcEKw683EEKV0FUDmPYpRtSZNB_SITYE4vGskJD oIvigry0qy4Xb.jdZLy6quYsn9iYfctuPfOvYztPIJQuvtSIrdTcV6igzn_J1bq5dROmkzc6wkYb _PmHpgZwWTprG7K7UV0cCYTgRLHGkUesMqH2cNsXjp7jNj7kG0VpV3vwLMx1EEyNDgAUPhaO03yv cmgFspMTAaGdrU_0ojZ4bcocMATan1Howy0UnBmgQJXT2oSBzqs2IhIthkwsE9beCgs8masE51P. _1BSHZuiUB8xu.vsljYAIjiYXXrNDdVpTIahWjXmTDfTumiz8o9W6b9OkuWUXfkSTWSAQRLOzno. 6UXQMxMUMkiTrZ8F3V9G4Y0solgQBNPvEUex86WRgCsAI0_6Z_F1f81IPSPLnQp2VnnGeIiItApr wvtsZmzAxBDBdRd4.6SQeynYq9Vi4NkMejsC1redHfIBz868YlOfJePRQhySRC_FNwShJqqPgPyN .mRailSCnBM93HqrWgzW_JpU7aelXrZk4mSCLKYZLdFC5bJtaq_AgA0a2zKgjJZk0s3TJMB1IZM. Oxgn9x_AUKolSnb2yIcLaXxLhv4udf7iI4v2OsTN9sxDUP_UsoJJAxhc8Sq61CqU-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Sat, 5 Sep 2020 18:14:47 +0000
Received: by smtp416.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b8f46c5335deea40084dc6c9857bc4a2; Sat, 05 Sep 2020 18:14:45 +0000 (UTC)
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> <cf7030be-adc4-dde4-7eda-516339fd6c91@verizon.net> <24393.25181.84151.476185@oz.mt.att.com> <4d77e33d-25bb-03a7-7a7e-1535bb2e1f18@verizon.net> <24399.58769.547600.368430@oz.mt.att.com> <8AAB93F3-6024-438E-9A32-5AE583A51C06@nlnetlabs.nl>
From: Stephen Kent <stkent@verizon.net>
Message-ID: <db88c706-5885-d16a-3dcb-54b8e5733283@verizon.net>
Date: Sat, 5 Sep 2020 14:14:44 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <8AAB93F3-6024-438E-9A32-5AE583A51C06@nlnetlabs.nl>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Mailer: WebService/1.1.16565 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/LccQk3OrjO-kEXKEs2IWvbG9pes>
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: Sat, 05 Sep 2020 18:14:52 -0000

Tim,
> Hi,
>
>> On 2 Sep 2020, at 20:33, Jay Borkenhagen <jayb@braeburn.org> wrote:
>>
>> Steve,
>>
>> Stephen Kent writes:
>>> The crux of the issue is whether it is preferable to reject all objects
>>> at a pub point if an error is detected (until the error is rectified),
>>> and thus potentially treat many more routes as having an unknown
>>> verification status, or to accept bits and pieces of data from a pub
>>> point with the potential that some routes will be treated as valid, even
>>> if they are invalid. To me, that is a value judgement to be made by
>>> network operators, not by developers of RP software. [...]
>> No, there is a bit more to it than that.
>>
>> I want my network's routers and those of all other networks to be fed
>> with VRPs that represent all the verified and legitimate published
>> origin-ASN intentions of verified, legitimate IP number resource
>> holders.
>>
>> Clearly the challenge there is in determining "verified" and
>> "legitimate."  In creating the rules (to be documented in
>> standards-track RFCs) for those determinations, I would like the input
>> of all SIDROPS participants to be valued, including the input of the
>> RPKI designers, the CA- and RP-implementers, the RIRs, and the network
>> operators.
>>
>> To my point: if RP-implementers feel that the "bits and pieces of
>> data" (to use your words) should be considered to best make those
>> determinations, such input should be welcomed; conversely, if
>> RP-implementers feel that strict publication rules and accompanying
>> strict handling of retrieved records together create the best way to
>> make those determinations, we all should listen to what they have to
>> say.
> I don't think it's entirely fair to say that us 'developers' are willing to create security issues for network operators.
>
> This document is still under discussion, and there simply are still cases that are not fully discussed, e.g. how to filter VRPs if a publication point is found to be bad - to which I posted a suggestion only last week. I thought that discussion phases were meant for that. To look at things from different angles. I am quite certain though that consensus can be reached if we have constructive talks, and that implementation can follow quickly when it does.
Sure.
> To the point of "bits and pieces". Rejecting a full publication point is the easiest to reason about, so I can see its appeal. That said, consider the case where a ROA is invalid because it contains a prefix no longer held by the CA. Instead of rejecting the complete PP for a CA certificate, and filtering out all VRPs overlapping the resources on it, one could also reject all the invalid ROAs and only filter out VRPs that have any overlap with those ROAs. I understand this is a bit more elaborate, but not dramatically different. As far as I can tell it is just as secure in that this cannot result in RPKI invalid announcements because of a single invalid ROA object.
>
> Note that I talk about ROA objects that can be fetched, and are known to be current. I.e. the actual manifest content. And provided they can be parsed and validated so you know which resources are affected. If any objects are missing or obsolete then assume the worst - I actually made statements to that effect months ago.
>
> In any case, I can live with the reject-all model for its simplicity. But I would like to hear an operator input on whether this is indeed desirable. And that the consequence of child CAs - even NIR sized ones - blinking out for a few hours every now and then is an acceptable price for this simplicity.

In revising 6486 I iterated through several versions, and received 
feedback that the less strict versions were not consistent with the 
perceived) WG consensus. That's how we arrived at the current version of 
the document. Simplicity is certainly a virtue wrt security, so more 
"elaborate" approaches to RP processing of repository data do concern 
me. Also, if a lot of RP software is having a hard time implementing the 
current set of validation procedures correctly, adding more complexity 
seems like a bad idea.

Steve