Re: [Sidrops] Interim Meeting Follow-up Mail

Stephen Kent <stkent@verizon.net> Fri, 23 October 2020 15:33 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 851BC3A0EF8 for <sidrops@ietfa.amsl.com>; Fri, 23 Oct 2020 08:33:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.348
X-Spam-Level:
X-Spam-Status: No, score=-2.348 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.247, 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 B0U1pDNm2oxg for <sidrops@ietfa.amsl.com>; Fri, 23 Oct 2020 08:33:34 -0700 (PDT)
Received: from sonic307-2.consmr.mail.bf2.yahoo.com (sonic307-2.consmr.mail.bf2.yahoo.com [74.6.134.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 D5BD23A0EF9 for <sidrops@ietf.org>; Fri, 23 Oct 2020 08:33:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1603467213; bh=KqXy/Qtu38FJawN0WI3nhqAZ4unyy99Ugk58cRU14gg=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=MIwShpkXMGRTRqBKkNc0BNS4wMKUid752fqIUha47nxjBdfPtxNRr64epRdUXyRA8Cn66OWPM5let7CVypLu/0UjMOQttyVRH5NkqlQiijudbuKBIt92O/jB/rBRnYlqd9ZdrELsqvRghDK9cDf7qUZK6fLKGoU576/mgMjlfiQP28s/SqhRaXM1Og2oEW9Ps4FpHZWQA4SA6YRzKG0CuofwEXxlYgPiiY92CK3Xz3Q4njInxnFb8hmeBhuQohQBC5sOzpI0Erh+OxXneCA3ltlr5Ltcd2Vr0G+pwsHxs5XvHWf8smWwA59R7Lqs2huSyyjkxNxRIyy0TNPfDzVs8Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1603467213; bh=6JdkLGbSvCwpk/Jg3sxzPnzsFpLEC8zbW+NwnkCxFtO=; h=Subject:To:From:Date; b=CU4Ht70n5C12was+4dh/TM64HlJy82d7Uqj7fcuXgrbUklCZtjAoaESxAFLfZDfZe/iQ4FQhNaC9gMjl6u1M8JDfUYobhBgqXVMimGvbKj+PAm8jU5GrKl2eiGc+ymc2sqSo+Dc6hlJLW3NuodtXuc+oPFQ6CeEv4oKDZ4qLJUsz+5LeK8hMRiYfcb94wRxF2cSu8pEmEdfnaBuZMXSTIBGiL29PySLybJol9FhatMdGK9Ms7UCOdj11GBS/QhU29fFsCnTo9M2yuRfu5/kBGu7WIcRG75IkTHtCL/DnvgqbpivyFQ6e5sfotEkDziCRzYRRKlSsP43ZWLXCChlapw==
X-YMail-OSG: Rbq2HwkVM1kqRRuQvzZFRxwZM9OP14x6avTWrVz0wFtlQZiiqWWwB4ooxI8lFhE JDQL.KmSORHaW2El_7NfHhJqQASq.8eVOOKzc_pCvRZmV8ZHdaceW3AOOXYoMN0KuY6Z5UvRLjPS SeXIm8BK98E_cE3iRjBQzBtL0MVJK47wmQq3X1PiuLxidLLnyu.iElflVOJwozE3nG88XBO_pE0C nIP5fKmvfqeI6zXPX4AQoX.Q80XFZDuvGyoywIZIsgsPQh8rDpiGEqLKihnq4g7uE1YL8SK_7buG 4ERHI0kmiCb19_ZCKOvjtEQNgAQ9ZvLOHRD8LJacZrCLwiQakHKGx0r59zDBuLw8mC5t4qCkGZ82 1lkcM7.8uzf0_oKE6QHEFptAjqbbZsxSErz6ekC7BK6B0PQTAK_2fBtRQ0PuBUb8EO0VydrW03pY IFJ57DTehAEBk5t1AAh6B7iICDA6xlQbNg3WjoIjV53Rox.__jyZeatd8ZERXuHqgZdPnFz2vPsE oc.ZF_Us1RdG28FSxc12kga9acxYeX669EdkUxQsnHGo.DADdzo1gYZblPgXm_OaCLzyY1T31LtM cVZu_q0gsJJmi_goP1KX89HDS3mBeCSiccvlFCeIjnusLdQjog1I167_AzaB.AP_2Hp.XGJoHBj. zY6sQ1ueXMlUmGlorgLb9MjuCFEwItVBzOGXiFt7yyuiNkVENEmRx08AugwirBj5Pg8AjDnqhZir 6An2x6yQm81d8D3ji4hhJlQl9MHZELYwdivVEMUJbnrCt76R8Vsge5JQkPJlFIyr4lvtimsE5ZT_ Xkd56GqIX2Ojc7eAMwcQ5mDFDbXtW4LwdsTsMN23590XzAVzp0ZImTmDoooXWeZPB2Gm.JZ8GLsK b2JlR0.u1JZqSw_h5B7C0Ry22pwb.spmM_TZAS_9fjG6dwtmJ..5iIemy_ZvSZ6CS3ploz_vUTfo FMaBo9_Q5RYEtc5k30lVX0jfNnvM0iqXsMWofpuZCWF8SOZbmSsZD3ILwQ9ISCy5BzGsL029HqYt FeNry2OUmR5HbXjfqYFpZsIh0a9TSPgqftWX.pgiW2c1eqGCr7XxUcepVdM5b.A.6sr0Ve1qsuDI lFIvuWIi4LTE6n8KM8vWop5.E576qg4JvlbO_5ZPxiw_Vrha7HVVO8Pm8J.E0LScE0DbcK9xRbHS wWoz_bd.FkJNwEUagj9UKCuYIGa0wzEk4n.HVXe9PFSSiwOnof1aIQja4eJCBQ6KskYwJQINKZsn waMLWhOdiFpF2GJkVns2L4ThGEEncEtHvVjAO8XVkODFBhE5B.etpYsuVlF6vUiaARM0bRvwqk5y uGpQzUKHHIDxiFX5H_qn13BniGuNUR62MKDMc3x.pQiSFstH3xWfZKcuUJ4CgpXcEET.Sm6mkxTM Oimh91CYZJARyzMYfcAcbzSBiXC01W0k1s768j.R2PbB9Nmu_Gf_XdVyurjby7ZRIE.TTgPjhLyP iFTeRo5Tu8cqyzNC3HWhoOF26KDPKLSw2MX0lDV94_iaZYl0iV1gEzE3cb1J1qFMokpNG8R7.MAA tQrlZqNbEtInGo74ZUsBjwhbqsVZAZAQTWFGJbriAbagYRxZLDz.7LaDIyOLdlKz7EyepjUixfc9 7oSeFPNzY8ZBmu8KpQocZVgyhFNXJWmZ54seYxhM6E9cX1d46Ebt7JF27IwSAzWA.VqxNTt2Cu1. bW9n4RJiX4tIMhEaoptPUX6cDfalg6NvoRyRgHf7qak9gSXlY6bopidGYQcOlaCc9eDjJZatoyit Bry0QLoxLq3ZRDcz_yP3Ucsi8kY6eXfzpAMqcphCiBWhuGp9efLsJi.zrD6YNnbCQgPl72GTG2N0 46eEtTVZ7JylPTbHxc2FEMpt_LfNeAqMQRfXSxaKmAJ3NLvyG1X3kDlKpa_kUMKGEDfqcQiBcxRB l3KMUUEtetZOzfb3rDKMdXfq49ElPp12mewjs3KS7qdlBan3eMpSXa.8JZwZub7Q7WPXxSTcrqSG MkjEhRqiDef9ArUeFyboQJ1BKVAvX0arXEOSihNjTxHRMWKGEsahY_Wp.Wpj8e7hb5JjvaB0zxxy 2Z.Bdo.30rE2rOzj74fbJaqkKj0_Ut6NtT1tOPBro7gPdhmCWPDj5atDxDUgYLXDtA6YcBkAd0gl UnfaRhIeG7efaEzLEYKPYyx9.U3GjiWMjj6WZ5SwHQxt.eRHBTI7WrHF3ii2er7fXL2igDpcr8Cl hl4SScrxq7b54oqszc1VlPHNfCMMHnt74D3gDniKU5SQuVpQVst8fxJ20IigXMnMN2zD51ALKhq2 VP53Ail1PdzzHbiexDRxDfTja9PqzcxtJPZ6ZLDKGfEln8iCnNzcuWudarGx1qI5KqNtvnKXWiQS R2ZohveaWj0ag.CN_L27DG3233jixj63j0fhxLbm_ZnamKmFD0e3kxu0PBgmtRDMA2hMU8CLM4cL 6ePX8fKCJqucjsKAMW7wCUKI9fA1FzbzCgzq8Pnmzq2GRlSS8hTKkcQlX9x1k5wGQ_dMwfiusQk6 zo816Xss3dNA9CxPT_Br7gJUtDu83_uFC8J8PRLhhfyRmyVeWQS7PUvdPbWmKaf4P2nwQuKD9Fq0 ngbI39TxXPPOt.2_Vp614wimtPoIIkJzAy5AcQvPCpT4SIK7xO7wMCZAifzrZDaa75QqTf2A-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Fri, 23 Oct 2020 15:33:33 +0000
Received: by smtp416.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b966781a900a0b896fc38d4090b4095f; Fri, 23 Oct 2020 15:33:30 +0000 (UTC)
To: sidrops@ietf.org
References: <87zh4ekvz9.wl-morrowc@ops-netman.net> <5660E325-98A9-4A3F-A009-BD13A5C62A47@nlnetlabs.nl>
From: Stephen Kent <stkent@verizon.net>
Message-ID: <06995a21-7cc8-1182-0472-00105ac7dd6d@verizon.net>
Date: Fri, 23 Oct 2020 11:33:27 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <5660E325-98A9-4A3F-A009-BD13A5C62A47@nlnetlabs.nl>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.16868 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/xo3gHl_S2StRyvRCv9XtR1WaD5g>
Subject: Re: [Sidrops] Interim Meeting Follow-up Mail
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, 23 Oct 2020 15:33:36 -0000

Tim,
> ...
> I pointed out there is a failure scenario that cannot be avoided, where a child CA produces delegated CA certificates or ROAs containing over-claims, i.e. referencing resources not on its own CA certificate as currently published by its parent.
>
> As a child CA using RFC 6492 (provisioning) I learn entitlements from my parent (section 3.3.2), but the response lacks the context to know:
> - when a current resource will disappear
> - when a new resource will be safe to use, ie. when my *parent* published my certificate, and it's picked up by RPs
>
> I am happy to try discuss preventing over-claims as a separate issue, but in the context of this document I believe we should assume that they will happen.
>
> This means that CAs will be temporarily rejected at times. This includes the case where an RIR (eg Lacnic), issues a certificate with extra resources to an NIR (eg nic.br), and the NIR issues and publishes a delegated certificate to one of its members, before the extended certificate is published by the RIR.
>
> FWIW, for the time being I can build a safeguard into the next version of Krill to refrain from using new resources for some time, but any time chosen is of course arbitrary.
>
> I think there are two options here:
>
> 1) accept that CAs will be temporarily rejected, even NIR level CAs
> 2) make an exception for overclaiming, but otherwise valid, objects
>
> I can see how #2 would be hard to swallow for some, but then at least consciously accept and acknowledge that #1 will happen, and it's not the rejected CA's fault.
>
Why should a parent push a new cert to a child without waiting a 
suitable interval to allow RPs to learn of changes? Such behavior seems 
a bit careless by the parent.
> ...
> The bottom line is that one might want to filter out VRPs for the resources on the CA certificate for the child CA. Except in cases where the child has *all* resources (e.g. it is the online CA under a TA), because then this could invalidate all objects in the RPKI.
>
> Two options wrt VRP filtering:
> 1) Doing this adds complexity, and possibly brittleness in software as a result.
> 2) Not doing this means the WG must accept that the landing is not always soft, and may result in brittleness in routing. A child CA can end up with invalid routes.
>
> To me the most important question is how routing security is best served, by #1 or #2. I can live with either choice, as long as it's consciously accepted and acknowledged.
VRP filtering seems to add considerable complexity. If CAs can't manage 
to do a better job when changing resource allocations, why should we 
expect the RP side of  a child CA to do the right thing re filtering?
>
> Observe the word 'valid' in this sentence in section 6.7 (Failed Fetches):
>
>     "or does not acquire current valid instances of all of the objects enumerated"
>
> As written this implies that unknown object types are not considered valid, and therefore RPs MUST reject *all* objects for a CA if they are encountered.
>
> This means that new object types can only be published safely when, some arbitrary value of, enough RPs have been upgraded to support it. And even then those operators who did not upgrade will be left behind. By this (arbitrary) time the burden may be on them, rather than the publishing CA.
>
> I, and some others I believe, suggested that unknown objects could be considered 'valid' in this context if they are present and match the hash in the manifest (i.e. the PP is complete and unaltered). One could even go further, and as long as the new object is a form of RPKI signed object (RFC6488) one could validate the outer object, but not its content.
Your suggestion would avoid the problem you describe, but it also means 
that publishers of such objects have no idea whether any RPs know what 
to do with them. Is the plan to allow publication of arbitrary new 
objects (so long as the outer wrapping meets the 6488 syntax), and to 
address the transition to use of new objects in the RFCs that define the 
semantics of those objects?
> ...
>
> PROPOSED:
>     Processing of the signed objects associated with the CA instance MUST
>     be considered as failed for this etch cycle, if:
>
>     o current instances of objects matching the names and hashes in a
>       current valid manifest could not be retreived
>     o any current object for a supported object type is considered
>       invalid
>     o any current object, of an unknown object type, which is found to
>       be a form of an RPKI Signed Object, fails the validation outlined
>       in section 3 of RFC 6488, with the exception that further validation
>       of the eContent (section 2.1.3.2) is not performed.

I find the wording above very confusing; the term "supported" is not 
defined, and  the last bullet is very, very convoluted, ...

How about:

    Processing of the signed objects associated with the CA instance MUST
    be considered as failed for this etch cycle, if

    o current instances of all the objects matching the names and hashes in a
      current valid manifest could not be retrieved
    o any of the retrieved objects fails the Signed Object validation process
      described in Section 3 of RFC 6488
    o any retrieved object, of a type that the RP is prepared to process,
      fails validation of the eContent as described in Section 2.1.3.2 above

> This would allow for new objects to be introduced, without causing existing - not updated - RPs to reject the publication point altogether. I believe that this is safe as long as a new type is orthogonal in its semantics to existing types - and it does not change their meaning. For example: ASPA objects do not change how ROAs work or should be validated.
I agree that new objects that are independent of semantics of existing 
object types could be tolerated under these revised processing rules.
> If new objects are not safe in this way, eg imagine that ASPA objects would change the meaning of ROAs, then we could just introduce two new object types instead: ASPA and ROAv2. CAs which would choose to do ASPA then, could just publish ASPA and ROAv2 objects and stop doing ROAs(v1).

Easily said, in a casual fashion, but if one examines the transition 
processes already defined for alg transition etc., this will entail a 
complex description. Still, I suspect your principal goal is allowing 
near-term publication of ASPA objects, without having to deal with 
description of a transition process, so for that concern the revised 
Manifest processing changes would suffice.

Steve