Re: [Sidrops] trying to limit RP processing variability

Stephen Kent <stkent@verizon.net> Thu, 16 April 2020 17:44 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 342563A09B4 for <sidrops@ietfa.amsl.com>; Thu, 16 Apr 2020 10:44:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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] 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 k3aFf5rawcwy for <sidrops@ietfa.amsl.com>; Thu, 16 Apr 2020 10:43:58 -0700 (PDT)
Received: from sonic301-3.consmr.mail.bf2.yahoo.com (sonic301-3.consmr.mail.bf2.yahoo.com [74.6.129.42]) (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 7C8B93A09F5 for <sidrops@ietf.org>; Thu, 16 Apr 2020 10:43:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1587059037; bh=Qp1FCa5txJSZAvn8KdpoMMjAUFgpCwnZWBEmnkx4Rmw=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From:Subject; b=bsJSSki8wPHVy4VdL1eoFaXsfZHKk5Bnr7nSKlEgxbpWGp/JVnuzbAQEsIiCMY//8KSISI1PUgcLWDiZHdNpZ/mu1PMRrVUzNGhetHmr8BYxOH9k1DADO9nPP2wI19dg8OxmHBqWHVYjleFdxhNIOi0t2q3sEhc70e/LmMb4KNgrR6SXE7TyOSANkRYHfQlkp6rT6rKQUWE/SxmCZNvaQijNC6GuTTzkRYCfB6M0YM7oOITkN54FBE9lNEGMxGkQwxS9bdpJoSjOjjljLitEGksSgz1Gy1vY+Dk0XFSOR5FqAyIte9X8BBy1hW/R6fHvNFtm4GYLdT0yiYQhZvglSg==
X-YMail-OSG: ZgvsgPIVM1n2n9pd9dCYD04VCgZz6_m32gN.Ld66.niT2L2nn08ZhLFxV3XG4xP KfX2TnS8LVK8jbFaSt150dG4xJn.Z903RSGOr6NP3xb6Xd2lV_iQiIN6hrZNsJQ2dJBIVFL73pVq 9lsLJeGrk.7a5RSGoUi6uDdXIFX6PL1L6zoI9UG50_7buEISuNXK0awK6nIASWnR8kno034TxkaR 1KrosqDYSuEsbQRtAKfXO_eoLW7oQi._fVPkNprBLATNZJe2yfDTu1h7HMie58IMeFfPDM6AMoG7 7EZXcT34dwu6ZfGy04S2cVjmQQFVfNcDX0mpuvsV8j7aryVX0iqqk3RCJfIEUjQX_5old29237eN pQnq0U..6g5ZsGJSWfFy1rBW72Cx9DFOipQ8wyTqfR3CjigwhU9QdVReflLo9HPqpoUIOKnq6O4I ak5kyiyjq4.YFxJOIAFZnr7HuK6.qvOt45qqHYdMs40_1SxMWWNymrYowfz_RegK1v0baV2PSUU. 6h8qEkxzBaW_IC5RhMBozO4.IRzxD54O85J_tDJQzKyxYlY2GFq.jvbPhZUpSAoj9NVoqcRASoqI d7wAzcKJED7y.AuWHe3SnTpiWlIouuodqHf5P8GccnOO7x8CC5v01u_RmL.FJPBbfPkXEA6QYR6b NDZJwxaMSWiZsPN6u49jmpl6gzUGQ7XJqRMHjZSOHxNYquW7JC1n8KFIti1KQRCkga5KmqEjuj.K m3WhUnqKrMixRKocJ.zcFwMsjevMODOJrwIOdypOkz.qYCs7jI48gfbMnfs.1CI2fgrrcDpOyrui SNllY6vjoiK.vs9kXwOTcaBxezAgcyjeZnHzddfAEyDQAuqdZP5Ggdp8d8xV7t8Bd2iatGSeACEI Kw_vCL_hsoe2qICN8uObB6pGy_Bz3EkNxj0hsKAaWJGRWi0P2u8PhL5Sn0kbHODYAVzaJBP_1e7D nmsxiARpCIftptgy.Pv8HaKDFTaNS6WetCX44IbzsCDxXIl3c057D.OtDgQ1kuDtJkOmZMclRJ13 KfHNavYfbDddcSn1h0FCPRlCVuDru4UVG_hBccRsEnOxa5jtb9BvU_Q5u0lSmpkorpqYE8rByf2H CRF9cIntCWTCpcM13nW1WgsPGHJNNt00kNwWhIYjEnqHKxSp91qJx19jzopLUTC8p2uO7t5JG0ZG UkSrFibEZuzOzlrGZ54Fd8qCaZ2tROowNc4Qa3gknxYuV5uI3DLEBlJkmBmNLTJHZM7P.nkfKX7A M7ryJCUY0jyqQnyo3cD27NhlFbEO4_jW_ljcb4ZkCb94V8p3TcTIeqfh1KL_IyhUMqHjnYOiEnkl FDD8tyMCoGOhDCJzWDW4jDOG6oBzZIp6hcD3vuAELWV6I_FC_AJ3aYHpHMpQdk4khB27xlGnDCs2 O_jlf.14_mDnw19I1LiHoo.aF4zpWGP.YYdLyXS4cKgwSAa6bE6t_ZEzL8ifRmmS56SjdaA4-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Thu, 16 Apr 2020 17:43:57 +0000
Received: by smtp420.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 85b4bd910b0b976324b98849c5ec7624; Thu, 16 Apr 2020 17:43:56 +0000 (UTC)
From: Stephen Kent <stkent@verizon.net>
To: Claudio Jeker <cjeker@diehard.n-r-g.com>
Cc: Martin Hoffmann <martin@opennetlabs.com>, "sidrops@ietf.org" <sidrops@ietf.org>, Job Snijders <job@ntt.net>
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> <9d7a9500-2ff8-e9d2-f3a5-89eeaa4a90e8@verizon.net> <20200416154509.GT72650@diehard.n-r-g.com>
Message-ID: <8ffd835c-cd11-5af0-81bf-d8935e0e2190@verizon.net>
Date: Thu, 16 Apr 2020 13:43:55 -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: <20200416154509.GT72650@diehard.n-r-g.com>
Content-Type: multipart/alternative; boundary="------------2DDF9962A64F69379D43DDE2"
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/3SN3E_4Q5_xigb1XuNBTXJvCtu0>
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 17:44:01 -0000

Claudio,
> On Thu, Apr 16, 2020 at 10:54:34AM -0400, Stephen Kent wrote:
>> 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.
> My point was that the CRL referenced by the MFT is part of the MFT
> FileAndHash list and is therefor not yet verified and loaded. So either
> one must verify the EE cert of the MFT without checking the CRL or one
> must load a not yet verified CRL file to be able to do proper full EE cert
> verification. This is the chicken and egg situation I was referring to.
If the MFT has been updated, but the CRL has not, then an RP has an 
existing CRL against which to check the EE cert in the MFT object. So, 
the case you cite need not always arise. Only when the CRL and MFT 
change at the same time, does the situation you noted arise. If the MFT 
makes use of a single-use cert, and if the MFT is being published at the 
Next Update time, there also is no problem, since the cert expired with 
the MFT and would not be subject to revocation. Thus, it appears that 
the only cases in which the issue you cited arises is if a new MFT is 
published before the Next Update time and/or the MFT EE cert is not 
single-use. Agreed?
>   
>>> 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?
> I think Job Snijders showed this very well with his examples where removal
> of one roa file would result in the insertion of an AS 0 VRP covering a
> large part of Germany's IP space unless all of the manifest data is
> ignored.
>
I was puzzled by the opening sentence, i.e., "For a CRL listed in 
manifests ..." since _every_ CRL is listed in a manifest.

Job has been emphasizing cases where one of more ROAs are listed in a 
manifest and are not present at a PP. Your comment said "If a CRL, ROA 
or CWERT in a manifest is missing ..." which is a much broader statement.

We're trying to analyze a set of complex cases; it helps if we can make 
precise statements about the issues of concern.

Steve