IETF Logo Mail Archive

Re: [Sidrops] trying to limit RP processing variability

Stephen Kent <stkent@verizon.net> Thu, 16 April 2020 14:54 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 0D9423A0AB9 for <sidrops@ietfa.amsl.com>; Thu, 16 Apr 2020 07:54:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 z0FsIX3m1yi9 for <sidrops@ietfa.amsl.com>; Thu, 16 Apr 2020 07:54:39 -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 0EC053A0AA8 for <sidrops@ietf.org>; Thu, 16 Apr 2020 07:54:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1587048877; bh=VOEq5CzpYJGQL0PvviGarHcJg84GaLa0XMENtJlB0s4=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From:Subject; b=W/sYn2G9wKQ0albkc5JUR+NYWASX8TCFqbw4fhDJmAhNxVhRFQ2WrrCUOhfyCn1ASL2wYveqiDDu9vwbZ0kb+FIek/oYlTBjPfNxcIBn0cxNB0g0MCyJiw72LMl04YEzsPRRsasgMOHs39UDthpteNfJ8OfDKMTVAmTvgSgM6mef+BzC0ODagnRUAk+cu0hK9PtbaNT/lGmDUOgqiGNUUUkEuI60uljS7DiXAQQIrDGTPixLcy37mQePW/Nbo+Jc4XLpm+vC3UYA7Gvuo73IUo4yeVUS56FJ89VEq8uxZpsddT5POxEMLAwY/O/UxvFaIK8VNCtQbhBmCYLRaN19NA==
X-YMail-OSG: 0eIMZDoVM1kO0GYYWZmmY4TuqpW3Fz.gqnTaQHDk0vkuu9fYkrCyjOQ_V4uFYaX N.VFrKGFydiOjGIoRD.63b22vG6Bw6by84KhIK0JLCyXTEup5MBaOm9fG9HERLCzq9EA7KbHZoVJ FEBmcHPo23vAMU2GrMMiskHiXdHsmJVcFrYd9OMiImpk5ArqYrry6CG5UWU8EiB0gQjmGYog2AQj mbZP7pUhazCcG2aY9FsQkKUw525lXf1uOUmb99SzAKQw.jw58OSKExXkcTLxMZEuT.gFCOb1OrPo ZKPxAo8ZgwfD.deZ_smrwhELm0Vkbv3zRlsKOBkSBunzyZAdvJT66s0HDKExVcAGOyvhOhB0CoUO .ERTSmsswJ3rnFpk2OSkiE7xyMYGZh3Mrtlenvw.xxLkyWahPL3BZ2nWKawPiAxnm9z4EAeqg.ms .KGGbBsruoHlGUedFP451uTgCwBv.lPNrgNZ_H14PVm.deSByD4KPy7iN04tuE.vpE05D1cC8uxl ZzuyHIx4EKHCrUrTC5En_dIHVinNn8fy29QzjXqPZFSirgdmMmc3ncfixqdlZOzJViov9w4ZghJR xwlOLkMPt4aVW10.2xN2txPsc3cbxqQQQYJUjPrImXjqrNkl1DYzpFamkMQNO.oQ_lxFUR7Iad9. RkVng3OJeb_GBvDzGklEZkvo1925.Z4fJ.zT8SHnGOElFQNe_.Zhpc4VBF7pwKC.No9yo195JkkE whc9lOHCN_4AnxZUUHjCSRz2b4vE5QP7c80eF_tPVu0Q2MIl4BsDDK5M8_Q1AoleoB_E3e7KB4m2 QXpqJ6AUk4FIOccbujfY8FwiSqYSviDNndj8jjTeZzIHv9G.Z.yJarZWcxmLA5iavBiOeDE4BYPa SubzFHjLQ88rDmE622FRXkwIEggZHzvndpyzuI.deYCgmJVllOQykSiGu2meV3RR.tlukhizFgcW 0STE2eXSYjalnatNhIoZaPrdQT6dnSkVE4bNyKm61O1L5EALbUDJSGKFXedo2YXSEFozISvyBDal mYBedhQV_uoYmZZyNWwHcqOIKVh3gCE.r77EWQAoQ.CRiw17L8K_NweUrSOQwO5.yc6CsXxNK9pb WQmAvd32JQzGq13dc7XWai99vYG9zL6DhXEYTAEAGwZC_NKMfo9gQbHGu.ePt_Ch14WDSH4XFTfs Ixsa25CsVaTVcDriI_4Ap8ZAmntabE2JtuCJzOiRe6VNJLjKH7l.h88m8DvmuiZhdoCBxmqm7EGb YBJHi1ScpzztflcqpR1KygWr57tspQPOPDBgEkPCoPpAT.JCuLTW96PLcFSJdO_uC.x2AtErwI0T wzAO4CTMirQRYuxSNRbal8SzqLJetAdsaR3jW28.Y09fIQFbM3MDm8DMurWHLVMm.YiXmWT5542E NfEBjfdWvMBuWfJORsts2sULSiekKdDDmJ4HHqKTn
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Thu, 16 Apr 2020 14:54:37 +0000
Received: by smtp421.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e2352f31449a835a48f7c6f050b48a31; Thu, 16 Apr 2020 14:54:35 +0000 (UTC)
From: Stephen Kent <stkent@verizon.net>
To: Claudio Jeker <cjeker@diehard.n-r-g.com>, Martin Hoffmann <martin@opennetlabs.com>
Cc: Job Snijders <job@ntt.net>, "sidrops@ietf.org" <sidrops@ietf.org>
References: <a9448e54-320f-300c-d4f9-d01aca2b6ef4.ref@verizon.net> <a9448e54-320f-300c-d4f9-d01aca2b6ef4@verizon.net> <20200415150141.016d021d@glaurung.nlnetlabs.nl> <20200415140012.GB30412@vurt.meerval.net> <20200415161415.29c49f4e@glaurung.nlnetlabs.nl> <20200415143321.GM72650@diehard.n-r-g.com>
Message-ID: <9d7a9500-2ff8-e9d2-f3a5-89eeaa4a90e8@verizon.net>
Date: Thu, 16 Apr 2020 10:54:34 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200415143321.GM72650@diehard.n-r-g.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.15651 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/eWAZHZj5vDlhOgev486I7OyGuU4>
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: Thu, 16 Apr 2020 14:54:44 -0000

Claudio,
> ...
>> In all cases. Since it is ignored, it doesn’t really matter whether it
>> is good or bad or ugly.
>>
>> I suppose I would go with "SHOULD be ignored" here.
> Which CRL are we talking about? The ones listed in the manifest or the one
> referenced by the manifest certificate?
> I agree that the CRL for manifests is ignored mainly because of the chicken
> and egg situation (the manifest holds the CRL fileAndHash which is uses by
> the manifest itself).

See my earlier comment that I believe there really is not a chicken and 
egg problem here re CRLs. I don't see any indication in 6486 that the 
CRLDP in an EE cert for a manifest is different from that of the EE 
certs appearing in ROAs.

> For CRL listed in manifests I think the situation is different. If a CRL,
> ROA or CERT in a manifest is missing then the manifest must be considered
> invalid and everything under it ignored. This is so that missing ROA would
> not suddenly result in RPKI invalid routes because only part of a set was
> processed.

Could you elaborate on this last comment?

Thanks,

Steve

v2.23.0 | Report a Bug | By Email