From nobody Wed Apr 1 11:33:14 2020 Return-Path: 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 11FB13A15FE for ; Wed, 1 Apr 2020 11:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=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=gmail.com 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 Rm0t6w5Sxy7j for ; Wed, 1 Apr 2020 11:33:10 -0700 (PDT) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 DBCE83A1614 for ; Wed, 1 Apr 2020 11:33:09 -0700 (PDT) Received: by mail-qv1-xf2f.google.com with SMTP id t4so254136qvz.8 for ; Wed, 01 Apr 2020 11:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wt8mqvQ31xemRJI69e3FVdj4gZtM2HTb+vLFgmUo/GI=; b=vfEGkIavkADSuhe/d/0JFhqnf7UvG7Ie63eECRiNP1E0tFcMQnPCoFUQAfwcazDo4S 2YXi5leSftdKr8E+qyGvooHXiEJCKHWJ+2bIDtRCChtUZbr8pI56vzuATqAaq96Er6F1 BCLXEtrUXeuyng71S8yvhwmwYioNPMm1+pSdg31e2nTyvKUr3EUePbCm5zEJT/IOX7wJ pLoJ1gYyAq4CWwxYbH+EU3hpAdKuJ6t9vyfeZ+4NFLcHhvhkmOAKSpcG4X1mYVj0ZITe FKHP9gFTBFgfb111N7SEtWU7rL6MuM1G8ahzwfpEaVgwERixcMzYkWkpG26k106G/jyO 5AuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Wt8mqvQ31xemRJI69e3FVdj4gZtM2HTb+vLFgmUo/GI=; b=MbqmSfBjC/n5+asgYXfd/3m5oXDU4zOf6Zg6XqVqzhz5KvYO3hbPvw5RYJQ6sKPLGq oBumonqWVLGoyCjFQ41juH+NaCc08TTpX+X9v/sHZbMwG9XhI35gUDXmcppn03SvpchI JqhbyR/mil1nPKwV5Na7RkI1YTaCq4syYPXbC7BqVV27qqSTK44qe0HP+4nMf4ZkGVVy g5kJoJV0sOQaa2kDwP5q78KdDdcGUyKunVZ+enSd+R/cdF8qwGvI1gn+qm9K8x0y5CJ/ Kt8WUgGhE/o0J70lvFDOjze1614atNDtKH5c7+bIxijL6W7KfaZAqF3ZqQgz+AQCEkje mHVQ== X-Gm-Message-State: ANhLgQ2OYbAqTYfcgTbrlfGDr/4hJh1Y6dzeJZWoDCUcd0K1nldBAd6G iZgQsCSCJf7v0wL29iirK2WFHobkbYD6sgiROibgDU4n X-Google-Smtp-Source: ADFU+vvLoxPwi+oz9kLxhgQ8Hc8NaBK7/5CpKGLdV+0OXBMVAzDy8BTLNTcOspXPsVY6IDLNwYcUCYq0LzJWmjCIbvQ= X-Received: by 2002:a0c:eb4a:: with SMTP id c10mr16564211qvq.70.1585765988468; Wed, 01 Apr 2020 11:33:08 -0700 (PDT) MIME-Version: 1.0 References: <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> <3a683da4-42f9-28c6-f0dd-4d11d3c67857@ripe.net> <4fe26a30-4a08-41a5-be7f-0c5997230d0a@www.fastmail.com> <3B072025-68C5-4E62-9466-5122D483F691@nlnetlabs.nl> <20200324135828.GG60268@vurt.meerval.net> <20200324152009.6e6a2c3f@glaurung.nlnetlabs.nl> <20200324151101.GH60268@vurt.meerval.net> <7f54a255-643f-cd2d-12c2-da19562bbffa@verizon.net> <7465c59f-fa10-4083-8e52-291cb47587f6@www.fastmail.com> In-Reply-To: From: Christopher Morrow Date: Wed, 1 Apr 2020 14:32:57 -0400 Message-ID: To: George Michaelson Cc: SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 18:33:12 -0000 On Tue, Mar 31, 2020 at 6:21 PM George Michaelson wrote: > > I think you did capture the spirit. > > I would remind people that *all* the products in a repository are > signed objects. To arrive at a state where a manifest is "wrong" this was the meat of the first part of my message: "We planned from the get-go that transport security wasn't available, and instead object security would be required." This brought along some, perhaps implicit, requirements about the state of the repository and objects contained therein. > demands two things: it doesn't reflect some real-world situation > regarding contents of the repository *and* its signed by keys you can > validate back to a trust anchor. If you cannot validate the manifest, > then its not "wrong" its forged, or invalid cryptographically. To me, I agree with this, > a "wrong" manifest checks out cryptographically but somehow is not > coherent with the state of the repository. If objects are on the > manifest but cannot be fetched, you are probably suffering either from > hiding of objects, or a transitional state of publication. If objects > can be found which are not on the manifest, you may be seeing > artifacts which are not defined as critical (must be found) or, the > manifest has not yet been updated. This part isn't really what we started talking about, but bears some discussion I think. The manifest is 'must be there' objects in the repository. If there are manifest listed objects which are not in the fetch... that repository is in a bad state and probably operations should decide what to do about that. o Do we have guidance? o Does that guidance provide a list of actions/tradeoffs? o will resolution come in time (for your particular problem) I think most of the docs so far are less definitive ;) about this. This, is one of the things that I think the discussion/wg should provide in a more clear manner. As an ops group it seems reasonable for us to do this even, we're pointing out a difference between theory and practice and documenting a fix. > There are potentially transitional states in the production of a large > repository under eventually consistent production (e.g. multiple > asynchronous cooperating processes, dual-redundant signing models) > where what can be fetched and what is on manifest do not align. If we Part of the agreement between repository and RP is really, I think: "This repository once published is correct" (note, not: 'eventually consistent') This isn't really said in the docs either, and since we let all the flowers bloom here, and kept saying: "the repositories are going to be inconsistent for a bit" I think we didn't help repository operators pick 'sane' models for management of their repository content over time. > wish to demand that the manifest and a given state of the repository > *always* align, we need to formalise that in a way which makes it > clear we publish repository state in as close to atomic-update as > possible. (copying a repo to a new dir, modifying the contents of the > new dir, and (re)publishing the change through the rename() call in > UNIX is one such model) This was, actually, part of the point I made 'years back' about management of repositories... that lead to the model I (admittedly 'puppet for dummies' style) put together for managing the test repository work setup. I think it'd be worth document (as part of the outcome of the proposed conversation) what 'contract' we expect the respository operations and relying parties to have.. 'contract' in a software expectations sense, not in a legal-beagle sense. The next bits step into the 'given case X guidance from the WG for operators says 'do Y'. > A missing manifest is not a "wrong" manifest -its a sign of data being > hidden from you either because of transitional effect in publishing > the repository, or for persisting state a problem in the repository > (diskfull?) or, production systems, or a MITM attack. Which do you > think is actually most likely at this current time? This is no > different to a missing CRL in that regard. Which do you think is the > most likely reason, because you cannot a-priori know that its a MITM > attack, or a failure in networks, or storage systems, or production > systems. > > During the early design phases of the system, we determined that since > the products were all cryptographically signed, there was no strict > requirement for cryptographic protections on transport. If that > decision needs to be revised I think it should be done in standards > work, here, as a discussion. I do not yet see a document which says > that. I don't see formalisms which go to a normative change in SHOULD > to MUST on this. > > So these comments aside, my plea is that people clearly state when > they say "wrong" or "bad" if they mean that it is cryptographically yes, loose lips (phrasing) sinks ships (discussions). I'm trying to be more clear, if I'm not please say: "You are unclear here, more words pls!" > valid, but does not align with some external reality, or some other > meaning. (Which btw, is complex because the part which none of this > can adequately capture is *intentionality* -Just because you think a > publication of RPKI state is nonsensical does not mean its not > intentional) > > Attack models need to state clearly how they acheve the state. An > attack on the integrity of the manifest needs to explain coherently > how it creates a manifest which checks out cryptographically, and yet > hides or legitemates something which should not exist. They also need > to explain how the specific attack on the manifest in these situation > outweighs other considerations: If they have the keys, then surely the > attack vector is to make validly signed things which cannot be > detected as an attack? > > -George > > On Wed, Apr 1, 2020 at 1:42 AM Christopher Morrow > wrote: > > > > first, apologies for getting back around to this so late :( > > > > On Thu, Mar 26, 2020 at 10:57 AM Stephen Kent > > wrote: > > > > > So, I think discussing MITM attacks is a distraction, unless we have examples of how > > > such attacks can affect RPs in ways different from attacks on repositories. Maybe re-reading > > > RFC 8211 would be useful, as it tries to analyze a range of possible "adverse actions" by CAs or > > > repository managers in the RPKI context, and discusses how RPKI mechanisms are intended to > > > detect/counter these actions. > > > > In the case of the incident which started this thread we ended up > > publishing part of the content a > > repository needs to publish such that the relying parties can verify > > properly that the content in the > > repository is correct/valid/usable. The discussion then went along a path like: > > 1) "well... maybe we shouldn't have belt and suspenders?" (manifest AND crl) > > 2) "what happens if we don't publish this pesky CRL? and rely only > > on the manifest?" > > 3) "what if we don't publish the manifest and only rely on the CRL?" > > 4) "CRL + Manifest has made 'rp software' hard/buggy" > > > > In the world where the protections specified for RPKI exist: > > 1) self contained content protection (roa / ee-certs / etc are > > packaged securely) > > 2) crl signed and available in the repository for revocation actions > > on objects in the repository > > 3) manifest signed and listing all objects of interest in the repository > > > > Steve (kent!) is right mitm is harder to see as a threat. > > "All objects you get are signed by a ca-cert which is signed by the > > root.. which is in the list of TAL you have. You can't have missing > > objects and you cant' remove objects without affecting the signed > > manifest" > > > > In a world where we remove one/some of the protections: > > A) no more manifest > > B) no more crl > > C) both > > > > I think mitm problems are much harder to detect/deal with :( > > It sounds like WG folk (RP users and RP/CA software authors) are > > asking for guidance on handling the problem(s) discussed here. > > It sounds, to me, like a chat at the upcoming interim meeting would be > > a great place to start that with some slideware and a proposal to use > > as kindling. > > > > I think the shape of the conversation is roughly: > > "What would be the effect (on the routing system) for RelyingParties > > if we decided to be less strict about CRL existence?" > > "What would be the effect (on the routing system) for Relying > > Parties if we decided to be less strict about repository contents vs > > Manifest contents?" > > "What happens to the routing system if the manifest and crl are > > either/both 'broken' in a repository?" > > > > I don't think it matters much to the routing system where the breakage > > occurs (my repository or RIPE/ARIN/etc) certainly there's more fallout > > from ARIN/RIPE/etc, but... you can't get to me either way :) > > (possibly) until repair and propogation. > > > > Thoughts on some slideware and discussion? > > Did I about capture the meat of the sandwich here? > > > > -chris > > co-chair but asking as a regular chemical engineer at this party. > > > > _______________________________________________ > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Apr 1 11:35:19 2020 Return-Path: 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 158213A1617 for ; Wed, 1 Apr 2020 11:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=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=gmail.com 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 y7fvwpfOtVZy for ; Wed, 1 Apr 2020 11:35:16 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 C88CE3A1618 for ; Wed, 1 Apr 2020 11:35:15 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id l25so1088728qki.7 for ; Wed, 01 Apr 2020 11:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CHNaoXJYvtV6qibk7U3Tg9UKw9LXddqf9LSzSl4BPRQ=; b=I7TVOBIF2+Ey+HpbhagAdbFAnzGHZ3kbbd3Yq6+tKZpLUAfS5xWBCKIDIpXSBzctPA 6+VOjRjiul98cdS8aA3rI5soLr+XwSUEWtVHtd3HnUq4ow2gWs7x5kIaBE4oAH5fxJw4 Pc0SKrAG4MMR5BkEsZy1J/OD1o9lyVqom+dFAt0lGrmRkPd84Z0YUuo+3imRjTE9GMB4 P112sX7tzlLyd1G0spDN6NCX3rSc4IifWzynFBxkkCiNjFfCpjYbEyFIXwE4e16XMOj7 Mk2nnnxrrKJrZ/cv5AFSTEbWhmVEv4cGYLx9r7djgnyEb2zk46SOt3lIv1uWBnVrDe1i +dhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CHNaoXJYvtV6qibk7U3Tg9UKw9LXddqf9LSzSl4BPRQ=; b=MYKtugAdquYJH2oVHJpZmI669alQ9kjWvkICpk5YNDVt85tbi6v9GPuywxxyPY7I2N AMtO5MsCR1FyIZjUbIB8qZsdMLR5oLkzHyurDoT9Kfq4QIMRPuFU9m9nAAL+XfFFccxC scdQxycRRMmgrrfCC6BJo8HuFC9WGRWch8TYsOJ+S9RyBVvdTpvZgy2wl6Z97Qe0dPsP 8LIJOez7nwX7qhTQlstFrkUPJVGiyrw4PQaXdF7WX97gZUDwvh7e/OKfaQpNVNIFQ7+W spyPw3Djv4ZHSKIOBZbwE9PKoF/6u800vE3ar/82IxqXembCcRTkQUxnVhKfbnt6kuIE rYwg== X-Gm-Message-State: ANhLgQ1UjrityVYc4Wi0s2YDEA2O2Z+3LjOYkZocmcfcjicAosKsJBz6 2I0yJ53TheVtiSdE43MpIQwbWxXkh3GYqNJi10Y= X-Google-Smtp-Source: ADFU+vvVyVhj7qWHP8AfXMB1L3MD/IxbXIn4S44/t0nlsgCQEAFVdspAbuB69JO31J2a18mWnuoB4OErNUPOCgR/05k= X-Received: by 2002:a05:620a:166a:: with SMTP id d10mr11664849qko.388.1585766114516; Wed, 01 Apr 2020 11:35:14 -0700 (PDT) MIME-Version: 1.0 References: <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> <3a683da4-42f9-28c6-f0dd-4d11d3c67857@ripe.net> <4fe26a30-4a08-41a5-be7f-0c5997230d0a@www.fastmail.com> <3B072025-68C5-4E62-9466-5122D483F691@nlnetlabs.nl> <20200324135828.GG60268@vurt.meerval.net> <20200324152009.6e6a2c3f@glaurung.nlnetlabs.nl> <20200324151101.GH60268@vurt.meerval.net> <7f54a255-643f-cd2d-12c2-da19562bbffa@verizon.net> <7465c59f-fa10-4083-8e52-291cb47587f6@www.fastmail.com> In-Reply-To: From: Christopher Morrow Date: Wed, 1 Apr 2020 14:35:03 -0400 Message-ID: To: Di Ma Cc: George Michaelson , SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 18:35:18 -0000 On Tue, Mar 31, 2020 at 11:03 PM Di Ma wrote: > > Yes. > > Although the RPKI provides object-oriented security yet the validity of a= n object relies on a trust chain, any wrong node of which would cause failu= re. > > So-called =E2=80=9Cwrong=E2=80=9D MFT will bring about trouble no matter = it is rooted from transport or RPKI provisioning side. > > Situations could be complicated as analyzed in section 2.2 of RFC 8211 in= terms of adverse actions on MFT but RFC 6488 leaves much to RP to decide. > > BTW, in RFC 8211 we authors differentiate if the attacker have got access= to the private key of the INR holder, trying to give a threat mode. > > So it is right time to reconsider the requirements posed on RP in case of= =E2=80=9Cwrong=E2=80=9D MFT. yes this last sentence is the discussion I'd like to see happen... I think guiding that with: "Here are the ways an manifest could go badly: bad sig, bad content, missing content, missing manifest..." and: "given the damage from X, Y, Z, the proposed actions for an RP are... because ..." > Di > > > 2020=E5=B9=B44=E6=9C=881=E6=97=A5 06:20=EF=BC=8CGeorge Michaelson =E5=86=99=E9=81=93=EF=BC=9A > > > > I think you did capture the spirit. > > > > I would remind people that *all* the products in a repository are > > signed objects. To arrive at a state where a manifest is "wrong" > > demands two things: it doesn't reflect some real-world situation > > regarding contents of the repository *and* its signed by keys you can > > validate back to a trust anchor. If you cannot validate the manifest, > > then its not "wrong" its forged, or invalid cryptographically. To me, > > a "wrong" manifest checks out cryptographically but somehow is not > > coherent with the state of the repository. If objects are on the > > manifest but cannot be fetched, you are probably suffering either from > > hiding of objects, or a transitional state of publication. If objects > > can be found which are not on the manifest, you may be seeing > > artifacts which are not defined as critical (must be found) or, the > > manifest has not yet been updated. > > > > There are potentially transitional states in the production of a large > > repository under eventually consistent production (e.g. multiple > > asynchronous cooperating processes, dual-redundant signing models) > > where what can be fetched and what is on manifest do not align. If we > > wish to demand that the manifest and a given state of the repository > > *always* align, we need to formalise that in a way which makes it > > clear we publish repository state in as close to atomic-update as > > possible. (copying a repo to a new dir, modifying the contents of the > > new dir, and (re)publishing the change through the rename() call in > > UNIX is one such model) > > > > A missing manifest is not a "wrong" manifest -its a sign of data being > > hidden from you either because of transitional effect in publishing > > the repository, or for persisting state a problem in the repository > > (diskfull?) or, production systems, or a MITM attack. Which do you > > think is actually most likely at this current time? This is no > > different to a missing CRL in that regard. Which do you think is the > > most likely reason, because you cannot a-priori know that its a MITM > > attack, or a failure in networks, or storage systems, or production > > systems. > > > > During the early design phases of the system, we determined that since > > the products were all cryptographically signed, there was no strict > > requirement for cryptographic protections on transport. If that > > decision needs to be revised I think it should be done in standards > > work, here, as a discussion. I do not yet see a document which says > > that. I don't see formalisms which go to a normative change in SHOULD > > to MUST on this. > > > > So these comments aside, my plea is that people clearly state when > > they say "wrong" or "bad" if they mean that it is cryptographically > > valid, but does not align with some external reality, or some other > > meaning. (Which btw, is complex because the part which none of this > > can adequately capture is *intentionality* -Just because you think a > > publication of RPKI state is nonsensical does not mean its not > > intentional) > > > > Attack models need to state clearly how they acheve the state. An > > attack on the integrity of the manifest needs to explain coherently > > how it creates a manifest which checks out cryptographically, and yet > > hides or legitemates something which should not exist. They also need > > to explain how the specific attack on the manifest in these situation > > outweighs other considerations: If they have the keys, then surely the > > attack vector is to make validly signed things which cannot be > > detected as an attack? > > > > -George > > > > On Wed, Apr 1, 2020 at 1:42 AM Christopher Morrow > > wrote: > >> > >> first, apologies for getting back around to this so late :( > >> > >> On Thu, Mar 26, 2020 at 10:57 AM Stephen Kent > >> wrote: > >> > >>> So, I think discussing MITM attacks is a distraction, unless we have = examples of how > >>> such attacks can affect RPs in ways different from attacks on reposit= ories. Maybe re-reading > >>> RFC 8211 would be useful, as it tries to analyze a range of possible = "adverse actions" by CAs or > >>> repository managers in the RPKI context, and discusses how RPKI mecha= nisms are intended to > >>> detect/counter these actions. > >> > >> In the case of the incident which started this thread we ended up > >> publishing part of the content a > >> repository needs to publish such that the relying parties can verify > >> properly that the content in the > >> repository is correct/valid/usable. The discussion then went along a p= ath like: > >> 1) "well... maybe we shouldn't have belt and suspenders?" (manifest = AND crl) > >> 2) "what happens if we don't publish this pesky CRL? and rely only > >> on the manifest?" > >> 3) "what if we don't publish the manifest and only rely on the CRL?" > >> 4) "CRL + Manifest has made 'rp software' hard/buggy" > >> > >> In the world where the protections specified for RPKI exist: > >> 1) self contained content protection (roa / ee-certs / etc are > >> packaged securely) > >> 2) crl signed and available in the repository for revocation actions > >> on objects in the repository > >> 3) manifest signed and listing all objects of interest in the reposit= ory > >> > >> Steve (kent!) is right mitm is harder to see as a threat. > >> "All objects you get are signed by a ca-cert which is signed by the > >> root.. which is in the list of TAL you have. You can't have missing > >> objects and you cant' remove objects without affecting the signed > >> manifest" > >> > >> In a world where we remove one/some of the protections: > >> A) no more manifest > >> B) no more crl > >> C) both > >> > >> I think mitm problems are much harder to detect/deal with :( > >> It sounds like WG folk (RP users and RP/CA software authors) are > >> asking for guidance on handling the problem(s) discussed here. > >> It sounds, to me, like a chat at the upcoming interim meeting would be > >> a great place to start that with some slideware and a proposal to use > >> as kindling. > >> > >> I think the shape of the conversation is roughly: > >> "What would be the effect (on the routing system) for RelyingParties > >> if we decided to be less strict about CRL existence?" > >> "What would be the effect (on the routing system) for Relying > >> Parties if we decided to be less strict about repository contents vs > >> Manifest contents?" > >> "What happens to the routing system if the manifest and crl are > >> either/both 'broken' in a repository?" > >> > >> I don't think it matters much to the routing system where the breakage > >> occurs (my repository or RIPE/ARIN/etc) certainly there's more fallout > >> from ARIN/RIPE/etc, but... you can't get to me either way :) > >> (possibly) until repair and propogation. > >> > >> Thoughts on some slideware and discussion? > >> Did I about capture the meat of the sandwich here? > >> > >> -chris > >> co-chair but asking as a regular chemical engineer at this party. > >> > >> _______________________________________________ > >> Sidrops mailing list > >> Sidrops@ietf.org > >> https://www.ietf.org/mailman/listinfo/sidrops > > > > _______________________________________________ > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops > > > > > From nobody Wed Apr 1 12:36:47 2020 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5B93A1834; Wed, 1 Apr 2020 12:36:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar via Datatracker To: Cc: draft-ietf-sidrops-ov-egress.all@ietf.org, sidrops@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.123.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158576979679.30652.11243360019367571918@ietfa.amsl.com> Reply-To: Linda Dunbar Date: Wed, 01 Apr 2020 12:36:36 -0700 Archived-At: Subject: [Sidrops] Opsdir telechat review of draft-ietf-sidrops-ov-egress-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 19:36:37 -0000 Reviewer: Linda Dunbar Review result: Ready I have reviewed this document as part of the Ops area directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Ops area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I think the document is ready and precise. Just one minor comment: The document emphasizes the importance of origin validation in eBGP egress policies, explaining specifics of correct implementation. I just wish it adds the examples described by Chris Morrow on the mailing list on the use cases that explain why the mechanism described in the document is necessary because not everyone is as smart and knowledgeable as the authors. My two cents. Linda Dunbar From nobody Wed Apr 1 15:17:07 2020 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5920E3A1047; Wed, 1 Apr 2020 15:17:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jouni Korhonen via Datatracker To: Cc: draft-ietf-sidrops-ov-egress.all@ietf.org, last-call@ietf.org, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.123.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158577942531.31132.14192491820838585248@ietfa.amsl.com> Reply-To: Jouni Korhonen Date: Wed, 01 Apr 2020 15:17:05 -0700 Archived-At: Subject: [Sidrops] Intdir telechat review of draft-ietf-sidrops-ov-egress-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 22:17:06 -0000 Reviewer: Jouni Korhonen Review result: Ready with Nits I found the document ready for publication with one editorial nit. The abstract doesn't mention that this document updates RFC6811, which it should. From nobody Wed Apr 1 17:50:41 2020 Return-Path: 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 EEE843A0028 for ; Wed, 1 Apr 2020 17:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=algebras-org.20150623.gappssmtp.com 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 UlbOuhYiCyBs for ; Wed, 1 Apr 2020 17:50:37 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 0A5CD3A16D7 for ; Wed, 1 Apr 2020 17:50:36 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id n13so1954003ilm.5 for ; Wed, 01 Apr 2020 17:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=nRQoCgtP8IWeD5yOwHO2OCq12Oh5PVOyzhb2HvY7ncg=; b=FCUf+Yd8WuIpwmSQoUeBLjPk9Pg6UOH7sDlx5/ahCNxLs9SKUYJWOWjSFe+ljEkKxA 4dtK20yIETCwxX5XhpRNZz6fmRc+LJF/3vkJgL2e9d/d1mwrm6s5SA8Ihk+L83bnulCQ nZmbmJ+nJH+VoVFpZaHAgSHLecOa2S/VI7t+3fyIJeCwKdhxjV9EtYwZq7pB0lgz8ixd DVlstT4cfBLPYHC8iMXg3fp7NcOARISyYJrMQpfc+DVMV9+7NZiNeyWNy+0hoC/Hp3zN PmfgeVpIzFSRzkD+ftMvt0yMy6MzgFQKg56yC/ZYrIqbOEy3N5CbZAp0oRdcYhSCTY/V Khag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nRQoCgtP8IWeD5yOwHO2OCq12Oh5PVOyzhb2HvY7ncg=; b=A66odLC2WXYVyckcXR7Y2ZPLy+t+4I4gCsNv/r0Eo/BXRetZNiWmuwwdDP4oPBiipm 61pnZhGvfSOZsSCkCCFp8UIWLLdmxcpyFYQkT9+cR/hDxxTTNK0wh9/PmOGBScW+QluU 9J/fU6KBqLai6wPS7Rue1fXEcvVAoIrHU+cvwCrOaNKjz7wj+sdrKUZh29dUBIb3NF3L m4DNwlLm8nINlGbzH+jcAYZfluJrWW6LFjP61Lwf5c7GJhFGWQp7xOqUWtB8L3Y1sFQd +ibXzyH3htyceGelbO0ys19nmZhPCuC1v6d7YIzlJ7hQHvnYv1+E18AxdA5w8czUESQj LsrA== X-Gm-Message-State: AGi0PuZk+YHTdcc0IPZXWlAiOHEHMdKNFJ4rFQ4Ue968Qwm2kfHzJ9Rb aBqczDyGq6EsUaDLoXi4rgpdsQ2XeZbZw4Kdj+7z3/heMAbarQ== X-Google-Smtp-Source: APiQypL5WHGabxWMWYY7Mc6hrA3jUW/hKGR2jsAvVgJ8a7gsIQEUQ+DFvwZnaNnETWrTM9xMfMy0kCniXrlFhztshUk= X-Received: by 2002:a92:5c0a:: with SMTP id q10mr683212ilb.65.1585788635454; Wed, 01 Apr 2020 17:50:35 -0700 (PDT) MIME-Version: 1.0 From: George Michaelson Date: Thu, 2 Apr 2020 10:50:24 +1000 Message-ID: To: SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Sidrops] ISIF foundation seeks grant applications for research in RPKI X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 00:50:39 -0000 ISIF.asia has a call out for research proposals in fields including RPKI. https://isif.asia/2020-netops/ cheers -george From nobody Wed Apr 1 19:25:41 2020 Return-Path: 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 5C6303A0AC0; Wed, 1 Apr 2020 19:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 geVSio8CxnQT; Wed, 1 Apr 2020 19:25:25 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F28FA3A0AAD; Wed, 1 Apr 2020 19:25:24 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jJpXn-0006dw-D0; Thu, 02 Apr 2020 02:25:23 +0000 Date: Wed, 01 Apr 2020 19:25:22 -0700 Message-ID: From: Randy Bush To: Jouni Korhonen via Datatracker Cc: , draft-ietf-sidrops-ov-egress.all@ietf.org, last-call@ietf.org, sidrops@ietf.org In-Reply-To: <158577942531.31132.14192491820838585248@ietfa.amsl.com> References: <158577942531.31132.14192491820838585248@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Intdir telechat review of draft-ietf-sidrops-ov-egress-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 02:25:28 -0000 > The abstract doesn't mention that this document updates RFC6811, which > it should. is that the convention now, even when the masthead and the intro says it? randy From nobody Thu Apr 2 01:02:47 2020 Return-Path: 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 D4DE33A0D16 for ; Thu, 2 Apr 2020 01:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Vr2AJS_Qi5AB for ; Thu, 2 Apr 2020 01:02:44 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542C83A0D14 for ; Thu, 2 Apr 2020 01:02:44 -0700 (PDT) Received: from allealle.ripe.net ([193.0.23.12]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jJuoE-0005w5-UK for sidrops@ietf.org; Thu, 02 Apr 2020 10:02:42 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::1b1]) by allealle.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.3) (envelope-from ) id 1jJuoE-0000wt-Rj for sidrops@ietf.org; Thu, 02 Apr 2020 10:02:42 +0200 References: <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> <3a683da4-42f9-28c6-f0dd-4d11d3c67857@ripe.net> <4fe26a30-4a08-41a5-be7f-0c5997230d0a@www.fastmail.com> <3B072025-68C5-4E62-9466-5122D483F691@nlnetlabs.nl> <20200324135828.GG60268@vurt.meerval.net> <20200324152009.6e6a2c3f@glaurung.nlnetlabs.nl> <20200324151101.GH60268@vurt.meerval.net> <7f54a255-643f-cd2d-12c2-da19562bbffa@verizon.net> <7465c59f-fa10-4083-8e52-291cb47587f6@www.fastmail.com> From: Robert Kisteleki Autocrypt: addr=robert@ripe.net; prefer-encrypt=mutual; keydata= xsBNBEzFa6gBCADVASYXBbUF7v1D+Y9XR41SEEMiZUARlUWeP0NrFHZmRRGdR5nM/p6HguUd StIPRmdqMdyLDqBsV8XPVu6lvhcb4+ZFu/V1XFPVyPBH8U6iQ4PdGDeqFlBm3gxoDOGraGw8 bjojvASTz/Wk3ddLPm34Kb6oMI2MclC016UgrPgIj6A1Uu8qQeBDyWrk+OrWUPOUOKM7QhQg cpU4JwuaesthFvqdoPNQJi9QUfn94r14ZNDYmeJlchZiRHWO70Gwoy3ywfAM9Kyi1tx78Qc9 E5ZhGIw9qqlzqa6c6a0qhup2Zh/dhVBJ05jCDN7bUQT5tRiOV2icyX8Dsr4KaWYCsAOVABEB AAHNMVJvYmVydCBLaXN0ZWxla2kgKFJJUEUgTkNDIGtleSkgPHJvYmVydEByaXBlLm5ldD7C wHgEEwECACICGyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJWUwoeAAoJEC0ZXiKtTC3+ 04UH/jlvSR0esDGFSponUVawru+/QF61KdsNrdH6/Vs2buQvczW2Uh+S6Dic2vr2H0B1YrvL F2XpL2WJUHBUDLTA7dYTslvnHpyZrR8Sfb+h+wJ8OynxEC5wMKxfYNx2fMSk5EIU5mRjMaYg X/VkssDcoQAznNwVVYeqHYUJDMcrJhAYh44VHO208VwjPjHUDRlC+BoMGjHJnWDOAstlES8j 0r3adj2MqIHdDEjSdEx1+rbV0iZlgcDbYDex3qulOYlcZL+PJvGHzD6CkNBa8SbSN7cO0yqR OJ2sgobITOJ0GbRIbIvkUe1Iqw717CuQV/u822dFISDYOAhGYmfWGJWmkezOwE0ETMVrqAEI AKazZ2Agrv0nNFPWV69l6fEout/FaqWfyAG5V414l4yr+qVShUYzS+txA2vC+ouHvdORZ/JG xwKf6HE+YvvWS+Oa+b6h+GZfA3G43XGpQlxXrFK019TeMjhHqWprZALL4w2k6TatYT1ZW369 rORtwSgtn5ZC4uNcpZeDQddQvCjyYoknqlZqAFf1pssuGPTE8GvhrZGEp52dALYYoDIf7y/z 8fCAcy72rhMhQV02rPB49UxOEh2FZJhST0743tuMtFemBkp06B/Mcx54QT0muG8zj19oMDG3 AAaGjNP6B3qzR6F8VczR/qVhQzRvNMr8A6+y/ew/x4+48P+O/4n/I50AEQEAAcLAXwQYAQIA CQIbDAUCVlMKHgAKCRAtGV4irUwt/mvlB/sFID7mlsWAS66UyrI+tGs4Xfl59vvhRRZ4ZKiR 8VEbWbLKh/b9SoYcKt9SLEfVxJE5ebWPgIIvUSdLS6f4n9uAJteDZ4w/AVfp5a6jbfvMm7JP AMW4HtnZ3YbNevRgXdGVXN+bTLZzXoVijOKu+xHDBRNaUswaG3glrDJfUGkPQtCXFn6m6Pdw dW1/ShzwQgfuE/NXa83jhJ175P+NoQ2KG7934vu2MZdrtIqPibKuaGWMPG0L5YzPotK9ONmd taJMnuk92qqZ6S9JPwRZmogRW/sX54XvGg6RzNpdHS5C+iN01tCNJTRTlOJ1X73+RrGokvKc dp6fdfc4PHHhpcMd Organization: RIPE NCC To: SIDR Operations WG Message-ID: <6c7d5f08-20d5-f4d7-18a2-04fa3ae87067@ripe.net> Date: Thu, 2 Apr 2020 10:02:42 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ACL-Warn: Delaying message X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274145fa1964f5b53164e63ce64de07219e Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 08:02:46 -0000 >> So it is right time to reconsider the requirements posed on RP in case of “wrong” MFT. > > yes this last sentence is the discussion I'd like to see happen... I > think guiding that with: > "Here are the ways an manifest could go badly: bad sig, bad content, > missing content, missing manifest..." > > and: > "given the damage from X, Y, Z, the proposed actions for an RP > are... because ..." I was thinking along the same lines while having a related conversation with Job/Tim here: > I believe a more nuanced approach is needed, like if there's a problem > on a particular validation path (a cert is missing or has an error) then > invalidate that path, if a CRL is missing then warn but use a stale one, > but leave the otherwise unaffected bits validated. If repository R hosts objects for CAs A, B, ... Z, A has subtrees A1...A9 and there's a problem with the manifest of A1, the rest (B..Z) is perfectly fine an usable. IMO A2..A9 are fine as well. As for A1: the RP action IMO should really depend on what the exact issue is, for example: - an object is missing: check if you have it from the previous run and if so, use it - a CRL is missing / corrupt / expired: warn but use the previous one I'd be happy to contribute and I think that if this happens, contribution from operator(s) would be extremely useful. Robert From nobody Thu Apr 2 01:07:21 2020 Return-Path: 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 D868D3A0D24 for ; Thu, 2 Apr 2020 01:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 hpkW6Z3IDv7h for ; Thu, 2 Apr 2020 01:07:17 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB2D43A0D23 for ; Thu, 2 Apr 2020 01:07:17 -0700 (PDT) Received: from allealle.ripe.net ([193.0.23.12]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jJuse-000CAy-6b for sidrops@ietf.org; Thu, 02 Apr 2020 10:07:16 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::1b1]) by allealle.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.3) (envelope-from ) id 1jJuse-0001Kw-4F for sidrops@ietf.org; Thu, 02 Apr 2020 10:07:16 +0200 References: <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> <3a683da4-42f9-28c6-f0dd-4d11d3c67857@ripe.net> <4fe26a30-4a08-41a5-be7f-0c5997230d0a@www.fastmail.com> <3B072025-68C5-4E62-9466-5122D483F691@nlnetlabs.nl> <20200324135828.GG60268@vurt.meerval.net> <20200324152009.6e6a2c3f@glaurung.nlnetlabs.nl> <20200324151101.GH60268@vurt.meerval.net> <7f54a255-643f-cd2d-12c2-da19562bbffa@verizon.net> <7465c59f-fa10-4083-8e52-291cb47587f6@www.fastmail.com> To: SIDR Operations WG From: Robert Kisteleki Autocrypt: addr=robert@ripe.net; prefer-encrypt=mutual; keydata= xsBNBEzFa6gBCADVASYXBbUF7v1D+Y9XR41SEEMiZUARlUWeP0NrFHZmRRGdR5nM/p6HguUd StIPRmdqMdyLDqBsV8XPVu6lvhcb4+ZFu/V1XFPVyPBH8U6iQ4PdGDeqFlBm3gxoDOGraGw8 bjojvASTz/Wk3ddLPm34Kb6oMI2MclC016UgrPgIj6A1Uu8qQeBDyWrk+OrWUPOUOKM7QhQg cpU4JwuaesthFvqdoPNQJi9QUfn94r14ZNDYmeJlchZiRHWO70Gwoy3ywfAM9Kyi1tx78Qc9 E5ZhGIw9qqlzqa6c6a0qhup2Zh/dhVBJ05jCDN7bUQT5tRiOV2icyX8Dsr4KaWYCsAOVABEB AAHNMVJvYmVydCBLaXN0ZWxla2kgKFJJUEUgTkNDIGtleSkgPHJvYmVydEByaXBlLm5ldD7C wHgEEwECACICGyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJWUwoeAAoJEC0ZXiKtTC3+ 04UH/jlvSR0esDGFSponUVawru+/QF61KdsNrdH6/Vs2buQvczW2Uh+S6Dic2vr2H0B1YrvL F2XpL2WJUHBUDLTA7dYTslvnHpyZrR8Sfb+h+wJ8OynxEC5wMKxfYNx2fMSk5EIU5mRjMaYg X/VkssDcoQAznNwVVYeqHYUJDMcrJhAYh44VHO208VwjPjHUDRlC+BoMGjHJnWDOAstlES8j 0r3adj2MqIHdDEjSdEx1+rbV0iZlgcDbYDex3qulOYlcZL+PJvGHzD6CkNBa8SbSN7cO0yqR OJ2sgobITOJ0GbRIbIvkUe1Iqw717CuQV/u822dFISDYOAhGYmfWGJWmkezOwE0ETMVrqAEI AKazZ2Agrv0nNFPWV69l6fEout/FaqWfyAG5V414l4yr+qVShUYzS+txA2vC+ouHvdORZ/JG xwKf6HE+YvvWS+Oa+b6h+GZfA3G43XGpQlxXrFK019TeMjhHqWprZALL4w2k6TatYT1ZW369 rORtwSgtn5ZC4uNcpZeDQddQvCjyYoknqlZqAFf1pssuGPTE8GvhrZGEp52dALYYoDIf7y/z 8fCAcy72rhMhQV02rPB49UxOEh2FZJhST0743tuMtFemBkp06B/Mcx54QT0muG8zj19oMDG3 AAaGjNP6B3qzR6F8VczR/qVhQzRvNMr8A6+y/ew/x4+48P+O/4n/I50AEQEAAcLAXwQYAQIA CQIbDAUCVlMKHgAKCRAtGV4irUwt/mvlB/sFID7mlsWAS66UyrI+tGs4Xfl59vvhRRZ4ZKiR 8VEbWbLKh/b9SoYcKt9SLEfVxJE5ebWPgIIvUSdLS6f4n9uAJteDZ4w/AVfp5a6jbfvMm7JP AMW4HtnZ3YbNevRgXdGVXN+bTLZzXoVijOKu+xHDBRNaUswaG3glrDJfUGkPQtCXFn6m6Pdw dW1/ShzwQgfuE/NXa83jhJ175P+NoQ2KG7934vu2MZdrtIqPibKuaGWMPG0L5YzPotK9ONmd taJMnuk92qqZ6S9JPwRZmogRW/sX54XvGg6RzNpdHS5C+iN01tCNJTRTlOJ1X73+RrGokvKc dp6fdfc4PHHhpcMd Organization: RIPE NCC Message-ID: Date: Thu, 2 Apr 2020 10:07:15 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-ACL-Warn: Delaying message X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274aa89c6fae8d30c8ad45ecaa37743b9d6 Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 08:07:19 -0000 > There are potentially transitional states in the production of a large > repository under eventually consistent production (e.g. multiple > asynchronous cooperating processes, dual-redundant signing models) > where what can be fetched and what is on manifest do not align. If we > wish to demand that the manifest and a given state of the repository > *always* align, we need to formalise that in a way which makes it > clear we publish repository state in as close to atomic-update as > possible. (copying a repo to a new dir, modifying the contents of the > new dir, and (re)publishing the change through the rename() call in > UNIX is one such model) Being smart on the repo side surely decreases the probability of a hickup, but I don't think it can completely avoid point-in-time inconsistencies. So the RP has to be prepared to deal with this. Assumptions about a repo always being self-consistent will not hold up, even without an attacker around. (I also recall that, at least in theory, there is such a thing as a "repository service" where one can use a private CA but someone else's repo to publish. Such a scenario compicates the consistency requirement even further.) Robert From nobody Thu Apr 2 02:46:14 2020 Return-Path: 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 64AC93A0E95 for ; Thu, 2 Apr 2020 02:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 xY9s8d7kmPoh for ; Thu, 2 Apr 2020 02:46:09 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A27E13A0E8F for ; Thu, 2 Apr 2020 02:46:09 -0700 (PDT) Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id CE3EC2F910; Thu, 2 Apr 2020 11:46:06 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Thu, 2 Apr 2020 11:46:06 +0200 From: Martin Hoffmann To: George Michaelson Cc: Christopher Morrow , SIDR Operations WG Message-ID: <20200402114606.68abed9c@glaurung.nlnetlabs.nl> In-Reply-To: References: <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> <3a683da4-42f9-28c6-f0dd-4d11d3c67857@ripe.net> <4fe26a30-4a08-41a5-be7f-0c5997230d0a@www.fastmail.com> <3B072025-68C5-4E62-9466-5122D483F691@nlnetlabs.nl> <20200324135828.GG60268@vurt.meerval.net> <20200324152009.6e6a2c3f@glaurung.nlnetlabs.nl> <20200324151101.GH60268@vurt.meerval.net> <7f54a255-643f-cd2d-12c2-da19562bbffa@verizon.net> <7465c59f-fa10-4083-8e52-291cb47587f6@www.fastmail.com> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 09:46:11 -0000 George Michaelson wrote: >=20 > I would remind people that *all* the products in a repository are > signed objects. To arrive at a state where a manifest is "wrong" > demands two things: it doesn't reflect some real-world situation > regarding contents of the repository *and* its signed by keys you can > validate back to a trust anchor. If you cannot validate the manifest, > then its not "wrong" its forged, or invalid cryptographically. To me, > a "wrong" manifest checks out cryptographically but somehow is not > coherent with the state of the repository. I think we are still having this conceptually backwards: It isn=E2=80=99t t= he manifest that is wrong, it is the repository content. Whether it was originally intended that way or not, having a manifest at all to me only makes sense if it is considered to contain the truth, the whole truth, and nothing but the truth. I honestly believe that the current state of affairs where basically the guidance for RP software developers is to look at the current repository content, past repository content, the manifest and the CRL and then figure stuff out themselves is rather ... unfortunate and doesn=E2=80=99t exactly improve the confidence in the overall system. Given the inherent complexities of a distributed repository, it seems important to me to make the system as straightforward as possible to implement. Declaring the manifest to be the sole list of currently published objects is a means to this end. Kind regards, Martin From nobody Thu Apr 2 03:14:30 2020 Return-Path: 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 15E1F3A089C for ; Thu, 2 Apr 2020 03:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 Zg1uikyugLmX for ; Thu, 2 Apr 2020 03:14:26 -0700 (PDT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7D3B3A0F09 for ; Thu, 2 Apr 2020 03:14:25 -0700 (PDT) Received: (qmail 68946 invoked by uid 1000); 2 Apr 2020 10:14:20 -0000 Date: Thu, 2 Apr 2020 12:14:20 +0200 From: Claudio Jeker To: Martin Hoffmann Cc: George Michaelson , Christopher Morrow , SIDR Operations WG Message-ID: <20200402101420.GA44821@diehard.n-r-g.com> References: <3B072025-68C5-4E62-9466-5122D483F691@nlnetlabs.nl> <20200324135828.GG60268@vurt.meerval.net> <20200324152009.6e6a2c3f@glaurung.nlnetlabs.nl> <20200324151101.GH60268@vurt.meerval.net> <7f54a255-643f-cd2d-12c2-da19562bbffa@verizon.net> <7465c59f-fa10-4083-8e52-291cb47587f6@www.fastmail.com> <20200402114606.68abed9c@glaurung.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200402114606.68abed9c@glaurung.nlnetlabs.nl> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 10:14:28 -0000 On Thu, Apr 02, 2020 at 11:46:06AM +0200, Martin Hoffmann wrote: > George Michaelson wrote: > > > > I would remind people that *all* the products in a repository are > > signed objects. To arrive at a state where a manifest is "wrong" > > demands two things: it doesn't reflect some real-world situation > > regarding contents of the repository *and* its signed by keys you can > > validate back to a trust anchor. If you cannot validate the manifest, > > then its not "wrong" its forged, or invalid cryptographically. To me, > > a "wrong" manifest checks out cryptographically but somehow is not > > coherent with the state of the repository. > > I think we are still having this conceptually backwards: It isn’t the > manifest that is wrong, it is the repository content. Whether it was > originally intended that way or not, having a manifest at all to me only > makes sense if it is considered to contain the truth, the whole truth, > and nothing but the truth. > > I honestly believe that the current state of affairs where basically > the guidance for RP software developers is to look at the current > repository content, past repository content, the manifest and the CRL > and then figure stuff out themselves is rather ... unfortunate and > doesn’t exactly improve the confidence in the overall system. > > Given the inherent complexities of a distributed repository, it seems > important to me to make the system as straightforward as possible to > implement. Declaring the manifest to be the sole list of currently > published objects is a means to this end. I completely agree with this. As example rpki-client only looks at files that are referenced via the .mft files. The .mft file tells the truth (it was validated that it is the truth with the cert chain). Only files in the MFTs will be used to build the VRP tree (and only if their hash is correct). There is no concept of previous repository state or some other file that is per accident around. -- :wq Claudio From nobody Thu Apr 2 03:18:43 2020 Return-Path: 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 197FB3A0F2C for ; Thu, 2 Apr 2020 03:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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=instituut-net.20150623.gappssmtp.com 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 65ztqwnmdtPi for ; Thu, 2 Apr 2020 03:18:39 -0700 (PDT) Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (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 330123A0F1A for ; Thu, 2 Apr 2020 03:18:38 -0700 (PDT) Received: by mail-wm1-x343.google.com with SMTP id f6so2993947wmj.3 for ; Thu, 02 Apr 2020 03:18:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=VufYJJHOtlSgDkR4Qt30/EV6STxRn5B+yH0kzknLRqg=; b=GG3rvD/9cR5c9NeebmOKiR9Eh0ZiCfJfHjIa6dAHF5Nkhkn1lOhF+4IjC5wI/sKK/j 80Zh6J3AjXbpJbMdMRpm9Eqpa0c1Igqwgr5ug5ZsiZgyHE6OyX79frWTEb4g4ZeEHBsp imgPbiDafdGdS2+CXURs0VoIRaB3h1rwcbM6pYzG4B9J3H1AE29qmomp+clytvCn9o/l 9kEnsVOJ+O6uKNPYVKgJpaSf0asOq7qctNQY79qz0CMvnmE3/YwwNoz47BEkhzccX+67 HB1zAXvqe2DPLJk6bhzXoPpPaxdrEH+oblEIlvLAUE9oq5EJHO85buNTaf7qr/WGv4KR 6s8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=VufYJJHOtlSgDkR4Qt30/EV6STxRn5B+yH0kzknLRqg=; b=WOlRZnT49rsfhNskPQCizVM/Iw27He7eW0qyzeSp8W8gyNovxUVN911wiCcESW94IZ AbdjT9vK/Rh89DPxyYBHFwPPP6kIKHhlecLZqRgkaHFWDjgY6qfILhJQya/aQO6JKuAp h0UvU66Sr/vLXZzZispx+tY510cIwZYdErVp2FQ11j8MNH4aYujC3yxHaDUyCwahifk3 7YQOJbUim8dGTZ31Y/DmOeO6mEX+9U4biXMsPAEwJWRhY+5zxgF2COcJaEjDChZhF4Hv Daw6h1AT/tadnu3qr+c5LeU/S1REAVwJKc7n4zSITy+PgyVqzTN9HFCVZQc5C+agaKZF PMAw== X-Gm-Message-State: AGi0PuY6paWZfKFOPlJVPlyTgCeCroYgzEYkLr4ipLmx4E5itx7t1T8J z1CgWlb8uQURrIgJUJGanA0D0w== X-Google-Smtp-Source: APiQypI9eAfNAv9FC3iKXcGX1ql8FAmpPUa1AWIChBXLbk4aiWMeLwqZkj6m+POhNlYwMFEcAjjHGg== X-Received: by 2002:a1c:4c19:: with SMTP id z25mr2697161wmf.53.1585822717047; Thu, 02 Apr 2020 03:18:37 -0700 (PDT) Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id y4sm6593689wrl.40.2020.04.02.03.18.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Apr 2020 03:18:36 -0700 (PDT) Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 7f50b694; Thu, 2 Apr 2020 10:18:35 +0000 (UTC) Date: Thu, 2 Apr 2020 10:18:34 +0000 From: Job Snijders To: Martin Hoffmann Cc: George Michaelson , Christopher Morrow , SIDR Operations WG Message-ID: <20200402101834.GA60268@vurt.meerval.net> References: <3B072025-68C5-4E62-9466-5122D483F691@nlnetlabs.nl> <20200324135828.GG60268@vurt.meerval.net> <20200324152009.6e6a2c3f@glaurung.nlnetlabs.nl> <20200324151101.GH60268@vurt.meerval.net> <7f54a255-643f-cd2d-12c2-da19562bbffa@verizon.net> <7465c59f-fa10-4083-8e52-291cb47587f6@www.fastmail.com> <20200402114606.68abed9c@glaurung.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200402114606.68abed9c@glaurung.nlnetlabs.nl> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 10:18:41 -0000 On Thu, Apr 02, 2020 at 11:46:06AM +0200, Martin Hoffmann wrote: > George Michaelson wrote: > > I would remind people that *all* the products in a repository are > > signed objects. To arrive at a state where a manifest is "wrong" > > demands two things: it doesn't reflect some real-world situation > > regarding contents of the repository *and* its signed by keys you can > > validate back to a trust anchor. If you cannot validate the manifest, > > then its not "wrong" its forged, or invalid cryptographically. To me, > > a "wrong" manifest checks out cryptographically but somehow is not > > coherent with the state of the repository. > > I think we are still having this conceptually backwards: It isn’t the > manifest that is wrong, it is the repository content. Whether it was > originally intended that way or not, having a manifest at all to me only > makes sense if it is considered to contain the truth, the whole truth, > and nothing but the truth. > > I honestly believe that the current state of affairs where basically > the guidance for RP software developers is to look at the current > repository content, past repository content, the manifest and the CRL > and then figure stuff out themselves is rather ... unfortunate and > doesn’t exactly improve the confidence in the overall system. > > Given the inherent complexities of a distributed repository, it seems > important to me to make the system as straightforward as possible to > implement. Declaring the manifest to be the sole list of currently > published objects is a means to this end. I agree, straightforwardness is crucial here. rpki-client has now implemented mitigations as following: When the manifest is valid (valid in the sense that the signatures check out, the CRL is not expired, the manifest file format is correct), and it references .roa files which are either missing from the repository, or where the .roa file's hash does not match with the hash listed in the manifest, rpki-client will not output any VRPs that could potentially be extracted from the remaining .roa files at that level of the tree. At the MITM layer one roa is hidden from the view: job@mieli:~/fake-ripe-repo$ rm repository/DEFAULT/3e/01d411-d915-4277-8fe2-76b0dda2bf3e/1/LkKeUPYrfgzjsOIejLjsHGk44cU.roa After this partial witholding attack, the validator under attack will emit this error: rpki-client: rpki.ripe.net/repository/DEFAULT/3e/01d411-d915-4277-8fe2-76b0dda2bf3e/1/1-tcQDnftkRnWbiMhu2cR1-dgmCs.mft: referenced file LkKeUPYrfgzjsOIejLjsHGk44cU.roa: No such file or directory which results in no VRPs being emitted from any .roa files that 1-tcQDnftkRnWbiMhu2cR1-dgmCs.mft referenced: job@anton ~$ grepcidr 80.128.0.0/11 /var/db/rpki-client/openbgpd job@anton ~$ The above is the *safe* outcome, because the attacker is now limited to the ability to flip BGP announcements from 'valid' to 'not-found', instead of 'invalid' (in case the validator has not been patched). Scenarios where routes flip to 'invalid' represent hard outages. The operator's understanding of the RPKI is that when things go wrong in the RPKI, BGP routes potentially change state to 'not-found'. In other words, because LkKeUPYrfgzjsOIejLjsHGk44cU.roa is missing, the following .roa files are *not* parsed: repository/DEFAULT/3e/01d411-d915-4277-8fe2-76b0dda2bf3e/1/IM3xMiMU1QChuWMOGgnbDwYolrU.roa repository/DEFAULT/3e/01d411-d915-4277-8fe2-76b0dda2bf3e/1/NpI_Uj3OZb6jvwfUTX0-eOk9QV4.roa repository/DEFAULT/3e/01d411-d915-4277-8fe2-76b0dda2bf3e/1/fIeCcC8KpdJQd-olU2APdxNZkyA.roa repository/DEFAULT/3e/01d411-d915-4277-8fe2-76b0dda2bf3e/1/r5vtD4isKhTzGXNGulSnZ7XCS04.roa repository/DEFAULT/3e/01d411-d915-4277-8fe2-76b0dda2bf3e/1/r7TSyWn_GbYPjNWvt4r5ewSNAsk.roa Even though they are referenced in 1-tcQDnftkRnWbiMhu2cR1-dgmCs.mft (valid), and the remaining .roa files are valid themselves. Proceeding to output VRPs derived from say 7TSyWn_GbYPjNWvt4r5ewSNAsk.roa while LkKeUPYrfgzjsOIejLjsHGk44cU.roa is missing is akin to "garbage in garbage out". Manifests are truth. A repository can contain /more/ files than referenced in the manifest files, but not *less*. Kind regards, Job From nobody Thu Apr 2 07:08:26 2020 Return-Path: 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 574813A10BD; Thu, 2 Apr 2020 05:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=LPj2u8XP; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=WyjJ9Edl 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 JBHmv1p3V_5V; Thu, 2 Apr 2020 05:01:48 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98AA73A10BA; Thu, 2 Apr 2020 05:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1332; q=dns/txt; s=iport; t=1585828908; x=1587038508; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Hy0mpr0L/skcmPVILB2+4qbdp2BOIlIE160Y5pVw4zw=; b=LPj2u8XPZq7PbX7plnzu0l6Bsc28RHl4FMscFLchNrUUZM5VAZmfU0l8 I69sZSxJaLY+uDlzQ0nBSno34XTIItnynd+An6bQ2JzDrnIlx7njJJvsV lW/4bOqrCicnMzvugZVGbW1tj7yBYbIsfe0zSKqP6sp5i2VEnAcaCa/YN 0=; IronPort-PHdr: =?us-ascii?q?9a23=3Ai7gYsBTwdswZqC8gnqD6DZU0gtpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBdfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOiEkDcJJV1JN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CxAADz0oVe/4gNJK1mGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF7gVRQBWxYIAQLKoQbg0UDimyCX4ltjjGCUgN?= =?us-ascii?q?UCgEBAQwBARgLCgIEAQGERAIXgikkOBMCAwEBCwEBBQEBAQIBBQRthVYMhXA?= =?us-ascii?q?BAQEBAwEBEBERDAEBLAsBCwQCAQgRAwECAwImAgICHwYLFAEICAIEAQ0FIoM?= =?us-ascii?q?EAYJLAy4BDqQUAoE5iGJ1gTKCfwEBBYUyDQuCDAMGgQ4qjDEagUE/gTgggk0?= =?us-ascii?q?+gh5JAQGBZYMSMoIskQKfPkYKgj2SYwSENB2SPIk2jymLW5A7AgQCBAUCDgE?= =?us-ascii?q?BBYFpIoFXcBU7KgGCPlAYDY4dg3OFFIVBdIEpjh4BAQ?= X-IronPort-AV: E=Sophos;i="5.72,335,1580774400"; d="scan'208";a="457160857" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Apr 2020 12:01:46 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 032C1kwH028993 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 Apr 2020 12:01:46 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 2 Apr 2020 07:01:46 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 2 Apr 2020 07:01:45 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 2 Apr 2020 07:01:45 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N55JaUZfWJxr9LYH/MBujOKjJrBYeZMNpgE9uxvWojaphtXtNtKNkkzqwljwdmAzDaq06BI3QQBliDR1rYezqe9Fsllh/PY2JvvOupf+yLPxTHeWvQ46Y2JQr51VWh/5jHdnsCGDrDe0/Zdf+4nERTbYGgyFjGbZmVdx4Eu1w/4POEtkYKE3vnPArsNvT++MZPbeeQpYwF4WYQ2C1zbNiaKR6hWlz12dNmQoisIRviBLH9V4EBn1GG8ivtZ8dicUjaaf5JCWaEFp/hCrd/J8a7rC2a4tFDpVWRDHjkVff0oPBdawfVLw9YMMAfGp5i555DTWE67PxFpN4eNeaF+h6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Hy0mpr0L/skcmPVILB2+4qbdp2BOIlIE160Y5pVw4zw=; b=PET9XFUrVeHUTAeTfD92N5XTvCiAfjTNG1Q/gS/+hV70IT59jgla/Ztyz6G3ef79D/HMJw5pqI9rPz1I8Z65Y+ovBMyDs9zDSB4nlD8heMwxyGjnfpCHLAMAh5AmUWSEqkEqfEWvuH8G52mrhPKXbQ5RPAPc/GCd6ut/cHfod3bVAh6eb63UzVBsGDFJk8mjK53tWIgyAdFcwTaiDo0KSIuXbWUUO5AT45vm7Ld0lCi7bjM3BnOzWnWUGYwpPkoF0yxjizMS1Cos+V0cyhCHrb0mC7HooMHhx5p9RdyGG2QdDylpxXX57QOIbRWPj4zHnBIfVNNH1iKH63SwwORBFQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Hy0mpr0L/skcmPVILB2+4qbdp2BOIlIE160Y5pVw4zw=; b=WyjJ9EdlDIq90fupB1CrC3wHQSlUNV3NEwMvx9z+au8/TjECjKvZUpL1b8D8Bpl1CGkKCVN6MgoMHWnGWhCvEcJ4AkOCgMse9hGW2QXvhpN7oyHr/cnzdEKt8+H8QLIDNBdeWda8a6q5FPNX8v2iYKiiXZKQkKnFXCQeSeGfUDM= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (2603:10b6:3:10d::13) by DM5PR11MB0076.namprd11.prod.outlook.com (2603:10b6:4:6b::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Thu, 2 Apr 2020 12:01:45 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::680d:e22e:72d5:67ca]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::680d:e22e:72d5:67ca%3]) with mapi id 15.20.2856.019; Thu, 2 Apr 2020 12:01:45 +0000 From: "Eric Vyncke (evyncke)" To: Jouni Korhonen , "int-dir@ietf.org" CC: "last-call@ietf.org" , "sidrops@ietf.org" , "draft-ietf-sidrops-ov-egress.all@ietf.org" Thread-Topic: [Int-dir] Intdir telechat review of draft-ietf-sidrops-ov-egress-02 Thread-Index: AQHWCHNPCt3H6YeVRkO26Wz411x8+ahl3ZQA Date: Thu, 2 Apr 2020 12:01:45 +0000 Message-ID: <1E8D4B13-FFCB-42CD-BC05-73060C9548BE@cisco.com> References: <158577942531.31132.14192491820838585248@ietfa.amsl.com> In-Reply-To: <158577942531.31132.14192491820838585248@ietfa.amsl.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:ad33:1e6:78ba:617b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e7ff31d4-4724-487a-503b-08d7d6fd9d7f x-ms-traffictypediagnostic: DM5PR11MB0076: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 0361212EA8 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB1753.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(136003)(396003)(346002)(39860400002)(376002)(6486002)(110136005)(4326008)(33656002)(54906003)(5660300002)(2906002)(966005)(71200400001)(316002)(478600001)(36756003)(6506007)(6512007)(66946007)(81166006)(76116006)(186003)(53546011)(91956017)(2616005)(86362001)(66556008)(66446008)(8936002)(64756008)(8676002)(66476007)(4744005)(81156014); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YcEaVWKaBn7o6pvGjqrH2apFzn3KpsAUiMnC3cyXFhIveHvi5mCwYhPyj5V7eaY4PkfBOHJP1Apo4RO4XZlJJ/Fl0DLpAQypaPiKcfzDbJ5/DfH4qTcv84o3ON6TqAzfjz1tPTuRJCo+aCWXVfglwXf4pFrgPowpw+6rBtNZNHCHZNwGosHVoG5VHP3mbtrP/ZWHN0vlFJu8oSmQqWrfx/Iyk/BOudXQaL/0cS+0amt6KfdrhDF8z22xflhJuAhxTpKyujcDf9Y1o/YTbO8We8o5XueWVJnfJt6yFx0MHj4Us88Gc+uOyyjzWKZftH52cNC6lViazk8F5aZzb+GrdqYobjmIIXjrYFh6oOHRNwPqRP6rgB3v67wDQZ/naYg5J8k1MIJnZpQRznOKi6TMN2JEU0ENZPC/UJskNVnTjUnuQ//MzKpaoMQJksMkVcOppuxUgosktaQDLsERQ0yU8wA4CSEyV2pKCVa/54k8yYeSokTWcxIp1FNRR4oWuxMZg1dg8UrlLhVdARpDibjBoA== x-ms-exchange-antispam-messagedata: xsuqjmQRI8QETrOmJGUo2tmrD4CNymR5mFMAnoOQLy+TMVBRztZ0gRSuM1WvPFYWK/+KQcSPFa6hP26lKKpoilaQVNcCBRnAViFzjVTN+wNzlohEQmOzHcLR28IzW3R//qj+o00Tb/nFjwkayazsxkQ5XH3r1BWRgPJBvotHMF/T/+UFvZgEJOXH5vKX9Pe3Up8boIhSNUrlnGQC/fOA5g== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e7ff31d4-4724-487a-503b-08d7d6fd9d7f X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2020 12:01:45.2231 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jB2TC9RmGLWobKm2dCdv5+mG8jpQylIQRmekiES00mrBcGV4n6szB4ux6sWSQGYWwm4p/c1OH4V7wSzGASAIxw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB0076 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: X-Mailman-Approved-At: Thu, 02 Apr 2020 07:08:24 -0700 Subject: Re: [Sidrops] [Int-dir] Intdir telechat review of draft-ietf-sidrops-ov-egress-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 12:01:51 -0000 VGhhbmsgeW91IEpvdW5pIGZvciB0aGUgcmV2aWV3DQoNCi3DqXJpYw0KDQrvu78tLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSW50LWRpciA8aW50LWRpci1ib3VuY2VzQGlldGYub3Jn PiBvbiBiZWhhbGYgb2YgSm91bmkgS29yaG9uZW4gdmlhIERhdGF0cmFja2VyIDxub3JlcGx5QGll dGYub3JnPg0KUmVwbHktVG86IEpvdW5pIEtvcmhvbmVuIDxqb3VuaS5ub3NwYW1AZ21haWwuY29t Pg0KRGF0ZTogVGh1cnNkYXksIDIgQXByaWwgMjAyMCBhdCAwMDoxNw0KVG86ICJpbnQtZGlyQGll dGYub3JnIiA8aW50LWRpckBpZXRmLm9yZz4NCkNjOiAibGFzdC1jYWxsQGlldGYub3JnIiA8bGFz dC1jYWxsQGlldGYub3JnPiwgInNpZHJvcHNAaWV0Zi5vcmciIDxzaWRyb3BzQGlldGYub3JnPiwg ImRyYWZ0LWlldGYtc2lkcm9wcy1vdi1lZ3Jlc3MuYWxsQGlldGYub3JnIiA8ZHJhZnQtaWV0Zi1z aWRyb3BzLW92LWVncmVzcy5hbGxAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbSW50LWRpcl0gSW50ZGly IHRlbGVjaGF0IHJldmlldyBvZiBkcmFmdC1pZXRmLXNpZHJvcHMtb3YtZWdyZXNzLTAyDQoNCiAg ICBSZXZpZXdlcjogSm91bmkgS29yaG9uZW4NCiAgICBSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRo IE5pdHMNCiAgICANCiAgICBJIGZvdW5kIHRoZSBkb2N1bWVudCByZWFkeSBmb3IgcHVibGljYXRp b24gd2l0aCBvbmUgZWRpdG9yaWFsIG5pdC4NCiAgICBUaGUgYWJzdHJhY3QgZG9lc24ndCBtZW50 aW9uIHRoYXQgdGhpcyBkb2N1bWVudCB1cGRhdGVzIFJGQzY4MTEsIHdoaWNoIGl0IHNob3VsZC4N CiAgICANCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KICAgIEludC1kaXIgbWFpbGluZyBsaXN0DQogICAgSW50LWRpckBpZXRmLm9yZw0K ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW50LWRpcg0KICAgIA0K DQo= From nobody Thu Apr 2 07:19:02 2020 Return-Path: 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 492AE3A1337 for ; Thu, 2 Apr 2020 07:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=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=gmail.com 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 DWleKuWgtfvB for ; Thu, 2 Apr 2020 07:18:59 -0700 (PDT) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 E16DD3A1326 for ; Thu, 2 Apr 2020 07:18:58 -0700 (PDT) Received: by mail-qv1-xf2f.google.com with SMTP id n1so1715013qvz.4 for ; Thu, 02 Apr 2020 07:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4HnLPwxmm34eZKzEs/5mNzw8WW57rouqk8RUY3nB5ac=; b=a5MlnJ9YUZiuZtJ2hh/7IByXoDtBwda5Fo//dfARQ8b1FpCIri6CnQK9yWRcIbemLg XlKgrFKe/hIT0oGnOqByoYY7Tbl7ONkyQSx7wEDr0j4DjE5p2JEOcSc3283c06MdyraY UFuH5+xNcFaW685DsYZoEGtADqBRymqEShE8CKJCUvRuqZbEjUnzxCfloNULqNai/HL6 ZI+koGgU84YVTAMVmCKGgqJleV6HKnutAJO6NejJ6nRqcgwsbET4q2JBTMYV03IxiVtA 6qG+AllaBWrI+vwoAq+09laKqIvyGRK4/UvTRYxqV2+O3YONYpGXp41d6Iwy3+H+TZK8 TsnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4HnLPwxmm34eZKzEs/5mNzw8WW57rouqk8RUY3nB5ac=; b=mUvPwgiDPRrVJLl5y3xCjqGFu+8MpnXDOcFqP/stwoa16SZvtOcYQkphOH74pLgH2T Y3QhhZ23LnJOVriip/8TnVVN0TC7QvO9W9LBbCldV/GxaMxQgPs9hk0CuKz9C7grVX/L EWhRXMX8Fc8a1ZQMqSRgjLVvuhkmWsTaVqiFlR3RPpDrO9F3JjqiCdOAToZULQbZvWtS MbpEcXMgpTCzhTWIjcaD6McRC8i1YpBg2TG87fdoyta5M6OT6qK4y9zngJt8/kdfQ0J4 hTc93VK4l/GZIiNrSrvQFs2QqkdumkIQ8WjFVpuKyrRtq6Ea5EFo5J+9g94XLs2AYusb XPZw== X-Gm-Message-State: AGi0PuadvkHFJCLc2/I5PfXtXgRyE8bhVm6cw4Nwmi00BVukYtiHpcrf fg65qT9bWWTWi21iyLZ4qWJlQZEH4VytU5VFOjE= X-Google-Smtp-Source: APiQypI+/0+eFzpqoNhYLNUhrPtEjf55JjG1TJctAkdVqSrlp/51RCNbT4P+vxMaLLHFd7OoUiYAPVQTRh/205MzV00= X-Received: by 2002:a0c:aee5:: with SMTP id n37mr3266680qvd.173.1585837137606; Thu, 02 Apr 2020 07:18:57 -0700 (PDT) MIME-Version: 1.0 References: <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> <3a683da4-42f9-28c6-f0dd-4d11d3c67857@ripe.net> <4fe26a30-4a08-41a5-be7f-0c5997230d0a@www.fastmail.com> <3B072025-68C5-4E62-9466-5122D483F691@nlnetlabs.nl> <20200324135828.GG60268@vurt.meerval.net> <20200324152009.6e6a2c3f@glaurung.nlnetlabs.nl> <20200324151101.GH60268@vurt.meerval.net> <7f54a255-643f-cd2d-12c2-da19562bbffa@verizon.net> <7465c59f-fa10-4083-8e52-291cb47587f6@www.fastmail.com> <6c7d5f08-20d5-f4d7-18a2-04fa3ae87067@ripe.net> In-Reply-To: <6c7d5f08-20d5-f4d7-18a2-04fa3ae87067@ripe.net> From: Christopher Morrow Date: Thu, 2 Apr 2020 10:18:46 -0400 Message-ID: To: Robert Kisteleki Cc: SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 14:19:01 -0000 On Thu, Apr 2, 2020 at 4:02 AM Robert Kisteleki wrote: > > > >> So it is right time to reconsider the requirements posed on RP in case= of =E2=80=9Cwrong=E2=80=9D MFT. > > > > yes this last sentence is the discussion I'd like to see happen... I > > think guiding that with: > > "Here are the ways an manifest could go badly: bad sig, bad content, > > missing content, missing manifest..." > > > > and: > > "given the damage from X, Y, Z, the proposed actions for an RP > > are... because ..." > > I was thinking along the same lines while having a related conversation > with Job/Tim here: > > > I believe a more nuanced approach is needed, like if there's a problem > > on a particular validation path (a cert is missing or has an error) the= n > > invalidate that path, if a CRL is missing then warn but use a stale one= , > > but leave the otherwise unaffected bits validated. > > If repository R hosts objects for CAs A, B, ... Z, A has subtrees > A1...A9 and there's a problem with the manifest of A1, the rest (B..Z) > is perfectly fine an usable. IMO A2..A9 are fine as well. As for A1: the > RP action IMO should really depend on what the exact issue is, for exampl= e: > - an object is missing: check if you have it from the previous run and > if so, use it I would like to believe that whether a repository is 1 organization (one repository only vaslii!) or an organization that is hosting many repositories, the story about CRL/MFT is the same, at the single repository level. In practical terms this means that RIR who host 'large numbers of repositories for their customers' are really just running a slew of little items. Any breakage at the individual level is indistinguishable from that which a self-hosted ca/repository may make. At the top of the tree, yes there are more possible ways to get broken, and the effect on the locally-hosted (or self-hosted far away!) repositories from breakage up-tree is certainly bad... but I'd rather not get lost in that discussion. > - a CRL is missing / corrupt / expired: warn but use the previous one > > I'd be happy to contribute and I think that if this happens, > contribution from operator(s) would be extremely useful. > ok, I think for the upcoming interim let's see if we can have a strawman to discuss :) From nobody Thu Apr 2 10:24:20 2020 Return-Path: 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 3F5823A0AA1; Thu, 2 Apr 2020 10:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 BBxCHSNThqJE; Thu, 2 Apr 2020 10:24:16 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8E193A0A52; Thu, 2 Apr 2020 10:24:16 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jK3Zf-0000Pa-C6; Thu, 02 Apr 2020 17:24:15 +0000 Date: Thu, 02 Apr 2020 10:24:14 -0700 Message-ID: From: Randy Bush To: Jouni Korhonen via Datatracker Cc: , draft-ietf-sidrops-ov-egress.all@ietf.org, last-call@ietf.org, sidrops@ietf.org In-Reply-To: <158577942531.31132.14192491820838585248@ietfa.amsl.com> References: <158577942531.31132.14192491820838585248@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Intdir telechat review of draft-ietf-sidrops-ov-egress-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 17:24:19 -0000 warren informed me that fashions had changed, and indeed an 'updates' goes in the abstract. -03 will have Abstract A BGP speaker may perform RPKI origin validation not only on routes received from BGP neighbors and routes that are redistributed from other routing protocols, but also on routes it sends to BGP neighbors. For egress policy, it is important that the classification uses the effective origin AS of the processed route, which may specifically be altered by the commonly available knobs such as removing private ASs, confederation handling, and other modifications of the origin AS. This document updates [RFC6811]. randy From nobody Thu Apr 2 13:48:28 2020 Return-Path: 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 641233A194C for ; Thu, 2 Apr 2020 13:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no 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 BAW1wtpr07v9 for ; Thu, 2 Apr 2020 13:48:25 -0700 (PDT) Received: from hrabosky.cbbtier3.att.net (braeburn.org [12.0.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC573A194D for ; Thu, 2 Apr 2020 13:48:25 -0700 (PDT) Received: from oz.mt.att.com (zoe.cbbtier3.att.net [12.0.1.45]) by hrabosky.cbbtier3.att.net (Postfix) with ESMTP id 46C592D7FE for ; Thu, 2 Apr 2020 20:48:24 +0000 (UTC) Received: by oz.mt.att.com (Postfix, from userid 1000) id 1B374A407C8; Thu, 2 Apr 2020 16:48:24 -0400 (EDT) X-Mailer: emacs 24.3.1 (via feedmail 11-beta-1 I); VM 8.2.0b under 24.3.1 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24198.20355.168888.506246@oz.mt.att.com> Date: Thu, 2 Apr 2020 16:48:03 -0400 From: Jay Borkenhagen To: sidrops@ietf.org In-Reply-To: <75140927-0b8b-07ab-ad2e-952e32256df1@verizon.net> References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <20200226173935.GE72144@vurt.meerval.net> <2db8d19a-6f91-d2fc-36c3-65742ba77e6c@ripe.net> <8B09B96B-432C-4190-9DE0-DC2004AAFCC2@nlnetlabs.nl> <75140927-0b8b-07ab-ad2e-952e32256df1@verizon.net> Reply-To: Jay Borkenhagen X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 20:48:27 -0000 Hi, Re-visiting an older message in preparation for the upcoming SIDROPS virtual interim meeting. On 23-March-2020, Stephen Kent writes: > I agree that more uniform processing is desirable, but in the routing > system the notion of local policy seems to be ingrained, so ... When I first saw this, I thought Steve was just making a pithy comment about local policy and network operators. But a friend thinks Steve had not meant it as a joke at all, so let me take Steve's comment at face value and respond: As a network operator, yes, I expect to have the flexibility of configuring my network using local policy. But in the context of the RPKI, we need to reach a point where all RFC-compliant RPs will generate identical sets of VRPs when presented with the same input. There will be reasons why I may prefer to operate one RP over another, but the VRPs that a particular RP generates should never be one of them. No network operators want to specify any 'local policy' on their RP instances to control under which conditions an RPKI object would be accepted. Some network operators in this WG have voiced strong opinions about how such acceptance should be decided, but that's not because they want the ability to exert local policy there. Such opinions are all toward the goal we share of all implementations reliably creating a correct/consistent VRP set. I encourage feedback from other network operators on this one simple point. Hopefully we all see this 'local policy' matter the same way, and the WG can turn its attention to consistent handling of the corner cases. Thanks. Jay B. From nobody Thu Apr 2 14:32:11 2020 Return-Path: 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 EFD973A1A36 for ; Thu, 2 Apr 2020 14:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 BK-j_Xfy4Mbn for ; Thu, 2 Apr 2020 14:32:08 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE24B3A1A34 for ; Thu, 2 Apr 2020 14:32:08 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jK7RW-0000zr-70; Thu, 02 Apr 2020 21:32:06 +0000 Date: Thu, 02 Apr 2020 14:32:05 -0700 Message-ID: From: Randy Bush To: Jay Borkenhagen Cc: SIDR Operations WG In-Reply-To: <24198.20355.168888.506246@oz.mt.att.com> References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <20200226173935.GE72144@vurt.meerval.net> <2db8d19a-6f91-d2fc-36c3-65742ba77e6c@ripe.net> <8B09B96B-432C-4190-9DE0-DC2004AAFCC2@nlnetlabs.nl> <75140927-0b8b-07ab-ad2e-952e32256df1@verizon.net> <24198.20355.168888.506246@oz.mt.att.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 21:32:10 -0000 credit where due department: > As a network operator, yes, I expect to have the flexibility of > configuring my network using local policy. But in the context of the > RPKI, we need to reach a point where all RFC-compliant RPs will > generate identical sets of VRPs when presented with the same input. > There will be reasons why I may prefer to operate one RP over another, > but the VRPs that a particular RP generates should never be one of > them. > > No network operators want to specify any 'local policy' on their RP > instances to control under which conditions an RPKI object would be > accepted. Some network operators in this WG have voiced strong > opinions about how such acceptance should be decided, but that's not > because they want the ability to exert local policy there. Such > opinions are all toward the goal we share of all implementations > reliably creating a correct/consistent VRP set. you have been testing RP compliance to this for a good number of years, and having quiet chats with RP implementors. this has really helped and is much appreciated. randy From nobody Thu Apr 2 16:05:22 2020 Return-Path: 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 C9C6B3A1BCB for ; Thu, 2 Apr 2020 16:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 P9Yj-HUA5hTL for ; Thu, 2 Apr 2020 16:05:17 -0700 (PDT) Received: from smtp-relay2.web-server.biz (smtp-relay2.web-server.biz [137.74.38.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74EF73A1BC8 for ; Thu, 2 Apr 2020 16:05:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-relay2.web-server.biz (Postfix) with ESMTP id 93AA71C91F for ; Fri, 3 Apr 2020 01:05:15 +0200 (CEST) Received: from smtp-relay2.web-server.biz ([137.74.38.202]) by localhost (smtp-relay2.web-server.biz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNW9D3Kg3JKR for ; Fri, 3 Apr 2020 01:05:13 +0200 (CEST) Received: from mail5.web-server.biz (www5.web-server.biz [185.181.105.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-relay2.web-server.biz (Postfix) with ESMTPS id 2C3DB1CA00 for ; Fri, 3 Apr 2020 01:05:13 +0200 (CEST) Received: from mail-il1-f180.google.com (mail-il1-f180.google.com [209.85.166.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail5.web-server.biz (Postfix) with ESMTPSA id 5E30847C77 for ; Thu, 2 Apr 2020 23:05:07 +0000 (UTC) Received: by mail-il1-f180.google.com with SMTP id j9so5408812ilr.7 for ; Thu, 02 Apr 2020 16:05:07 -0700 (PDT) X-Gm-Message-State: AGi0PuYwgSz4fCwiuLg5k+Pyuxcw7F/hT3LAfjW5VUNWhrhrbFSqO0q3 E3hnTlSKe3tr8By0zRr7RjeQQKdd8PVFnV20I8A= X-Google-Smtp-Source: APiQypLOO3Ydqc/r81rGXCMnaAZHMc1akLBEq7FRxVPShK9r+DLnJ1HBwjXYoEMK5HEep2b/EOXEhmXKCpmsjY9cb94= X-Received: by 2002:a05:6e02:54e:: with SMTP id i14mr6149983ils.166.1585868706596; Thu, 02 Apr 2020 16:05:06 -0700 (PDT) MIME-Version: 1.0 References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <20200226173935.GE72144@vurt.meerval.net> <2db8d19a-6f91-d2fc-36c3-65742ba77e6c@ripe.net> <8B09B96B-432C-4190-9DE0-DC2004AAFCC2@nlnetlabs.nl> <75140927-0b8b-07ab-ad2e-952e32256df1@verizon.net> <24198.20355.168888.506246@oz.mt.att.com> In-Reply-To: <24198.20355.168888.506246@oz.mt.att.com> From: Lukas Tribus Date: Fri, 3 Apr 2020 01:04:55 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Jay Borkenhagen Cc: sidrops@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 23:05:19 -0000 Hello, On Thu, 2 Apr 2020 at 22:48, Jay Borkenhagen wrote: > No network operators want to specify any 'local policy' on their RP > instances to control under which conditions an RPKI object would be > accepted. Some network operators in this WG have voiced strong > opinions about how such acceptance should be decided, but that's not > because they want the ability to exert local policy there. Such > opinions are all toward the goal we share of all implementations > reliably creating a correct/consistent VRP set. > > > I encourage feedback from other network operators on this one simple > point. Hopefully we all see this 'local policy' matter the same way, > and the WG can turn its attention to consistent handling of the corner > cases. As a network operator, and without commenting on low-level aspects, I expect (TL;DR: all the good and none of the bad stuff please): - all RP's to produce the same VRP sets, given the same input (otherwise we slow down detection of bugs, misconfigurations and attacks), I suggest to NOT implement different code paths and local policy exceptions. - the end-result of rsync vs RRDP to be the same, in every case, under every attack scenario - no MITM attacks possible that lead to incomplete VRP sets (with the supported retrieval methods, which still includes rsync) I wanna be able to run different RP's in my network, without my routers behaving differently based on whether they are currently considering RP implementation A or RP implementation B. I also expect some outages of RPKI infrastructure in the coming years, just as we had outages in the past and just like other ecosystems have (DNS, DNSSEC, TLS, etc). I consider that acceptable and realistic, realizing that there are some scenarios where this will not only cause NOTFOUNDs, but also false-positive INVALIDs. That's really bad, but it also will be very rare (losing a subset of ROAs at IRR level). But I would strongly encourage not to weaken or simplify the checks that are in place, despite being aware that hosting the repository is hard (atomic updates and all). Maybe we could come up with some best practices documentation about setup, maintenance of a repository (BCP?) for repository operators. I would like for the ecosystem to stay extendable if someday we want to add something other than ROA to it, and I would still like it to be cryptographically reliable and consistent in that (and every other) case. I know it's not that black and white, I realize I am grossly oversimplifying. But if I think about TLS or the WebPKI in general, lax rules, simplifications and fallbacks always turned out to be a bad idea in the end. lukas From nobody Thu Apr 2 17:29:42 2020 Return-Path: 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 BE1393A097D for ; Thu, 2 Apr 2020 17:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no 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 cYj-4ayXjkfB for ; Thu, 2 Apr 2020 17:28:42 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5D13A0969 for ; Thu, 2 Apr 2020 17:28:37 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jKACH-0001O1-4O; Fri, 03 Apr 2020 00:28:33 +0000 Date: Thu, 02 Apr 2020 17:28:31 -0700 Message-ID: From: Randy Bush To: Lukas Tribus Cc: Jay Borkenhagen , sidrops@ietf.org In-Reply-To: References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <20200226173935.GE72144@vurt.meerval.net> <2db8d19a-6f91-d2fc-36c3-65742ba77e6c@ripe.net> <8B09B96B-432C-4190-9DE0-DC2004AAFCC2@nlnetlabs.nl> <75140927-0b8b-07ab-ad2e-952e32256df1@verizon.net> <24198.20355.168888.506246@oz.mt.att.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 00:29:21 -0000 > - no MITM attacks possible that lead to incomplete VRP sets (with the > supported retrieval methods, which still includes rsync) you are asking for transport security. we chose not to take that path. if an evil monkey gets in the middle, it should be detectable. but the design does not prevent mitm. randy From nobody Fri Apr 3 00:22:21 2020 Return-Path: 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 EA49D3A12EE for ; Fri, 3 Apr 2020 00:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 gyDiD5o7XzXn for ; Fri, 3 Apr 2020 00:22:18 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 808B03A12EB for ; Fri, 3 Apr 2020 00:22:17 -0700 (PDT) Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id A033531271; Fri, 3 Apr 2020 09:22:15 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Fri, 3 Apr 2020 09:22:15 +0200 From: Martin Hoffmann To: Randy Bush Cc: Lukas Tribus , Jay Borkenhagen , sidrops@ietf.org Message-ID: <20200403092215.2482032b@glaurung.nlnetlabs.nl> In-Reply-To: References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <20200226173935.GE72144@vurt.meerval.net> <2db8d19a-6f91-d2fc-36c3-65742ba77e6c@ripe.net> <8B09B96B-432C-4190-9DE0-DC2004AAFCC2@nlnetlabs.nl> <75140927-0b8b-07ab-ad2e-952e32256df1@verizon.net> <24198.20355.168888.506246@oz.mt.att.com> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 07:22:20 -0000 Randy Bush wrote: > > - no MITM attacks possible that lead to incomplete VRP sets (with > > the supported retrieval methods, which still includes rsync) > > you are asking for transport security. we chose not to take that > path. if an evil monkey gets in the middle, it should be detectable. > but the design does not prevent mitm. It may also be worthwhile noting that this sort of thing is always a trade-off. If we too quickly discard suspicious data, it becomes all that much easier to disable origin validation as step one of a malicious route hijack. Kind regards, Martin From nobody Fri Apr 3 00:33:01 2020 Return-Path: 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 D9A523A1366 for ; Fri, 3 Apr 2020 00:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 gG7nnW8BuLFi for ; Fri, 3 Apr 2020 00:32:49 -0700 (PDT) Received: from smtp-relay2.web-server.biz (smtp-relay2.web-server.biz [137.74.38.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AAFE3A1333 for ; Fri, 3 Apr 2020 00:32:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-relay2.web-server.biz (Postfix) with ESMTP id EF93C1CD42 for ; Fri, 3 Apr 2020 09:32:46 +0200 (CEST) Received: from smtp-relay2.web-server.biz ([137.74.38.202]) by localhost (smtp-relay2.web-server.biz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FQ9Y0erH58Z for ; Fri, 3 Apr 2020 09:32:44 +0200 (CEST) Received: from mail5.web-server.biz (www5.web-server.biz [185.181.105.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-relay2.web-server.biz (Postfix) with ESMTPS id 0F2051CD19 for ; Fri, 3 Apr 2020 09:32:44 +0200 (CEST) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail5.web-server.biz (Postfix) with ESMTPSA id 8E60C47C77 for ; Fri, 3 Apr 2020 07:32:39 +0000 (UTC) Received: by mail-io1-f47.google.com with SMTP id i3so6439124ioo.13 for ; Fri, 03 Apr 2020 00:32:39 -0700 (PDT) X-Gm-Message-State: AGi0Pua9SB5sDBvW1HPXyVyPnlicKhWd100aZXhzRTwwo032jZ/Hcn/7 gHjfXCCyT5FB7jhjuWGLvCN5GWj77cX9+iz1Gk0= X-Google-Smtp-Source: APiQypKqYeQ+J8zU/ntUkf1dnpxTxAAPEy0iAC354aFeJOF29B2WYB5DKdzwxHigpZOzmzbx91eOtE35rda4UD28gpY= X-Received: by 2002:a02:b616:: with SMTP id h22mr7290162jam.126.1585899157861; Fri, 03 Apr 2020 00:32:37 -0700 (PDT) MIME-Version: 1.0 References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <20200226173935.GE72144@vurt.meerval.net> <2db8d19a-6f91-d2fc-36c3-65742ba77e6c@ripe.net> <8B09B96B-432C-4190-9DE0-DC2004AAFCC2@nlnetlabs.nl> <75140927-0b8b-07ab-ad2e-952e32256df1@verizon.net> <24198.20355.168888.506246@oz.mt.att.com> In-Reply-To: From: Lukas Tribus Date: Fri, 3 Apr 2020 09:32:26 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Randy Bush Cc: Jay Borkenhagen , sidrops@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 07:33:00 -0000 Hello Randy, On Fri, 3 Apr 2020 at 02:28, Randy Bush wrote: > > > - no MITM attacks possible that lead to incomplete VRP sets (with the > > supported retrieval methods, which still includes rsync) > > you are asking for transport security. we chose not to take that path. > if an evil monkey gets in the middle, it should be detectable. but the > design does not prevent mitm. What I'm trying to say is something different: We promised transport agnostic security. I'm asking that we maintain that promise. But if we are unable to maintain that promise and start relying on transport security, then we need to actually fully admit that and drop rysnc. This is because I read some arguments on this list akin to "well this attack will not work against RRDP, so only rsync ...". What I am saying is that: we should maintain the same guarantees and consistencies at the end of the day with both retrieval methods. I understand MITM - as in denying the *entire* service - is an attack that affects both retrieval methods. That's ok. What would be unacceptable for me is that a repository retrieved via rsync could be affected by a partial withhold attack, withholding some VRP's. The TL;DR here is, as a network operator, I expect both retrieval methods to provide the same kind of assurances, consistencies and security guarantees. On the other hand, if rsync is a second class citizen, then we need big fat warnings about rsync. Lukas From nobody Fri Apr 3 01:12:44 2020 Return-Path: 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 922DB3A13E6 for ; Fri, 3 Apr 2020 01:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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 (1024-bit key) header.d=nlnetlabs.nl 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 J4ogCdqPKYNm for ; Fri, 3 Apr 2020 01:12:39 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 243FF3A13E2 for ; Fri, 3 Apr 2020 01:12:39 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:2502:d63b:9003:3606] (unknown [IPv6:2001:981:4b52:1:2502:d63b:9003:3606]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 2C0DC313A3; Fri, 3 Apr 2020 10:12:37 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1585901557; bh=WiNeHw5eFc09jujebhjKVZe5peqZ9MTKmARwLapjN58=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ZS10obWZ9lO+tyFfmIpwMvMrZfPmY8ruXibo1O4BWWzeL7Q8gm4+z/VZed5AH8nqq cZo1LtH+GCfES5X27uxW2t9wXIyeHCih1KtU3FcW7y82/niMfrhB/chik8kILe6xAG Tg/RQjkC8x4MOGmuZBOjh9mkPYo2OXrQO4UfeLiE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Tim Bruijnzeels In-Reply-To: Date: Fri, 3 Apr 2020 10:12:36 +0200 Cc: Randy Bush , Jay Borkenhagen , sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <20200226173935.GE72144@vurt.meerval.net> <2db8d19a-6f91-d2fc-36c3-65742ba77e6c@ripe.net> <8B09B96B-432C-4190-9DE0-DC2004AAFCC2@nlnetlabs.nl> <75140927-0b8b-07ab-ad2e-952e32256df1@verizon.net> <24198.20355.168888.506246@oz.mt.att.com> To: Lukas Tribus X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 08:12:41 -0000 Hi, > On 3 Apr 2020, at 09:32, Lukas Tribus wrote: >=20 > Hello Randy, >=20 > On Fri, 3 Apr 2020 at 02:28, Randy Bush wrote: >>=20 >>> - no MITM attacks possible that lead to incomplete VRP sets (with = the >>> supported retrieval methods, which still includes rsync) >>=20 >> you are asking for transport security. we chose not to take that = path. >> if an evil monkey gets in the middle, it should be detectable. but = the >> design does not prevent mitm. >=20 > What I'm trying to say is something different: >=20 > We promised transport agnostic security. I'm asking that we maintain > that promise. >=20 >=20 > But if we are unable to maintain that promise and start relying on > transport security, then we need to actually fully admit that and drop > rysnc. >=20 > This is because I read some arguments on this list akin to "well this > attack will not work against RRDP, so only rsync ...". What I am > saying is that: we should maintain the same guarantees and > consistencies at the end of the day with both retrieval methods. >=20 >=20 > I understand MITM - as in denying the *entire* service - is an attack > that affects both retrieval methods. That's ok. What would be > unacceptable for me is that a repository retrieved via rsync could be > affected by a partial withhold attack, withholding some VRP's. >=20 >=20 > The TL;DR here is, as a network operator, I expect both retrieval > methods to provide the same kind of assurances, consistencies and > security guarantees. On the other hand, if rsync is a second class > citizen, then we need big fat warnings about rsync. I believe that TLS Verification for RRDP MUST become mandatory. No, it's = not perfect, it's not a replacement for the *object* security that = exists in RPKI, but it's an additional check. In particular it can help = to flag if an RP is misdirected or a MITM might be in play. With regards to phasing out rsync. I tried to start that discussion at = IETF 106, and made an initial write-up: = https://datatracker.ietf.org/doc/draft-sidrops-bruijnzeels-deprecate-rsync= / I have not yet asked for WG adoption - I forgot in the midst of lots of = other work etc. That said, I can do so. I am happy to accept co-authors = as well. My impression from the room (not wanting to put on any chair = hats) is that there is no strong opposition to phasing out rsync. However, this discussion is somewhat orthogonal to what RPs should do in = case they find issues with a MFT, CRL, or know that there are objects = that are missing. These problems exist regardless of the transport. Tim >=20 >=20 > Lukas >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Apr 3 01:20:41 2020 Return-Path: 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 85DDB3A1417 for ; Fri, 3 Apr 2020 01:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Yn5mP-L63frL for ; Fri, 3 Apr 2020 01:20:38 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FC003A1416 for ; Fri, 3 Apr 2020 01:20:38 -0700 (PDT) Received: from bufobufo.ripe.net ([193.0.23.13]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jKHZ7-0007Az-8f; Fri, 03 Apr 2020 10:20:37 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::339]) by bufobufo.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.3) (envelope-from ) id 1jKHZ7-0005nb-5l; Fri, 03 Apr 2020 10:20:37 +0200 To: Tim Bruijnzeels Cc: sidrops@ietf.org References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <20200226173935.GE72144@vurt.meerval.net> <2db8d19a-6f91-d2fc-36c3-65742ba77e6c@ripe.net> <8B09B96B-432C-4190-9DE0-DC2004AAFCC2@nlnetlabs.nl> <75140927-0b8b-07ab-ad2e-952e32256df1@verizon.net> <24198.20355.168888.506246@oz.mt.att.com> From: Robert Kisteleki Autocrypt: addr=robert@ripe.net; prefer-encrypt=mutual; keydata= xsBNBEzFa6gBCADVASYXBbUF7v1D+Y9XR41SEEMiZUARlUWeP0NrFHZmRRGdR5nM/p6HguUd StIPRmdqMdyLDqBsV8XPVu6lvhcb4+ZFu/V1XFPVyPBH8U6iQ4PdGDeqFlBm3gxoDOGraGw8 bjojvASTz/Wk3ddLPm34Kb6oMI2MclC016UgrPgIj6A1Uu8qQeBDyWrk+OrWUPOUOKM7QhQg cpU4JwuaesthFvqdoPNQJi9QUfn94r14ZNDYmeJlchZiRHWO70Gwoy3ywfAM9Kyi1tx78Qc9 E5ZhGIw9qqlzqa6c6a0qhup2Zh/dhVBJ05jCDN7bUQT5tRiOV2icyX8Dsr4KaWYCsAOVABEB AAHNMVJvYmVydCBLaXN0ZWxla2kgKFJJUEUgTkNDIGtleSkgPHJvYmVydEByaXBlLm5ldD7C wHgEEwECACICGyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJWUwoeAAoJEC0ZXiKtTC3+ 04UH/jlvSR0esDGFSponUVawru+/QF61KdsNrdH6/Vs2buQvczW2Uh+S6Dic2vr2H0B1YrvL F2XpL2WJUHBUDLTA7dYTslvnHpyZrR8Sfb+h+wJ8OynxEC5wMKxfYNx2fMSk5EIU5mRjMaYg X/VkssDcoQAznNwVVYeqHYUJDMcrJhAYh44VHO208VwjPjHUDRlC+BoMGjHJnWDOAstlES8j 0r3adj2MqIHdDEjSdEx1+rbV0iZlgcDbYDex3qulOYlcZL+PJvGHzD6CkNBa8SbSN7cO0yqR OJ2sgobITOJ0GbRIbIvkUe1Iqw717CuQV/u822dFISDYOAhGYmfWGJWmkezOwE0ETMVrqAEI AKazZ2Agrv0nNFPWV69l6fEout/FaqWfyAG5V414l4yr+qVShUYzS+txA2vC+ouHvdORZ/JG xwKf6HE+YvvWS+Oa+b6h+GZfA3G43XGpQlxXrFK019TeMjhHqWprZALL4w2k6TatYT1ZW369 rORtwSgtn5ZC4uNcpZeDQddQvCjyYoknqlZqAFf1pssuGPTE8GvhrZGEp52dALYYoDIf7y/z 8fCAcy72rhMhQV02rPB49UxOEh2FZJhST0743tuMtFemBkp06B/Mcx54QT0muG8zj19oMDG3 AAaGjNP6B3qzR6F8VczR/qVhQzRvNMr8A6+y/ew/x4+48P+O/4n/I50AEQEAAcLAXwQYAQIA CQIbDAUCVlMKHgAKCRAtGV4irUwt/mvlB/sFID7mlsWAS66UyrI+tGs4Xfl59vvhRRZ4ZKiR 8VEbWbLKh/b9SoYcKt9SLEfVxJE5ebWPgIIvUSdLS6f4n9uAJteDZ4w/AVfp5a6jbfvMm7JP AMW4HtnZ3YbNevRgXdGVXN+bTLZzXoVijOKu+xHDBRNaUswaG3glrDJfUGkPQtCXFn6m6Pdw dW1/ShzwQgfuE/NXa83jhJ175P+NoQ2KG7934vu2MZdrtIqPibKuaGWMPG0L5YzPotK9ONmd taJMnuk92qqZ6S9JPwRZmogRW/sX54XvGg6RzNpdHS5C+iN01tCNJTRTlOJ1X73+RrGokvKc dp6fdfc4PHHhpcMd Organization: RIPE NCC Message-ID: Date: Fri, 3 Apr 2020 10:20:36 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ACL-Warn: Delaying message X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274f6d95c6aa7389fa4377e20d23eb68d6b Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 08:20:40 -0000 > However, this discussion is somewhat orthogonal to what RPs should do > in case they find issues with a MFT, CRL, or know that there are > objects that are missing. These problems exist regardless of the > transport. I agree. Job pointed out a behavioural example from a tool, and we have evidence that the RP tools behave differently under different conditions. If, as Lukas wrote: "[I expect] all RP's to produce the same VRP sets, given the same input" is a desired goal, then we likely need a document specifying said behaviour. Robert From nobody Fri Apr 3 01:32:59 2020 Return-Path: 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 853203A0CFA for ; Fri, 3 Apr 2020 01:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 yfbPp1_ulppR for ; Fri, 3 Apr 2020 01:32:56 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1954A3A0C95 for ; Fri, 3 Apr 2020 01:32:55 -0700 (PDT) Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 6E8FE31412; Fri, 3 Apr 2020 10:32:53 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Fri, 3 Apr 2020 10:32:53 +0200 From: Martin Hoffmann To: Robert Kisteleki Cc: Tim Bruijnzeels , sidrops@ietf.org Message-ID: <20200403103253.23ec1020@glaurung.nlnetlabs.nl> In-Reply-To: References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <20200226173935.GE72144@vurt.meerval.net> <2db8d19a-6f91-d2fc-36c3-65742ba77e6c@ripe.net> <8B09B96B-432C-4190-9DE0-DC2004AAFCC2@nlnetlabs.nl> <75140927-0b8b-07ab-ad2e-952e32256df1@verizon.net> <24198.20355.168888.506246@oz.mt.att.com> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 08:32:58 -0000 Robert Kisteleki wrote: > > However, this discussion is somewhat orthogonal to what RPs should > > do in case they find issues with a MFT, CRL, or know that there are > > objects that are missing. These problems exist regardless of the > > transport. =20 > I agree. Job pointed out a behavioural example from a tool, and we > have evidence that the RP tools behave differently under different > conditions. If, as Lukas wrote: "[I expect] all RP's to produce the > same VRP sets, given the same input" is a desired goal, then we > likely need a document specifying said behaviour. Ideally, these would be a 6486-bis and 6487-bis with more detailed instructions on validation. There=E2=80=99s already quite a number of documents and it isn=E2=80=99t always clear which ones are important. I=E2= =80=99d prefer to have this in the document an implementer will definitely read. I=E2=80=99ll be happy to help working on these bises. Kind regards, Martin From nobody Fri Apr 3 08:06:43 2020 Return-Path: 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 75F793A1906 for ; Fri, 3 Apr 2020 08:06:41 -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=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 yh5mWwWmHUMq for ; Fri, 3 Apr 2020 08:06:40 -0700 (PDT) Received: from sonic308-2.consmr.mail.bf2.yahoo.com (sonic308-2.consmr.mail.bf2.yahoo.com [74.6.130.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 16B143A1901 for ; Fri, 3 Apr 2020 08:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1585926396; bh=UOxeFZZ2eUln/FyRynAxOyLGnzOuAvKEk4uwhBLmaMw=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=EvDDhu1ebq3k7iWPgl8VgTwvmhi9xjzKBKXTmqJ2LtEQSccwyLYbrSre8SrUYapNlaU1DmSkSQ6GOmtOjI+92E4vbJQA0slkMdDgQF7a/rKQe+8kiwi+AcwuudbY0+tYsLncR3Nx6/EfjwwwtjLVBephw4xA4LTTvla64SonLWnVVzyuhKn0MrgrdylOh/uSEkjYBb6Oet6z+jNHxEpoQJpJYeLkhy3jJlkseMbsefCEfg15FJBATaEz9hG/TtUMa+wWwFZ14jNirnnqXAslsGrbFdeOpQ35qKlM0++Y0xxVPv9Ptp3AmMkaxxok6QQijTwk7w18LptTR1MQlQAYFw== X-YMail-OSG: miKBk7IVM1kXLfZSstuDECslSc7CtxlEz7fBxfFBjyzKm_X8yS1VPie4n20EwEP vSbqqJTdhbJegZLqktzDG9TEJUV67N8kCRMkXYPal8fAGa81R39jcOl3Zk9UJXn250SSbMzf9jMQ V9_FeEWwLFJUYRpXIR2Y.1T86sKvM23D1.OLB17k2wr3QqmgSYAJ81GY_93eb7wHPY52IHh4ednX jbdWhDKqzHQUlmZSkwguvozyt9_ldI4g4d7uyWqWUV.F3ZU7U0lLLqkuJFT4nxvhgXERH45kBAsh 6uClFKuL4UO1.PdTA_n.mtjUSyTpQuBZr6kAev8c.9KLqXsBzyucfohCgN7ktxKSyIv9kaongPoo .ySy7lk1iCbn75V90PnDPbVhB6aeK3cJukzEkH2gR92079dnrJTo2FzAQIjjQzHBKEAk2x7qwhRt m3H9T5oUXC6FKdPaBOjf.aNgSpfR2IKX04nXidKkDJhjbHpNGLZVgQV92TUnw8CHVZpMNpgeq8ol i3Yq4C_oTkJP.wiOC3kMfSUoIgkNz6lDg8k8ByNsYPBsngHKLzsdL3yVYDL19dGepShMjfCxKFVT 3AI2OyRfdWEu_T4VRNfiVx.VxFiP0wHmHu8cSivEiyi8uCZTcZR6X0ZO1a6seEGgmM7THkiSUzzs GSbDFzNUDPwALH49zoqOrXt1x4cqI_bm_alRp7rhpAUKkWJJzd04GqpFXj_HIOC6qufstNN0Y1Lh qQYRORwlDC9blclJoiZ.Vze9cZuq3hWbsJINK7QjVbKsVzNf1UxSvNFx8sAcuAocW9y_BeKMg71O xJn1g6ppuTIev51i8Vyb0g.0J1Xv_LcPKz8yPz0Fq5oSrKLZffEpA_LTmWHap4qgH3JqokWkKROI zzeH074mNSBDPTlwbz0JGFBsiWK3pXVmznB7Etoathx8sYPYuOW6c98iKH39y_UNtLcByVmd5bb4 xzkp5EPD0OfGvRx8vxB46YznQGN8giDjVDsP85az3gR5xZSy9tM4yrUM.u7f9zykDCcNMf1M_q0L 8vzJpIXmK2HBi5jNgGsG8_6d4NWruts7nv_xtppHqrwxh18485IJJWISN4bFAVYrp2nhZ0nA3DbW eTs8YEoipggULpk8_hqtkfa6Ry9yJ5_1uWL2OucRk6QMOkEeTujpoS.h1DQXvJVvu1YT23SM5wcE LA0Dyi3_0MA_HcLwE5ocSuyO.ByBKzPJEqg_1qUEG8FOAgf6RIMNUvebQC3E810D2DedhCuk8f8m dtEnVoDmnmX4AZ46sIiQ89N7tcikIUqqpf3mL1S5kNeaWP6zGr5iJOMTQAWS59oepSp0I5EjdLar yfpCCW6dmlxqvYSH.rb9yvliz.5fJL57pJWduWPC5RmOkEr0KPLMX2o9dPDEhqCQjkmvJ0oQ.FbO efppVKTmXpEDmOQujmbKStWjI6eQ6DMsRGiSjJblIxYUQc84- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.bf2.yahoo.com with HTTP; Fri, 3 Apr 2020 15:06:36 +0000 Received: by smtp412.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e6b5a31cd9e16e9a218aa38d90d0cad0; Fri, 03 Apr 2020 15:06:31 +0000 (UTC) To: sidrops@ietf.org References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <20200226173935.GE72144@vurt.meerval.net> <2db8d19a-6f91-d2fc-36c3-65742ba77e6c@ripe.net> <8B09B96B-432C-4190-9DE0-DC2004AAFCC2@nlnetlabs.nl> <75140927-0b8b-07ab-ad2e-952e32256df1@verizon.net> <24198.20355.168888.506246@oz.mt.att.com> From: Stephen Kent Message-ID: Date: Fri, 3 Apr 2020 11:06:30 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <24198.20355.168888.506246@oz.mt.att.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.15585 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 15:06:42 -0000 OJay, > Hi, > > Re-visiting an older message in preparation for the upcoming SIDROPS > virtual interim meeting. > > On 23-March-2020, Stephen Kent writes: > > I agree that more uniform processing is desirable, but in the routing > > system the notion of local policy seems to be ingrained, so ... > > When I first saw this, I thought Steve was just making a pithy comment > about local policy and network operators. I often strive for pithy, but ... > But a friend thinks Steve > had not meant it as a joke at all, so let me take Steve's comment at > face value and respond: > > As a network operator, yes, I expect to have the flexibility of > configuring my network using local policy. But in the context of the > RPKI, we need to reach a point where all RFC-compliant RPs will > generate identical sets of VRPs when presented with the same input. > There will be reasons why I may prefer to operate one RP over another, > but the VRPs that a particular RP generates should never be one of > them. Thanks for the clarification. If the operator community can agree on a consistent way to deal with inconsistencies in downloaded pub point data I think that would be ideal. I'll post some suggestions and an outline of the decision points, shortly. Steve From nobody Fri Apr 3 08:40:21 2020 Return-Path: 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 D36243A19A3 for ; Fri, 3 Apr 2020 08:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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 VqiMMPss0qY2 for ; Fri, 3 Apr 2020 08:40:18 -0700 (PDT) Received: from sonic305-2.consmr.mail.bf2.yahoo.com (sonic305-2.consmr.mail.bf2.yahoo.com [74.6.133.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 C4C393A142D for ; Fri, 3 Apr 2020 08:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1585928416; bh=fqXzk5tRK0r2aGPCXTyngXM2nWat6R+69SEMtabkEVY=; h=To:From:Subject:Date:References:From:Subject; b=YYoDpFjLy5xq52lYdyrut8C++QfMoZNr2ns7HI29pMam0VJno6D1mvYaD5ZTcU5J4ac/iTmyb6D1MsdJaV264aTaHUnt9A7ReNXGJHE/B1ikFY9bARi0bSKolklGQWX5J2XM7XUOfXY82OM2KzedintoO/EqJnHr0dc63aXvjSjHPxJnVPlT5GUkdIJKN9BVJi0DtEKpZBlTO7uJm0wTQFz7jPhEKVgIR2+qIRrYVHtnsLHxjQQ3IJWUhThy42dprHPUNzLgcbErdh3ckpmg8951V8zFNxQTkkM9qXI974D9f8ouqJqugGEq3ga+tDSZoDlHbE+JhulR6s6tPOzqWA== X-YMail-OSG: U.80sL8VM1nuvDSz32MT3spGpWnu_zf5Gqi05SnMggxqX8csucRMqsOcczsiqfO ZVkuC782xDr9H_XxCC3AkyCAShVTxjv.blOQlT5Bz4DQi4naa64mbSS79zwtc5Q9oozkK1eMH2LP CdME8mnDDtnR3ETCvC_l.AIrQwLLVJYF2AuVlj8D9Ur5A4VobkQ6cxTG0kPQlmd6pFhrdBmKiozY 5ZBC_FP1bFS5Z6O0_2isT0dpMYvpL12cSewuiZMv113a8.vLdVMyzzNq4k6b.0qKEARyq0rCmm6W fBVs.y012XHn3Ubzmw_rv5Zd6T9MY.KNxZyLufOjn_G3JYWI1C1FUKiiFE53oEf9BS3jph8O6gS6 s_wiNhOWp9oZjg9z4sLKEI8fFHNLKCIHFIKsxjcROFQJVKbM1y.NsP5h8SXEeuv3YTRA4oHlbspJ 0guoV6_K7.WAMpMU0qWj22vb11AQODvAR3Doaj690dL9WzB5SvY2QxA0WhJZygoN86oy8Tv197Ft ni2hMLI3P05_PAmwR9B0xRqUWmA8HKWQrXKChq6oCJwNSlRSzD5.WDcT7jSI13ZD_xUQ_Ll0K8v6 N.qThmf3A9icxh5Ovd4oJjs3tpqGbOSKeJcfhKb3YpJjBE0Qi5uGRxUFgNYP6aM8WTX5Mgoz03Hn yimeKvOTvz3LiihHW4_Q78mILnpMW3OJLx.Dix0FMkjs3n9PdUr0L3bWXSZ8nBC194R3LyRTigHX TJDmeaFQi.cp2pGHl.FC.gznFwFMadlBbxTBtp2OilTZaHtUDtuNBB_.aweETLFEBxl3UxZHnPXb WcGq.knCMk29JMRBBXnM.6hTXEC4TPDZkx21ZyMFpSRNHKAg5vNdHdYyOlQ8Q_qac1263uSDoxmh aLAA8XBXk0qRFe5Uh.XyM3vi7I493aFMlhobuHq2SYqoWgk._SxBCoYu323Yl3N5Dd.QzmRHr84a o8UvfFPaDtjxjQ3PvmBlxqYjojcwDWcz.LJKqphzvQFf_zHEhaxG4Q2B79BjS6e0uUEgyu2s1wmJ wLYVdOb59D2dM3wbm_ryEDYRrWaVy5FQ17rw7dH7J8K_r3FOVrfOlRpSuK3UCktnVVlu159lAAWj v4LrhdKS5xeCnv5jBlAIR3mAf.L9JHi1O7XLzvLScO6HDs8qH7JBcYObzv27Urv4fqG1RGDUkDfk 1HN2QZ3ppCKC9WlyN4OKJ2Zc6QRAIFfjBu5fII.XoSyV0uDIezaEOBkSZQ32Mry2_L.Gu4Ib7vg3 U_M2juMTrRycVlSFFIknASjiLrFQh.rSjjhn77ZhhGuwuH7gj_163y.WZ8rssaHmnVYJlJHUm.C6 xp4SKCOzElm35laYEZy.TOnTPH7VBCh73zZme7vRzLp63kBic9FHKKNpERSqVxIxtJJ3N0d4k6dF GJM_56PE74V9LG.BC9HGqxoaqKxhVUMccz4xGCyUUBlVMQb3zR1VFMPeUQmic Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Fri, 3 Apr 2020 15:40:16 +0000 Received: by smtp432.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 453cfff583cfc07fd06b3a244539a6f9; Fri, 03 Apr 2020 15:40:11 +0000 (UTC) To: "sidrops@ietf.org" From: Stephen Kent Message-ID: Date: Fri, 3 Apr 2020 11:40:10 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------88C38A45D98F9F60FD000D8E" Content-Language: en-US References: X-Mailer: WebService/1.1.15620 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 15:40:20 -0000 This is a multi-part message in MIME format. --------------88C38A45D98F9F60FD000D8E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit *Overview * A publication point (PP) in an RPKI repository contains the following elements: 1.CA certificates (optional, present only for subordinate CAs) 2.EE certificates (optional, present only for routers) 3.CRL (usually one) 4.ROAs 5.Manifest (usually one) 6.Ghostbusters record (one, optional) *Terminology* Valid: a signed object (other than a certificate or CRL) is deemed *valid* if it is encoded in a fashion consistent with the relevant RPKI RFCs (i.e., 6482, 6486, 6487, 6488, 6493) and the signed object’s signature can be verified consistent with RFC 6488. Current: A CRL or Manifest is *current* if the current date & time is before the Next Update date and the CRLNumber (or ManifestNumber) is greater than any prior, valid CRLs or Manifests processed by the RP. Stale: A CRL or Manifest is stale if the current date & time is later than the Next Update date. A stale CRL or Manifest is not “expired” it’s just not as current as it is supposed to be. The case analysis below examines what to do when a Manifest, or CRL, or both are stale. Missing: an object named in a Manifest, but not available for download from a PP, is termed *missing*. An RP has no obvious way to acquire missing objects, but operators SHOULD be warned about which objects are missing. Corrupted: if an object named in a Manifest, is available for download from a PP, but it’s hash does not match the corresponding value in the Manifest, the object is termed *corrupted* and the object SHOULD be ignored. *Case analysis* If we can agree to ignore any objects at a PP that do not appear on the current manifest, the case analysis is easier. (The discussion of corrupted objects above addresses the case where an object is named on the Manifest, but the hash does not match.) Below is a proposed outline for the cases. The group needs to decide what action is to be taken in each case. 1.Manifest present, valid, current 1.1.CRL present, valid, current 1.2.CRL present, stale 1.3.CRL present, invalid 1.4.CRL missing 2.Manifest present, valid, stale 2.1.CRL present, valid, current 2.2.CRL present, stale 2.3.CRL present, invalid 2.4.CRL missing 3.Manifest present, but invalid 3.1.CRL present, valid, current 3.2.CRL present, stale 3.3.CRL present, invalid 3.4.CRL missing 4.Manifest not present 4.1.CRL present, valid, current 4.2.CRL present, stale 4.3.CRL present, invalid 4.4.CRL missing --------------88C38A45D98F9F60FD000D8E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Overview


A publication point (PP) in an RPKI repository contains the following elements:

 

1.    CA certificates (optional, present only for subordinate CAs)

2.    EE certificates (optional, present only for routers)

3.    CRL (usually one)

4.    ROAs

5.    Manifest (usually one)

6.    Ghostbusters record (one, optional)

 

 

 

Terminology

 

Valid: a signed object (other than a certificate or CRL) is deemed valid if it is encoded in a fashion consistent with the relevant RPKI RFCs (i.e., 6482, 6486, 6487, 6488, 6493) and the signed object’s signature can be verified consistent with RFC 6488.


Current: A CRL or Manifest is current if the current date & time is before the Next Update date and the CRLNumber (or ManifestNumber) is greater than any prior, valid CRLs or Manifests processed by the RP.


Stale: A CRL or Manifest is stale if the current date & time is later than the Next Update date. A stale CRL or Manifest is not “expired” it’s just not as current as it is supposed to be. The case analysis below examines what to do when a Manifest, or CRL, or both are stale.

 

Missing: an object named in a Manifest, but not available for download from a PP, is termed missing. An RP has no obvious way to acquire missing objects, but operators SHOULD be warned about which objects are missing.

 

Corrupted: if an object named in a Manifest, is available for download from a PP, but it’s hash does not match the corresponding value in the Manifest, the object is termed corrupted and the object SHOULD be ignored.

 

 

Case analysis

 

 

If we can agree to ignore any objects at a PP that do not appear on the current manifest, the case analysis is easier. (The discussion of corrupted objects above addresses the case where an object is named on the Manifest, but the hash does not match.)


Below is a proposed outline for the cases. The group needs to decide what action is to be taken in each case.



1.    Manifest present, valid, current

1.1. CRL present, valid, current

1.2. CRL present, stale

1.3. CRL present, invalid

1.4. CRL missing

 

2.    Manifest present, valid, stale

2.1. CRL present, valid, current

2.2. CRL present, stale

2.3. CRL present, invalid

2.4. CRL missing

 

3.    Manifest present, but invalid

3.1. CRL present, valid, current

3.2. CRL present, stale

3.3. CRL present, invalid

3.4. CRL missing

 

4.    Manifest not present

4.1. CRL present, valid, current

4.2. CRL present, stale

4.3. CRL present, invalid

4.4. CRL missing

--------------88C38A45D98F9F60FD000D8E-- From nobody Fri Apr 3 09:07:33 2020 Return-Path: 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 3B1193A19EC for ; Fri, 3 Apr 2020 09:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 9NI9x6BG99OW for ; Fri, 3 Apr 2020 09:07:31 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC4273A1A21 for ; Fri, 3 Apr 2020 09:07:22 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jKOqm-0004Mt-BZ; Fri, 03 Apr 2020 16:07:20 +0000 Date: Fri, 03 Apr 2020 09:07:19 -0700 Message-ID: From: Randy Bush To: Lukas Tribus Cc: Jay Borkenhagen , sidrops@ietf.org In-Reply-To: References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <20200226173935.GE72144@vurt.meerval.net> <2db8d19a-6f91-d2fc-36c3-65742ba77e6c@ripe.net> <8B09B96B-432C-4190-9DE0-DC2004AAFCC2@nlnetlabs.nl> <75140927-0b8b-07ab-ad2e-952e32256df1@verizon.net> <24198.20355.168888.506246@oz.mt.att.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 16:07:32 -0000 > we should maintain the same guarantees and consistencies at the end of > the day with both retrieval methods. i am with you there randy From nobody Fri Apr 3 09:26:56 2020 Return-Path: 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 95BF73A1AE0 for ; Fri, 3 Apr 2020 09:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no 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 pokJL03-hVWh for ; Fri, 3 Apr 2020 09:26:53 -0700 (PDT) Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (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 67DD43A1ADD for ; Fri, 3 Apr 2020 09:26:52 -0700 (PDT) Received: by mail-wr1-f51.google.com with SMTP id m17so9197449wrw.11 for ; Fri, 03 Apr 2020 09:26:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=1PV2BERHF6atQgHkOhGnWm9sxQ1gEGOyDtLE7bu8HzE=; b=sRk5OZ98js0us1SJNnghlkXezode42R+MiLK/r2cBy/KX04M+oojT6kRfjp2oq+QDG 5hDZ2Md/MjPt3z2bq/jADN2jhkQSqhuLOdj+rKK86EQsrVh20Fd4McV12ZH4zEcbjPJo BCooGQvFOyTsJsSFmrUNrdU15irBxdkXviJAtp9zJMjFeRPksbSKHNfImhpoFCu98jcv qrOD9u6GnrQhzR7855NpmE35fDyj/Yy+2LX/9jimUuLH7NO9kDNezcKnFXezMT7I8Y3w hAXYqYkGahJ0MuGPEfdqtKMA7tn0GQmii388OmwhKa3des5rpLBCdcbGdCg3x/VR3IdV EYhA== X-Gm-Message-State: AGi0Pua4vkL3RouQBuKRJ+3qwYXXLqRJjvrqGnBIJxfnmpGrxlm0Fzkk wLz/60I+XMs4IdsrIIyO16ZYN0IC4Lc= X-Google-Smtp-Source: APiQypIPXGA3gIVVsQvcw28Bq6ljao1YeG1I85iet8AZRoccJaThkqIZQmkXWdW5QKBLw7Ln3V+z/g== X-Received: by 2002:adf:f8c1:: with SMTP id f1mr10132235wrq.345.1585931211090; Fri, 03 Apr 2020 09:26:51 -0700 (PDT) Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id c18sm12455204wrx.5.2020.04.03.09.26.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Apr 2020 09:26:50 -0700 (PDT) Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 12915645; Fri, 3 Apr 2020 16:26:47 +0000 (UTC) Date: Fri, 3 Apr 2020 16:26:47 +0000 From: Job Snijders To: Stephen Kent Cc: "sidrops@ietf.org" Message-ID: <20200403162647.GH60268@vurt.meerval.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 16:26:55 -0000 Dear Stephen, Thank you for spearheading this initiative. It is helpful to see the various permuations for which a decision tree needs to be constructed laid out in this way. On Fri, Apr 03, 2020 at 11:40:10AM -0400, Stephen Kent wrote: > *Terminology* > > Valid: a signed object (other than a certificate or CRL) is deemed > *valid* if it is encoded in a fashion consistent with the relevant > RPKI RFCs (i.e., 6482, 6486, 6487, 6488, 6493) and the signed object’s > signature can be verified consistent with RFC 6488. > > Current: A CRL or Manifest is *current* if the current date & time is > before the Next Update date and the CRLNumber (or ManifestNumber) is > greater than any prior, valid CRLs or Manifests processed by the RP. > > Stale: A CRL or Manifest is stale if the current date & time is later > than the Next Update date. A stale CRL or Manifest is not “expired” > it’s just not as current as it is supposed to be. The case analysis > below examines what to do when a Manifest, or CRL, or both are stale. > > Missing: an object named in a Manifest, but not available for download > from a PP, is termed *missing*. An RP has no obvious way to acquire > missing objects, but operators SHOULD be warned about which objects > are missing. > > Corrupted: if an object named in a Manifest, is available for download > from a PP, but it’s hash does not match the corresponding value in the > Manifest, the object is termed *corrupted* and the object SHOULD be > ignored. Can you also provide a definition for your use of the word 'invalid'? I see the phrase used in the case analysis permutations. Kind regards, Job From nobody Fri Apr 3 10:27:23 2020 Return-Path: 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 43AAC3A0951 for ; Fri, 3 Apr 2020 10:27:21 -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 VGm9EpRCRYum for ; Fri, 3 Apr 2020 10:27:18 -0700 (PDT) Received: from sonic317-26.consmr.mail.bf2.yahoo.com (sonic317-26.consmr.mail.bf2.yahoo.com [74.6.129.81]) (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 D9CE73A094E for ; Fri, 3 Apr 2020 10:27:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1585934836; bh=r6+xwiEEG2BubVJIMjB+vxegJasWzLXUZswSPspcDXY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=nC7KiTbfDqDquj+/BnQOpTckzV4PkAbU964ZSsALVRCOGsNE43eUyZQOab4tXpwdStE1Hkqcn7/GEHx+LY3+SNWV4Clo6/5ECpHGfSow72c/Ixo3x4K5a/ZaP1y5CriBP8Smd7gnvX+6ftYzo/Fwzoi3+yfN64a403AmunTUMZxF1GgJkxjZQ07RnIe5EQ6OyJBwwt4NUxQnYAJNY9kZaOWuw8Npsdjd5287SctKpm54TOjwlCHzba5336MVKYJQYrCo7aI+lAolHOC/eTlxF4gBIIYFRZRJutwG16TrDcDINldMVRGWR0iAw8QMx06zrNKnXZq3zMvAkwDxLVZ8Zg== X-YMail-OSG: NkucQv8VM1mqKLQKzLgzDVFzOr.1FtglE4YbYleh_MCaMNXSR.nnBA1er9xB8r. aVd8thDJOvdhWVnpspuGV.U2z5XS1yOZzU5edii2e6AiSeP8meJaKpxqt08JS3CzcWP5dwqt2Ax7 GnQdRptNCT3ENkBuIyYmNGwlOPEwj8AcKRrTp0UPbiNo1Ps5QXqY79AF5AiV5xJ_71oHlGgvw3Mr Gj3HLMwX9kGKQVA_0XLkSicrGbAQx_GiHQBVBQWbtb.3BQ6VPYYt483_XdyvPFDlOnJLHwkkwbu7 OMPfOtY7pEZ0pi_g9Txm.W.myKhaKwT_.4I_9XGNVeqXpJvD6n_v0WM4Hk9_KDEdkePvkbcA_8GS On0CrabrLchTZ4zE3aXxNbXhctpkUkWh.uU2bGvSVjG60JkY_0USYLx8INVjzJiex_0R7NvZZE3T JkbUNdbgWKcF1qCaJcu45dkGVnOuHuttBo5LW7D3XXDKquBP_l_BO.uLGpYsdpnqm2IvAjH4TxSR klPtju9CiTMaFGpn4YSDALI3BenciVMOiJtOHpoUAhJ_8Pjay5TC4PvubLQXkpFaOfLZWjzt7Rx6 OKALZQ2UJ7h2raRH7tkm1D6UwM8HSnqSE5wgGOPngPaofNieDDRzAHAr9CywVeWRUV.KhzRZlmRy fLohRh26PaAjRZqAMniZFyjoJHTsOvPBEOiJxIzIsoC9Zyz_YJIfDsWcr6PMVMclRDXqmqy1PMfQ p0581Uqv7VL1Nd9JUXxGuzmToM07eHO9zGg3lstKoJfccizP6nM.ALAqBWbK_Qu_2Xuy3XP.rGUD 0EAvo5sznhV4ptzeofMeX.RqoHTVJTt1jzFky59zXaRyLYiWJdeXxPWjjWWfzbdcGiNPkx0r7U2B Uijo6oMWT4PbKZi7bJkor2nb5tCk0VgKTFF04LatcCUogyyxX559THdNb.n2QklNCvASdfq1z0yh sehUfr4J_LQC6s6NB4px6zrzAObP8E2055e4rIGMpGfyzjAn3Mo5_DMs.xkeRt5C7KG10R_mPHWk XfZV_ZG64CyU5jFbUXeMEaCTpMBAVENr81P0OdgK5tYpMZFb7tdav9Ye86VLsX6FFipRcojl3hN3 3SrN53lPvmqi0WkFWWCD.vi5t.LBzBE4YDm10giJlSQQw2MiHW349XOuI7pOeeXN7358nqOlBmuW .AVEcCygT.OjcGHhwtoI4QVGzRrAbQvrUCnH__APbRRf4bZokshfsySnf4oGcaW_nEPDKWVdwFJY P2El3rSpncHwxyMurAXyq7IOlzJH1M6tOTN_yOrC_bq_Mo2QH1g79wINhFnWjdhjlhB1Agwlj4uK ZJLf.S_l57qdZph4_w4oICC29wbznKBAzYZxAe9KzFd101FDehSpDalqugNeFp4btqu.pkvlJKR8 BqQd8e55U0pjPI_jY5LY4FsyhqBYQVlOj Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Fri, 3 Apr 2020 17:27:16 +0000 Received: by smtp424.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f20071974ca103ca917ce5f82d55aeff; Fri, 03 Apr 2020 17:27:15 +0000 (UTC) To: Job Snijders Cc: "sidrops@ietf.org" References: <20200403162647.GH60268@vurt.meerval.net> From: Stephen Kent Message-ID: Date: Fri, 3 Apr 2020 13:27:14 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200403162647.GH60268@vurt.meerval.net> Content-Type: multipart/alternative; boundary="------------2293205DBF3BCBC59959813F" Content-Language: en-US X-Mailer: WebService/1.1.15620 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 17:27:22 -0000 This is a multi-part message in MIME format. --------------2293205DBF3BCBC59959813F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Job, > Dear Stephen, > > Thank you for spearheading this initiative. It is helpful to see the > various permuations for which a decision tree needs to be constructed > laid out in this way. > > On Fri, Apr 03, 2020 at 11:40:10AM -0400, Stephen Kent wrote: >> *Terminology* >> >> Valid: a signed object (other than a certificate or CRL) is deemed >> *valid* if it is encoded in a fashion consistent with the relevant >> RPKI RFCs (i.e., 6482, 6486, 6487, 6488, 6493) and the signed object’s >> signature can be verified consistent with RFC 6488. >> >> Current: A CRL or Manifest is *current* if the current date & time is >> before the Next Update date and the CRLNumber (or ManifestNumber) is >> greater than any prior, valid CRLs or Manifests processed by the RP. >> >> Stale: A CRL or Manifest is stale if the current date & time is later >> than the Next Update date. A stale CRL or Manifest is not “expired” >> it’s just not as current as it is supposed to be. The case analysis >> below examines what to do when a Manifest, or CRL, or both are stale. >> >> Missing: an object named in a Manifest, but not available for download >> from a PP, is termed *missing*. An RP has no obvious way to acquire >> missing objects, but operators SHOULD be warned about which objects >> are missing. >> >> Corrupted: if an object named in a Manifest, is available for download >> from a PP, but it’s hash does not match the corresponding value in the >> Manifest, the object is termed *corrupted* and the object SHOULD be >> ignored. > Can you also provide a definition for your use of the word 'invalid'? I > see the phrase used in the case analysis permutations. I would call a signed object invalid if it is syntactically broken (e.g., bad ASN.1 encoding), or if the signature cannot be validated as specified in RFC 6488. This is just another way of saying that it fails either of the  criteria cited in definition of *valid*. Steve --------------2293205DBF3BCBC59959813F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Job,
Dear Stephen,

Thank you for spearheading this initiative. It is helpful to see the
various permuations for which a decision tree needs to be constructed
laid out in this way.

On Fri, Apr 03, 2020 at 11:40:10AM -0400, Stephen Kent wrote:

*Terminology*

Valid: a signed object (other than a certificate or CRL) is deemed
*valid* if it is encoded in a fashion consistent with the relevant
RPKI RFCs (i.e., 6482, 6486, 6487, 6488, 6493) and the signed object’s
signature can be verified consistent with RFC 6488.

Current: A CRL or Manifest is *current* if the current date & time is
before the Next Update date and the CRLNumber (or ManifestNumber) is
greater than any prior, valid CRLs or Manifests processed by the RP.

Stale: A CRL or Manifest is stale if the current date & time is later
than the Next Update date. A stale CRL or Manifest is not “expired”
it’s just not as current as it is supposed to be. The case analysis
below examines what to do when a Manifest, or CRL, or both are stale.

Missing: an object named in a Manifest, but not available for download
from a PP, is termed *missing*. An RP has no obvious way to acquire
missing objects, but operators SHOULD be warned about which objects
are missing.

Corrupted: if an object named in a Manifest, is available for download
from a PP, but it’s hash does not match the corresponding value in the
Manifest, the object is termed *corrupted* and the object SHOULD be
ignored.

Can you also provide a definition for your use of the word 'invalid'? I
see the phrase used in the case analysis permutations.

I would call a signed object invalid if it is syntactically broken (e.g., bad ASN.1 encoding), or if the signature cannot be validated as specified in RFC 6488. This is just another way of saying that it fails either of the  criteria cited in definition of valid.

Steve


--------------2293205DBF3BCBC59959813F-- From nobody Fri Apr 3 10:27:35 2020 Return-Path: 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 D1AAF3A094E for ; Fri, 3 Apr 2020 10:27:23 -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=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 2tbJmISrlwkQ for ; Fri, 3 Apr 2020 10:27:18 -0700 (PDT) Received: from sonic317-26.consmr.mail.bf2.yahoo.com (sonic317-26.consmr.mail.bf2.yahoo.com [74.6.129.81]) (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 452953A094F for ; Fri, 3 Apr 2020 10:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1585934836; bh=r6+xwiEEG2BubVJIMjB+vxegJasWzLXUZswSPspcDXY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=nC7KiTbfDqDquj+/BnQOpTckzV4PkAbU964ZSsALVRCOGsNE43eUyZQOab4tXpwdStE1Hkqcn7/GEHx+LY3+SNWV4Clo6/5ECpHGfSow72c/Ixo3x4K5a/ZaP1y5CriBP8Smd7gnvX+6ftYzo/Fwzoi3+yfN64a403AmunTUMZxF1GgJkxjZQ07RnIe5EQ6OyJBwwt4NUxQnYAJNY9kZaOWuw8Npsdjd5287SctKpm54TOjwlCHzba5336MVKYJQYrCo7aI+lAolHOC/eTlxF4gBIIYFRZRJutwG16TrDcDINldMVRGWR0iAw8QMx06zrNKnXZq3zMvAkwDxLVZ8Zg== X-YMail-OSG: NkucQv8VM1mqKLQKzLgzDVFzOr.1FtglE4YbYleh_MCaMNXSR.nnBA1er9xB8r. aVd8thDJOvdhWVnpspuGV.U2z5XS1yOZzU5edii2e6AiSeP8meJaKpxqt08JS3CzcWP5dwqt2Ax7 GnQdRptNCT3ENkBuIyYmNGwlOPEwj8AcKRrTp0UPbiNo1Ps5QXqY79AF5AiV5xJ_71oHlGgvw3Mr Gj3HLMwX9kGKQVA_0XLkSicrGbAQx_GiHQBVBQWbtb.3BQ6VPYYt483_XdyvPFDlOnJLHwkkwbu7 OMPfOtY7pEZ0pi_g9Txm.W.myKhaKwT_.4I_9XGNVeqXpJvD6n_v0WM4Hk9_KDEdkePvkbcA_8GS On0CrabrLchTZ4zE3aXxNbXhctpkUkWh.uU2bGvSVjG60JkY_0USYLx8INVjzJiex_0R7NvZZE3T JkbUNdbgWKcF1qCaJcu45dkGVnOuHuttBo5LW7D3XXDKquBP_l_BO.uLGpYsdpnqm2IvAjH4TxSR klPtju9CiTMaFGpn4YSDALI3BenciVMOiJtOHpoUAhJ_8Pjay5TC4PvubLQXkpFaOfLZWjzt7Rx6 OKALZQ2UJ7h2raRH7tkm1D6UwM8HSnqSE5wgGOPngPaofNieDDRzAHAr9CywVeWRUV.KhzRZlmRy fLohRh26PaAjRZqAMniZFyjoJHTsOvPBEOiJxIzIsoC9Zyz_YJIfDsWcr6PMVMclRDXqmqy1PMfQ p0581Uqv7VL1Nd9JUXxGuzmToM07eHO9zGg3lstKoJfccizP6nM.ALAqBWbK_Qu_2Xuy3XP.rGUD 0EAvo5sznhV4ptzeofMeX.RqoHTVJTt1jzFky59zXaRyLYiWJdeXxPWjjWWfzbdcGiNPkx0r7U2B Uijo6oMWT4PbKZi7bJkor2nb5tCk0VgKTFF04LatcCUogyyxX559THdNb.n2QklNCvASdfq1z0yh sehUfr4J_LQC6s6NB4px6zrzAObP8E2055e4rIGMpGfyzjAn3Mo5_DMs.xkeRt5C7KG10R_mPHWk XfZV_ZG64CyU5jFbUXeMEaCTpMBAVENr81P0OdgK5tYpMZFb7tdav9Ye86VLsX6FFipRcojl3hN3 3SrN53lPvmqi0WkFWWCD.vi5t.LBzBE4YDm10giJlSQQw2MiHW349XOuI7pOeeXN7358nqOlBmuW .AVEcCygT.OjcGHhwtoI4QVGzRrAbQvrUCnH__APbRRf4bZokshfsySnf4oGcaW_nEPDKWVdwFJY P2El3rSpncHwxyMurAXyq7IOlzJH1M6tOTN_yOrC_bq_Mo2QH1g79wINhFnWjdhjlhB1Agwlj4uK ZJLf.S_l57qdZph4_w4oICC29wbznKBAzYZxAe9KzFd101FDehSpDalqugNeFp4btqu.pkvlJKR8 BqQd8e55U0pjPI_jY5LY4FsyhqBYQVlOj Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Fri, 3 Apr 2020 17:27:16 +0000 Received: by smtp424.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f20071974ca103ca917ce5f82d55aeff; Fri, 03 Apr 2020 17:27:15 +0000 (UTC) To: Job Snijders Cc: "sidrops@ietf.org" References: <20200403162647.GH60268@vurt.meerval.net> From: Stephen Kent Message-ID: Date: Fri, 3 Apr 2020 13:27:14 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200403162647.GH60268@vurt.meerval.net> Content-Type: multipart/alternative; boundary="------------2293205DBF3BCBC59959813F" Content-Language: en-US X-Mailer: WebService/1.1.15620 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 17:27:24 -0000 This is a multi-part message in MIME format. --------------2293205DBF3BCBC59959813F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Job, > Dear Stephen, > > Thank you for spearheading this initiative. It is helpful to see the > various permuations for which a decision tree needs to be constructed > laid out in this way. > > On Fri, Apr 03, 2020 at 11:40:10AM -0400, Stephen Kent wrote: >> *Terminology* >> >> Valid: a signed object (other than a certificate or CRL) is deemed >> *valid* if it is encoded in a fashion consistent with the relevant >> RPKI RFCs (i.e., 6482, 6486, 6487, 6488, 6493) and the signed object’s >> signature can be verified consistent with RFC 6488. >> >> Current: A CRL or Manifest is *current* if the current date & time is >> before the Next Update date and the CRLNumber (or ManifestNumber) is >> greater than any prior, valid CRLs or Manifests processed by the RP. >> >> Stale: A CRL or Manifest is stale if the current date & time is later >> than the Next Update date. A stale CRL or Manifest is not “expired” >> it’s just not as current as it is supposed to be. The case analysis >> below examines what to do when a Manifest, or CRL, or both are stale. >> >> Missing: an object named in a Manifest, but not available for download >> from a PP, is termed *missing*. An RP has no obvious way to acquire >> missing objects, but operators SHOULD be warned about which objects >> are missing. >> >> Corrupted: if an object named in a Manifest, is available for download >> from a PP, but it’s hash does not match the corresponding value in the >> Manifest, the object is termed *corrupted* and the object SHOULD be >> ignored. > Can you also provide a definition for your use of the word 'invalid'? I > see the phrase used in the case analysis permutations. I would call a signed object invalid if it is syntactically broken (e.g., bad ASN.1 encoding), or if the signature cannot be validated as specified in RFC 6488. This is just another way of saying that it fails either of the  criteria cited in definition of *valid*. Steve --------------2293205DBF3BCBC59959813F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Job,
Dear Stephen,

Thank you for spearheading this initiative. It is helpful to see the
various permuations for which a decision tree needs to be constructed
laid out in this way.

On Fri, Apr 03, 2020 at 11:40:10AM -0400, Stephen Kent wrote:

*Terminology*

Valid: a signed object (other than a certificate or CRL) is deemed
*valid* if it is encoded in a fashion consistent with the relevant
RPKI RFCs (i.e., 6482, 6486, 6487, 6488, 6493) and the signed object’s
signature can be verified consistent with RFC 6488.

Current: A CRL or Manifest is *current* if the current date & time is
before the Next Update date and the CRLNumber (or ManifestNumber) is
greater than any prior, valid CRLs or Manifests processed by the RP.

Stale: A CRL or Manifest is stale if the current date & time is later
than the Next Update date. A stale CRL or Manifest is not “expired”
it’s just not as current as it is supposed to be. The case analysis
below examines what to do when a Manifest, or CRL, or both are stale.

Missing: an object named in a Manifest, but not available for download
from a PP, is termed *missing*. An RP has no obvious way to acquire
missing objects, but operators SHOULD be warned about which objects
are missing.

Corrupted: if an object named in a Manifest, is available for download
from a PP, but it’s hash does not match the corresponding value in the
Manifest, the object is termed *corrupted* and the object SHOULD be
ignored.

Can you also provide a definition for your use of the word 'invalid'? I
see the phrase used in the case analysis permutations.

I would call a signed object invalid if it is syntactically broken (e.g., bad ASN.1 encoding), or if the signature cannot be validated as specified in RFC 6488. This is just another way of saying that it fails either of the  criteria cited in definition of valid.

Steve


--------------2293205DBF3BCBC59959813F-- From nobody Sun Apr 5 18:22:53 2020 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A5D3A0A9D; Sun, 5 Apr 2020 18:22:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-sidrops-rp@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, Nathalie Trenaman , nathalie@ripe.net X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <158613616207.15143.11123745814428159832@ietfa.amsl.com> Date: Sun, 05 Apr 2020 18:22:42 -0700 Archived-At: Subject: [Sidrops] Erik Kline's Yes on draft-ietf-sidrops-rp-06: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 01:22:43 -0000 Erik Kline has entered the following ballot position for draft-ietf-sidrops-rp-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- {Yes} [nits] S4.2.2 * This is the first time ROA is really used. Consider expanding it here one time, or up in the introduction where it first appears in the list of RFCs. S4.2.4 * I had some trouble parsing "but using the constraints applied come from ...". S4.3 * s/make decision/make decisions|make a decision/ S4.4 * s/slate/stale/ From nobody Mon Apr 6 09:49:14 2020 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C783A0A5F; Mon, 6 Apr 2020 09:49:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-sidrops-ov-egress@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, sidrops-chairs@ietf.org, keyur@arrcus.com, warren@kumari.net, nathalie@ripe.net, keyur@arrcus.com X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <158619174173.5693.3701421912223917488@ietfa.amsl.com> Date: Mon, 06 Apr 2020 09:49:02 -0700 Archived-At: Subject: [Sidrops] Alissa Cooper's No Objection on draft-ietf-sidrops-ov-egress-02: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 16:49:02 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-sidrops-ov-egress-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-egress/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "Therefore it SHOULD be possible to specify an origin validation policy which MUST BE run after such non-deterministic policies." The normative language here doesn't quite make sense. "MUST BE" is not a normative keyword and the construction "SHOULD ... which MUST" is a little confusing. I would suggest something like: An origin validation policy that is required to be run after such non-deterministic policies SHOULD be specified. From nobody Mon Apr 6 09:51:02 2020 Return-Path: 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 97E033A0887; Mon, 6 Apr 2020 09:50:42 -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, 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=cooperw.in header.b=TGmMEuLW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rOF8iwyj 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 6gMdMZbXn3by; Mon, 6 Apr 2020 09:50:40 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 515DC3A0865; Mon, 6 Apr 2020 09:50:33 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 48A3F945; Mon, 6 Apr 2020 12:50:32 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 06 Apr 2020 12:50:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=7 RkE7vVEwH0SI5TBZBxBZE6Nuz7K1Y/bXQZTgBsr68k=; b=TGmMEuLWwm2aSJUrN FhXeTKlqa5ScHNyjS1ZoHTZqFpD3JBc7dchOHmA6HyePQSeypTkNYvuggomsbKqr k/Kl18lyq7ZhIIFChNEBKozw8/1cTA3rfGdX2cJN0Ir0sFaFAOdEGd1PXdxAjLAX lhurV9Tcxg/To+pS/hwcDbd9L5a3ZHKbRwWIlLlJuhWQkVykaE18jrRI5F7+BuP5 Yp0899O3rHrV52JvNUrKXJZU8hPr3teFxrYJx/9S4zZ6X+ogYb2n1gBBnq1ElatL p6MW6pH4DEbjejIhJDPjKOT/UV4LLhmtyuT5HBnGqNsz2Z3YxeHkq6R/RaEo20FD ryopg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=7RkE7vVEwH0SI5TBZBxBZE6Nuz7K1Y/bXQZTgBsr6 8k=; b=rOF8iwyjTxvYBpUPHO7klPbEu8KjFg3+wcanckQXx/6bQfCZ94xqEEmxU hnbehwvydomUoU2B/3YBu9kQWM++s8jXsZhMybm75r91q9th4NXMzXpWKzfb6Cha KJMMkSAsyrHIx5XKzR0ey0bIFDeujer16AF5mKQ7rwJexuWmhFmoKXkJSZCr2ce0 0kFXhoUgodQUjL43qeuRpoBp5qLni63+QlA56rrUF+6oYJ1i8H7xBVp98bduJJ2L m2nLn81I6vNmsLAHn8Coc5v0UdLr2jcEGuSXlGclVkBhiYmslhSZn+REk8xoP/Mf dYDvcnwa4KaysvClidMzS7xO3vFTQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudefgdellecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepuddtkedrhedurddutddurdelkeenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhishhsrgestghooh hpvghrfidrihhn X-ME-Proxy: Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id 670A63280067; Mon, 6 Apr 2020 12:50:31 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) From: Alissa Cooper In-Reply-To: <158411258778.3418.757369789772046254@ietfa.amsl.com> Date: Mon, 6 Apr 2020 12:50:30 -0400 Cc: gen-art@ietf.org, last-call@ietf.org, sidrops@ietf.org, draft-ietf-sidrops-ov-egress.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <000C921B-6DE3-4E59-B349-B013F3798C7F@cooperw.in> References: <158411258778.3418.757369789772046254@ietfa.amsl.com> To: Robert Sparks X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: Re: [Sidrops] [Gen-art] Genart last call review of draft-ietf-sidrops-ov-egress-01 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 16:50:43 -0000 Robert, thanks for your review. All, thanks for your responses and text = updates. I entered a No Objection ballot. Alissa > On Mar 13, 2020, at 11:16 AM, Robert Sparks via Datatracker = wrote: >=20 > Reviewer: Robert Sparks > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-sidrops-ov-egress-01 > Reviewer: Robert Sparks > Review Date: 2020-03-13 > IETF LC End Date: 2020-03-18 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: Ready for publication as a Proposed Standard RFC >=20 > Very minor nit - feel free to ignore - >=20 > This sentence slowed me down when reading: >=20 > As the origin AS may be modified by outbound policy, policy = semantics > based on RPKI Origin Validation state MUST be able to be applied > separately on distribution into BGP and on egress. >=20 > I suggest something like: >=20 > As the origin AS may be modified by outbound policy, a BGP speaker=20 > MUST be able to apply policy semantics based on RPKI Origin = Validation=20 > state separately on distribution into BGP and on egress. >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Mon Apr 6 10:07:33 2020 Return-Path: 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 AC6163A0AE0; Mon, 6 Apr 2020 10:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 RwXH7ofc82ku; Mon, 6 Apr 2020 10:07:07 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BDE33A0AE5; Mon, 6 Apr 2020 10:07:06 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jLVDD-0005i4-Ou; Mon, 06 Apr 2020 17:07:04 +0000 Date: Mon, 06 Apr 2020 10:07:02 -0700 Message-ID: From: Randy Bush To: Alissa Cooper via Datatracker Cc: "The IESG" , draft-ietf-sidrops-ov-egress@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, keyur@arrcus.com, warren@kumari.net, nathalie@ripe.net In-Reply-To: <158619174173.5693.3701421912223917488@ietfa.amsl.com> References: <158619174173.5693.3701421912223917488@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Alissa Cooper's No Objection on draft-ietf-sidrops-ov-egress-02: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 17:07:09 -0000 > "Therefore it SHOULD be possible to specify an origin validation > policy which MUST BE run after such non-deterministic policies." > > The normative language here doesn't quite make sense. "MUST BE" is not a > normative keyword and the construction "SHOULD ... which MUST" is a little > confusing. point > I would suggest something like: > > An origin validation policy that is required to be run after such > non-deterministic policies SHOULD be specified. nope. that says the op SHOULD specify the policy; when MAY would be the appropriate point here. how about a simpler hack (with context)? Configurations may have complex policy where the final announced origin AS may not be easily predicted before these policies have been run. Therefore it SHOULD be possible to specify an origin validation policy which will run after all such non-deterministic policies. i suspect some might suggest the point of the draft should really be s/SHOULD/MUST/ randy From nobody Mon Apr 6 10:43:19 2020 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B033A0D06; Mon, 6 Apr 2020 10:43:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-sidrops-ov-egress@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, sidrops-chairs@ietf.org, keyur@arrcus.com, warren@kumari.net, nathalie@ripe.net, keyur@arrcus.com X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <158619498278.23732.2401194914615255069@ietfa.amsl.com> Date: Mon, 06 Apr 2020 10:43:03 -0700 Archived-At: Subject: [Sidrops] Robert Wilton's No Objection on draft-ietf-sidrops-ov-egress-02: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 17:43:03 -0000 Robert Wilton has entered the following ballot position for draft-ietf-sidrops-ov-egress-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-egress/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm not a BGP expert, but this document seems sensible to me. Some comments: 1) In the first sentence of the introduction: Is it really correct that the "This document does not change semantics of [RFC6811] RPKI-based origin validation"? Given that the 4th paragraph in the introduction then states that "This document clarifies ..." 2) I wasn't entirely sure that section 2 (Suggested Reading) is required at all, given that this is effectively what section 8.1 and 8.2 is listing anyway, but equally I'm okay if the section is left in. 3) The security section is terse, and I agree that this doesn't introduce any new security issues. But I was wondering if the purpose of this clarification is to improve security with more reliable filtering, and if so, would it be helpful to have a sentence in the security section that states that? One nit: 1) In the first sentence of the introduction "of [RFC6811] of RPKI-based origin validation" -> "of [RFC6811] RPKI-based origin validation"? From nobody Mon Apr 6 11:09:53 2020 Return-Path: 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 6AE6A3A0D59; Mon, 6 Apr 2020 11:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 DcExFASOkEnp; Mon, 6 Apr 2020 11:09:28 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 010FD3A0D7E; Mon, 6 Apr 2020 11:09:27 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jLWBZ-0005wC-6q; Mon, 06 Apr 2020 18:09:25 +0000 Date: Mon, 06 Apr 2020 11:09:21 -0700 Message-ID: From: Randy Bush To: Robert Wilton via Datatracker Cc: "The IESG" , draft-ietf-sidrops-ov-egress@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, keyur@arrcus.com, warren@kumari.net, nathalie@ripe.net In-Reply-To: <158619498278.23732.2401194914615255069@ietfa.amsl.com> References: <158619498278.23732.2401194914615255069@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Robert Wilton's No Objection on draft-ietf-sidrops-ov-egress-02: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 18:09:30 -0000 > 1) In the first sentence of the introduction: Is it really correct that the > "This document does not change semantics of [RFC6811] RPKI-based origin > validation"? Given that the 4th paragraph in the introduction then states that > "This document clarifies ..." the document adds, not modifies. > 2) I wasn't entirely sure that section 2 (Suggested Reading) is > required at all, given that this is effectively what section 8.1 and > 8.2 is listing anyway, but equally I'm okay if the section is left in. yes, the Suggested Reading kinda duplicates many References. yet we still get requests to enumerate all the bgp features which modify AS and other disgusting bgp knobs. it was hoped that a bit of rtfm would help. there is an underlying problem that there are many knobs which are not in rfcs; and it is not clear that they are even enumerable. > 3) The security section is terse, and I agree that this doesn't introduce any > new security issues. But I was wondering if the purpose of this clarification > is to improve security with more reliable filtering, and if so, would it be > helpful to have a sentence in the security section that states that? This document does not create security considerations beyond those of [RFC6811] and [RFC8481]. By facilitating more correct validation, it attempts to improve BGP reliability. i hesitated to say increses 'security', as origin validation is more accident reduction than a real security mechanism. this distinction is too oft misunderstood. > 1) In the first sentence of the introduction "of [RFC6811] of RPKI-based origin > validation" -> "of [RFC6811] RPKI-based origin validation"? actually, i looked at the title of 6811, and the text is now [RFC6811], BGP prefix origin validation. thanks! randy From nobody Mon Apr 6 15:07:18 2020 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 908223A0D29; Mon, 6 Apr 2020 15:07:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana via Datatracker To: "The IESG" Cc: draft-ietf-sidrops-ov-egress@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, sidrops-chairs@ietf.org, keyur@arrcus.com, warren@kumari.net, nathalie@ripe.net, keyur@arrcus.com X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alvaro Retana Message-ID: <158621083315.16634.8714357093097492160@ietfa.amsl.com> Date: Mon, 06 Apr 2020 15:07:13 -0700 Archived-At: Subject: [Sidrops] Alvaro Retana's No Objection on draft-ietf-sidrops-ov-egress-02: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 22:07:14 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-sidrops-ov-egress-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-egress/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (0) This document should be marked as replacing draft-ymbk-sidrops-ov-egress. (1) The purpose of this document is to clarify "that implementations must use the effective origin AS". The use of "effective" seems deliberate to qualify a specific characteristic of the origin AS. However, the term is not only not defined anywhere (with respect to simply using "origin AS", for example), but there is inconsistency in the language, for example: "origin Autonomous System number which will actually be put in the AS_PATH" or "final announced origin AS". Please be clear in the definition, and consistent in the language used. (2) §1: As the origin AS of a BGP UPDATE is decided by configuration and outbound policy of the BGP speaker, a validating BGP speaker MUST apply Route Origin Validation policy semantics against the origin Autonomous System number which will actually be put in the AS_PATH (see [RFC4271] 4.3 Path Attributes:b) of the UPDATE to the peer. (2a) [major] "MUST apply Route Origin Validation policy semantics against the origin Autonomous System number which will actually be put in the AS_PATH" Put where? The assumption in this text seems to be that there will only be one AS number present (even with prepending), in line with §5.1.2/rfc4271. However, rfc7705 (which Updates rfc4271) specifies AS migration mechanisms...some of which may result in more than one AS number placed in the AS_PATH (even at route origination). It is then important to clarify *where* the ASN "will actually be put", or which ASN should the validation be done against. [Note that this is a variation of the initial comment about clearly defining the terms.] (2b) [nit] s/(see [RFC4271] 4.3 Path Attributes:b)/([RFC4271]) Not only is the detailed reference unnecessary, but the format may be confusing. Also, it is §5.1.2 the section that actually talks about the use of the AS_PATH. (3) §1: It would be very nice to add these references: s/confederation, AS migration/confederation [rfc5065], AS migration [rfc7705] Given the comment above, the reference to rfc7705 should be Normative. (4) §3: "BGP implementations supporting RPKI-based origin validation SHOULD provide the same policy configuration primitives for decisions based on validation state available for use in ingress, redistribution, and egress policies." When would it be ok for an implementation not to "provide the same policy configuration"? IOW, why is MUST not used? s/SHOULD/MUST (5) §4: Configurations may have complex policy where the final announced origin AS may not be easily predicted before all policies have been run. Therefore it SHOULD be possible to specify an origin validation policy which MUST BE run after such non-deterministic policies. (5a) [major] "SHOULD be possible to specify an origin validation policy" What is an "origin validation policy"? To me it sounds as the ability to either validate or not: as in, "the policy is to validate for this origin AS, but not for a different one". Is that it? Or are you referring to a blanket policy akin to "if the origin AS is X, then the route must always be considered Valid"?? [This piece of text confuses me more given the suggestion to Alissa's comments: "Therefore it SHOULD be possible to specify an origin validation policy which will run after all such non-deterministic policies." A validation policy for *all* policies??] (5b) I know that this next point was discussed on the list...but describing the outcome of complex policy as not "easily predicted" and non-deterministic is causing me a lot of heartburn. I can see how optional information in an Update (communities, etc.) can cause a policy result to be known only at "run time", but that doesn't make the outcome unpredictable or non-deterministic: the outcome of the policy is what it is supposed to be, given the current conditions -- we just didn't know before the Update was received. This is a non-blocking comment and you can consider it a nit...it simply sounds as if the operator was guessing, and I know some are not. ;-) s/...may not be easily predicted before all policies...such non-deterministic policies./...may be determined only after all policies...such policies. (6) §4: "SHOULD be able to list what announcements are not sent to a peer because they were marked Invalid, as long as the router still has them in memory." After reading this text many times, I think I understand that you mean that the operator should be able to use a "show command"...and not that he/she should be able to create a list of announcements (as in a filter). Is that what you mean? Suggestion (maybe something like this)> An implementation SHOULD display announcements that are not sent to a peer because they were marked Invalid, as long as the router still has them in memory. From nobody Tue Apr 7 01:07:48 2020 Return-Path: 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 F17593A18C0; Tue, 7 Apr 2020 01:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DglHwLp0; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=l6j2GgL8 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 3nAqV2BfiK7h; Tue, 7 Apr 2020 01:07:41 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 406CE3A18BE; Tue, 7 Apr 2020 01:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2698; q=dns/txt; s=iport; t=1586246861; x=1587456461; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=W7/jgvBAbJUv51QncVw71vWD+G2mM0xLSlfYzKTRLWo=; b=DglHwLp0P7zxHZufYf3miM3LvwSzLuAZkGNJItswuaMNXhrqxlJw3to+ Z6z6gDnO+Uw8u9MsskkHIz/7cB+m/mN8xqqs/+qREraYqKWgsWaQLSi2D PLJf03HyKW17ATlQLWzimqFQSldoX/5zE5oz9/rW5b/Lphw5/WReIxyFH U=; IronPort-PHdr: =?us-ascii?q?9a23=3AKRC4XRdDm9YTRde/91G3QDJ7lGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dTM7GNhFUndu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A2DAD+M4xe/40NJK1mHgELHIFwC4F?= =?us-ascii?q?UUAWBRCAECyoKh1YDimdOghGYIIEugSQDVAoBAQEMAQEtAgQBAYREAoJKJDY?= =?us-ascii?q?HDgIDAQELAQEFAQEBAgEFBG2FVgyFcAEBAQECARIVEwYBATcBCwQCAQgRBAE?= =?us-ascii?q?BHxAyHQgCBA4FCBqFUAMOIAEDpHYCgTmIYoF0M4J/AQEFhTgYgg0JgTiMMxq?= =?us-ascii?q?BQT+BEUOCTT6EUINCgiyQSZB1j2QKgj2Sc4RUnAKrXAIEAgQFAg4BAQWBWQ4?= =?us-ascii?q?kgVdwFRqDClAYDY4dOIM7ilV0gSmLYi2BBAGBDwEB?= X-IronPort-AV: E=Sophos;i="5.72,353,1580774400"; d="scan'208";a="749894134" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Apr 2020 08:07:40 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 03787e88001285 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Apr 2020 08:07:40 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 7 Apr 2020 03:07:40 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 7 Apr 2020 03:07:39 -0500 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 7 Apr 2020 03:07:39 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HZM6cBZPFANDfiqD7p1Htv9Z8jzEV6CghsAU3NW6rpGf8tHTfGGtA6z7GWNoWAdnJMM0vyQh6eaEQpY7dHKruaPD0O8bCRPvpRREmbwj6VupNaUzJSN0ksAe5WuhI1T3Ept60OeBB0WnhXhZQrGip7r7J4UCFguof11xX0eygNxkGttLfRdX7CxC/zpK+kIgfH9zgScVrO6+RO9sc9CjVK8j6wxdNj98obKQK/352Q66BtgFvOhMsYvggqvTmKSOv1bKr8qoets70tR/qs0GHaxI3s8LjcByPlWCEGetD8cw5we5g8oskDHTXJt9kjn6yvI1FwmHNnwRDeNvjRtLYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cgXEYGz471Qa+y6ETt6rB/Q2icjcchlX7IjLNPBRGwM=; b=ka2B4F5itrxaWOoNL8n7f+eusvOJ8TaoLSGmmIakVbkHDcgJ20gsvPxYI7Auv2Wo1fNh/SWZczlmR2cZp1p3pnsgFZSVFJUYrCHSoJKBMs+ihAY6eyvCw5avJUWz/61QeXr/d2UX3aRPEh75eZxVBPLqFqsD45oBhEziA7O/R56Vmvrq5k/XoiheVGzCo1RZYm3r61Bh0WnuSixlE7L5xcrbZPpQ1yD2FJIYBni6ue6jSnIf/AUbDiXsjrHL+YGg0t8HZ2pbnf4VWOPItDZ+YSF5oc52Y0vJjxnrPld7nW9WddmyD5JXPlk4Kn9S0jE1ENJVYNpEJHrWQTWs9c2h1Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cgXEYGz471Qa+y6ETt6rB/Q2icjcchlX7IjLNPBRGwM=; b=l6j2GgL8MMx7TzkpsFST6/zVUb4w6boJEyLLoUIbnbseB7c+OSW8XVgq0Gp2rSuPDh17mgB93OhK6oFZkOWuCA6NVBILdg+c1HRur/I34pioVt9Jpj/G4B0hHFMh7dwebcldTYO1g/g30ljnMU+S+nte1XY47Cy3eFxTFRN8iPM= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB3551.namprd11.prod.outlook.com (2603:10b6:208:ea::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Tue, 7 Apr 2020 08:07:38 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3:2164:a8e2:33b3]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3:2164:a8e2:33b3%5]) with mapi id 15.20.2878.018; Tue, 7 Apr 2020 08:07:38 +0000 From: "Rob Wilton (rwilton)" To: Randy Bush CC: "keyur@arrcus.com" , "sidrops@ietf.org" , "draft-ietf-sidrops-ov-egress@ietf.org" , "sidrops-chairs@ietf.org" , The IESG , "nathalie@ripe.net" , "warren@kumari.net" Thread-Topic: Robert Wilton's No Objection on draft-ietf-sidrops-ov-egress-02: (with COMMENT) Thread-Index: AQHWDDrtB/dYhjXXtE6Xu3DmkQLpKqhsZIeAgADo7VA= Date: Tue, 7 Apr 2020 08:07:37 +0000 Message-ID: References: <158619498278.23732.2401194914615255069@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [82.15.79.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0dd2017b-ed9a-4e14-710d-08d7dacabcc9 x-ms-traffictypediagnostic: MN2PR11MB3551: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(396003)(366004)(136003)(39860400002)(376002)(4326008)(33656002)(8676002)(9686003)(71200400001)(81156014)(86362001)(8936002)(55016002)(66946007)(76116006)(66476007)(64756008)(478600001)(52536014)(66556008)(5660300002)(2906002)(81166006)(6916009)(6506007)(7696005)(54906003)(26005)(316002)(66446008)(186003)(53546011); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JbewWapRM7DQruWAt78+AnFuZe317J17MeYGtzf4o1eLALjndJqmgaUgB5p9++XCByIn5JE/kPeg5QGoDd5UoiJMLbIX6HhK4ms02MybvJ+YjzIMkCcAFwSU54pgtqs094HNytpw8X9r72I6bYcT17eYz0yHWw2XZDSdyiVq33KFn8bR97iPaBee5nIzpOXUor/Bn8P2YTzXofogmywrLPotUu8FN610TKphZtymXh+IpnxKpKP0SOnDPKfHrjMAgV69QoK70dn5yFejAu40Al0F+mcMUTEGcqhSfWifuLcyrLgRrfpJUiApcyuAW8M3z2tW/GJdNLn3uqTJkOhgc38O9m3KM3wGDtSxlyubX6ImcxQPhSxnL0RE8TZ5vdMh/IQv/gBCoamhrpvFSaAA+E0rbkA5otnkrYmkX7vR0DoA46Inl/FoGt7RxyFhWkGa x-ms-exchange-antispam-messagedata: Nrw1wu+w4fM7vf2Ca/w9L7IPuM33aPXhCEJwaSxi9OVUALqhH8I32sZBD2Py4C+wwl1ttYkdlsp0oVxiKaoYoiUxKG6ZkjRaju1f3QRyohtOrPgBQ8i8F6EVT8wUqVloxwG6npftcbO5DlHN8Vni5w== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0dd2017b-ed9a-4e14-710d-08d7dacabcc9 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2020 08:07:37.9752 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YQCi0EIumhhWmdzcjlAUbxuCLuulGbMl8PLHBxvHNtt/jbQNHh/IIaXKJ28NZPkww+7S7Xm6cSjS/gV9ELt5Rg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3551 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [Sidrops] Robert Wilton's No Objection on draft-ietf-sidrops-ov-egress-02: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 08:07:43 -0000 > -----Original Message----- > From: iesg On Behalf Of Randy Bush > Sent: 06 April 2020 19:09 > To: Robert Wilton via Datatracker > Cc: keyur@arrcus.com; sidrops@ietf.org; draft-ietf-sidrops-ov- > egress@ietf.org; sidrops-chairs@ietf.org; The IESG ; > nathalie@ripe.net; warren@kumari.net > Subject: Re: Robert Wilton's No Objection on draft-ietf-sidrops-ov-egress= - > 02: (with COMMENT) >=20 > > 1) In the first sentence of the introduction: Is it really correct > > that the "This document does not change semantics of [RFC6811] > > RPKI-based origin validation"? Given that the 4th paragraph in the > > introduction then states that "This document clarifies ..." >=20 > the document adds, not modifies. [RW]=20 Okay. Possibly pulling the 4th paragraph about updating into the first par= agraph would make the document more clear as to how it is treats/updates RF= C6811, but I'm also okay if you want to leave the introduction as is. >=20 > > 2) I wasn't entirely sure that section 2 (Suggested Reading) is > > required at all, given that this is effectively what section 8.1 and > > 8.2 is listing anyway, but equally I'm okay if the section is left in. >=20 > yes, the Suggested Reading kinda duplicates many References. yet we stil= l > get requests to enumerate all the bgp features which modify AS and other > disgusting bgp knobs. it was hoped that a bit of rtfm would help. there > is an underlying problem that there are many knobs which are not in rfcs; > and it is not clear that they are even enumerable. >=20 > > 3) The security section is terse, and I agree that this doesn't > > introduce any new security issues. But I was wondering if the purpose > > of this clarification is to improve security with more reliable > > filtering, and if so, would it be helpful to have a sentence in the > security section that states that? >=20 > This document does not create security considerations beyond those of > [RFC6811] and [RFC8481]. By facilitating more correct validation, it > attempts to improve BGP reliability. [RW]=20 LGTM. >=20 > i hesitated to say increses 'security', as origin validation is more > accident reduction than a real security mechanism. this distinction is > too oft misunderstood. >=20 > > 1) In the first sentence of the introduction "of [RFC6811] of > > RPKI-based origin validation" -> "of [RFC6811] RPKI-based origin > validation"? >=20 > actually, i looked at the title of 6811, and the text is now >=20 > [RFC6811], BGP prefix origin validation. >=20 > thanks! >=20 > randy Thanks, Rob From nobody Tue Apr 7 09:03:35 2020 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B48A83A0DA1; Tue, 7 Apr 2020 09:03:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-sidrops-ov-egress@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, sidrops-chairs@ietf.org, keyur@arrcus.com, warren@kumari.net, nathalie@ripe.net, keyur@arrcus.com X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158627541271.31464.16065110875282211603@ietfa.amsl.com> Date: Tue, 07 Apr 2020 09:03:32 -0700 Archived-At: Subject: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-ov-egress-02: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 16:03:33 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-sidrops-ov-egress-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-egress/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Abstract [IIRC the mention of "updates 6811" is queued already.] Section 1 As the origin AS of a BGP UPDATE is decided by configuration and outbound policy of the BGP speaker, a validating BGP speaker MUST apply Route Origin Validation policy semantics against the origin Autonomous System number which will actually be put in the AS_PATH (To the extent that the speaker applies outbound policy at all? Or is that required by being a "validating BGP speaker"?) Section 3 will (or would) be announced to the peer. The effective origin AS may differ from that of the route in the RIB due to commonly available knobs such as: removal of private ASs, AS path manipulation, confederation handling, etc. Do we feel a need to add a "but not limited to"? Feels like overkill to me... nit: earlier we wrote "private AS(s)" Section 4 Configurations may have complex policy where the final announced origin AS may not be easily predicted before all policies have been run. Therefore it SHOULD be possible to specify an origin validation policy which MUST BE run after such non-deterministic policies. nit: are complex policies necessarily non-deterministic (vs. "not easily predicted")? From nobody Tue Apr 7 10:39:24 2020 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 307543A0ACF; Tue, 7 Apr 2020 10:39:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana via Datatracker To: "The IESG" Cc: draft-ietf-sidrops-rp@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, Nathalie Trenaman X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alvaro Retana Message-ID: <158628115517.31038.16065105204924712745@ietfa.amsl.com> Date: Tue, 07 Apr 2020 10:39:15 -0700 Archived-At: Subject: [Sidrops] Alvaro Retana's Abstain on draft-ietf-sidrops-rp-06: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 17:39:15 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-sidrops-rp-06: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ABSTAIN This document presents a nice summary, but I am ABSTAINing, and not standing in the way of publication, because I don't think the contribution has enough archival value and it could cause confusion. While the document tries to provide "a single reference point", it mostly points at other RFCs, which an implementer will have to consult anyway. IOW, this document seems to add to the list. No normative language is used, which is good from the point of view that this document doesn't define a specification, but in some places the text implies a requirement level, which may cause confusion -- again, the reader will have to consult the existing RFCs... The document itself recognizes the need to maintain it up to date: "This document will be update to reflect new or changed requirements as these RFCs are updated, or new RFCs are written." (s/be update/be updated) And the difficulty in doing so is evident in the fact that one of the referenced RFCs is already obsolete, but the text doesn't reflect that. [Even though I'm ABSTAINing, I have a couple of comments.] (1) This paragraph from §4.3 caught my eye... If there are valid objects in a publication point that are not present on a Manifest, [RFC6486] does not mandate specific RP behavior with respect to such objects. However, most RP software ignores such objects and the authors of this document suggest this behavior be adopted uniformly. ...because in it the authors get away from pointing at the existing RFCs to suggest a behavior. That clearly should not be the job of this document. (2) Nits: s/RPKI make use/RPKI makes use s/one of necessary/one of the necessary s/RP is required perform/RP is required to perform s/[RFC8208]and/[RFC8208] and From nobody Tue Apr 7 11:35:46 2020 Return-Path: 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 CC0963A0CC8 for ; Tue, 7 Apr 2020 11:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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=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 pdwXUBQuGPFX for ; Tue, 7 Apr 2020 11:35:44 -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 91A643A0CCD for ; Tue, 7 Apr 2020 11:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1586284543; bh=rEw5j6eHiyEOS5G14r5aV5jU0LYkqVxrJVEShBX6kNw=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=bBoJLnk3Z12dyAbxk5xBrXny6l5TUMhVR6mZ3weihAiV/kTOBSsyn5wt1zJISEaBZgJZqoBoW/tm8NWV0nHVoS3X2CndL12BWtR5icRVddzKeWv8rCI3jzOsNHARyShn2kGAAyTeDe6dUWEG7Q57NIm63rIdxrVK6lFc/0nxOub9frCpuYZeFzdztVO+92mDjHM/YUN+pm5qJa+poc/qyi785h5DlB8BParMLWXZtyqoGauw5bLfYoU8GzWf+uMsYTpprO7mz2YEX1ysgaPeHvzW1MJK2jem6PGuQ1l2YNWzZOe32lYrrOSOp99QdTEspz1YsiQNXei2Y29I2A3Ymg== X-YMail-OSG: c9A2wk8VM1kBhZSQJkKQP6_lO_JmJlICRxQNZRNPI.oGSI4HLL0E9Sh3mE1zJjk fEEbeiEwRd5Hv4VA6.FPW3UPbPAoIVsKFgi1sH8.f8LsSYN87nyd9zUYlshRjBGJTqMujhduS3ym bRVxuhTtQG0rt0jzwtogk3M6eNlxDnTqHHB7nNPGK_QbLBL6zGQEbNQtpzU7J3a1iaTx_jUYv.2G 6A.En0Xd2yR.f0tlNLDavpTQlTE9GMXZW9_hcU39BkWLG1mOrVTA5te5owNS4REoCBaH9xw1DL4L ETi1AyV3JqykqcertpuEtik4G3aWjRJGGLH.qFxdHZaUvABtyGR67RzWXRwdIB0Cxm9_dXOiXhFw LeLDz0m_N0cJ.wutskvyTPHB4kBQqyiUnjgDNqjtv89fpgCFnx6rkBXnIcx0pwJdBdQ.nUcMmC4A 6G9UNVM9X3OYM0SB6t4cgHNQNwUKcUAmShHHbgTso8Un5yN6Ru6BtAmwBkJb391trhyvcTGQaoOB swRYA.XEWHji6rnk9WiSPcYnw6w.6qDvuZoqiCRl1QxZGHX.1ij0UkkZ4_HtnCXFSQ3SFwnsN16S zvYFFqcV_QCj9pHTr2UPsRTu6F5k..OUDiojVtFczihirKSA9fKNKFoDQ87TKpWp0PWJt0cGzkCf U9tK70jGTnmeB9rzZBxINVYZDX92dFZXH3k3Sf_huubiBxcFiqm5mcFkexzJhUE8iPg2EFJd1tvR IhFP36I5fN6r7wegdQ2phBfDDWCgwOEWxFlaA8JUrgvIeiTIq1OPguSCy3vUdqNLJuMhNgYR8cqO EMohX6Ykrl5dTNvVZXftdzvwTxy0.ZPaKBua0Cwc2NrdwJcffhKgW3M6QKxo9dYe4padzpMEB_ZI YucAqA0xjq2.bLHqp6.ZLF4JcPBfTb6q60KwmjrDwDEFQbNxAqdPv2nWEAfaZRZi.lMqPbp7ycQ9 Qnnx0mkUc91DDuEweef9F4Pu81YQzhA2TXvn1TfskgS3jGsIZCfkL_onMnRL5xWi75NcAGU4NXeT L7Xs5R1vkePmqbDiNkqUPm3aN8A0C9ETOVlWgr2cKGklZAkpVQDAEGT1AfrwroCIdrmBnwP3pC5m dy2SJdsUlMb1fsBUuHPRRjsaEREY9RBxh_BhMKxJ169vNbyNlD20FChXrsrBqIM_zs2IYzfwRV3F W2SOz.b2AtATE.xNSlzms1A57_clQhF3ETcVQSSPfnjMoge5Eor24eLS92TNATvkoxt9f2.YT_ed nqMq7Uo6a87RhtbaNhqfTqmYyk39Y48ADJbS.Ffa08vuRlVKz4dpcRTsmyclAxBQMKzrn68hl4rj Ssgk4sVEk2OVaV2lZnDvdzG0oe552bn23NmS.dF54V958XJk.rh6IF3mhI0yQDERHr5RQuFAuMLS UFFiKkdPvWk9S8_2BNf9gAkVwQdN85Q-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Tue, 7 Apr 2020 18:35:43 +0000 Received: by smtp415.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7155b2b350817975b175bae26ef1d54c; Tue, 07 Apr 2020 18:35:41 +0000 (UTC) To: sidrops@ietf.org, iesg@ietf.org, "sidrops-chairs@ietf.org" References: <158628115517.31038.16065105204924712745@ietfa.amsl.com> From: Stephen Kent Message-ID: <22060449-5cd4-603b-b96f-12415e989c26@verizon.net> Date: Tue, 7 Apr 2020 14:35:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <158628115517.31038.16065105204924712745@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailer: WebService/1.1.15620 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) Archived-At: Subject: Re: [Sidrops] Alvaro Retana's Abstain on draft-ietf-sidrops-rp-06: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 18:35:46 -0000 Alvaro, > > (1) This paragraph from §4.3 caught my eye... > > If there are valid objects in a publication point that are not > present on a Manifest, [RFC6486] does not mandate specific RP > behavior with respect to such objects. However, most RP software > ignores such objects and the authors of this document suggest this > behavior be adopted uniformly. > > ...because in it the authors get away from pointing at the existing RFCs to > suggest a behavior. That clearly should not be the job of this document. You're right and we will delete the offending sentences. The WG has recently decided to try to adopt uniform procedures for dealing with the ambiguous areas in 6486 and this issue will be addressed there. > > (2) Nits: > > s/RPKI make use/RPKI makes use > > s/one of necessary/one of the necessary > > s/RP is required perform/RP is required to perform > > s/[RFC8208]and/[RFC8208] and We will make the edits you suggest. Thanks for your review. Steve From nobody Tue Apr 7 13:45:44 2020 Return-Path: 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 4A6CC3A11D9; Tue, 7 Apr 2020 13:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 neoBQuCkedXA; Tue, 7 Apr 2020 13:45:32 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3A913A11C4; Tue, 7 Apr 2020 13:45:31 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jLv69-0001Gh-Vx; Tue, 07 Apr 2020 20:45:30 +0000 Date: Tue, 07 Apr 2020 13:45:24 -0700 Message-ID: From: Randy Bush To: Alvaro Retana via Datatracker Cc: "The IESG" , draft-ietf-sidrops-ov-egress@ietf.org, sidrops@ietf.org In-Reply-To: <158621083315.16634.8714357093097492160@ietfa.amsl.com> References: <158621083315.16634.8714357093097492160@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] Alvaro Retana's No Objection on draft-ietf-sidrops-ov-egress-02: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 20:45:35 -0000 cc: redundancy reduced thanks alvaro for the thorough and helpful review > (0) This document should be marked as replacing draft-ymbk-sidrops-ov-egr= ess. an elf seems to have done that; thanks elf > (1) The purpose of this document is to clarify "that implementations > must use the effective origin AS". The use of "effective" seems > deliberate to qualify a specific characteristic of the origin AS. > However, the term is not only not defined anywhere (with respect to > simply using "origin AS", for example), but there is inconsistency in > the language, for example: "origin Autonomous System number which will > actually be put in the AS_PATH" or "final announced origin AS". > Please be clear in the definition, and consistent in the language > used. added The term 'effective origin AS' as used in this document refers to the Autonomous System number which is used by [RFC6811] BGP Prefix Origin Validation. and made text consistent > (2) =A71: >=20 > As the origin AS of a BGP UPDATE is decided by configuration and > outbound policy of the BGP speaker, a validating BGP speaker MUST > apply Route Origin Validation policy semantics against the origin > Autonomous System number which will actually be put in the AS_PATH > (see [RFC4271] 4.3 Path Attributes:b) of the UPDATE to the peer. >=20 > (2a) [major] "MUST apply Route Origin Validation policy semantics against= the > origin Autonomous System number which will actually be put in the AS_PATH= " Put > where? >=20 > The assumption in this text seems to be that there will only be one AS n= umber > present (even with prepending), in line with =A75.1.2/rfc4271. However,= rfc7705 > (which Updates rfc4271) specifies AS migration mechanisms...some of whic= h may > result in more than one AS number placed in the AS_PATH (even at route > origination). It is then important to clarify *where* the ASN "will act= ually > be put", or which ASN should the validation be done against. [Note that= this > is a variation of the initial comment about clearly defining the terms.] >=20 > (2b) [nit] s/(see [RFC4271] 4.3 Path Attributes:b)/([RFC4271]) >=20 > Not only is the detailed reference unnecessary, but the format may be > confusing. Also, it is =A75.1.2 the section that actually talks about t= he use > of the AS_PATH. how about As the effective origin AS of a BGP UPDATE is decided by configuration and outbound policy of the BGP speaker, a validating BGP speaker MUST apply Route Origin Validation policy semantics (see [RFC6811] Sec 2 and [RFC8481] Sec 4) against the origin Autonomous System number which will actually be used by subsequent [RFC6811] BGP Prefix Origin Validation. > (3) =A71: It would be very nice to add these references: s/confederation,= AS > migration/confederation [rfc5065], AS migration [rfc7705] >=20 > Given the comment above, the reference to rfc7705 should be > Normative. and 5085 too, i guess. ok > (4) =A73: "BGP implementations supporting RPKI-based origin validation SH= OULD > provide the same policy configuration primitives for decisions based on > validation state available for use in ingress, redistribution, and egress > policies." >=20 > When would it be ok for an implementation not to "provide the same policy > configuration"? IOW, why is MUST not used? s/SHOULD/MUST ok > (5) =A74: >=20 > Configurations may have complex policy where the final announced > origin AS may not be easily predicted before all policies have been > run. Therefore it SHOULD be possible to specify an origin validation > policy which MUST BE run after such non-deterministic policies. >=20 > (5a) [major] "SHOULD be possible to specify an origin validation policy" = What > is an "origin validation policy"? To me it sounds as the ability to eith= er > validate or not: as in, "the policy is to validate for this origin AS, bu= t not > for a different one". Is that it? Or are you referring to a blanket pol= icy > akin to "if the origin AS is X, then the route must always be considered > Valid"?? actually, i my broken memory is that 6811 says config may have policy which selectively validates based on origin, prefix, peer, etc. An implementation MAY provide configuration options to control which routes the lookup is applied to. yes, rfced allowed an adj at the end of a sentence :) i forget which docco says that may be by peer, prefix, origin, etc. Configurations may have complex policy where the final announced effective origin AS may not be easily predicted before the outbound policies have been run. Therefore it SHOULD be possible to specify origin validation policy which will run after all non-validating outbound policies. > [This piece of text confuses me more given the suggestion to Alissa's > comments: "Therefore it SHOULD be possible to specify an origin validati= on > policy which will run after all such non-deterministic policies." A > validation policy for *all* policies??] i am not sure where to go here > (5b) I know that this next point was discussed on the list...but describi= ng the > outcome of complex policy as not "easily predicted" and non-deterministic= is > causing me a lot of heartburn. I can see how optional information in an = Update > (communities, etc.) can cause a policy result to be known only at "run ti= me", > but that doesn't make the outcome unpredictable or non-deterministic: the > outcome of the policy is what it is supposed to be, given the current > conditions -- we just didn't know before the Update was received. This i= s a > non-blocking comment and you can consider it a nit...it simply sounds as = if the > operator was guessing, and I know some are not. ;-) >=20 > s/...may not be easily predicted before all policies...such non-determin= istic > policies./...may be determined only after all policies...such > policies. ack. will the above do? > (6) =A74: "SHOULD be able to list what announcements are not sent to a pe= er > because they were marked Invalid, as long as the router still has them in > memory." After reading this text many times, I think I understand that = you > mean that the operator should be able to use a "show command"...and not t= hat > he/she should be able to create a list of announcements (as in a filter).= Is > that what you mean? >=20 > Suggestion (maybe something like this)> > An implementation SHOULD display announcements that are not sent to a = peer > because they were marked Invalid, as long as the router still has them= in > memory. i prefer 'list' to 'display' because it could be in response to non-cli. but, indeed, it is the implementation which should list. and i realize that they might not have been sent for a validation policy other than drop invalid. so how about An implementation SHOULD be able to list announcements that were not sent to a peer, e.g., because they were marked Invalid, as long as the router still has them in memory. randy From nobody Tue Apr 7 13:56:28 2020 Return-Path: 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 46C7A3A12A8; Tue, 7 Apr 2020 13:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 dpxbWqZhWWfz; Tue, 7 Apr 2020 13:56:24 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F043A1257; Tue, 7 Apr 2020 13:56:01 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jLvGJ-0001NE-SL; Tue, 07 Apr 2020 20:56:00 +0000 Date: Tue, 07 Apr 2020 13:55:59 -0700 Message-ID: From: Randy Bush To: Benjamin Kaduk via Datatracker Cc: "The IESG" , draft-ietf-sidrops-ov-egress@ietf.org, sidrops@ietf.org In-Reply-To: <158627541271.31464.16065110875282211603@ietfa.amsl.com> References: <158627541271.31464.16065110875282211603@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-ov-egress-02: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 20:56:27 -0000 benjamin: thanks for the review > Section 1 > > As the origin AS of a BGP UPDATE is decided by configuration and > outbound policy of the BGP speaker, a validating BGP speaker MUST > apply Route Origin Validation policy semantics against the origin > Autonomous System number which will actually be put in the AS_PATH > > (To the extent that the speaker applies outbound policy at all? Or is > that required by being a "validating BGP speaker"?) a speaker applies policy in all circumstances. some times a particular vendor's syntax will apply 'allow' or 'deny' by default. taking that default is applying policy. or am i being too pedanic? but, point taken. any suggested wording? > Section 3 > > will (or would) be announced to the peer. The effective origin AS > may differ from that of the route in the RIB due to commonly > available knobs such as: removal of private ASs, AS path > manipulation, confederation handling, etc. > > Do we feel a need to add a "but not limited to"? Feels like overkill to > me... the "etc." was not strogh enough? > nit: earlier we wrote "private AS(s)" thanks > Section 4 > > Configurations may have complex policy where the final announced > origin AS may not be easily predicted before all policies have been > run. Therefore it SHOULD be possible to specify an origin validation > policy which MUST BE run after such non-deterministic policies. > > nit: are complex policies necessarily non-deterministic (vs. "not easily > predicted")? you and alvaro both caught this one. my ex-compiler-writer instinct is "may not be statically predicted" but i fear that would not make things more clear to the average protocol hacker. post alvaro, i have Configurations may have complex policy where the final announced effective origin AS may not be easily predicted before the outbound policies have been run. Therefore it SHOULD be possible to specify origin validation policy which will run after all non-validating outbound policies. seem reasonable? if not, send a clue randy From nobody Tue Apr 7 14:02:06 2020 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6E83A1161; Tue, 7 Apr 2020 14:02:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <158629332389.13606.14101492112170637278@ietfa.amsl.com> Date: Tue, 07 Apr 2020 14:02:04 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-ov-egress-03.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 21:02:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : BGP RPKI-Based Origin Validation on Export Authors : Randy Bush Ruediger Volk Jakob Heitz Filename : draft-ietf-sidrops-ov-egress-03.txt Pages : 5 Date : 2020-04-07 Abstract: A BGP speaker may perform RPKI origin validation not only on routes received from BGP neighbors and routes that are redistributed from other routing protocols, but also on routes it sends to BGP neighbors. For egress policy, it is important that the classification uses the 'effective origin AS' of the processed route, which may specifically be altered by the commonly available knobs such as removing private ASs, confederation handling, and other modifications of the origin AS. This document updates [RFC6811]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-egress/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-ov-egress-03 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-ov-egress-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-ov-egress-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 7 14:04:34 2020 Return-Path: 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 3094A3A12C3; Tue, 7 Apr 2020 14:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 O3SYvGyTWdwW; Tue, 7 Apr 2020 14:04:21 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68113A12C1; Tue, 7 Apr 2020 14:04:20 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jLvON-0001UR-Fx; Tue, 07 Apr 2020 21:04:19 +0000 Date: Tue, 07 Apr 2020 14:04:18 -0700 Message-ID: From: Randy Bush To: Benjamin Kaduk via Datatracker , Alvaro Retana Cc: The IESG , sidrops@ietf.org In-Reply-To: <158627541271.31464.16065110875282211603@ietfa.amsl.com> References: <158627541271.31464.16065110875282211603@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-ov-egress-02: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 21:04:22 -0000 i pushed -03 in case folk want to review post corrections suggested so far and in case anyone has the time to catch any new badness i managed to introduce. randy From nobody Tue Apr 7 17:35:29 2020 Return-Path: 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 A497B3A0FCD for ; Tue, 7 Apr 2020 17:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no 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 A-bgqAbSd206 for ; Tue, 7 Apr 2020 17:35:26 -0700 (PDT) Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.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 41AAA3A0FC7 for ; Tue, 7 Apr 2020 17:35:25 -0700 (PDT) Received: by mail-wm1-f41.google.com with SMTP id a81so3662225wmf.5 for ; Tue, 07 Apr 2020 17:35:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=qJiKqd1GmYMTMKTc8maGCm6e7NJE8H9hOnH/yQir0EU=; b=o55gyVDN49zJ1VnpoihVJ18uxFLtz3aSPjRHHAc7bt5I9ivhYq9oXjRVLcbO/11/r1 8qbkdT1ArfH4kYjYUA+crLlCPOUaM+cdSJjIPKPpm7mur/skSsVUQGvf7+nnaBs1sudA 7IFecf2BTVzFqSgN+ioSNLLwFyT2ZF6QhYShPRgM7nAsK9yPVkAAt8qdI1+naptxg9ZM 22ZsedbOzCs62GEL2y7qAfMumM1i86kyLa4IgCnMBOAPDgiQzJoaXNC3l/Jd2watWHYQ AqGFc4sYFAd1guUiUS8OQleM86TplG83TEh2wn0/LsDgJJEjA53faWUdwJypLRR4HZYQ DfjA== X-Gm-Message-State: AGi0PuZL+Kad4dQ8OJiMxKeanFHCKcKwbLxuVCkralH5cMrbWtKimi/v wMC4SUR2ENnHa3vnMmXx3egm9CWPdPc= X-Google-Smtp-Source: APiQypK5MmqXCw36dF8im0F16L1tyDRjTGmzg5h1qhGizA5VTXA3+GpiH1PqeOa7diy8rrSQ0GshKw== X-Received: by 2002:a1c:ed18:: with SMTP id l24mr1810265wmh.122.1586306123760; Tue, 07 Apr 2020 17:35:23 -0700 (PDT) Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id b5sm21674598wrs.16.2020.04.07.17.35.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Apr 2020 17:35:22 -0700 (PDT) Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id cd0521a4; Wed, 8 Apr 2020 00:35:21 +0000 (UTC) Date: Wed, 8 Apr 2020 00:35:21 +0000 From: Job Snijders To: Stephen Kent Cc: "sidrops@ietf.org" Message-ID: <20200408003521.GV68514@vurt.meerval.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 00:35:28 -0000 Hi, On Fri, Apr 03, 2020 at 11:40:10AM -0400, Stephen Kent wrote: > *Terminology* > > Valid: a signed object (other than a certificate or CRL) is deemed > *valid* if it is encoded in a fashion consistent with the relevant > RPKI RFCs (i.e., 6482, 6486, 6487, 6488, 6493) and the signed object’s > signature can be verified consistent with RFC 6488. > > Current: A CRL or Manifest is *current* if the current date & time is > before the Next Update date and the CRLNumber (or ManifestNumber) is > greater than any prior, valid CRLs or Manifests processed by the RP. > > Stale: A CRL or Manifest is stale if the current date & time is later > than the Next Update date. A stale CRL or Manifest is not “expired” > it’s just not as current as it is supposed to be. The case analysis > below examines what to do when a Manifest, or CRL, or both are stale. > > Missing: an object named in a Manifest, but not available for download > from a PP, is termed *missing*. An RP has no obvious way to acquire > missing objects, but operators SHOULD be warned about which objects > are missing. > > Corrupted: if an object named in a Manifest, is available for download > from a PP, but it’s hash does not match the corresponding value in the > Manifest, the object is termed *corrupted* and the object SHOULD be > ignored. > > *Case analysis* > > If we can agree to ignore any objects at a PP that do not appear on > the current manifest, the case analysis is easier. (The discussion of > corrupted objects above addresses the case where an object is named on > the Manifest, but the hash does not match.) > > Below is a proposed outline for the cases. The group needs to decide > what action is to be taken in each case. > > > 1.Manifest present, valid, current > 1.1.CRL present, valid, current pass. all lights are green. > [ snip lots of variants ] All cases we can come up with (except the 'all green') probably require some mailinglist back and forth as to why it is that we can safely ignore one or another validation check. If nobody steps up to advocate a particular case, perhaps we don't need it. My suggestion to the group is that we go through Kent's list and start with a justification for the simplest of cases (as described above), and then construct justifications for any other variants, if they exist. I imagine some of the cases have already been discussed in years prior, but RPKI OV deployment on the Internet at scale is still fairly new, taking a fresh look at things is exciting :) Kind regards, Job From nobody Tue Apr 7 21:42:52 2020 Return-Path: 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 045B33A0B9F; Tue, 7 Apr 2020 21:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 gQ6yiBOIlaf4; Tue, 7 Apr 2020 21:42:32 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 992FC3A0B9E; Tue, 7 Apr 2020 21:42:31 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0384gQ64015615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Apr 2020 00:42:29 -0400 Date: Tue, 7 Apr 2020 21:42:26 -0700 From: Benjamin Kaduk To: Randy Bush Cc: Benjamin Kaduk via Datatracker , sidrops@ietf.org, The IESG , draft-ietf-sidrops-ov-egress@ietf.org Message-ID: <20200408044226.GO88064@kduck.mit.edu> References: <158627541271.31464.16065110875282211603@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-ov-egress-02: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 04:42:34 -0000 On Tue, Apr 07, 2020 at 01:55:59PM -0700, Randy Bush wrote: > benjamin: > > thanks for the review > > > Section 1 > > > > As the origin AS of a BGP UPDATE is decided by configuration and > > outbound policy of the BGP speaker, a validating BGP speaker MUST > > apply Route Origin Validation policy semantics against the origin > > Autonomous System number which will actually be put in the AS_PATH > > > > (To the extent that the speaker applies outbound policy at all? Or is > > that required by being a "validating BGP speaker"?) > > a speaker applies policy in all circumstances. some times a particular > vendor's syntax will apply 'allow' or 'deny' by default. taking that > default is applying policy. or am i being too pedanic? > > but, point taken. any suggested wording? I think in my head it was like "any Route Origin Validation policy semantics applied MUST be applied against the origin AS number that will actually be put in the AS_PATH", but tweak (or reject) as desired; I have no horse in this race. > > Section 3 > > > > will (or would) be announced to the peer. The effective origin AS > > may differ from that of the route in the RIB due to commonly > > available knobs such as: removal of private ASs, AS path > > manipulation, confederation handling, etc. > > > > Do we feel a need to add a "but not limited to"? Feels like overkill to > > me... > > the "etc." was not strogh enough? I ... think I read past it. Sorry! > > nit: earlier we wrote "private AS(s)" > > thanks > > > Section 4 > > > > Configurations may have complex policy where the final announced > > origin AS may not be easily predicted before all policies have been > > run. Therefore it SHOULD be possible to specify an origin validation > > policy which MUST BE run after such non-deterministic policies. > > > > nit: are complex policies necessarily non-deterministic (vs. "not easily > > predicted")? > > you and alvaro both caught this one. my ex-compiler-writer instinct is > "may not be statically predicted" but i fear that would not make things > more clear to the average protocol hacker. post alvaro, i have > > Configurations may have complex policy where the final announced > effective origin AS may not be easily predicted before the outbound > policies have been run. Therefore it SHOULD be possible to specify > origin validation policy which will run after all non-validating > outbound policies. > > seem reasonable? if not, send a clue Looks good. Thanks! -Ben From nobody Wed Apr 8 04:26:05 2020 Return-Path: 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 254713A1357; Wed, 8 Apr 2020 04:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qV3i_jMnM47K; Wed, 8 Apr 2020 04:25:57 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 7B0653A1356; Wed, 8 Apr 2020 04:25:52 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id y24so967710wma.4; Wed, 08 Apr 2020 04:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=u/upePLVufZWGba7yokIyDddJnC4hb35orNv8w7h30g=; b=HYZkCrOep/5Z89MnzRbjTLsLicCket6kv4YIfto0gZKkuhZlLqoEhBvG1VTu2X/FEE 2aU8fIsJLEEWjtMjTQ868lhx07TV+0pbgwtriWOIkS1RH6yGEE0wbA2uccP6siDn5aN9 tE/iADHL0iPMKA7h/eRy4yUz1MpeFgG/L+xNcZMbZUvzoFb5QzNu02x45MESo+8cm0Df dZ+HSrlAhLVPGBB/8IHbUST/gPkrb7PuA1VwtDsPRIECNcRnQwrzbLL0v50XeAEqQKNv hmIpj/nY4BFWUnuQzkZwCTSZifUIVMQX+xaROr+xIY1nVgbg9XJIgD6ZjoOTWJNjh8Wu DwjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=u/upePLVufZWGba7yokIyDddJnC4hb35orNv8w7h30g=; b=KhGEJ99MBQOR8W9teW7+JPnjHQsx6IfH5AmlMjzGxUMk3IYVqeAvogDOKgmGBS8PXN fUtTnxonGKfnHu0r73tiieqgBpJU44Isvoffme0CXzBtKGexBJDW8bvr6KYHYitmkTaA c+GJQA5lrbuweKeLJ62mDevqENbGdxOoKzWnTc1bkI1zRv9lasQFT+y+jyRtP/BiY8c0 fUevS7bqfLeVDpcekTKSapGcM4mIdSWOyX14gunpp1oD8kBsqvT7omzsZggSd31nRyF4 WyD6JYzSFY0z+9BMWAI+c0IdkyR2iCa/ruC84UHEYf7h8nOvipOQQjW30/b2KMYniB5b L0fQ== X-Gm-Message-State: AGi0PuZaXDgdU5QiLqsmVwP9sa0iCpS5Du/y6XCvDD5jkpvJS/vsrIfi bW/uf7tdPFyVqYswPmN9DR8+JCxYNU2+As7WYwUHsWrR X-Google-Smtp-Source: APiQypJ2OnX+hRdf3B1naFk26cZdbGg4u+zizRNUG5k2YwDGnhopH7YiDHZUgZMHAxPSD7Wk41BYnRzG7LlpaFsZ5TY= X-Received: by 2002:a1c:5ac4:: with SMTP id o187mr4373854wmb.79.1586345150696; Wed, 08 Apr 2020 04:25:50 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 8 Apr 2020 04:25:49 -0700 From: Alvaro Retana In-Reply-To: References: <158621083315.16634.8714357093097492160@ietfa.amsl.com> MIME-Version: 1.0 Date: Wed, 8 Apr 2020 04:25:49 -0700 Message-ID: To: Randy Bush Cc: draft-ietf-sidrops-ov-egress@ietf.org, sidrops@ietf.org, The IESG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] Alvaro Retana's No Objection on draft-ietf-sidrops-ov-egress-02: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 11:25:59 -0000 On April 7, 2020 at 4:45:40 PM, Randy Bush wrote: Randy: Hi! ... > > (1) The purpose of this document is to clarify "that implementations > > must use the effective origin AS". The use of "effective" seems > > deliberate to qualify a specific characteristic of the origin AS. > > However, the term is not only not defined anywhere (with respect to > > simply using "origin AS", for example), but there is inconsistency in > > the language, for example: "origin Autonomous System number which will > > actually be put in the AS_PATH" or "final announced origin AS". > > Please be clear in the definition, and consistent in the language > > used. > > added > > The term 'effective origin AS' as used in this document refers to the > Autonomous System number which is used by [RFC6811] BGP Prefix Origin > Validation. Honestly, that sounds like a circular reference to me because we already know that the intent of this document is to clarify "that implementations must use the effective origin AS" -- so it is obvious that it will be the one used for origin validation. =C2=A0Maybe a better question should have been, how is it determined by a validating router? I looked at rfc6811 and it started by talking about "the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route)"...not too useful. =C2=A0But then I ran into the definition of the "Route Origin ASN". Suggestion> =C2=A0 =C2=A0The term 'effective origin AS' as used in this document refers= to the Route =C2=A0 =C2=A0Origin ASN ([RFC6811]) of the UPDATE to be sent to neighboring= BGP speakers. Another alternative is to simply s/effective origin AS/Route Origin ASN > and made text consistent There's some repetition here (looking at -03): OLD> =C2=A0 =C2=A0As the effective origin AS of a BGP UPDATE is decided by =C2=A0 =C2=A0configuration and outbound policy of the BGP speaker, a valida= ting =C2=A0 =C2=A0BGP speaker MUST apply Route Origin Validation policy semantic= s (see =C2=A0 =C2=A0[RFC6811] Sec 2 and [RFC8481] Sec 4) against the origin Autono= mous =C2=A0 =C2=A0System number which will actually be used by subsequent [RFC68= 11] BGP =C2=A0 =C2=A0Prefix Origin Validation. NEW> =C2=A0 =C2=A0The effective origin AS of a BGP UPDATE is decided by configur= ation and =C2=A0 =C2=A0outbound policy of the BGP speaker. =C2=A0A validating BGP spe= aker MUST apply =C2=A0 =C2=A0Route Origin Validation policy semantics (see [RFC6811] Sec 2 = and [RFC8481] =C2=A0 =C2=A0Sec 4) after applying any egress configuration and policy. [This text would also address comment #2.] [nit] I think that the references to explicit sections is not needed...but I can live with them. ... > > (5) =C2=A74: > > > > Configurations may have complex policy where the final announced > > origin AS may not be easily predicted before all policies have been > > run. Therefore it SHOULD be possible to specify an origin validation > > policy which MUST BE run after such non-deterministic policies. > > > > (5a) [major] "SHOULD be possible to specify an origin validation policy= " > > What is an "origin validation policy"? To me it sounds as the ability t= o > > either validate or not: as in, "the policy is to validate for this orig= in > > AS, but notvfor a different one". Is that it? Or are you referring to a > > blanket policy akin to "if the origin AS is X, then the route must alwa= ys > > be considered Valid"?? > > actually, i my broken memory is that 6811 says config may have policy > which selectively validates based on origin, prefix, peer, etc. > > An implementation MAY provide configuration options to control which > routes the lookup is applied to. > > yes, rfced allowed an adj at the end of a sentence :) > > i forget which docco says that may be by peer, prefix, origin, etc. I see, that makes sense. I didn't see it specifically in rfc6811 (or rfc7115), but I think the text above (from rfc6811) is clear enough. =C2=A0The only issue is that it says that the support is optional (MAY), while this document recommends it (SHOULD). Because we're already Updating rfc6811, then I think this is ok. > Configurations may have complex policy where the final announced > effective origin AS may not be easily predicted before the outbound > policies have been run. Therefore it SHOULD be possible to specify > origin validation policy which will run after all non-validating > outbound policies. > > > [This piece of text confuses me more given the suggestion to Alissa's > > comments: "Therefore it SHOULD be possible to specify an origin validat= ion > > policy which will run after all such non-deterministic policies." A > > validation policy for *all* policies??] > > i am not sure where to go here Maybe we have too many "policies"... And don't see the explicit connection between a complex policy and the need to apply an origin validation policy...much less the need to apply it to all. OLD> =C2=A0 =C2=A0Configurations may have complex policy where the final announc= ed =C2=A0 =C2=A0effective origin AS may not be easily predicted before the out= bound =C2=A0 =C2=A0policies have been run. =C2=A0Therefore it SHOULD be possible = to specify =C2=A0 =C2=A0origin validation policy which will run after all non-validati= ng =C2=A0 =C2=A0outbound policies. NEW> =C2=A0 =C2=A0Configurations may have complex policy where the effective ori= gin AS may =C2=A0 =C2=A0not be easily determined before the outbound policies have bee= n run. =C2=A0It =C2=A0 =C2=A0SHOULD be possible to specify a selective origin validation po= licy to be =C2=A0 =C2=A0applied after any existing non-validating outbound policies. I still went with "determined" (instead of "predicted") because we're not guessing...but can live with either one. Thanks! Alvaro. From nobody Wed Apr 8 06:22:33 2020 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEFA3A0893; Wed, 8 Apr 2020 06:22:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-sidrops-rp@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, Nathalie Trenaman , nathalie@ripe.net X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <158635214730.7934.5595563917251501429@ietfa.amsl.com> Date: Wed, 08 Apr 2020 06:22:27 -0700 Archived-At: Subject: [Sidrops] Robert Wilton's No Objection on draft-ietf-sidrops-rp-06: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 13:22:28 -0000 Robert Wilton has entered the following ballot position for draft-ietf-sidrops-rp-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this - I think that this document is useful. One issue with the IETF standard format is that it can be difficult to find which RFCs need to be read to fully solve a particular problem, particularly considering that some of those RFCs may be updated or obsoleted by other RFCs. I agree with Warren's comment that it would make a good living document, if IETF had such things. In terms of reading the document, I noted that it uses quite a lot of acronyms that I was not immediately familiar with and that are not defined in the document. Perhaps the document could be improved by having a short terminology section? The acronyms that didn't appear to be defined include CRL, INR, CA, ROA. 4.2.1. Manifest To determine whether a manifest is valid, the RP is required to perform manifest-specific checks in addition to those specified in [RFC6488]. I found the above paragraph as being unclear, in that I don't know what "those" is referring to, and hence I suggest more clearly identifying “those” checks. Finally, I agree with Alvaro's comment related to section 4.3: This document probably shouldn't be giving recommendations. Perhaps better to just keep this as "However, most RP software ignores such objects.", or combine it with the previous sentence. From nobody Wed Apr 8 10:41:52 2020 Return-Path: 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 507F63A14C3; Wed, 8 Apr 2020 10:41:46 -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, 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=cooperw.in header.b=4oRtn+pD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JF2byNx9 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 nvU71XZTYIHa; Wed, 8 Apr 2020 10:41:45 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 202973A14C1; Wed, 8 Apr 2020 10:41:43 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6B8C25C0282; Wed, 8 Apr 2020 13:41:42 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 08 Apr 2020 13:41:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=6 XJxOrOvklJxwYgd+cEfoMR/tzPxXjDa1MOL992r/Vc=; b=4oRtn+pD3QD8qE3eR 08vkQjYYZJ0EOCjtAme5z93gGshLYoLaC1Kn1GgPEUGXMNbjLOgB7xFa7ppqoFID 9dw7IJ/M4NSLatTSWolsIxOwEO9a3yNFk2d+zYpgQ9JGCRT8RKj8O3/1wsANZr6Y Ya/ZDPN0jqSeb5ukd3pdL7o199tD+51Of26+nvgrxJHGhQ19+YbxHBhrWq/Qd9SN fMsCfzi2qQ2Dj9IKNWyDqZaPIMOAXWr7mSjDHbtbs57Xwqq8u9DTPboNtQa9JUVc pcnn4GXjZ/KH1De0ePsEcOiSAhSfgix4oRAaUXQDRIAfUad5IDXaFS/22x5EdXDZ Xf9PA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=6XJxOrOvklJxwYgd+cEfoMR/tzPxXjDa1MOL992r/ Vc=; b=JF2byNx9F8iE3NBx2LEdSs8RoihxE1LsratK9JiPnuKpe5Fme2MCSMnSQ YO5TRmhpmpMm8uqHXR9GeQQOr17mHaBYsC5XlYc6wJIhwbDpvP1wkxbcTssRpA/M 6onps7/WCxzqCMrNROeCdR6CREfx0FdnQ5tlmklFW8vQWY0exdNU1UuM591vzZtk 1GsdS1ohhUb1U9Y18lPFD6Exivs85D+4JVYX4GzB7GjAvYmh3jOMUx1HtXwYgDwr FRe1wDLQ1Gq6fqspIqUDcbY1W9+5V9/Nb3S7jNgjz0bYhFFExwl+cV3LC9D2TJBA 5a+dbrUe1eezDsNOmrg+CYAfs+lOA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudejgdduudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucfkphepud ejfedrfeekrdduudejrdeijeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhep mhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhn X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.67]) by mail.messagingengine.com (Postfix) with ESMTPA id 7D5EB3280059; Wed, 8 Apr 2020 13:41:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) From: Alissa Cooper In-Reply-To: Date: Wed, 8 Apr 2020 13:41:39 -0400 Cc: Alissa Cooper via Datatracker , keyur@arrcus.com, sidrops@ietf.org, draft-ietf-sidrops-ov-egress@ietf.org, sidrops-chairs@ietf.org, IESG , nathalie@ripe.net, warren@kumari.net Content-Transfer-Encoding: quoted-printable Message-Id: <66C2B854-995A-41C9-9CED-BB8787D23C1A@cooperw.in> References: <158619174173.5693.3701421912223917488@ietfa.amsl.com> To: Randy Bush X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: Re: [Sidrops] Alissa Cooper's No Objection on draft-ietf-sidrops-ov-egress-02: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 17:41:47 -0000 Hi Randy, > On Apr 6, 2020, at 1:07 PM, Randy Bush wrote: >=20 >> "Therefore it SHOULD be possible to specify an origin validation >> policy which MUST BE run after such non-deterministic policies." >>=20 >> The normative language here doesn't quite make sense. "MUST BE" is = not a >> normative keyword and the construction "SHOULD ... which MUST" is a = little >> confusing. >=20 > point >=20 >> I would suggest something like: >>=20 >> An origin validation policy that is required to be run after such >> non-deterministic policies SHOULD be specified. >=20 > nope. that says the op SHOULD specify the policy; when MAY would be = the > appropriate point here. >=20 > how about a simpler hack (with context)? >=20 > Configurations may have complex policy where the final announced > origin AS may not be easily predicted before these policies have been > run. Therefore it SHOULD be possible to specify an origin validation > policy which will run after all such non-deterministic policies. I tend to prefer SHOULD , but your proposal is an = improvement over what is in the draft. Thanks, Alissa >=20 > i suspect some might suggest the point of the draft should really be > s/SHOULD/MUST/ >=20 > randy >=20 From nobody Wed Apr 8 12:47:13 2020 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CEC3A0E61; Wed, 8 Apr 2020 12:47:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.125.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <158637523126.28532.10433017260821047410@ietfa.amsl.com> Date: Wed, 08 Apr 2020 12:47:11 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-ov-egress-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 19:47:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : BGP RPKI-Based Origin Validation on Export Authors : Randy Bush Ruediger Volk Jakob Heitz Filename : draft-ietf-sidrops-ov-egress-04.txt Pages : 5 Date : 2020-04-08 Abstract: A BGP speaker may perform RPKI origin validation not only on routes received from BGP neighbors and routes that are redistributed from other routing protocols, but also on routes it sends to BGP neighbors. For egress policy, it is important that the classification uses the 'effective origin AS' of the processed route, which may specifically be altered by the commonly available knobs such as removing private ASs, confederation handling, and other modifications of the origin AS. This document updates [RFC6811]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-egress/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-ov-egress-04 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-ov-egress-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-ov-egress-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 8 12:47:50 2020 Return-Path: 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 B6C223A15A3; Wed, 8 Apr 2020 12:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 rqIAhL3qV7Fe; Wed, 8 Apr 2020 12:47:48 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9FF3A16FF; Wed, 8 Apr 2020 12:47:41 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jMGfj-0007Wi-J5; Wed, 08 Apr 2020 19:47:39 +0000 Date: Wed, 08 Apr 2020 12:47:38 -0700 Message-ID: From: Randy Bush To: Alvaro Retana Cc: draft-ietf-sidrops-ov-egress@ietf.org, sidrops@ietf.org, The IESG In-Reply-To: References: <158621083315.16634.8714357093097492160@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Alvaro Retana's No Objection on draft-ietf-sidrops-ov-egress-02: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 19:47:50 -0000 -04 pushed randy From nobody Wed Apr 8 14:34:44 2020 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F07123A17F6; Wed, 8 Apr 2020 14:34:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-sidrops-rp@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, Nathalie Trenaman , nathalie@ripe.net X-Test-IDTracker: no X-IETF-IDTracker: 6.125.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <158638167249.20283.18380733180622446749@ietfa.amsl.com> Date: Wed, 08 Apr 2020 14:34:32 -0700 Archived-At: Subject: [Sidrops] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sidrops-rp-06=3A_=28with_COMMENT=29?= X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 21:34:34 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-sidrops-rp-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- While this document is useful for a RPKI newcomer or implementer, I wonder whether it should become a RFC even if informal... and the "requirements" in the title is also conflicting IMHO with an informational RFC. I wonder whether the "security considerations" section is really about security considerations linked to this document or to the overall RP system. Regards -éric From nobody Wed Apr 8 19:00:18 2020 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD1E3A1D71; Wed, 8 Apr 2020 19:00:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-sidrops-rp@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, Nathalie Trenaman , nathalie@ripe.net X-Test-IDTracker: no X-IETF-IDTracker: 6.125.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <158639761310.14576.3625316672934417222@ietfa.amsl.com> Date: Wed, 08 Apr 2020 19:00:13 -0700 Archived-At: Subject: [Sidrops] Roman Danyliw's No Objection on draft-ietf-sidrops-rp-06: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 02:00:14 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-sidrops-rp-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ** In the spirit of this being a pathfinding document, provide additional references as follows: -- Section 3.2. Per “An RP is expected to support the amended procedure to handle with accidental over-claim.”, a pointer to these procedures would be helpful. -- Section 3.3. Per “CRLs in the RPKI are tightly constrained; only the AuthorityKeyIndetifier and CRLNumber extensions are allowed …”, a pointer to these extensions would be helpful. -- Section 4.2.4, Per “Additionally, the certificate must contain an AS Identifier Delegation extension …”, a pointer to this extension would be helpful. ** Section 1. Per “Besides, software engineering calls for how to segment the RP system into components with orthogonal functionalities, so that those components could be distributed across the operational timeline of the user”. I didn’t follow the intent of this sentence. What are principles of software engineering calling for? ** Section 3.3. Typo in the extension name. s/AuthorityKeyIndetifier/AuthorityKeyIdentifier/ ** Section 7. Please add text that this document doesn’t introduce any new security considerations but is a resource to implementers. The individual RPKI RFC need to be consulted for specific guidance. ** Editorial Nits -- Section 1. Typo. s/This document will be update …/This document will be updated …/ -- Section 3.1. Typo. s/must be present and value of each extension/must be present and the value of each extension/ From nobody Wed Apr 8 23:12:44 2020 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9CD3A0BFE; Wed, 8 Apr 2020 23:12:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-sidrops-rp@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, Nathalie Trenaman , nathalie@ripe.net X-Test-IDTracker: no X-IETF-IDTracker: 6.125.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158641275843.11786.5802713073847135604@ietfa.amsl.com> Date: Wed, 08 Apr 2020 23:12:38 -0700 Archived-At: Subject: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rp-06: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 06:12:39 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-sidrops-rp-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 2 RP software uses synchronization mechanisms supported by targeted repositories (e.g., [rsync], RRDP [RFC8182]) to download all RPKI changed data objects in the repository system and cache them locally. nit(?): perhaps "changed" requires a bit more explanation. Section 2.1 TAL acquisition and processing are specified in Section 3 of [RFC8630]. I'm not really convinced that the referenced section discusses specifically TAL *acquisition*. Section 2.2 by using the SIA and AIA extensions. Detailed specifications of SIA and AIA extensions in a resource certificate are described in Section 4 of [RFC6487]. (Subsections thereof, though I trust that the reader should be able to figure this out.) Section 3.1 established by Section 4 of [RFC6487]. This means that all extensions mandated by Section 4.8 of [RFC6487] must be present and value of each extension must be within the range specified by this RFC. Moreover, any extension excluded by Section 4.8 of [RFC6487] nit: s/this/that/ ("this RFC" is the thing that draft-ietf-sidrops-rp will become, in this context). Section 7.1 of [RFC6487] gives the procedure that the RP should follow to verify resource certificate and syntax. "verify resource certificate and syntax" seems a little broad; the referenced section seems specific to validating the extension defined in RFC 3779. Section 3.2 Certificate Authorities that want to reduce aspects of operational fragility will migrate to the new OIDs [RFC8360], informing the RP of using an alternative RPKI validation algorithm. An RP is expected to support the amended procedure to handle with accidental over-claim. nit: I suggest s/with accidental over-claim/accidental overclaim/. Section 3.3 Processing of a CRL that is not consistent with a manifest is a matter of local policy, as described in the fourth paragraph of Section 6.6 of [RFC6486]. Is the fifth paragraph relevant, also? Section 4.1 Note that these checks are necessary, but not sufficient. Additional validation checks must be performed based on the specific type of signed object. These additional validations are covered in the following sections, it seems -- should we mention that here? Section 4.2.4 contain an IP Address Delegation extension. The validation procedure used for BGPsec Router Certificates is identical to the validation procedure described in Section 7 of [RFC6487], but using the constraints applied come from specification of Section 7 of [RFC8209]. nit: if it does something differently, it's no longer "identical"; maybe "analogous" or it's following the validation procedure [...] with additional constraints"? That said, Section 7 of RFC 8209 is the IANA considerations, so I'm not sure what the "constraints applied come from" is intended to say. Section 7 The validation steps discussed throughout this document are also pretty important to the security of the system as a whole. Section 10.1 I'm not sure that RFC 5280 actually is normative here. (That might be the first time I've ever said that!) Section 10.2 I think that RFCs 6489, 6916, and 8634 are probably better as normative. From nobody Thu Apr 9 03:25:17 2020 Return-Path: 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 D3B3D3A00C9 for ; Thu, 9 Apr 2020 03:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 P9cY0B_sXHNg for ; Thu, 9 Apr 2020 03:25:10 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2EAA3A0060 for ; Thu, 9 Apr 2020 03:25:09 -0700 (PDT) Received: from bufobufo.ripe.net ([193.0.23.13]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jMUMt-0005kw-Vt; Thu, 09 Apr 2020 12:25:07 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::e30]) by bufobufo.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.3) (envelope-from ) id 1jMUMt-0007U5-Tl; Thu, 09 Apr 2020 12:25:07 +0200 To: Stephen Kent , "sidrops@ietf.org" References: From: Robert Kisteleki Autocrypt: addr=robert@ripe.net; prefer-encrypt=mutual; keydata= xsBNBEzFa6gBCADVASYXBbUF7v1D+Y9XR41SEEMiZUARlUWeP0NrFHZmRRGdR5nM/p6HguUd StIPRmdqMdyLDqBsV8XPVu6lvhcb4+ZFu/V1XFPVyPBH8U6iQ4PdGDeqFlBm3gxoDOGraGw8 bjojvASTz/Wk3ddLPm34Kb6oMI2MclC016UgrPgIj6A1Uu8qQeBDyWrk+OrWUPOUOKM7QhQg cpU4JwuaesthFvqdoPNQJi9QUfn94r14ZNDYmeJlchZiRHWO70Gwoy3ywfAM9Kyi1tx78Qc9 E5ZhGIw9qqlzqa6c6a0qhup2Zh/dhVBJ05jCDN7bUQT5tRiOV2icyX8Dsr4KaWYCsAOVABEB AAHNMVJvYmVydCBLaXN0ZWxla2kgKFJJUEUgTkNDIGtleSkgPHJvYmVydEByaXBlLm5ldD7C wHgEEwECACICGyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJWUwoeAAoJEC0ZXiKtTC3+ 04UH/jlvSR0esDGFSponUVawru+/QF61KdsNrdH6/Vs2buQvczW2Uh+S6Dic2vr2H0B1YrvL F2XpL2WJUHBUDLTA7dYTslvnHpyZrR8Sfb+h+wJ8OynxEC5wMKxfYNx2fMSk5EIU5mRjMaYg X/VkssDcoQAznNwVVYeqHYUJDMcrJhAYh44VHO208VwjPjHUDRlC+BoMGjHJnWDOAstlES8j 0r3adj2MqIHdDEjSdEx1+rbV0iZlgcDbYDex3qulOYlcZL+PJvGHzD6CkNBa8SbSN7cO0yqR OJ2sgobITOJ0GbRIbIvkUe1Iqw717CuQV/u822dFISDYOAhGYmfWGJWmkezOwE0ETMVrqAEI AKazZ2Agrv0nNFPWV69l6fEout/FaqWfyAG5V414l4yr+qVShUYzS+txA2vC+ouHvdORZ/JG xwKf6HE+YvvWS+Oa+b6h+GZfA3G43XGpQlxXrFK019TeMjhHqWprZALL4w2k6TatYT1ZW369 rORtwSgtn5ZC4uNcpZeDQddQvCjyYoknqlZqAFf1pssuGPTE8GvhrZGEp52dALYYoDIf7y/z 8fCAcy72rhMhQV02rPB49UxOEh2FZJhST0743tuMtFemBkp06B/Mcx54QT0muG8zj19oMDG3 AAaGjNP6B3qzR6F8VczR/qVhQzRvNMr8A6+y/ew/x4+48P+O/4n/I50AEQEAAcLAXwQYAQIA CQIbDAUCVlMKHgAKCRAtGV4irUwt/mvlB/sFID7mlsWAS66UyrI+tGs4Xfl59vvhRRZ4ZKiR 8VEbWbLKh/b9SoYcKt9SLEfVxJE5ebWPgIIvUSdLS6f4n9uAJteDZ4w/AVfp5a6jbfvMm7JP AMW4HtnZ3YbNevRgXdGVXN+bTLZzXoVijOKu+xHDBRNaUswaG3glrDJfUGkPQtCXFn6m6Pdw dW1/ShzwQgfuE/NXa83jhJ175P+NoQ2KG7934vu2MZdrtIqPibKuaGWMPG0L5YzPotK9ONmd taJMnuk92qqZ6S9JPwRZmogRW/sX54XvGg6RzNpdHS5C+iN01tCNJTRTlOJ1X73+RrGokvKc dp6fdfc4PHHhpcMd Organization: RIPE NCC Message-ID: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> Date: Thu, 9 Apr 2020 12:25:07 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ACL-Warn: Delaying message X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274b347c7c4d6d49e50bba692bf8cdea9e8 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 10:25:13 -0000 Hi, > Missing: an object named in a Manifest, but not available for download > from a PP, is termed *missing*. An RP has no obvious way to acquire > missing objects, but operators SHOULD be warned about which objects are > missing. IMO an "RP has no obvious way to acquire missing objects" is not entirely true. If, at the previous run, the RP fetched the relevant (now missing) object, then I see no reason to not use it again. Think of the previous run as an object a cache if you will: if you're looking for an object mentioned in the manifest, and you have it already (hash / name / etc. matches) then you can reuse it. Of course it can be useful to check if it still exists in the PP, but it seems to me the only benefit is to detect that it is missing from there and perhaps warn the PP operator. Otherwise the RP has a hard time arguing "no idea what this is since it's not there!". For bonus points: an implementation that fetched a PP's manifest, detected that it's exactly the same as before, and therefore reused the validation outcome from the previous run would not even have to fetch *any* other objects from the same PP. The downside is that this process will not be able to point out the omission. The upside is saves a lot of resources (bandwidth, CPU and all). A further upside is that as a side-effect this protects against a malicious attacker (selectively) hiding objects. Where this comes back to the current discussion is: would this behaviour be mandated, recommended, or considered a big no-no? Robert From nobody Thu Apr 9 05:07:01 2020 Return-Path: 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 6D0683A09C7 for ; Thu, 9 Apr 2020 05:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 2hJUoGIIEvYJ for ; Thu, 9 Apr 2020 05:06:57 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4988B3A09AE for ; Thu, 9 Apr 2020 05:06:57 -0700 (PDT) Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 9004012E83; Thu, 9 Apr 2020 14:06:54 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Thu, 9 Apr 2020 14:06:54 +0200 From: Martin Hoffmann To: Robert Kisteleki Cc: Stephen Kent , "sidrops@ietf.org" Message-ID: <20200409140654.2804a85f@glaurung.nlnetlabs.nl> In-Reply-To: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> References: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 12:07:00 -0000 Robert Kisteleki wrote: >=20 > IMO an "RP has no obvious way to acquire missing objects" is not > entirely true. >=20 > If, at the previous run, the RP fetched the relevant (now missing) > object, then I see no reason to not use it again. Think of the > previous run as an object a cache if you will: if you're looking for > an object mentioned in the manifest, and you have it already (hash / > name / etc. matches) then you can reuse it. That is theoretical possible, but in practice you treat synchronising and validation of repository content as two separate steps. I.e, before you even start looking at a CA=E2=80=99s repository, you synchronize its content. This is enshrined in the way both rsync and RRDP work: They don=E2=80=99t update single files but entire directory trees all at once. T= his step includes deleting objects that have been deleted on the server. Since the complete RPKI repository has a hierarchical structure following the rsync URIs of objects, many RP implementations keep the objects in the file system only. This is in particular useful for rsync: Just let rsync update the directory in place. An additional bonus of this strategy is that you don=E2=80=99t need a fancy database. You could, of course, concoct a mechanism that marks files for deletion and only deletes them if they aren=E2=80=99t actually used in the next validation run. But, considering that this thread is actually subjected =E2=80=9Ctrying to limit RP processing variability,=E2=80=9D I am= not sure this is a good idea. There is a strong likelihood that different strategies will behave slightly differently. If we really want to come to a point where every RP implementation produces the same output from given input, we need to defined simple rules that are easy to implement in a wide range of circumstances. Another consequence of doing this is that validation on a newly deployed RP software differs from one that has been running for a while. As a consequence, the datasets from two different caches configured in routers differ. So now you even have difference between caches running the same software.[0] Kind regards, Martin=20 [0] Yes, with broken RRDP servers where snapshots differ from a sequence of deltas, this can happen too. We should perhaps also look into improving the robustness of RRDP. From nobody Thu Apr 9 06:13:40 2020 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 052EF3A0AD7; Thu, 9 Apr 2020 06:13:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-sidrops-rp@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, Nathalie Trenaman , nathalie@ripe.net X-Test-IDTracker: no X-IETF-IDTracker: 6.125.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <158643800057.11588.10970441649702494106@ietfa.amsl.com> Date: Thu, 09 Apr 2020 06:13:21 -0700 Archived-At: Subject: [Sidrops] Alissa Cooper's No Objection on draft-ietf-sidrops-rp-06: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 13:13:22 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-sidrops-rp-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Alvaro about Section 4.3. From nobody Thu Apr 9 07:25:21 2020 Return-Path: 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 8FF1A3A0651 for ; Thu, 9 Apr 2020 07:25:18 -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=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 NP9ZUjXChKQn for ; Thu, 9 Apr 2020 07:25:16 -0700 (PDT) Received: from sonic315-13.consmr.mail.bf2.yahoo.com (sonic315-13.consmr.mail.bf2.yahoo.com [74.6.134.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 B7A1A3A0640 for ; Thu, 9 Apr 2020 07:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1586442315; bh=ukPkvZQYCulVtzCthPvDIXI6bH2rLj+ZPvtq7JEINsc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=cMnJvt8p8p74eN1/xy3UUSyoIIY2aYi+zqC1jVM0w2t6UMqmaezqAHAbjhq7yEOsuXPQKmPyytiliTFfW1947KadNjkGazt+8yOApSlwtPmdrT3tI4g5D3/RDd6hrvnwALDBThfxIXMN7A0v7vQFiLvfGjhC4VDo4QRDu8V2trERHmlmNQpOg9Zl/JM9siZT+UFkh5nQeCt1DAJ+svZNiNIqQHa0HFZK8otJtUEkEDo8lqBHfSAvltShFkWHJXvgy0qyVGh4x/uNP+AYFopd3Cm5/wngiz0eq4r3xwIdowgdJNjwX2xVZX1nkgpgLr77vcj2V6HRLj1H/BegYvCvig== X-YMail-OSG: 39o.M1sVM1mpYRJeyVf1ie_yqNEv2iWeXxFX2qgRUzuXZifEWLpA6tnl0FIfDB_ i3a7RBEn70S_NTQINi0RGYwFcbtkrrD8.wawTeJygOeLnOBSpfYwj1zmUTxPy6zi7I9AuSvTxdHG ySMLYnoavQ0p0jpdNOP2M.GfqwwM4X7mqOIs9HPQaJExI_Lxwev95hPQBtv7svYIsj5mrObX4yIn EaXIm0VJe0H5NXolux.fyiRQwwXwWtFdIwrSztFc4Qzr4_HqxVrL_gZpP3ljhS9E.i0cp3PtkD8H XLdF.FjC_3A80mpTS6uE_9MoTczauo0fKZFwAsVPpibyFrrnF5FxHr.lHf5cRd9CaxzVFV8P6jjm 8kaqMsMHIOaenLkthANsU7.ArY4JJuFDG8tdaTI4YAd1hXsMLFpVYPOLr934TNSguwh6.kZfH8wu vpyMSO0sX5SR48FXELZhY_H_Y.x7qd3v6BtpORgBUs6mZ85ToYkTAmlVL7v43z8OlyHwvgyBLlrm BhwXvREbA6kKV9JBdGSjcrHYt0pzQbXiF.mQHS8sgCe.S.Qn7X0.qVqyNTw8YPj6KnMJJYeeHSFN w3S1LA0f8dK8Eic1LHHS5OnH5IeP8Bwxui7ev5MkrAlNnnAmF6sOKNYdMDEnsy2nlohfVVMsshLx bV..wCa9POVmuqBboDOZi_jv6AVv3uUKf3_d1uPvSMBvfMfOI7WdvuzHO9fJds21Q.TZ88CmIEZs pVy8YP06GNVcwy0.hRtHNtuUhT6iRgRtfgwgLEokpaOQJS1DcyyatDdr5JXreVyagHatq43oUyDD AqNNz.I3JYFIyUYtztiPt6AIAckLiru3cZlX7sO8SEVk4JtE8XPmNp0g.zdX9SKWhNZsihMwr8OG hgrUkedCsxz2j515O3r2bAMPD.ouwUz4J8pL51zN8wgUHcJfwTj71Zz5PZElRsh7FVqk.wmKnZh4 f6XC8DO08cWUFLQo.iUtwtuo4CWfRhij30kUHslz4997AecpiQ2tHFCZsdOy9QwKkv54psEaszPp .YgvmJYbe0Zktg.Mt_lkfpfmaHwe9N9lgPwHfTF5unQgpTFpdhxeGc2Xv6j293zNZZqD88syWbdw JNTkC9K.dw8NJGDKaS8q8rSc747TFF5q9DCi.XidgF5fIn7wprlFr0U8kQ4d0OSTDqVfoIl9gG7D HaBfnwy2Wy7z.9cA5YpmWh.jXatcHJrHPE0D.FAWOLi9yUr7IGfpazL7ORjcWsMUtRkt._4SDDz3 svTyEfCXUfukE2aKr0nndaqTGXNc.cCO3P7040RJaE2Jgx4IYJIf32alSzRMQngLQQ7weguBK6Q. uxGGDjlTKEFEP5Mcl3Wke8f7OYWoAuqV_wYczcCjTf5BjbnC.9i5Jw4XfTqShqgrEJk9.WG83f49 EIAobr9TsMebAZBxMZiKqMV.XO0Bspa7CO3Qbpma6y3Xmf4NRgQc6hO5Ft51bAjoMZc9Sfucspg- - Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Thu, 9 Apr 2020 14:25:15 +0000 Received: by smtp406.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7697ad90edd7dbd15b5df9aa194deef6; Thu, 09 Apr 2020 14:25:13 +0000 (UTC) To: =?UTF-8?Q?=c3=89ric_Vyncke?= , The IESG Cc: draft-ietf-sidrops-rp@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, Nathalie Trenaman References: <158638167249.20283.18380733180622446749@ietfa.amsl.com> From: Stephen Kent Message-ID: <133793a3-f1a0-a834-2f39-8ac6b7c1a628@verizon.net> Date: Thu, 9 Apr 2020 10:25:12 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <158638167249.20283.18380733180622446749@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailer: WebService/1.1.15620 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) Archived-At: Subject: Re: [Sidrops] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sidrops-rp-06=3A_=28with_COMMENT=29?= X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 14:25:19 -0000 Éric, > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > While this document is useful for a RPKI newcomer or implementer, I wonder > whether it should become a RFC even if informal... and the "requirements" in > the title is also conflicting IMHO with an informational RFC. Informational RFCs have been used to document requirements, separate from standards track RFCs, in many cases.  A quick scan of Informational RFCs published over the past 20 years, with titles including the word "requirements" identifies over 200 such documents. So I don't believe the use of that term in a title is disqualifying per se. Admittedly, these RFCs often were generated to provide guidance for later standards work, e.g., establishing a basis for a WG that is being formed. In this case, the motivation for a post hoc Informational RFC is the plethora of separate RFCs that establish processing criteria for an RP dealing with repository objects. The WG believes that this is a valid rationale for publication. > I wonder whether the "security considerations" section is really about security > considerations linked to this document or to the overall RP system. The Security Considerations in this document are associated with relying party processing of data acquired from the repository system. There are a broader set of security considerations for the RPKI that address the behavior of the CAs and repository operators, not to mention how ISPs make use of the RPKI data after it has been validated. Steve From nobody Thu Apr 9 07:35:37 2020 Return-Path: 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 7AB543A07AE for ; Thu, 9 Apr 2020 07:35:31 -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_DNSWL_NONE=-0.0001, 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 xk9_WB1tB5kL for ; Thu, 9 Apr 2020 07:35:30 -0700 (PDT) Received: from sonic304-9.consmr.mail.bf2.yahoo.com (sonic304-9.consmr.mail.bf2.yahoo.com [74.6.128.32]) (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 6D8863A07B9 for ; Thu, 9 Apr 2020 07:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1586442916; bh=ukPkvZQYCulVtzCthPvDIXI6bH2rLj+ZPvtq7JEINsc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=OcoN2D1tX/+rxg1AvPOujFn7oZjn8DtwAZZd68fwo7We2iYQA/sMTZIU4n8NTMORHhtZmJ8/jMA2VgqEa+8tLjQua/XQxDTV0JWPg5PadESeAWnoFe+8TIMGQGDyt8f59h91tLK3eIpI0G2Z9S6CaVhkyRIeIUB1Mu91+S2isaucRNoXbW/xuPckjNqAgrfYhw0bCHgBkT2vxO9EwULHD/jZORNZ0s/to+THlvkBqpW5TIiGeHCTXtbz6Z7EL2p3oTbw5ygJ1veZzMMsmIY1seUHqIva1wgnuWD/5cs2BKPCWsTQoo7uuwXmAXbCG65goW6UOGWxoOs/NGObYCg8zQ== X-YMail-OSG: 39o.M1sVM1mpYRJeyVf1ie_yqNEv2iWeXxFX2qgRUzuXZifEWLpA6tnl0FIfDB_ i3a7RBEn70S_NTQINi0RGYwFcbtkrrD8.wawTeJygOeLnOBSpfYwj1zmUTxPy6zi7I9AuSvTxdHG ySMLYnoavQ0p0jpdNOP2M.GfqwwM4X7mqOIs9HPQaJExI_Lxwev95hPQBtv7svYIsj5mrObX4yIn EaXIm0VJe0H5NXolux.fyiRQwwXwWtFdIwrSztFc4Qzr4_HqxVrL_gZpP3ljhS9E.i0cp3PtkD8H XLdF.FjC_3A80mpTS6uE_9MoTczauo0fKZFwAsVPpibyFrrnF5FxHr.lHf5cRd9CaxzVFV8P6jjm 8kaqMsMHIOaenLkthANsU7.ArY4JJuFDG8tdaTI4YAd1hXsMLFpVYPOLr934TNSguwh6.kZfH8wu vpyMSO0sX5SR48FXELZhY_H_Y.x7qd3v6BtpORgBUs6mZ85ToYkTAmlVL7v43z8OlyHwvgyBLlrm BhwXvREbA6kKV9JBdGSjcrHYt0pzQbXiF.mQHS8sgCe.S.Qn7X0.qVqyNTw8YPj6KnMJJYeeHSFN w3S1LA0f8dK8Eic1LHHS5OnH5IeP8Bwxui7ev5MkrAlNnnAmF6sOKNYdMDEnsy2nlohfVVMsshLx bV..wCa9POVmuqBboDOZi_jv6AVv3uUKf3_d1uPvSMBvfMfOI7WdvuzHO9fJds21Q.TZ88CmIEZs pVy8YP06GNVcwy0.hRtHNtuUhT6iRgRtfgwgLEokpaOQJS1DcyyatDdr5JXreVyagHatq43oUyDD AqNNz.I3JYFIyUYtztiPt6AIAckLiru3cZlX7sO8SEVk4JtE8XPmNp0g.zdX9SKWhNZsihMwr8OG hgrUkedCsxz2j515O3r2bAMPD.ouwUz4J8pL51zN8wgUHcJfwTj71Zz5PZElRsh7FVqk.wmKnZh4 f6XC8DO08cWUFLQo.iUtwtuo4CWfRhij30kUHslz4997AecpiQ2tHFCZsdOy9QwKkv54psEaszPp .YgvmJYbe0Zktg.Mt_lkfpfmaHwe9N9lgPwHfTF5unQgpTFpdhxeGc2Xv6j293zNZZqD88syWbdw JNTkC9K.dw8NJGDKaS8q8rSc747TFF5q9DCi.XidgF5fIn7wprlFr0U8kQ4d0OSTDqVfoIl9gG7D HaBfnwy2Wy7z.9cA5YpmWh.jXatcHJrHPE0D.FAWOLi9yUr7IGfpazL7ORjcWsMUtRkt._4SDDz3 svTyEfCXUfukE2aKr0nndaqTGXNc.cCO3P7040RJaE2Jgx4IYJIf32alSzRMQngLQQ7weguBK6Q. uxGGDjlTKEFEP5Mcl3Wke8f7OYWoAuqV_wYczcCjTf5BjbnC.9i5Jw4XfTqShqgrEJk9.WG83f49 EIAobr9TsMebAZBxMZiKqMV.XO0Bspa7CO3Qbpma6y3Xmf4NRgQc6hO5Ft51bAjoMZc9Sfucspg- - Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Thu, 9 Apr 2020 14:35:16 +0000 Received: by smtp406.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7697ad90edd7dbd15b5df9aa194deef6; Thu, 09 Apr 2020 14:25:13 +0000 (UTC) To: =?UTF-8?Q?=c3=89ric_Vyncke?= , The IESG Cc: draft-ietf-sidrops-rp@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, Nathalie Trenaman References: <158638167249.20283.18380733180622446749@ietfa.amsl.com> From: Stephen Kent Message-ID: <133793a3-f1a0-a834-2f39-8ac6b7c1a628@verizon.net> Date: Thu, 9 Apr 2020 10:25:12 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <158638167249.20283.18380733180622446749@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailer: WebService/1.1.15620 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) Archived-At: Subject: Re: [Sidrops] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sidrops-rp-06=3A_=28with_COMMENT=29?= X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 14:35:32 -0000 Éric, > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > While this document is useful for a RPKI newcomer or implementer, I wonder > whether it should become a RFC even if informal... and the "requirements" in > the title is also conflicting IMHO with an informational RFC. Informational RFCs have been used to document requirements, separate from standards track RFCs, in many cases.  A quick scan of Informational RFCs published over the past 20 years, with titles including the word "requirements" identifies over 200 such documents. So I don't believe the use of that term in a title is disqualifying per se. Admittedly, these RFCs often were generated to provide guidance for later standards work, e.g., establishing a basis for a WG that is being formed. In this case, the motivation for a post hoc Informational RFC is the plethora of separate RFCs that establish processing criteria for an RP dealing with repository objects. The WG believes that this is a valid rationale for publication. > I wonder whether the "security considerations" section is really about security > considerations linked to this document or to the overall RP system. The Security Considerations in this document are associated with relying party processing of data acquired from the repository system. There are a broader set of security considerations for the RPKI that address the behavior of the CAs and repository operators, not to mention how ISPs make use of the RPKI data after it has been validated. Steve From nobody Thu Apr 9 07:38:41 2020 Return-Path: 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 98B1A3A07E9; Thu, 9 Apr 2020 07:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 YJ7vWgeUUz86; Thu, 9 Apr 2020 07:38:26 -0700 (PDT) Received: from out20-50.mail.aliyun.com (out20-50.mail.aliyun.com [115.124.20.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B56B3A07AC; Thu, 9 Apr 2020 07:38:20 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.1399586|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_system_inform|0.0079605-3.23236e-05-0.992007; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03307; MF=madi@rpstir.net; NM=1; PH=DS; RN=6; RT=6; SR=0; TI=SMTPD_---.HDdfjWw_1586443092; Received: from 192.168.3.24(mailfrom:madi@rpstir.net fp:SMTPD_---.HDdfjWw_1586443092) by smtp.aliyun-inc.com(10.147.41.178); Thu, 09 Apr 2020 22:38:14 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Di Ma In-Reply-To: <158635214730.7934.5595563917251501429@ietfa.amsl.com> Date: Thu, 9 Apr 2020 22:38:09 +0800 Cc: The IESG , draft-ietf-sidrops-rp@ietf.org, SIDROps Chairs , sidrops@ietf.org, nathalie@ripe.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <158635214730.7934.5595563917251501429@ietfa.amsl.com> To: Robert Wilton X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Sidrops] Robert Wilton's No Objection on draft-ietf-sidrops-rp-06: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 14:38:35 -0000 Robert, Thanks for your review. Please find our response in lines. > 2020=E5=B9=B44=E6=9C=888=E6=97=A5 21:22=EF=BC=8CRobert Wilton via = Datatracker =E5=86=99=E9=81=93=EF=BC=9A >=20 > Robert Wilton has entered the following ballot position for > draft-ietf-sidrops-rp-06: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for this - I think that this document is useful. One issue = with the > IETF standard format is that it can be difficult to find which RFCs = need to be > read to fully solve a particular problem, particularly considering = that some of > those RFCs may be updated or obsoleted by other RFCs. I agree with = Warren's > comment that it would make a good living document, if IETF had such = things. >=20 > In terms of reading the document, I noted that it uses quite a lot of = acronyms > that I was not immediately familiar with and that are not defined in = the > document. Perhaps the document could be improved by having a short = terminology > section? The acronyms that didn't appear to be defined include CRL, = INR, CA, > ROA. >=20 This document is intended for implementors or operators who have already = read RFC 6480, which we mentioned in first paragraph of the = Introduction. Thus we expect readers already know those acronyms and = related concepts. > 4.2.1. Manifest >=20 > To determine whether a manifest is valid, the RP is required to > perform manifest-specific checks in addition to those specified in > [RFC6488]. >=20 > I found the above paragraph as being unclear, in that I don't know = what "those" > is referring to, and hence I suggest more clearly identifying = =E2=80=9Cthose=E2=80=9D checks. >=20 In this context "those" refers to the generic signed object checks = described in 6488. We will improve this sentence by stating that = explicitly. > Finally, I agree with Alvaro's comment related to section 4.3: This = document > probably shouldn't be giving recommendations. Perhaps better to just = keep this > as "However, most RP software ignores such objects.", or combine it = with the > previous sentence. >=20 >=20 My co-author Steve has responded to Alvaro in terms of deleting the = recommendations.=20 Di From nobody Thu Apr 9 07:45:26 2020 Return-Path: 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 1A95E3A0844; Thu, 9 Apr 2020 07:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 8MprkQ2S1hYY; Thu, 9 Apr 2020 07:45:18 -0700 (PDT) Received: from out20-38.mail.aliyun.com (out20-38.mail.aliyun.com [115.124.20.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B684B3A0843; Thu, 9 Apr 2020 07:45:15 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.08401275|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_regular_dialog|0.0133755-3.34407e-05-0.986591; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03294; MF=madi@rpstir.net; NM=1; PH=DS; RN=6; RT=6; SR=0; TI=SMTPD_---.HDdjb.6_1586443503; Received: from 192.168.3.24(mailfrom:madi@rpstir.net fp:SMTPD_---.HDdjb.6_1586443503) by smtp.aliyun-inc.com(10.147.41.121); Thu, 09 Apr 2020 22:45:04 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Di Ma In-Reply-To: <158639761310.14576.3625316672934417222@ietfa.amsl.com> Date: Thu, 9 Apr 2020 22:45:00 +0800 Cc: The IESG , draft-ietf-sidrops-rp@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, nathalie@ripe.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <158639761310.14576.3625316672934417222@ietfa.amsl.com> To: Roman Danyliw X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Sidrops] Roman Danyliw's No Objection on draft-ietf-sidrops-rp-06: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 14:45:20 -0000 Roman, Thanks for your review. Please find our response in lines. > 2020=E5=B9=B44=E6=9C=889=E6=97=A5 10:00=EF=BC=8CRoman Danyliw via = Datatracker =E5=86=99=E9=81=93=EF=BC=9A >=20 > Roman Danyliw has entered the following ballot position for > draft-ietf-sidrops-rp-06: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > ** In the spirit of this being a pathfinding document, provide = additional > references as follows: >=20 > -- Section 3.2. Per =E2=80=9CAn RP is expected to support the amended = procedure to > handle with accidental over-claim.=E2=80=9D, a pointer to these = procedures would be > helpful. We will provide pointers to specific sections that describe these = procedures as you suggest. > -- Section 3.3. Per =E2=80=9CCRLs in the RPKI are tightly = constrained; only the > AuthorityKeyIndetifier and CRLNumber extensions are allowed =E2=80=A6=E2= =80=9D, a pointer to > these extensions would be helpful. ACK. We will add pointers to AuthorityKeyIndentifier (Section 4.8.3 of RFC = 6487) and CRL Number (Section 5.2.3 of RFC 5280) >=20 > -- Section 4.2.4, Per =E2=80=9CAdditionally, the certificate must = contain an AS > Identifier Delegation extension =E2=80=A6=E2=80=9D, a pointer to this = extension would be > helpful. ACK. We will add pointer to AS Identifier Delegation extension (Section = 4.8.11 of RFC 6487) . >=20 > ** Section 1. Per =E2=80=9CBesides, software engineering calls for = how to segment the > RP system into components with orthogonal functionalities, so that = those > components could be distributed across the operational timeline of the = user=E2=80=9D. I > didn=E2=80=99t follow the intent of this sentence. What are = principles of software > engineering calling for? By dividing RP function into some modules independent with one another, = the implementation is easy to be extended. That is, one module can be = evolved with another remaining unchanged. >=20 > ** Section 3.3. Typo in the extension name.=20 > s/AuthorityKeyIndetifier/AuthorityKeyIdentifier/ >=20 ACK. > ** Section 7. Please add text that this document doesn=E2=80=99t = introduce any new > security considerations but is a resource to implementers. The = individual RPKI > RFC need to be consulted for specific guidance. Good idea. We will add a sentence to that effect, at the beginning of = this section. >=20 > ** Editorial Nits > -- Section 1. Typo. s/This document will be update =E2=80=A6/This = document will be > updated =E2=80=A6/ ACK. >=20 > -- Section 3.1. Typo. s/must be present and value of each = extension/must be > present and the value of each extension/ >=20 >=20 ACK. Di From nobody Thu Apr 9 07:55:06 2020 Return-Path: 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 DA47E3A0908; Thu, 9 Apr 2020 07:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 PN4d7X8xF0Zd; Thu, 9 Apr 2020 07:54:41 -0700 (PDT) Received: from out20-61.mail.aliyun.com (out20-61.mail.aliyun.com [115.124.20.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF703A08FD; Thu, 9 Apr 2020 07:54:37 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.07440652|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_regular_dialog|0.00636693-0.000222686-0.99341; FP=0|0|0|0|0|-1|-1|-1; HT=e01a16370; MF=madi@rpstir.net; NM=1; PH=DS; RN=6; RT=6; SR=0; TI=SMTPD_---.HDdpOGB_1586444065; Received: from 192.168.3.24(mailfrom:madi@rpstir.net fp:SMTPD_---.HDdpOGB_1586444065) by smtp.aliyun-inc.com(10.147.40.2); Thu, 09 Apr 2020 22:54:27 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Di Ma In-Reply-To: <158641275843.11786.5802713073847135604@ietfa.amsl.com> Date: Thu, 9 Apr 2020 22:54:23 +0800 Cc: The IESG , draft-ietf-sidrops-rp@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, nathalie@ripe.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <158641275843.11786.5802713073847135604@ietfa.amsl.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rp-06: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 14:54:45 -0000 Benjamin, Thanks for your review. Please find our response in lines. > 2020=E5=B9=B44=E6=9C=889=E6=97=A5 14:12=EF=BC=8CBenjamin Kaduk via = Datatracker =E5=86=99=E9=81=93=EF=BC=9A >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-sidrops-rp-06: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Section 2 >=20 > RP software uses synchronization mechanisms supported by targeted > repositories (e.g., [rsync], RRDP [RFC8182]) to download all RPKI > changed data objects in the repository system and cache them = locally. >=20 > nit(?): perhaps "changed" requires a bit more explanation. How about: RP software uses synchronization mechanisms supported by targeted = repositories (e.g., [rsync], RRDP [RFC8182]) to download RPKI data = objects in the repository system in order to update the local cache. = These mechanisms download only those objects that have been added, or = replaced with new versions, since the time when the RP checked the = repository.=20 >=20 > Section 2.1 >=20 > TAL acquisition and processing are specified in Section 3 of > [RFC8630]. >=20 > I'm not really convinced that the referenced section discusses > specifically TAL *acquisition*. >=20 Good catch. "TAL configuration=E2=80=9D fits well here.=20 > Section 2.2 >=20 > by using the SIA and AIA extensions. Detailed specifications of SIA > and AIA extensions in a resource certificate are described in > Section 4 of [RFC6487]. >=20 > (Subsections thereof, though I trust that the reader should be able to > figure this out.) ACK. We will add more specific pointers to SIA and AIA extensions. >=20 > Section 3.1 >=20 > established by Section 4 of [RFC6487]. This means that all > extensions mandated by Section 4.8 of [RFC6487] must be present and > value of each extension must be within the range specified by this > RFC. Moreover, any extension excluded by Section 4.8 of [RFC6487] >=20 > nit: s/this/that/ ("this RFC" is the thing that draft-ietf-sidrops-rp > will become, in this context). ACK. We will use =E2=80=9Cthis document=E2=80=9D instead of =E2=80=9Cthis = RFC=E2=80=9D. >=20 > Section 7.1 of [RFC6487] gives the procedure that the RP should > follow to verify resource certificate and syntax. >=20 > "verify resource certificate and syntax" seems a little broad; the > referenced section seems specific to validating the extension defined = in > RFC 3779. Yes. We will say:=20 Section 7.1 of [RFC6487] specifies the procedure that the RP should = follow to verify the RCF 3779 extension. >=20 > Section 3.2 >=20 > Certificate Authorities that want to reduce aspects of operational > fragility will migrate to the new OIDs [RFC8360], informing the RP = of > using an alternative RPKI validation algorithm. An RP is expected = to > support the amended procedure to handle with accidental over-claim. >=20 > nit: I suggest s/with accidental over-claim/accidental overclaim/. ACK >=20 > Section 3.3 >=20 > Processing of a CRL that is not consistent with a manifest is a > matter of local policy, as described in the fourth paragraph of > Section 6.6 of [RFC6486]. >=20 > Is the fifth paragraph relevant, also? Yes. Good catch. >=20 > Section 4.1 >=20 > Note that these checks are necessary, but not sufficient. = Additional > validation checks must be performed based on the specific type of > signed object. >=20 > These additional validations are covered in the following sections, it > seems -- should we mention that here? Note that these checks are necessary, but not sufficient. Additional = validation checks must be performed based on the specific type of signed = object as described in Section 4.2.=20 >=20 > Section 4.2.4 >=20 > contain an IP Address Delegation extension. The validation = procedure > used for BGPsec Router Certificates is identical to the validation > procedure described in Section 7 of [RFC6487], but using the > constraints applied come from specification of Section 7 of > [RFC8209]. >=20 > nit: if it does something differently, it's no longer "identical"; = maybe > "analogous" or it's following the validation procedure [...] with > additional constraints"? > That said, Section 7 of RFC 8209 is the IANA considerations, so I'm = not > sure what the "constraints applied come from" is intended to say. >=20 proposed new text: The validation procedure used for BGPsec Router Certificates is = analogous to the validation procedure described in Section 7 of [RFC6487], but it uses the = constraints defined in Section 3 of [RFC8209]. > Section 7 >=20 > The validation steps discussed throughout this document are also = pretty > important to the security of the system as a whole. Good point. We'll add a final sentence: This document highlights many validation actions applied to RPKI signed = objects, an essential element of secure operation of RPKI security. >=20 > Section 10.1 >=20 > I'm not sure that RFC 5280 actually is normative here. (That might be > the first time I've ever said that!) We cite 5280 because it it the IETF profile for X.509; the various RPKI = RFCs further profile that RFC. >=20 > Section 10.2 >=20 > I think that RFCs 6489, 6916, and 8634 are probably better as = normative. OK, we'll move them up to 10.1 Di From nobody Thu Apr 9 12:03:38 2020 Return-Path: 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 6F74C3A0C41 for ; Thu, 9 Apr 2020 12:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 UJC5EkavsNfV for ; Thu, 9 Apr 2020 12:03:35 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD8823A0C92 for ; Thu, 9 Apr 2020 12:02:21 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jMcRP-00057a-VN for sidrops@ietf.org; Thu, 09 Apr 2020 19:02:20 +0000 Date: Thu, 09 Apr 2020 12:02:18 -0700 Message-ID: From: Randy Bush To: SIDR Operations WG User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] publication and fetching frequency X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 19:03:36 -0000 in the last days, on some mailing list or another, there was discussion of how often CA actually published and how frequently RPs pulled. my search fu is weak today. anyone have the thread? of course i have an opinion on the question :) randy From nobody Thu Apr 9 12:59:32 2020 Return-Path: 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 6CE6B3A0D39 for ; Thu, 9 Apr 2020 12:59:30 -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=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 OpJJx_cCQUpx for ; Thu, 9 Apr 2020 12:59:29 -0700 (PDT) Received: from sonic312-21.consmr.mail.bf2.yahoo.com (sonic312-21.consmr.mail.bf2.yahoo.com [74.6.128.83]) (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 2CA443A0D37 for ; Thu, 9 Apr 2020 12:59:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1586462368; bh=ZcoQhYql2wrqT7LPXuxGio2YzPrMF2geEdLjzdL4IPw=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=imrel3mSnWSWhqr09xL5R26DjDZCG4hCDqPfqvqjRvFy3uhevLMM8uNVFZZrFs24lAETFJJaA5+YIrU4HcxLIMoXKKLrMguaoDHk4oyz8GSGUXFQE+BKyomrTGfPpGpa+YXO7K1JkN1+krAC1H3oo0adyIHakY95CAwltuX472BvUTE+KT1ITdNCsnhsaxSOnmrZKf9pzWBn9I9DQwiKjMLgG1MJ2uD5hOhMjrVqFMe0ismT3ZlRpjfrZ/mLJUDrRQSECd62o1QEutY1BphBFdEGrnfukWd6EiyocYsyuhJathLVkWDICiM2adOBFEZ5zXKicrp7jrM5rqI/I99whA== X-YMail-OSG: 75gq400VM1nTaDyi.UsSVTXcqRh9GKyLbXLTsUlN02SHaUnKOJovvkd809qsUjS iLL0ivBLIH687Ho1cuihPf8RRP8yjMKM4DS2DmOxH5GCbrNdG2uNs4cXCxnUk.MFyh50WlcWaQ42 4cyox.R6qeoXV_6ISIHMSURcJwQC0JhsBaHsUU0PojKxIXdNhaStn5qqkoCqorWdRZai9PUatbdL RT2iU6UaiwWftA1.7BFFVjQh59E6.2ag1JZ0SD8yhkpjN23NGHflQlQCfOFtajM2.Pn4q4OZ2.Vx Xz_S3Hspq.5K4OJPe8ZbZbjWMK6RYStwzXm58NzDyBbWwnqYXcOQzjUKRwl_4TMjtijXAY2_zH54 NVglA5zk7IjQiAioO9yL5mN1Z05_y3pbjKQlS_BpBuaTM8o_2.yCyY6hniluHbSr5Fx_n8GotiVN 8RCdprYVEkqqtDHjtttmvsHKpIyMVuVrzzVv3iRSK9dwf38xg86IGVYhmVH4.qDRTIX4b2LTSQpO mSCeKoqJiupoKGwPxU68Tz10jwMAZLTsVKSmv8tWSUrN4fqYM8Iw0JSw..IXOO_HBgaC_N4MyTMi 9jxmS52RvQBxy2tBWHOaz0J1mGKjvtFhSgTbhO1aujDFjVfhavsPfQG2qK.AMSzXsplTmyuv28Bk QQFIZVeQ78kFfz1kZxolC3Z6CmzGUBeSPm3nHmyhT_9mx3tjQ1Vg.2H_eosSo8NCFLl.Pq4ihwKy fGRywb9NIVeEpfOZ60SSW41rsAUb5v2GDX6ziCbXSKeliZj_4dHGs2SKhSG2aKQ9AescXndXCjJz U4jEQdzL.uEHEpJ.6u01a83MpwzT5LqFQYGDVrD4PXgixltfN.GGJ3FO2hVADAxqcq2pfxbXu4SO 7QE8CQ8EA_hcLnXrN_NETB07cdkzAsQTVlCBzaG0rP.F.iOWRdQHyx7yF6ZJSWQBsBMwUZ7Fo32y XQVax1Asekdntgu8f2YhtLTJ_58sltpnsoN7giVsoNpM4pMCVNF6gBT9CYqZfPWaUR0TqWsloR.u bvnYtHuJhych0aPoWrXT.IfyAhYniq8JYfb8xaQfrdgEvs4s8aBo79LGjn0nXw8h2ISxFnz0.e6H hKnzJq_lqB9ulX4Zh57RjdCDoVYCsg91qrbxY7ZptpVGo_6Xmv2i9jGXynLmcCDFVPU7A5B8cWjL j0RHDT0KKnxv7_cyRWhxlPlKNPaWuOsl0Ioko7h3Pl.D1x76iJ4Wr.e820U4v1TGejFLoeK.cteO AyZFEylS6PhnNZL9LkHqqXKLGL0kU1F2M82_ZIsd8wdNhWIXxg.JKE93ugb5JaJISOgu68y5K74O icvcPDOPCFCWXbKC8mJjrMdMWuYVCPF0F2xkUe.znlG6FsQdm5YjwY0RT9JktzWtqGmHh6XesVyG uL4BXySK39Ed3xncolOZuEjFq7qmqR7SFfw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Thu, 9 Apr 2020 19:59:28 +0000 Received: by smtp408.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 16db1356950edc71143b80d88bc03477; Thu, 09 Apr 2020 19:59:26 +0000 (UTC) To: Robert Kisteleki , "sidrops@ietf.org" References: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> From: Stephen Kent Message-ID: Date: Thu, 9 Apr 2020 15:59:26 -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: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailer: WebService/1.1.15620 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 19:59:31 -0000 Robert, > Hi, > >> Missing: an object named in a Manifest, but not available for download >> from a PP, is termed *missing*. An RP has no obvious way to acquire >> missing objects, but operators SHOULD be warned about which objects are >> missing. > IMO an "RP has no obvious way to acquire missing objects" is not > entirely true. > > If, at the previous run, the RP fetched the relevant (now missing) > object, then I see no reason to not use it again. Think of the previous > run as an object a cache if you will: if you're looking for an object > mentioned in the manifest, and you have it already (hash / name / etc. > matches) then you can reuse it. I probably should have said that an RP views an object as "missing" if the the object is not present in the RP's cache and cannot be retrieved from the relevant PP. Because RPs retrieve objects only if the objects have changed (newly added or updated), an RP would not be aware that an object is not present at a PP if the object is present in the RP's cache. I recall a famous quote about whether an object that has not been updated makes any noise when it is deleted from a PP, or something like that :-) > Of course it can be useful to check if it still exists in the PP, but it > seems to me the only benefit is to detect that it is missing from there > and perhaps warn the PP operator. Otherwise the RP has a hard time > arguing "no idea what this is since it's not there!". I think I agree about the utility of detecting an object that has gone missing from a PP, when the RP has the object locally cached. But, in my experience, RP software was not designed to detect this case. > For bonus points: an implementation that fetched a PP's manifest, > detected that it's exactly the same as before, and therefore reused the > validation outcome from the previous run would not even have to fetch > *any* other objects from the same PP. If the manifest was not changed, at all, then it would not be fetched, right? > The downside is that this process > will not be able to point out the omission. The upside is saves a lot of > resources (bandwidth, CPU and all). A further upside is that as a > side-effect this protects against a malicious attacker (selectively) > hiding objects. If the only things that changed in the manifest were the updates and manifest number, then there would be no need to retrieve any additional objects, and with rsync I don't believe there would be any other file retrievals. I can't be sure, but I think thge BBN RPSTIR software behaved that way.  Do we get bonus points? > Where this comes back to the current discussion is: would this behaviour > be mandated, recommended, or considered a big no-no? Which behavior? I would say recommended. Steve From nobody Thu Apr 9 13:25:08 2020 Return-Path: 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 86DE43A0DC2 for ; Thu, 9 Apr 2020 13:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 6fmKFUreDh-w for ; Thu, 9 Apr 2020 13:25:04 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 726BE3A0C9D for ; Thu, 9 Apr 2020 13:25:04 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 64B6128B003B; Thu, 9 Apr 2020 16:25:03 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 4E9E11F804E; Thu, 9 Apr 2020 16:25:03 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sandra Murphy In-Reply-To: Date: Thu, 9 Apr 2020 16:25:01 -0400 Cc: Sandra Murphy , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Randy Bush X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Sidrops] publication and fetching frequency X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 20:25:06 -0000 > On Apr 9, 2020, at 3:02 PM, Randy Bush wrote: >=20 > in the last days, on some mailing list or another, there was = discussion > of how often CA actually published and how frequently RPs pulled. my > search fu is weak today. anyone have the thread? >=20 > of course i have an opinion on the question :) >=20 > randy >=20 Is this what you were looking for? =E2=80=94Sandy thread: Re: [routing-wg] Subject: RPKI ROA Deletion: Post-mortem > On Apr 6, 2020, at 10:02 AM, Job Snijders wrote: >=20 > Hi, >=20 > On Mon, Apr 6, 2020, at 15:54, Danny McPherson wrote: >> Thanks for this Job, interesting analysis. >>=20 >> Another question here: at what interval is data from a given RIR=20 >> repository ingested / operationalized by a given network operator? = Or=20 >> put differently, any idea how much lag today between when an RIR RPKI=20= >> repository has a change until that becomes OV policy in _your = routers? =20 >> I'm sure this varies but not sure by how much within a given = operator,=20 >> or across operators. >=20 > Consumption: Some network operators fetch & validate RPKI data only = once a day, some perform that action every 15 minutes. >=20 > Publication: Some CA operators publish changes every 6 hours, some = publish every 15 minutes. >=20 > I agree I wouldn't expect a lot of variance within a given operator, = but across operators we should expect differences.=20 >=20 > Kind regards, >=20 > Job From nobody Thu Apr 9 13:31:25 2020 Return-Path: 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 96CEB3A0DD2 for ; Thu, 9 Apr 2020 13:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_SINGLE_WORD=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 bhBoTTupBLUK for ; Thu, 9 Apr 2020 13:31:17 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9463A0DDF for ; Thu, 9 Apr 2020 13:31:17 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jMdpS-0005az-Jw; Thu, 09 Apr 2020 20:31:14 +0000 Date: Thu, 09 Apr 2020 13:31:13 -0700 Message-ID: From: Randy Bush To: Sandra Murphy Cc: SIDR Operations WG In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] publication and fetching frequency X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 20:31:23 -0000 thanks! From nobody Thu Apr 9 15:16:28 2020 Return-Path: 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 6C3733A1057; Thu, 9 Apr 2020 15:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 JNuyFBQsL1_q; Thu, 9 Apr 2020 15:16:17 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA443A1055; Thu, 9 Apr 2020 15:16:16 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 039MG6Qm020704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Apr 2020 18:16:12 -0400 Date: Thu, 9 Apr 2020 15:16:05 -0700 From: Benjamin Kaduk To: Di Ma Cc: The IESG , draft-ietf-sidrops-rp@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, nathalie@ripe.net Message-ID: <20200409221605.GI88064@kduck.mit.edu> References: <158641275843.11786.5802713073847135604@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rp-06: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 22:16:20 -0000 On Thu, Apr 09, 2020 at 10:54:23PM +0800, Di Ma wrote: > Benjamin, > > Thanks for your review. > > Please find our response in lines. > > > 2020年4月9日 14:12，Benjamin Kaduk via Datatracker 写道： > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-sidrops-rp-06: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Section 2 > > > > RP software uses synchronization mechanisms supported by targeted > > repositories (e.g., [rsync], RRDP [RFC8182]) to download all RPKI > > changed data objects in the repository system and cache them locally. > > > > nit(?): perhaps "changed" requires a bit more explanation. > > > How about: > > RP software uses synchronization mechanisms supported by targeted repositories (e.g., [rsync], RRDP [RFC8182]) to download RPKI data objects in the repository system in order to update the local cache. These mechanisms download only those objects that have been added, or replaced with new versions, since the time when the RP checked the repository. Looks good, thanks. > > > > > Section 2.1 > > > > TAL acquisition and processing are specified in Section 3 of > > [RFC8630]. > > > > I'm not really convinced that the referenced section discusses > > specifically TAL *acquisition*. > > > > Good catch. > > "TAL configuration” fits well here. > > > Section 2.2 > > > > by using the SIA and AIA extensions. Detailed specifications of SIA > > and AIA extensions in a resource certificate are described in > > Section 4 of [RFC6487]. > > > > (Subsections thereof, though I trust that the reader should be able to > > figure this out.) > > > ACK. > > We will add more specific pointers to SIA and AIA extensions. > > > > > Section 3.1 > > > > established by Section 4 of [RFC6487]. This means that all > > extensions mandated by Section 4.8 of [RFC6487] must be present and > > value of each extension must be within the range specified by this > > RFC. Moreover, any extension excluded by Section 4.8 of [RFC6487] > > > > nit: s/this/that/ ("this RFC" is the thing that draft-ietf-sidrops-rp > > will become, in this context). > > > ACK. > > We will use “this document” instead of “this RFC”. It's not aquestion of "RFC" vs. "document" but rather "this" vs. "that" -- someone reading the RFC that draft-ietf-sidrops-rp will become is reading "this RFC", whereas that other RFC (RFC 6487) that we're making a reference to is "that RFC". > > > > Section 7.1 of [RFC6487] gives the procedure that the RP should > > follow to verify resource certificate and syntax. > > > > "verify resource certificate and syntax" seems a little broad; the > > referenced section seems specific to validating the extension defined in > > RFC 3779. > > Yes. > > We will say: > > Section 7.1 of [RFC6487] specifies the procedure that the RP should follow to verify the RCF 3779 extension. > > > > > Section 3.2 > > > > Certificate Authorities that want to reduce aspects of operational > > fragility will migrate to the new OIDs [RFC8360], informing the RP of > > using an alternative RPKI validation algorithm. An RP is expected to > > support the amended procedure to handle with accidental over-claim. > > > > nit: I suggest s/with accidental over-claim/accidental overclaim/. > > ACK > > > > > Section 3.3 > > > > Processing of a CRL that is not consistent with a manifest is a > > matter of local policy, as described in the fourth paragraph of > > Section 6.6 of [RFC6486]. > > > > Is the fifth paragraph relevant, also? > > Yes. Good catch. > > > > > Section 4.1 > > > > Note that these checks are necessary, but not sufficient. Additional > > validation checks must be performed based on the specific type of > > signed object. > > > > These additional validations are covered in the following sections, it > > seems -- should we mention that here? > > Note that these checks are necessary, but not sufficient. Additional validation checks must be performed based on the specific type of signed object as described in Section 4.2. > > > > > Section 4.2.4 > > > > contain an IP Address Delegation extension. The validation procedure > > used for BGPsec Router Certificates is identical to the validation > > procedure described in Section 7 of [RFC6487], but using the > > constraints applied come from specification of Section 7 of > > [RFC8209]. > > > > nit: if it does something differently, it's no longer "identical"; maybe > > "analogous" or it's following the validation procedure [...] with > > additional constraints"? > > That said, Section 7 of RFC 8209 is the IANA considerations, so I'm not > > sure what the "constraints applied come from" is intended to say. > > > > proposed new text: > The validation procedure used for BGPsec Router Certificates is analogous to the validation > procedure described in Section 7 of [RFC6487], but it uses the constraints defined in Section 3 of [RFC8209]. I think that works. (Section 3 makes much more sense than Section 7!) > > > Section 7 > > > > The validation steps discussed throughout this document are also pretty > > important to the security of the system as a whole. > > Good point. We'll add a final sentence: > > This document highlights many validation actions applied to RPKI signed objects, an essential element of secure operation of RPKI security. > > > > > > Section 10.1 > > > > I'm not sure that RFC 5280 actually is normative here. (That might be > > the first time I've ever said that!) > > We cite 5280 because it it the IETF profile for X.509; the various RPKI RFCs further profile that RFC. > > > > > > Section 10.2 > > > > I think that RFCs 6489, 6916, and 8634 are probably better as normative. > > OK, we'll move them up to 10.1 Thanks for the updates! -Ben From nobody Thu Apr 9 22:09:22 2020 Return-Path: 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 628DE3A1EE7 for ; Thu, 9 Apr 2020 22:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 o35STA7J8Psi for ; Thu, 9 Apr 2020 22:09:18 -0700 (PDT) Received: from out20-97.mail.aliyun.com (out20-97.mail.aliyun.com [115.124.20.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3B83A1EE0 for ; Thu, 9 Apr 2020 22:09:16 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.4835023|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_system_inform|0.302309-0.000775527-0.696916; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03300; MF=madi@rpstir.net; NM=1; PH=DS; RN=3; RT=3; SR=0; TI=SMTPD_---.HDzGa1Z_1586495350; Received: from 192.168.218.230(mailfrom:madi@rpstir.net fp:SMTPD_---.HDzGa1Z_1586495350) by smtp.aliyun-inc.com(10.147.40.2); Fri, 10 Apr 2020 13:09:11 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Di Ma In-Reply-To: Date: Fri, 10 Apr 2020 13:09:07 +0800 Cc: Robert Kisteleki , "sidrops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> To: Stephen Kent X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2020 05:09:20 -0000 >> The downside is that this process >> will not be able to point out the omission. The upside is saves a lot = of >> resources (bandwidth, CPU and all). A further upside is that as a >> side-effect this protects against a malicious attacker (selectively) >> hiding objects. > If the only things that changed in the manifest were the updates and = manifest number, then there would be no need to retrieve any additional = objects, and with rsync I don't believe there would be any other file = retrievals. I can't be sure, but I think thge BBN RPSTIR software = behaved that way. Do we get bonus points? Yes.=20 RPSTIR doesn=E2=80=99t retrieve any additional objects by using rsync to = keep synchronized with repositories. However, how to deal with those downloaded objects (use/ignore/warn) = depends on how we cope with MFT, CRL and local analysis. Di= From nobody Thu Apr 9 23:20:25 2020 Return-Path: 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 2D9EE3A1831 for ; Thu, 9 Apr 2020 23:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 kl1RWnDo3W6t for ; Thu, 9 Apr 2020 23:20:19 -0700 (PDT) Received: from smtpbgeu1.qq.com (smtpbgeu1.qq.com [52.59.177.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01C2E3A182F for ; Thu, 9 Apr 2020 23:20:18 -0700 (PDT) X-QQ-mid: bizesmtp18t1586499611tfq2w3df Received: from [192.168.218.230] (unknown [202.173.9.210]) by esmtp6.qq.com (ESMTP) with id ; Fri, 10 Apr 2020 14:20:09 +0800 (CST) X-QQ-SSF: 00400000002000N0ZI80000B0000000 X-QQ-FEAT: JtFveLzs4P9JtAYa2xZg7fSfam0cmhYM4duOBL5ID7LO7e/f1ycFW4pzp/TGb W3sxR9HvAs31Z+l8flLE2Qtvd26BfV4snm2boBhpAPJ2bSw6Wgh03jGlN0B4D2IUwuCI5F7 uZsZusdF6c85oQF4X17MCcQUhtFxam5jz3fZludbMNPltbEyGX7IusD3YHv2TiehyBHIhTv QtBHL1N6JBDyTD49nQl5t9S940qLDEefmiOmlR2lyfBRhzMGWNorLF23vnUkr2vOTCCeBmA hcrUyv9SEsewjhiSR+RrmHMjGSMsxWc/TkNgAU+jW1k+pK9Mm+ZX5DKql9nJGh1l7nKsVkW z6BoEl3UXIhsgTAYFw= X-QQ-GoodBg: 2 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Di Ma In-Reply-To: <20200409221605.GI88064@kduck.mit.edu> Date: Fri, 10 Apr 2020 14:20:06 +0800 Cc: The IESG , draft-ietf-sidrops-rp@ietf.org, SIDROps Chairs , SIDR Operations WG , nathalie@ripe.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <158641275843.11786.5802713073847135604@ietfa.amsl.com> <20200409221605.GI88064@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3608.80.23.2.2) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign5 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rp-06: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2020 06:20:23 -0000 Benjamin, >>>=20 >>> Section 3.1 >>>=20 >>> established by Section 4 of [RFC6487]. This means that all >>> extensions mandated by Section 4.8 of [RFC6487] must be present and >>> value of each extension must be within the range specified by this >>> RFC. Moreover, any extension excluded by Section 4.8 of [RFC6487] >>>=20 >>> nit: s/this/that/ ("this RFC" is the thing that = draft-ietf-sidrops-rp >>> will become, in this context). >>=20 >>=20 >> ACK. >>=20 >> We will use =E2=80=9Cthis document=E2=80=9D instead of =E2=80=9Cthis = RFC=E2=80=9D. >=20 > It's not aquestion of "RFC" vs. "document" but rather "this" vs. = "that" -- > someone reading the RFC that draft-ietf-sidrops-rp will become is = reading > "this RFC", whereas that other RFC (RFC 6487) that we're making a > reference to is "that RFC". Gotcha:-) We will replace "this RFC" with "RFC 6487".=20 Di= From nobody Thu Apr 9 23:37:01 2020 Return-Path: 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 1923B3A185F for ; Thu, 9 Apr 2020 23:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 mYLcfBY9M_gj for ; Thu, 9 Apr 2020 23:36:51 -0700 (PDT) Received: from smtpproxy21.qq.com (smtpbg702.qq.com [203.205.195.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD4F23A185C for ; Thu, 9 Apr 2020 23:36:49 -0700 (PDT) X-QQ-mid: bizesmtp28t1586500606t09ozc8y Received: from [192.168.218.230] (unknown [202.173.9.210]) by esmtp10.qq.com (ESMTP) with id ; Fri, 10 Apr 2020 14:36:44 +0800 (CST) X-QQ-SSF: 00400000002000N0ZI80000B0000000 X-QQ-FEAT: hChbZg0DKHySrZJHW+Q+vsS77g65QKyAwkMMHmhttOpMUhZqhHSH8ZGdy2nvm RnZfhMKgm+hms7MhXtbuvCU8SZBMWrGQZRSJ03sveGuX39VFRl8fVFLna4TiWxAU0y7Ny4f oMDEabzF2OKDbefYNgNsbvpJtGZ7h2mZ7yBECpe14qoFXDbcdd3BuqGMSLkg3i7U/Ph0tSR dZCix/83qH1MntF4EUT5OQ0hXCwtZJZjwwEYk8oXobCZHvQeSMURnkB4QoF9++h4/AL3C3D NxDb3B0GQcNQ4zeVB/+vF0R/Sbkv4sZ8sVJtGjvB5QuGc3Yrdvdpl03hsTToyL7ORLfZKJE wdNDsn7WXA91BrADPz/iexA2HhfAw== X-QQ-GoodBg: 2 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Di Ma In-Reply-To: <158537641925.17606.5199067976726721275@ietfa.amsl.com> Date: Fri, 10 Apr 2020 14:36:41 +0800 Cc: The IESG , draft-ietf-sidrops-rp@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, Nathalie Trenaman Content-Transfer-Encoding: quoted-printable Message-Id: <6E5113E5-31DA-47B9-8AC8-8B39B936EE5F@zdns.cn> References: <158537641925.17606.5199067976726721275@ietfa.amsl.com> To: Murray Kucherawy X-Mailer: Apple Mail (2.3608.80.23.2.2) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign7 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [Sidrops] Murray Kucherawy's No Objection on draft-ietf-sidrops-rp-06: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2020 06:36:59 -0000 Murray, Thanks for your review. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Section 4.3: >=20 > =E2=80=9CA Manifest can be classified as either valid or invalid, and = a valid Manifest > is either current and stale.=E2=80=9D >=20 > That should be =E2=80=9C...or stale=E2=80=9D, right? >=20 Good catch. It should be "or" here. Di From nobody Sat Apr 11 13:04:35 2020 Return-Path: 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 94FBC3A18B4 for ; Sat, 11 Apr 2020 13:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 QsnSJpN4Hl2T for ; Sat, 11 Apr 2020 13:04:32 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC373A18B2 for ; Sat, 11 Apr 2020 13:04:32 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jNMMg-0004Gd-9L for sidrops@ietf.org; Sat, 11 Apr 2020 20:04:30 +0000 Date: Sat, 11 Apr 2020 13:04:29 -0700 Message-ID: From: Randy Bush To: SIDR Operations WG User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] rpki rp frequency X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2020 20:04:34 -0000 how often do RPs fetch? how often to routers fetch from RPs? an experiment announces 147.28.241.0/24 constantly from 47065 a CA has a ROA for { 147.28.241.0/24 47065 } from 12:00 to 04:00 UCT and for some other, non-announcing i.e. incorrect, AS from 04:00 to 12:00. it's 19:50 UTC, and a seattle router shows r0.sea#sh ip bg rpki table | i ^147.28.241 147.28.241.0/24 24 47065 0 147.28.0.30/323 i.e. it sees the ROA for the announcing prefix but the received bgp route to 147.28.241.0/24 is does not reach that router maybe because transits dropped as invalid? 2914 is the upstream for that router. but rv shows route-views>show ip bgp 147.28.241.0/24 BGP routing table entry for 147.28.241.0/24, version 523202351 Paths: (12 available, best #12, table default) Not advertised to any peer Refresh Epoch 2 3303 47065 217.192.89.50 from 217.192.89.50 (138.187.128.158) Origin IGP, localpref 100, valid, external Community: 3303:1004 3303:1006 3303:1030 3303:3051 47065:332 path 7F57D930ED10 RPKI State valid rx pathid: 0, tx pathid: 0 and more. but with no paths through 2914. how do we diagnose such things? randy From nobody Sat Apr 11 15:35:06 2020 Return-Path: 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 8076B3A1A32 for ; Sat, 11 Apr 2020 15:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 SE9QDz8-1HFg for ; Sat, 11 Apr 2020 15:35:02 -0700 (PDT) Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [204.2.238.64]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3AFA3A1A35 for ; Sat, 11 Apr 2020 15:35:02 -0700 (PDT) Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id E1D2D220181 for ; Sat, 11 Apr 2020 22:35:00 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id 40E9927C0054 for ; Sat, 11 Apr 2020 18:34:59 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute3.internal (MEProxy); Sat, 11 Apr 2020 18:34:59 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrvdehgddutdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedflfhosgcuufhnihhjuggvrhhsfdcuoehjohgssehnthht rdhnvghtqeenucffohhmrghinheptgholhhotghluhgvrdhnvghtpdhpvggvrhhinhhgug gsrdgtohhmpdhgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpehjohgsodhmvghsmhhtphgruhhthhhpvghrshhonhgrlh hithihqddutdegjeeludehkeegqddvfeeffeekfedvtddqjhhosgeppehnthhtrdhnvght sehsohgsohhrnhhoshhtrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 97D73C200A5; Sat, 11 Apr 2020 18:34:58 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1104-g203475c-fmstable-20200408v2 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sun, 12 Apr 2020 00:34:27 +0200 From: "Job Snijders" To: sidrops@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] rpki rp frequency X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2020 22:35:05 -0000 On Sat, Apr 11, 2020, at 22:04, Randy Bush wrote: > how do we diagnose such things? My approach would be just like most other BGP reachability issue? First = step is to figure out the peer who'd you expect to carry the route to th= e global system. I think in the case of this experiment the relevant ups= tream might be AS 8283. Luckily they have a public looking glass, we can see that their EBGP-in = side rejects 2 routes from AS 47065 https://birdseye.coloclue.net/birdse= ye/app/routeservers/0/protocols/peer_AS47065_49DA60/routes It shows the = route being rejected because of RPKI. One could then go to https://www.peeringdb.com/asn/8283 for NOC contact = info and other information. There we also see "filters facing peers are = updated every 12 hours" - I suspect that coincidences in a specific way = with the pace of the experiment. Full disclosure: I was the architect of AS 8283's network automation sys= tem (https://github.com/coloclue/kees). One of my design choices was to = not use RTR. Instead, the 'kees' system generated & distributes a config= uration snippet to all routers and SIGHUPs the BGP process. The snippet = contains all the RPKI VRPs. This process runs every few hours. In the large RPKI deployments some people opted for a sort of tiered set= up: a few validators at the top, and then a distribution mechanism to RT= R servers, which then in turn distribute data via RTR to the BGP routers= . I expect operators to pick different timers for publishing & fetching = at each tier. I hope I can share more at a later point about such setups= . Some low-hanging fruit outside of IETF might be to introduce a new field= to PeeringDB's datamodel where operators can self-declare what the "RPK= I Delay" in their network roughly is. The "RPKI Delay" would be the maxi= mum number of minutes that could lapse between a ROA becoming available = for fetching at the publication point, to the=C2=A0moment the VRP is pre= sent on all routers, during normal operations. Or perhaps a new RPKI Object profile is defined to message some operatio= nal parameters about the validation process policies an ASN operator app= lies? Some of the data elements in PeeringDB were put there only because= there wasn't any other place to put it.=20 Kind regards, Job From nobody Sun Apr 12 02:42:26 2020 Return-Path: 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 1E63B3A1FF1 for ; Sun, 12 Apr 2020 02:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 7ou5R0zdM4Vt for ; Sun, 12 Apr 2020 02:42:22 -0700 (PDT) Received: from out20-1.mail.aliyun.com (out20-1.mail.aliyun.com [115.124.20.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA01A3A1FEE for ; Sun, 12 Apr 2020 02:42:18 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.3879732|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_system_inform|0.0316105-0.000222543-0.968167; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03310; MF=madi@rpstir.net; NM=1; PH=DS; RN=2; RT=2; SR=0; TI=SMTPD_---.HFB0FG3_1586684531; Received: from 192.168.3.24(mailfrom:madi@rpstir.net fp:SMTPD_---.HFB0FG3_1586684531) by smtp.aliyun-inc.com(10.147.41.178); Sun, 12 Apr 2020 17:42:13 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Di Ma In-Reply-To: Date: Sun, 12 Apr 2020 17:42:06 +0800 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <20B9DFE3-73E5-48D6-B8F0-7F401EBA9E19@rpstir.net> References: To: Randy Bush X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Sidrops] rpki rp frequency X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 09:42:24 -0000 Randy, > 2020=E5=B9=B44=E6=9C=8812=E6=97=A5 04:04=EF=BC=8CRandy Bush = =E5=86=99=E9=81=93=EF=BC=9A >=20 > how often do RPs fetch? As often as necessary that the RP can synchronize with a repository. But the repository manager MAY limit RP=E2=80=99s access in the light of = security, which by the way, RPSITR encounters at times. Di From nobody Sun Apr 12 11:31:38 2020 Return-Path: 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 E01783A24A8 for ; Sun, 12 Apr 2020 11:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 KDJb0m2AIZwH for ; Sun, 12 Apr 2020 11:31:36 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA0E3A24A6 for ; Sun, 12 Apr 2020 11:31:36 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jNhOG-0007Fr-AJ; Sun, 12 Apr 2020 18:31:32 +0000 Date: Sun, 12 Apr 2020 11:31:31 -0700 Message-ID: From: Randy Bush To: Di Ma Cc: SIDR Operations WG In-Reply-To: <20B9DFE3-73E5-48D6-B8F0-7F401EBA9E19@rpstir.net> References: <20B9DFE3-73E5-48D6-B8F0-7F401EBA9E19@rpstir.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] rpki rp frequency X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 18:31:38 -0000 >> how often do RPs fetch? > As often as necessary that the RP can synchronize with a repository. how often is 'necessary?' in units of time, please. i suspect that we are judging 'success' by the number of ASs doing 'something,' and not the quality of what they do in terms of, for example, publishing ROAs in a 'reasonable' time (imiho < 1hr), actual routers responsiveness to changing ROA registration, BGP announcements, etc. randy From nobody Mon Apr 13 01:19:06 2020 Return-Path: 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 054B83A1195 for ; Mon, 13 Apr 2020 01:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 9b7Mk1rXcg-s for ; Mon, 13 Apr 2020 01:19:03 -0700 (PDT) Received: from out20-63.mail.aliyun.com (out20-63.mail.aliyun.com [115.124.20.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E4103A1192 for ; Mon, 13 Apr 2020 01:19:01 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.3446475|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_regular_dialog|0.077214-0.000989403-0.921797; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03309; MF=madi@rpstir.net; NM=1; PH=DS; RN=2; RT=2; SR=0; TI=SMTPD_---.HFlXHNT_1586765932; Received: from 192.168.3.24(mailfrom:madi@rpstir.net fp:SMTPD_---.HFlXHNT_1586765932) by smtp.aliyun-inc.com(10.147.43.230); Mon, 13 Apr 2020 16:18:53 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Di Ma In-Reply-To: Date: Mon, 13 Apr 2020 16:18:49 +0800 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <20B9DFE3-73E5-48D6-B8F0-7F401EBA9E19@rpstir.net> To: Randy Bush X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Sidrops] rpki rp frequency X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2020 08:19:05 -0000 > 2020=E5=B9=B44=E6=9C=8813=E6=97=A5 02:31=EF=BC=8CRandy Bush = =E5=86=99=E9=81=93=EF=BC=9A >=20 >>> how often do RPs fetch? >> As often as necessary that the RP can synchronize with a repository. >=20 > how often is 'necessary?' in units of time, please. I think It is the ISP who defines what is necessary. Instead, I would prefer to talk about =E2=80=9Chow often is = possible=E2=80=9D.=20 Once upon a time, RPSTIR can do fetching every half an hour, which by = the way is the time that takes RPSTIR to accomplish synchronization.=20 Granted, as I said, repository manager could limit the frequency. Di From nobody Mon Apr 13 01:26:03 2020 Return-Path: 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 0B0103A1194; Mon, 13 Apr 2020 01:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 jZPmqyd_IgYc; Mon, 13 Apr 2020 01:25:56 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D173A10B7; Mon, 13 Apr 2020 01:25:56 -0700 (PDT) Received: from lhreml705-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 00B98D0F08C52F5F3651; Mon, 13 Apr 2020 09:25:54 +0100 (IST) Received: from lhreml705-chm.china.huawei.com (10.201.108.54) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 13 Apr 2020 09:25:53 +0100 Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Mon, 13 Apr 2020 09:25:52 +0100 Received: from DGGEML512-MBX.china.huawei.com ([169.254.2.152]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0487.000; Mon, 13 Apr 2020 16:25:46 +0800 From: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" To: Job Snijders , Robert Raszuk , "draft-ietf-sidrops-ov-egress.authors@ietf.org" CC: "grow@ietf.org grow@ietf.org" , SIDR Operations WG Thread-Topic: [GROW] Playing with origin validation Thread-Index: AQHWEPnYMjz2Fc6T/ECUWs0DUE9yb6h1X2eAgAFTreA= Date: Mon, 13 Apr 2020 08:25:46 +0000 Message-ID: References: <20200412195119.GA45907@vurt.meerval.net> In-Reply-To: <20200412195119.GA45907@vurt.meerval.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.203.187] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Sidrops] =?gb2312?b?tPC4tDogW0dST1ddIFBsYXlpbmcgd2l0aCBvcmln?= =?gb2312?b?aW4gdmFsaWRhdGlvbg==?= X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2020 08:25:58 -0000 ZHJhZnQtaWV0Zi1zaWRyb3BzLW92LWVncmVzcy0wMiBjb3VsZCBiZSBhIGdvb2Qgc29sdXRpb24g dG8gdGhlIGNhc2UgdGhhdCBSb2JlcnQgcmFpc2VkLiBUaGUgZWdyZXNzIE9WIHByb3ZpZGVzIHRo ZSBleHBvcnQgZmlsdGVyaW5nIGZvciByb3V0ZXMgd2l0aCBpbnZhbGlkIFJPQSB2YWxpZGF0aW9u IHJlc3VsdC4gV2l0aCB0aGlzIGNhcGFiaWxpdHkgc3VwcG9ydGVkLCB0aGUgb3JpZ2luIEFTL0FT IG9wZXJhdG9yIGlzIGluIGZhY3QgYWJsZSB0byBpZGVudGlmeSB0aGF0IGl0cyBvd24gUk9BIGVu dHJ5IGlzIG91dCBvZiBkYXRlIGFuZCBuZWVkcyB0byBiZSB1cGRhdGVkLiBIb3dldmVyLCBjdXJy ZW50bHkgdGhlcmUncyBubyBmdXJ0aGVyIGFjdGlvbi9zdWdnZXN0aW9uIHNwZWNpZmllZCBvdGhl ciB0aGFuIGZpbHRlcmluZyBpbiB0aGUgZHJhZnQtaWV0Zi1zaWRyb3BzLW92LWVncmVzcy0wMi4g U28sIGEgc21hbGwgc3VnZ2VzdGlvbiB0byB0aGUgYXV0aG9ycyB0aGF0IG1heWJlIHNvbWUgc3Bl Y2lmaWNhdGlvbnMgY2FuIGJlIGFkZGVkIHRvIHRoZSBkcmFmdCByZWdhcmRpbmcgaG93IHRoZSBv cmlnaW4gQVMgY291bGQvc2hvdWxkIHJlYWN0IHVwb24gdGhpcyBjYXNlLiANCg0KQlIsDQoNCll1 bmFuDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBHUk9XIFttYWlsdG86Z3Jvdy1ib3Vu Y2VzQGlldGYub3JnXSC0+rHtIEpvYiBTbmlqZGVycw0Kt6LLzcqxvOQ6IDIwMjDE6jTUwjEzyNUg Mzo1MQ0KytW8/sjLOiBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldD4NCrOty806IGdy b3dAaWV0Zi5vcmcgZ3Jvd0BpZXRmLm9yZyA8Z3Jvd0BpZXRmLm9yZz4NCtb3zOI6IFJlOiBbR1JP V10gUGxheWluZyB3aXRoIG9yaWdpbiB2YWxpZGF0aW9uDQoNCk9uIFN1biwgQXByIDEyLCAyMDIw IGF0IDA4OjM5OjU4UE0gKzAyMDAsIFJvYmVydCBSYXN6dWsgd3JvdGU6DQo+IFdvdWxkIGFueW9u ZSBiZSBhYmxlIHRvIGV4cGxhaW4gdGhlIGJlbG93IHBoZW5vbWVub24/DQo+IA0KPiBSUEtJIE9y aWdpbiB2YWxpZGF0aW9uIG1hcmtzIG5ldCA0NS4yMjcuMjU0LjAvMjQgYXMgSU5WQUxJRCBhcyBp dCANCj4gZXhwZWN0cyBpdCB0byBiZSBvcmlnaW5hdGVkIGJ5IEFTTjogMzk1OTc4DQoNCklmIHlv dSBsb29rIGF0IGh0dHBzOi8vc3RhdC5yaXBlLm5ldC80NS4yMjcuMjU0LjAlMkYyNCN0YWJJZD1y b3V0aW5nIHlvdSBjYW4gc2VlIHRoYXQgdGhlIHByZWZpeCBpcyBvbmx5IHNlZW4gYnkgNzIlIG9m IHRoZSBSSVBFIFJJUyBjb2xsZWN0b3JzLCB0aGlzIGlzIGEgdmVyeSBsb3cgc2NvcmUsIEknZCBj b25zaWRlciB0aGlzIGEgcHJvYmxlbWF0aWMgbmV0d29yayBvdXRhZ2UuIElmIHlvdSdkIGhhdmUg aW50ZXJuZXQgYWNjZXNzIHVzZXJzIHNlcnZpY2VkIG91dCBvZiB0aGUgYmxvY2sgaXQgcHJvYmFi bHkgd291bGQgbWVhbiBtYW55IHdlYnNpdGVzIGRvbid0IHdvcmssIG9yIGRvbid0IHdvcmsgd2Vs bC4NCg0KSW4gdGhlICdSb3V0aW5nIEhpc3RvcnknIHdpZGdldCB3ZSBjYW4gc2VlOg0KDQogICAg TWF5IDIwMTggLSBKdWwgMjAxOCAtIEFTIDM5NTk3OCANCiAgICAgICAgICAgICAgIEF1ZyAyMDE4 IC0gQVMgNjIwODgNCiAgICBPY3QgMjAxOCAtIE1hciAyMDE5IC0gQVMgNDIyNjANCiAgICBGZWIg MjAxOSAtIE1hciAyMDIwIC0gQVMgNTE4NTINCg0KSSBndWVzcyBlYXJseSBzb21lb25lIGRlZW1l ZCBBUyAzOTU5NzggZGVlbWVkIHRvIGJlIHRoZSByaWdodCBvcmlnaW4gQVNOIGFuZCBjcmVhdGUg UlBLSSBST0FzLCBidXQgc3Vic2VxdWVudGx5IGRpZG4ndCB1cGRhdGUgdGhlc2UgUlBLSSBST0Fz IHRvIHRoZSBuZXcgQVNOcyBhcyB0aGUgc3BhY2UgbW92ZWQgZnJvbSBsZXNzZWUgdG8gbGVzc2Vl LiBJIHN1c3BlY3QgSVAgYWRkcmVzcyBsZWFzaW5nIGlzIGluIHBsYXkgYmVjYXVzZSB0aGUgYW5u b3VuY2VtZW50IHBlcmlvZHMgZG9uJ3Qgc2VlbSB0byBvdmVybGFwLCBzdWdnZXN0aW5nIHRoZXJl IG1pZ2h0IGhhdmUgYmVlbiBjb29yZGluYXRpb24gYmV0d2VlbiBwcmV2aW91cyBhbmQgbmV4dCBP cmlnaW4gQVNOLg0KDQpTaW5jZSB0aGUgUk9BIHN0aWxsIGV4aXN0cywgd2hvZXZlciBjcmVhdGVk IHRoZSBST0EgKHRvIGF1dGhvcml6ZQ0KMzk1OTc4KSBzdGlsbCBpcyBpbiBhdXRob3JpdHksIHNv IGZyb20gYW4gb3BlcmF0aW9uYWwgcGVyc3BlY3RpdmUgaXQgaXMgaW5jdW1iZW50IG9uIHRoYXQg ZW50aXR5IHRvIGNvcnJlY3QgdGhlIFJQS0kgaW5mb3JtYXRpb24uIElmIHRoZSBzcGFjZSBoYWQg YmVlbiB0cmFuc2ZlcnJlZCBmcm9tIG9uZSBMSVIgdG8gYW5vdGhlciBMSVIgdGhlICdvZmZlbmRp bmcnIFJPQSB3b3VsZCd2ZSBiZWVuIGRlbGV0ZWQgaW4gdGhhdCB0cmFuc2ZlciBwcm9jZXNzLg0K DQo+IEJ1dCBpdCBjb21lcyBmcm9tICA1MTg1MiB3aGljaCBhY2NvcmRpbmcgdG8gaXBpbmZvIG9y IGJncHZpZXcgaXMgDQo+IGxlZ2l0aW1hdGUgQVNOOg0KPiANCj4gaHR0cHM6Ly9pcGluZm8uaW8v QVM1MTg1Mi80NS4yMjcuMjU0LjAvMjQNCj4gaHR0cHM6Ly9iZ3B2aWV3LmlvL3ByZWZpeC80NS4y MjcuMjU0LjAvMjQNCg0KSSBhbSBub3Qgc3VyZSBpbiB3aGF0IHdheSB5b3UgYXJlIHJlYWRpbmcg dGhlIGRhdGEsIHRoZSBpbmZvcm1hdGlvbiBkaXNwbGF5ZWQgaGVyZSBkb2Vzbid0IHdlaWdoIGlu IG9uIGxlZ2l0aW1hY3kuIEJvdGggd2Vic2l0ZXMgYXJlIGZyb250ZW5kcyB0byBwdWJsaWMgd2hv aXMgZGF0YSwgdGhleSBzaG93cyB0aGUgcHJlZml4IGlzIHN1YmFsbG9jYXRlZCB0byAnWHdpbiB1 bml2ZXJzYWwgbHRkJywgYnV0IHRoZSBvcmlnaW5hdGluZyBBU04gaXMgJ1ByaXZhdGUgTGF5ZXIg SU5DJy4NCg0KPiBBcyBJIHNlZSBzaW1pbGFyIGRpc2NyZXBhbmNpZXMgaW4gbWFueSBnbG9iYWwg bmV0d29ya3MgSSB3b3VsZCBsaWtlIHRvIA0KPiBhc2sgd2hvIHRvIHRydXN0ID8gSWYgUlBLSSBk YXRhIGlzIG5vdCB2YWxpZCB0aGVuIEkgdGhpbmsgd2UgaGF2ZSBhIA0KPiByZWFsIHByb2JsZW0u DQoNCkkgYW0gbm90IHN1cmUgaXQgaXMgYWJvdXQgdHJ1c3QuIEkgdHJ1c3QgdGhlIHN5c3RlbSB3 b3JrcyBhcyBkZXNpZ25lZCwgd2hpY2ggbWVhbnMgdGhlcmUgaXMgcG90ZW50aWFsIGZvciBodW1h biBlcnJvciBpbiB0aGUgUk9BIGNyZWF0aW9uIHByb2Nlc3MuIEluIHRoaXMgc2Vuc2UgSVJSLCBE TlNTRUMsIGFuZCBSUEtJIGhhdmUgc29tZSBzaW1pbGFyaXRpZXMgLSB0aGV5IGFsbCBwb3RlbnRp YWxseSBzZXQgYSB1c2VyIHVwIGZvciBmYWlsdXJlLg0KDQpPcGVyYXRvcnMgZGVwbG95aW5nIE9W IGhhdmUgdG8gdGhlIGJhbGFuY2Ugb2YgaW5jb252ZW5pZW5jZSBmb3IgZW50aXRpZXMgd2hvIG1p c2NvbmZpZ3VyZWQgdGhlaXIgUk9BIGFnYWluc3QgdGhlIGNvbnNlcXVlbmNlcyBvZiBhY2NlcHRp bmcgQkdQIG1pc2NvbmZpZ3VyYXRpb25zIG9yIGhpamFja3Mgb2YgcHJlZml4ZXMgd2hpY2ggY291 bGQndmUgYmVlbiBwcmV2ZW50ZWQgaGFkIFJPQXMgYmVlbiBob25vcmVkLg0KDQpBbiBvcGVyYXRv ciBzaG91bGQgbm90aWZ5IGl0cyBjdXN0b21lcnMgd2hvIGFyZSBhbm5vdW5jaW5nIFJQS0kgaW52 YWxpZHMgYmVmb3JlIGRlcGxveWluZyBPcmlnaW4gVmFsaWRhdGlvbiB3aXRoICdpbnZhbGlkID09 IHJlamVjdCcgcG9saWNpZXMgb24gdGhlIEVCR1AgZWRnZS4gVGhpcyB3YXkgdGhlIGFsZXJ0IG5v dGlmaWNhdGlvbiBhYm91dCB0aGUgUk9BIG1pc2NvbmZpZ3VyYXRpb24gZm9sbG93cyBjb250cmFj dHVhbGx5IGVzdGFibGlzaGVkIGludGVyLW9yZ2FuaXNhdGlvbiBjb21tdW5pY2F0aW9uIGNoYW5u ZWxzLiBTb21ldGltZXMgdGhhdCBtZWNoYW5pc20gd29ya3Mgd2VsbCENCg0KQW5vdGhlciB0aGVv cnkgaXMgdGhhdCBzb21lIChhIGxvdD8pIG9mIHRoZSBSUEtJIEludmFsaWRzIHRoYXQgZXhpc3Qg aW4gdGhlIGRlZmF1bHQtZnJlZSB6b25lIGluIGEgc3RlYWR5IHN0YXRlIGFyZSBub3QgcmVhbGx5 IGluIHVzZSwganVzdCAncGFya2VkJy4gRm9sayB3aXNkb20gc3VnZ2VzdHMgaWYgeW91IGRvbid0 IGFubm91bmNlIGFsbCB5b3VyIHByZWZpeGVzIGluIHRoZSBERlosIG1hbGljaW91cyBhY3RvcnMg dGVuZCB0byBub3RpY2UgYW5kIHN0YXJ0IHVzaW5nIHRoZSBzcGFjZSBpbiB5b3VyIHN0ZWFkLiBC ZWNhdXNlIG9mIHRoaXMgKGFuZCBvdGhlciByZWFzb25zKSB3ZSBjYW4ndCByZWFsbHkga25vdyB3 aGF0IElQIGFkZHJlc3Mgc3BhY2UgaXMgYWN0dWFsbHkgaW4gdXNlIG9yIG5vdC4NCg0KVHJhZmZp YyBzdHVkaWVzIGRvbmUgYnkgc29tZSBuZXR3b3JrIG9wZXJhdG9ycyBpbiB0aGUgbW9udGhzIHBy aW9yIHRvIGRlcGxveWluZyBSUEtJIE9WIGNvbW1vbmx5IHNob3cgdmVyeSBsaXR0bGUgb3Igbm8g dHJhZmZpYyBkZXN0aW5lZCBmb3IgUlBLSSBJbnZhbGlkcy4gSW4gdGhlc2Ugc3R1ZGllcyBpdCBp cyBpbXBvcnRhbnQgdG8gc2VwYXJhdGUgUlBLSSBpbnZhbGlkcyB0aGF0IGJlY29tZSAndW5yZWFj aGFibGUnLCBhbmQgdHJhZmZpYyBmb3IgSVBzIGNvdmVyZWQgYnkgUlBLSSBpbnZhbGlkcyB3aGlj aCBhcmUgY292ZXJlZCBieSBhIGxlc3Mgc3BlY2lmaWMgbm90LWZvdW5kL3ZhbGlkIGFubm91bmNl bWVudC4gaHR0cHM6Ly9tYWlsbWFuLm5hbm9nLm9yZy9waXBlcm1haWwvbmFub2cvMjAxOS1GZWJy dWFyeS8wOTk1MjIuaHRtbA0KDQpCYWNrIHRvIHRoZSBwcmVmaXggYXQgaGFuZCwgSSBiZWxpZXZl IHRoaXMgdG8gYmUgdGhlIHBhcnR5IGluIGNoYXJnZSBvZiB0aGUgUlBLSSBST0E6DQoNCiAgICAk IHdob2lzIDQ1LjIyNy4yNTIuMC8yMiB8IGdyZXAgQCB8IHNvcnQgLXUNCiAgICBlLW1haWw6ICAg ICAgbm9jQEZMWVNFUlZFUlMuQ09NDQoNCk9uZSBjb3VsZCByZWFjaCBvdXQgdG8gdGhlIG9wZXJh dG9yIGFuZCBhc2sgdGhlbT8NCg0KS2luZCByZWdhcmRzLA0KDQpKb2INCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkdST1cgbWFpbGluZyBsaXN0DQpH Uk9XQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dyb3cN Cg== From nobody Mon Apr 13 07:17:30 2020 Return-Path: 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 3E0FC3A168E for ; Mon, 13 Apr 2020 07:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 QH1x4qWKdgY8 for ; Mon, 13 Apr 2020 07:17:27 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2511F3A168D for ; Mon, 13 Apr 2020 07:17:27 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jNztp-0001EN-KJ; Mon, 13 Apr 2020 14:17:21 +0000 Date: Mon, 13 Apr 2020 07:17:21 -0700 Message-ID: From: Randy Bush To: Di Ma Cc: SIDR Operations WG In-Reply-To: References: <20B9DFE3-73E5-48D6-B8F0-7F401EBA9E19@rpstir.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] rpki rp frequency X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2020 14:17:28 -0000 >>> As often as necessary that the RP can synchronize with a repository. >> how often is 'necessary?' in units of time, please. > I think It is the ISP who defines what is necessary. what is reasonable for the good of routing in the internet? i suggest an hour. before notify, we tolerated dns propagation of a day, and it was very painful. that seems primitive and silly now. randy From nobody Mon Apr 13 07:25:50 2020 Return-Path: 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 45AE73A16BD for ; Mon, 13 Apr 2020 07:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 RFare2H4tMPj for ; Mon, 13 Apr 2020 07:25:48 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DA483A16B9 for ; Mon, 13 Apr 2020 07:25:48 -0700 (PDT) Received: from [10.0.0.129] (c-68-49-104-93.hsd1.mi.comcast.net [68.49.104.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 6F07954014E; Mon, 13 Apr 2020 10:25:46 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Jared Mauch In-Reply-To: Date: Mon, 13 Apr 2020 10:25:45 -0400 Cc: Di Ma , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <20B9DFE3-73E5-48D6-B8F0-7F401EBA9E19@rpstir.net> To: Randy Bush X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Sidrops] rpki rp frequency X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2020 14:25:49 -0000 > On Apr 13, 2020, at 10:17 AM, Randy Bush wrote: >=20 >>>> As often as necessary that the RP can synchronize with a = repository. >>> how often is 'necessary?' in units of time, please. >> I think It is the ISP who defines what is necessary. >=20 > what is reasonable for the good of routing in the internet? i suggest > an hour. >=20 > before notify, we tolerated dns propagation of a day, and it was very > painful. that seems primitive and silly now. Most of the IRRs are mirroring at an interval of 5 minutes or so these = days, or that was one of the last things I asked to be changed at 2914 = before I left to ensure regular sync. I think 300s is reasonable, but 3600 (60 min) is likely the high limit. - Jared= From nobody Mon Apr 13 09:08:24 2020 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 158653A18F2; Mon, 13 Apr 2020 09:08:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.126.0 Auto-Submitted: auto-generated Precedence: bulk Cc: warren@kumari.net, draft-ietf-sidrops-ov-egress@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, The IESG , keyur@arrcus.com, rfc-editor@rfc-editor.org, nathalie@ripe.net MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <158679409607.30125.4088793020886167439@ietfa.amsl.com> Date: Mon, 13 Apr 2020 09:08:16 -0700 Archived-At: Subject: [Sidrops] Protocol Action: 'BGP RPKI-Based Origin Validation on Export' to Proposed Standard (draft-ietf-sidrops-ov-egress-04.txt) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2020 16:08:16 -0000 The IESG has approved the following document: - 'BGP RPKI-Based Origin Validation on Export' (draft-ietf-sidrops-ov-egress-04.txt) as Proposed Standard This document is the product of the SIDR Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-egress/ Technical Summary This document highlights an important use case of origin validation in eBGP egress policies, explaining specifics of correct implementation in this context. As the origin AS may be modified by outbound policy, policy semantics based on RPKI Origin Validation state MUST be able to be applied separately on distribution into BGP and on egress. This document mandates BGP implementations supporting RPKI-based origin validation to provide the same policy configuration primitives on egress as they are available for ingress and route redistribution. Working Group Summary The document went through the review at WGLC to include comments/suggestions/ changes. The conversation in the WG mail-list and meetings was productive and the chairs believe this document is ready to progress. Document Quality The document is simple, clear and concise. There are no nits nor is the document controversial. Personnel Keyur Patel (keyur@arrcus.com) is Document Shepherd Warren Kumari (warren@kumari.net) is RAD! From nobody Mon Apr 13 09:13:42 2020 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 099633A18A0; Mon, 13 Apr 2020 09:13:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.126.0 Auto-Submitted: auto-generated Precedence: bulk Cc: rfc-editor@rfc-editor.org, sidrops@ietf.org, Nathalie Trenaman , nathalie@ripe.net, warren@kumari.net, draft-ietf-sidrops-rp@ietf.org, sidrops-chairs@ietf.org, The IESG MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <158679441002.6241.18284326768637712051@ietfa.amsl.com> Date: Mon, 13 Apr 2020 09:13:30 -0700 Archived-At: Subject: [Sidrops] Document Action: 'Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties' to Informational RFC (draft-ietf-sidrops-rp-06.txt) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2020 16:13:31 -0000 The IESG has approved the following document: - 'Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties' (draft-ietf-sidrops-rp-06.txt) as Informational RFC This document is the product of the SIDR Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/ Technical Summary This document provides a single reference point for requirements for Relying Party (RP) software for use in the Resource Public Key Infrastructure (RPKI) in the context of securing Internet routing. It cites requirements that appear in several RPKI RFCs, making it easier for implementers to become aware of these requirements that are segmented with orthogonal functionalities. Working Group Summary This document provides a single reference point for requirements for Relying Party (RP) software for use in the Resource Public Key Infrastructure (RPKI) in the context of securing Internet routing. It cites requirements that appear in several RPKI RFCs, making it easier for implementers to become aware of these requirements that are segmented with orthogonal functionalities. Document Quality Since the first version of the document, there has been support for this draft. The two points worth noting are the concern of the WG to keep the document current and the removal of normative language because of the type of draft (Informational). This has been addressed. Personnel Nathalie Trenaman (nathalie@ripe.net) is Document Shepherd (DS) Warren Kumari (warren@kumari.net) is Responsible Area Director (RAD!) From nobody Mon Apr 13 10:31:02 2020 Return-Path: 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 F41C53A1000 for ; Mon, 13 Apr 2020 10:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Op_jUH2kjWiH for ; Mon, 13 Apr 2020 10:30:59 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D16763A0FFE for ; Mon, 13 Apr 2020 10:30:59 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jO2vA-0001fz-B0; Mon, 13 Apr 2020 17:30:56 +0000 Date: Mon, 13 Apr 2020 10:30:55 -0700 Message-ID: From: Randy Bush To: Jared Mauch Cc: SIDR Operations WG , Di Ma In-Reply-To: References: <20B9DFE3-73E5-48D6-B8F0-7F401EBA9E19@rpstir.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] rpki rp frequency X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2020 17:31:01 -0000 >>>>> As often as necessary that the RP can synchronize with a repository. >>>> how often is 'necessary?' in units of time, please. >>> I think It is the ISP who defines what is necessary. >> what is reasonable for the good of routing in the internet? i suggest >> an hour. >> before notify, we tolerated dns propagation of a day, and it was very >> painful. that seems primitive and silly now. > Most of the IRRs are mirroring at an interval of 5 minutes or so these > days, or that was one of the last things I asked to be changed at 2914 > before I left to ensure regular sync. > I think 300s is reasonable, but 3600 (60 min) is likely the high limit. there are the questions of how frequently a CA publishes, how often an RP pulls, and how often routers pull from their RP(s). for CA publishing, a few seconds seems easily achieved with reasonable software. for RPs pulling, 600s may be optimistic in the short term given o the load it will put on publication services o and one notorious repo which is against spec but it should be achievable in a while. an hour would be the longest acceptable in my mind today. for the router(s) pulling from the RP(s), 300-3600s is a wide window. but remember, the rpki-rtr protocol does have the equivalent of dns notify, where the cache tells the router that it has some nice tasty new data. you're welcome :) i imagine that few here are old enough to remember when curtis only updated the backbone (there was only one) routing peering once a week on wednesday. if we want the internet to rely on this stuff, it's time to get into the 21st century. randy From nobody Tue Apr 14 01:54:31 2020 Return-Path: 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 1D21F3A0815 for ; Tue, 14 Apr 2020 01:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no 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 kl6Dz9rKsorN for ; Tue, 14 Apr 2020 01:54:26 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14D103A0814 for ; Tue, 14 Apr 2020 01:54:26 -0700 (PDT) Received: from allealle.ripe.net ([193.0.23.12]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jOHKp-0005TY-Nz; Tue, 14 Apr 2020 10:54:23 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::400]) by allealle.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.3) (envelope-from ) id 1jOHKp-0002tI-LP; Tue, 14 Apr 2020 10:54:23 +0200 To: Stephen Kent , "sidrops@ietf.org" References: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> From: Robert Kisteleki Autocrypt: addr=robert@ripe.net; prefer-encrypt=mutual; keydata= xsBNBEzFa6gBCADVASYXBbUF7v1D+Y9XR41SEEMiZUARlUWeP0NrFHZmRRGdR5nM/p6HguUd StIPRmdqMdyLDqBsV8XPVu6lvhcb4+ZFu/V1XFPVyPBH8U6iQ4PdGDeqFlBm3gxoDOGraGw8 bjojvASTz/Wk3ddLPm34Kb6oMI2MclC016UgrPgIj6A1Uu8qQeBDyWrk+OrWUPOUOKM7QhQg cpU4JwuaesthFvqdoPNQJi9QUfn94r14ZNDYmeJlchZiRHWO70Gwoy3ywfAM9Kyi1tx78Qc9 E5ZhGIw9qqlzqa6c6a0qhup2Zh/dhVBJ05jCDN7bUQT5tRiOV2icyX8Dsr4KaWYCsAOVABEB AAHNMVJvYmVydCBLaXN0ZWxla2kgKFJJUEUgTkNDIGtleSkgPHJvYmVydEByaXBlLm5ldD7C wHgEEwECACICGyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJWUwoeAAoJEC0ZXiKtTC3+ 04UH/jlvSR0esDGFSponUVawru+/QF61KdsNrdH6/Vs2buQvczW2Uh+S6Dic2vr2H0B1YrvL F2XpL2WJUHBUDLTA7dYTslvnHpyZrR8Sfb+h+wJ8OynxEC5wMKxfYNx2fMSk5EIU5mRjMaYg X/VkssDcoQAznNwVVYeqHYUJDMcrJhAYh44VHO208VwjPjHUDRlC+BoMGjHJnWDOAstlES8j 0r3adj2MqIHdDEjSdEx1+rbV0iZlgcDbYDex3qulOYlcZL+PJvGHzD6CkNBa8SbSN7cO0yqR OJ2sgobITOJ0GbRIbIvkUe1Iqw717CuQV/u822dFISDYOAhGYmfWGJWmkezOwE0ETMVrqAEI AKazZ2Agrv0nNFPWV69l6fEout/FaqWfyAG5V414l4yr+qVShUYzS+txA2vC+ouHvdORZ/JG xwKf6HE+YvvWS+Oa+b6h+GZfA3G43XGpQlxXrFK019TeMjhHqWprZALL4w2k6TatYT1ZW369 rORtwSgtn5ZC4uNcpZeDQddQvCjyYoknqlZqAFf1pssuGPTE8GvhrZGEp52dALYYoDIf7y/z 8fCAcy72rhMhQV02rPB49UxOEh2FZJhST0743tuMtFemBkp06B/Mcx54QT0muG8zj19oMDG3 AAaGjNP6B3qzR6F8VczR/qVhQzRvNMr8A6+y/ew/x4+48P+O/4n/I50AEQEAAcLAXwQYAQIA CQIbDAUCVlMKHgAKCRAtGV4irUwt/mvlB/sFID7mlsWAS66UyrI+tGs4Xfl59vvhRRZ4ZKiR 8VEbWbLKh/b9SoYcKt9SLEfVxJE5ebWPgIIvUSdLS6f4n9uAJteDZ4w/AVfp5a6jbfvMm7JP AMW4HtnZ3YbNevRgXdGVXN+bTLZzXoVijOKu+xHDBRNaUswaG3glrDJfUGkPQtCXFn6m6Pdw dW1/ShzwQgfuE/NXa83jhJ175P+NoQ2KG7934vu2MZdrtIqPibKuaGWMPG0L5YzPotK9ONmd taJMnuk92qqZ6S9JPwRZmogRW/sX54XvGg6RzNpdHS5C+iN01tCNJTRTlOJ1X73+RrGokvKc dp6fdfc4PHHhpcMd Organization: RIPE NCC Message-ID: Date: Tue, 14 Apr 2020 10:54:23 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ACL-Warn: Delaying message X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a2747488cda607317ef40b1c7532a06f3463 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2020 08:54:29 -0000 Hi Steve, >> If, at the previous run, the RP fetched the relevant (now missing >> object, then I see no reason to not use it again. Think of the previous >> run as an object a cache if you will: if you're looking for an object >> mentioned in the manifest, and you have it already (hash / name / etc. >> matches) then you can reuse it. > I probably should have said that an RP views an object as "missing" if > the the object is not present in the RP's cache and cannot be retrieved > from the relevant PP. Because RPs retrieve objects only if the objects > have changed (newly added or updated), an RP would not be aware that an > object is not present at a PP if the object is present in the RP's > cache. I recall a famous quote about whether an object that has not been > updated makes any noise when it is deleted from a PP, or something like > that :-) rsync has a flag (--delete) where it literally syncs, ie. not only fetches new/updated objects but also removes the local ones that no longer exist remotely. (Either this, or some other processes have to do cleanup, otherwise the local copy accumulates objects eternally.) I believe the NLnetLabs routinator and the NCC's RPKI validator use --delete with rsync. Maybe this behaviour changes if/when not using rsync, I'm not sure. >> Of course it can be useful to check if it still exists in the PP, but it >> seems to me the only benefit is to detect that it is missing from there >> and perhaps warn the PP operator. Otherwise the RP has a hard time >> arguing "no idea what this is since it's not there!". > I think I agree about the utility of detecting an object that has gone > missing from a PP, when the RP has the object locally cached. But, in my > experience, RP software was not designed to detect this case. I believe the discussion here is about specifying how RP software should (or must) behave, so that their behaviour is consistent. IMO in order to achieve that, the behaviour around missing objects should be part of the specification. Cheers, Robert From nobody Tue Apr 14 02:18:24 2020 Return-Path: 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 BFBD83A089D for ; Tue, 14 Apr 2020 02:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 A1bIYe32-eLY for ; Tue, 14 Apr 2020 02:18:21 -0700 (PDT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD7A3A0899 for ; Tue, 14 Apr 2020 02:18:20 -0700 (PDT) Received: (qmail 3174 invoked by uid 1000); 14 Apr 2020 09:18:18 -0000 Date: Tue, 14 Apr 2020 11:18:18 +0200 From: Claudio Jeker To: Robert Kisteleki Cc: Stephen Kent , "sidrops@ietf.org" Message-ID: <20200414091818.GF72650@diehard.n-r-g.com> References: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2020 09:18:23 -0000 On Tue, Apr 14, 2020 at 10:54:23AM +0200, Robert Kisteleki wrote: > Hi Steve, > > >> If, at the previous run, the RP fetched the relevant (now missing > >> object, then I see no reason to not use it again. Think of the previous > >> run as an object a cache if you will: if you're looking for an object > >> mentioned in the manifest, and you have it already (hash / name / etc. > >> matches) then you can reuse it. > > I probably should have said that an RP views an object as "missing" if > > the the object is not present in the RP's cache and cannot be retrieved > > from the relevant PP. Because RPs retrieve objects only if the objects > > have changed (newly added or updated), an RP would not be aware that an > > object is not present at a PP if the object is present in the RP's > > cache. I recall a famous quote about whether an object that has not been > > updated makes any noise when it is deleted from a PP, or something like > > that :-) > > rsync has a flag (--delete) where it literally syncs, ie. not only > fetches new/updated objects but also removes the local ones that no > longer exist remotely. (Either this, or some other processes have to do > cleanup, otherwise the local copy accumulates objects eternally.) > > I believe the NLnetLabs routinator and the NCC's RPKI validator use > --delete with rsync. Maybe this behaviour changes if/when not using > rsync, I'm not sure. > > >> Of course it can be useful to check if it still exists in the PP, but it > >> seems to me the only benefit is to detect that it is missing from there > >> and perhaps warn the PP operator. Otherwise the RP has a hard time > >> arguing "no idea what this is since it's not there!". > > I think I agree about the utility of detecting an object that has gone > > missing from a PP, when the RP has the object locally cached. But, in my > > experience, RP software was not designed to detect this case. > > I believe the discussion here is about specifying how RP software should > (or must) behave, so that their behaviour is consistent. IMO in order to > achieve that, the behaviour around missing objects should be part of the > specification. This should not only be about RP software but also the RPKI CA software and the operation of such software and repositories. If the CA software publishes only consistent repos the problem would be solved. Also the operators of rpki repositories should check their repos before publishing them as part of monitoring. If the CA software is sloppy then the RP software will always have a hard time to get consitent behaviour. It is the typical garbage in garbage out issue. -- :wq Claudio From nobody Tue Apr 14 10:45:58 2020 Return-Path: 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 A6ED73A0825 for ; Tue, 14 Apr 2020 10:45:56 -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_DNSWL_NONE=-0.0001, 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 uM4pPz3QrScQ for ; Tue, 14 Apr 2020 10:45:55 -0700 (PDT) Received: from sonic302-3.consmr.mail.bf2.yahoo.com (sonic302-3.consmr.mail.bf2.yahoo.com [74.6.135.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 435343A0829 for ; Tue, 14 Apr 2020 10:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1586886354; bh=jUuCYh905UUpDOnDDOSKAYsklEWukEl/VRxHy9W1NGo=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=M9QMiQNqjd/auAeWHxba97DVAap3jUoMm/4wkJKY4UYbwKcOUdK2BOrYLgvnV+INnXgpcHvSCB2D3QgDrQvcnoWkfjBUe04pM6VTOM4EObg/GeZy12J05KV/4+H8UFI1YyyoEiWARRZCagDGSJnil2nArvSmQz5B3Fv6hC/tPHUBFCe6Wxhc7vrmwmsbzkAQP2G68b2F2H/47SIjb4UzGN6h84w+vmu2KTppk8rxwNlAdL+lN5ZHdUx9oFyA/MdlufAhW5sIRTIJ1otQ+UhWE4ZtFqzVJ+68ejaLgUjyxtj54wpq86Q22NVq8swFiaMbHG5Qf0GRcDCz/OrsDgeAsQ== X-YMail-OSG: 7KV5xkQVM1k3ICRjEuizHPfFBwl5F107ZcdbSxoftHnd69ol24tA59bHJLLh325 5IbwtSuFWoc7B5F_wy.ZwNnnk_rzBwwOKCqF9mxmmMgMY2ONuE_wKsEOAAjJfMmdPi9BUrg75oip VsxdM3SnTfCUw649eoLVg4enQdO3QW24otQKzpnVi22BSsuvnp4XPAtZ7TtwI9Sozevw6j9IepM_ dnbwEZ9RDqHE.lAuC.CdtMk385xjE2_yntkKKD1mJHM8X1wuRw6hEB.J5PQf4VqDUNm0fm_caUOH 0fp__FckSIWMy0_1BCPDM56WY06OBmEA4YfwSGO1ugBk_WbD.vALLzdw0c00Jsjx37SgoUpczL4H vEKBI2gQxRZ.J6coiZJ..6RuzwNkh3boNcQZdFwsAPvS3uF8xi.rdBqmxzUmO3b0E_lqSWzsg_nl wVNxOoTTweoK0WzmtGJIegGq8Xjkz.ax07bpHB_vmU6c3Q82.sGo36CaIWpvYUnH.GP722BugrXL jFXlSEtJ1ON2ZFxM7fmJUcJm5XzbkNH.GqhkwJ2BSJC0amm8sfwOb78CcrpT.W.SBD56ZQYpM5XH Uk4MxzOygODxFg8ZL7QA8Hb5s23PX8l428cvrbTWF4gvmY3RqVGQ.Dxo17o0zbjt51kA2peCFTtl Xa_z4Jz7dCl6sSj5w3VxVhjSRaMZm_y3IBmGjENaXwwyWFPkOsLmnmOTRL1TB1o1PucYPeUSsDKy cXPQUWT2nqtHXcOgsm54CfAzosIzOsEKPo5tfyZzXyfoDQ3HPfjXOQ1UV4Yyb92JvoqLu_oqoGdB TOy55xm5vpkcrh4hHhGM4DpOUCQR0MW.Ne6BWlohBSpOVMbFJ7e_Sr0B4tCSDV50Bid_l6hMauJ_ JR84801WwW_5vzdJjr7xEUfM8DB7DQ9MEVdiwRjl0QvtgGFyhNqVGdADeEEdveLb5wEMfn7e6EwM kpTnC7bovDKWkg1pWf4CBOwhdA0wCF.Qw2maZNBej41Iui66OorOOgjsnh5oJswOYb_D8BpRlk4c L25VrJgZP2WZjykwtYZoJqR_IckR4c3RT.OgtbR0Ci395lyuEmINNe7aluVdAS8m0NSa6JZIOWYq ws9qFpTUN3aPsVqlWjyo4lKR5CU5NuXloKLb6PymzL5TwxmrcoRUlg.eGOxpjjUGgM87uoIRA0ra luEwiNP_6AonIUF5U3yY7Jri0XSoFU2SzCG7EETnFQUnqLyNpUVCEKKRU6ChF8QmxwhgmYTgpGOj w6.3eHEE8xYp3z7puDXHiywhbbUJrRZ7JE067Abn4oDOjFc3H3iziN2cpr95HNp3.vN3c2pZISST hGjkswZqYruk6ZifCMyOw5x477y_HqYPwX.vJGrFnWLEsQNO975J2uH8QEKRh0OrZc4CkMcA1P9Y .akpR19Fv2LDTVSefVajb28sJFkvB0enUMFlo_YHgHf7R4eObELOsWqvTayhrBPeun.v2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Tue, 14 Apr 2020 17:45:54 +0000 Received: by smtp427.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f78a07c9b3778e5e270e4d1c3a671c9d; Tue, 14 Apr 2020 17:45:51 +0000 (UTC) To: Robert Kisteleki , "sidrops@ietf.org" References: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> From: Stephen Kent Message-ID: Date: Tue, 14 Apr 2020 13:45:50 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.15651 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2020 17:45:57 -0000 Robert, > Hi Steve, > >>> If, at the previous run, the RP fetched the relevant (now missing >>> object, then I see no reason to not use it again. Think of the previous >>> run as an object a cache if you will: if you're looking for an object >>> mentioned in the manifest, and you have it already (hash / name / etc. >>> matches) then you can reuse it. >> I probably should have said that an RP views an object as "missing" if >> the the object is not present in the RP's cache and cannot be retrieved >> from the relevant PP. Because RPs retrieve objects only if the objects >> have changed (newly added or updated), an RP would not be aware that an >> object is not present at a PP if the object is present in the RP's >> cache. I recall a famous quote about whether an object that has not been >> updated makes any noise when it is deleted from a PP, or something like >> that :-) > rsync has a flag (--delete) where it literally syncs, ie. not only > fetches new/updated objects but also removes the local ones that no > longer exist remotely. (Either this, or some other processes have to do > cleanup, otherwise the local copy accumulates objects eternally.) I forgot about the --delete flag. But, if one chooses to make use of the flag, it requires caution. if an attacker deleted files and an RP removed instances of those files from the local cache, this is an easy DoS attack. One would have to see if there is a current manifest and if it lists files that have been deleted from the PP. Only if there is a current manifest, and the deleted files are also not present in the manifest, would it be safe to delete those files. If one relies on examination of a current manifest to trigger deletion of cached files this problem would be avoided, and thus those files would not accumulate forever. maybe that's why I was not thinking about the flag. > > I believe the NLnetLabs routinator and the NCC's RPKI validator use > --delete with rsync. Maybe this behaviour changes if/when not using > rsync, I'm not sure. > >>> Of course it can be useful to check if it still exists in the PP, but it >>> seems to me the only benefit is to detect that it is missing from there >>> and perhaps warn the PP operator. Otherwise the RP has a hard time >>> arguing "no idea what this is since it's not there!". >> I think I agree about the utility of detecting an object that has gone >> missing from a PP, when the RP has the object locally cached. But, in my >> experience, RP software was not designed to detect this case. > I believe the discussion here is about specifying how RP software should > (or must) behave, so that their behaviour is consistent. IMO in order to > achieve that, the behaviour around missing objects should be part of the > specification. Agreed. Steve From nobody Wed Apr 15 03:37:54 2020 Return-Path: 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 9FB723A0A8C for ; Wed, 15 Apr 2020 03:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 A09eHxVe4g4w for ; Wed, 15 Apr 2020 03:37:51 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88AD63A0A8E for ; Wed, 15 Apr 2020 03:37:51 -0700 (PDT) Received: from bufobufo.ripe.net ([193.0.23.13]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jOfQS-0002hk-Sb; Wed, 15 Apr 2020 12:37:48 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::68e]) by bufobufo.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.3) (envelope-from ) id 1jOfQS-0006Rm-Q1; Wed, 15 Apr 2020 12:37:48 +0200 To: Stephen Kent , "sidrops@ietf.org" References: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> From: Robert Kisteleki Autocrypt: addr=robert@ripe.net; prefer-encrypt=mutual; keydata= xsBNBEzFa6gBCADVASYXBbUF7v1D+Y9XR41SEEMiZUARlUWeP0NrFHZmRRGdR5nM/p6HguUd StIPRmdqMdyLDqBsV8XPVu6lvhcb4+ZFu/V1XFPVyPBH8U6iQ4PdGDeqFlBm3gxoDOGraGw8 bjojvASTz/Wk3ddLPm34Kb6oMI2MclC016UgrPgIj6A1Uu8qQeBDyWrk+OrWUPOUOKM7QhQg cpU4JwuaesthFvqdoPNQJi9QUfn94r14ZNDYmeJlchZiRHWO70Gwoy3ywfAM9Kyi1tx78Qc9 E5ZhGIw9qqlzqa6c6a0qhup2Zh/dhVBJ05jCDN7bUQT5tRiOV2icyX8Dsr4KaWYCsAOVABEB AAHNMVJvYmVydCBLaXN0ZWxla2kgKFJJUEUgTkNDIGtleSkgPHJvYmVydEByaXBlLm5ldD7C wHgEEwECACICGyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJWUwoeAAoJEC0ZXiKtTC3+ 04UH/jlvSR0esDGFSponUVawru+/QF61KdsNrdH6/Vs2buQvczW2Uh+S6Dic2vr2H0B1YrvL F2XpL2WJUHBUDLTA7dYTslvnHpyZrR8Sfb+h+wJ8OynxEC5wMKxfYNx2fMSk5EIU5mRjMaYg X/VkssDcoQAznNwVVYeqHYUJDMcrJhAYh44VHO208VwjPjHUDRlC+BoMGjHJnWDOAstlES8j 0r3adj2MqIHdDEjSdEx1+rbV0iZlgcDbYDex3qulOYlcZL+PJvGHzD6CkNBa8SbSN7cO0yqR OJ2sgobITOJ0GbRIbIvkUe1Iqw717CuQV/u822dFISDYOAhGYmfWGJWmkezOwE0ETMVrqAEI AKazZ2Agrv0nNFPWV69l6fEout/FaqWfyAG5V414l4yr+qVShUYzS+txA2vC+ouHvdORZ/JG xwKf6HE+YvvWS+Oa+b6h+GZfA3G43XGpQlxXrFK019TeMjhHqWprZALL4w2k6TatYT1ZW369 rORtwSgtn5ZC4uNcpZeDQddQvCjyYoknqlZqAFf1pssuGPTE8GvhrZGEp52dALYYoDIf7y/z 8fCAcy72rhMhQV02rPB49UxOEh2FZJhST0743tuMtFemBkp06B/Mcx54QT0muG8zj19oMDG3 AAaGjNP6B3qzR6F8VczR/qVhQzRvNMr8A6+y/ew/x4+48P+O/4n/I50AEQEAAcLAXwQYAQIA CQIbDAUCVlMKHgAKCRAtGV4irUwt/mvlB/sFID7mlsWAS66UyrI+tGs4Xfl59vvhRRZ4ZKiR 8VEbWbLKh/b9SoYcKt9SLEfVxJE5ebWPgIIvUSdLS6f4n9uAJteDZ4w/AVfp5a6jbfvMm7JP AMW4HtnZ3YbNevRgXdGVXN+bTLZzXoVijOKu+xHDBRNaUswaG3glrDJfUGkPQtCXFn6m6Pdw dW1/ShzwQgfuE/NXa83jhJ175P+NoQ2KG7934vu2MZdrtIqPibKuaGWMPG0L5YzPotK9ONmd taJMnuk92qqZ6S9JPwRZmogRW/sX54XvGg6RzNpdHS5C+iN01tCNJTRTlOJ1X73+RrGokvKc dp6fdfc4PHHhpcMd Organization: RIPE NCC Message-ID: <1f788965-aa0e-665d-0a3e-f1196b1c39c3@ripe.net> Date: Wed, 15 Apr 2020 12:37:48 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-ACL-Warn: Delaying message X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a27483c7a220f53e2c02bf4e712037293aeb Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 10:37:53 -0000 Hi, >>> I probably should have said that an RP views an object as "missing" if >>> the the object is not present in the RP's cache and cannot be retrieved >>> from the relevant PP. Because RPs retrieve objects only if the objects >>> have changed (newly added or updated), an RP would not be aware that an >>> object is not present at a PP if the object is present in the RP's >>> cache. I recall a famous quote about whether an object that has not been >>> updated makes any noise when it is deleted from a PP, or something like >>> that :-) >> rsync has a flag (--delete) where it literally syncs, ie. not only >> fetches new/updated objects but also removes the local ones that no >> longer exist remotely. (Either this, or some other processes have to do >> cleanup, otherwise the local copy accumulates objects eternally.) > > I forgot about the --delete flag. But, if one chooses to make use of the > flag, it requires caution. if an attacker deleted files and an RP > removed instances of those files from the local cache, this is an easy > DoS attack. One would have to see if there is a current manifest and if > it lists files that have been deleted from the PP. Only if there is a > current manifest, and the deleted files are also not present in the > manifest, would it be safe to delete those files. I agree. However, that's not the practice today. Which is why I latched on to your proposal and I'm trying to highlight that we should cover this. Cheers, Robert From nobody Wed Apr 15 03:46:17 2020 Return-Path: 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 973C03A0AB9 for ; Wed, 15 Apr 2020 03:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no 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 039mriQ1xA3a for ; Wed, 15 Apr 2020 03:46:14 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB9E03A0AB8 for ; Wed, 15 Apr 2020 03:46:13 -0700 (PDT) Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 7F5431B198; Wed, 15 Apr 2020 12:46:11 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Wed, 15 Apr 2020 12:46:10 +0200 From: Martin Hoffmann To: Stephen Kent Cc: Robert Kisteleki , "sidrops@ietf.org" Message-ID: <20200415124611.7af291b1@glaurung.nlnetlabs.nl> In-Reply-To: References: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 10:46:16 -0000 Stephen Kent wrote: > > > rsync has a flag (--delete) where it literally syncs, ie. not only > > fetches new/updated objects but also removes the local ones that no > > longer exist remotely. (Either this, or some other processes have > > to do cleanup, otherwise the local copy accumulates objects > > eternally.) > > I forgot about the --delete flag. But, if one chooses to make use of > the flag, it requires caution. if an attacker deleted files and an RP > removed instances of those files from the local cache, this is an > easy DoS attack. One would have to see if there is a current manifest > and if it lists files that have been deleted from the PP. Only if > there is a current manifest, and the deleted files are also not > present in the manifest, would it be safe to delete those files. > > If one relies on examination of a current manifest to trigger > deletion of cached files this problem would be avoided, and thus > those files would not accumulate forever. maybe that's why I was not > thinking about the flag. An attacker who can delete files can as easily replace them with something else with the same result. So I am not sure the added code complexity is worth it. Kind regards, Martin From nobody Wed Apr 15 03:51:03 2020 Return-Path: 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 3FC643A0AD4 for ; Wed, 15 Apr 2020 03:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 KLD88UGj1OB7 for ; Wed, 15 Apr 2020 03:51:00 -0700 (PDT) Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [IPv6:2001:418:3ff:110::40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D514B3A0AD7 for ; Wed, 15 Apr 2020 03:51:00 -0700 (PDT) Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id BFEDE22011F for ; Wed, 15 Apr 2020 10:50:59 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id E110C27C0054 for ; Wed, 15 Apr 2020 06:50:52 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute3.internal (MEProxy); Wed, 15 Apr 2020 06:50:52 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrfeefgddvvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdflohgsucfunhhijhguvghrshdfuceojhhosgesnhhtthdr nhgvtheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epjhhosgdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidquddtgeejleduheek gedqvdeffeefkeefvddtqdhjohgspeepnhhtthdrnhgvthesshhosghorhhnohhsthdrnh gvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 443A5C200A4; Wed, 15 Apr 2020 06:50:52 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1131-g3221b37-fmstable-20200415v1 Mime-Version: 1.0 Message-Id: <974eeeaa-32e6-45b2-860f-6b1408ae14e6@www.fastmail.com> In-Reply-To: <20200415124611.7af291b1@glaurung.nlnetlabs.nl> References: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> <20200415124611.7af291b1@glaurung.nlnetlabs.nl> Date: Wed, 15 Apr 2020 12:50:32 +0200 From: "Job Snijders" To: sidrops@ietf.org Content-Type: text/plain Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 10:51:02 -0000 On Wed, Apr 15, 2020, at 12:46, Martin Hoffmann wrote: > An attacker who can delete files can as easily replace them with > something else with the same result. So I am not sure the added code > complexity is worth it. Agreed. fwiw: rpki-client runs as "openrsync -rlt --delete rsync://xxx/repository xxx/repository" Kind regards, Job From nobody Wed Apr 15 04:58:43 2020 Return-Path: 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 84CAF3A0D4E for ; Wed, 15 Apr 2020 04:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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=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 aOMu2o2SlMdE for ; Wed, 15 Apr 2020 04:58:40 -0700 (PDT) Received: from sonic314-13.consmr.mail.bf2.yahoo.com (sonic314-13.consmr.mail.bf2.yahoo.com [74.6.132.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 91D163A0D4D for ; Wed, 15 Apr 2020 04:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1586951918; bh=akTHaR19gSIfoZa7af9CRElc4eVXAiPcCxWpc9praI4=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=TBK885EcjOMbcrCIt7zKmOE2XUEVnxgiLzqyZDomXRDQG1bOr2lmDZE1kIlxqgGMN/xeCiyRK05rRvHKIJMgWTDF6ducVn7CXnJXYItiQNvMm5pJLjAVSRNrVFmqe9gC6QByi9ez0fWgzHiJDSbaaR6v+9R0ZRxmNxNdz6d967ZltxkpiiC4daPRK1nrflxLq7BN/t1PYI9AhE0lzOz1OiYsSrYm4S3kfoTfu76Vvsg5zQ+bRmmwHjFkpyOBsOZAX8eOizZdxj3/+xIoqXERK/GPSDiAK+j9PkVOpJVpKaBbJ76Pn+e074PMFit0CKG/DMB/NLUH8cR11LWCCEPKQA== X-YMail-OSG: nS5ITswVM1ldZKw61LZzq1fhjgloZRJd6o8lL1N7ohujXVZq7nXZO2x5AX4v78A t2YF5hSJgdVE_KgPBC.dBFkCifRfYIXMtYlmgoAs51zS0WfI9fY4Tk8uZ4ztNO10MisdYNz3YGYU 9ybTVdzHy_8pcYOdAakSdVYjfo51yLk7Ny6b_i36JUCfADBNuY4dg492yKszy3R0RHPTnjT1w73R FjjFNQS25nmEPwvx_6vlPadgnuA_WcDH9H3BEFFMYEb5cqqGn4Ing752nTBlfZP8Vy2q.3U.L0.O Eru1U5_RZIkjCHeX2c8qoeAl8WQ3LaVafMNEauGFY10YFMp1FVzi0VgUxuMA4JsO3rRBL_26DEvj FseGUmdW.dQTMLUb2lj1dmaWrOLoJrTExeyAfKStyjUNz.mXW3CjIZWUAPTYhMICYZNUMEgNseGN lIwj682WBXRxfRCmxOHgeMxM5WZBEnkG1vVb5NiT4TXxwLiadh0b6jvKOae.m1fCbDc_LYVYCjjQ vEo.EUiXnO0nFzblbldKP5wBIsPOSYd4M_.pd6I5p2QFqvEkL7YCPnK8wTdIENYPqTZcSzFwe.EF S0ayidayWkqrCM3fRYMx3zn0VkwDHOXtcQDC_QYpDk3cR3mthW8oQoSv7WW6nry3lQlL0E2RylrJ miwMfxqrGjx29Mlof3Hjr3zkGpBtFxckBmvKycub9HAJs93yoiD6ESkuWMwzH8eCXYp764ZSZNcq VafZdoM.p.RHjTgTc9ZRUBHFpehnsaZyCSzGWL.u2wM3BC5x.UhFCA8yo7657qtgRnrRNJYhdj8B _nZkoPyabnXmHVG4q6CxvVyV8fFC5tjzdCcvYK6IMj9ndCZp4dNRJ06hfE2Gs5E6AkQqwEYBtH57 MiVGyGQ3DuQHAph4Afl6gYAM0gi_20zwaEptp.xZE_QEv8Z5xrAngFKsaLxVysDIB3gSihBz7HSU tlKSDjGo6a8otl_yOeqzo7KpZTRzZZoJyiq9GE4N.goRw1wCmTw3s8u1pfImRmnDeYTIIrV9KkMa tnjfpThA77TFEEtgnEpigFR_kSkaA7UwSNj_LE8MRRs_UPF1lQI2G8tHbBNkQp_U5LVJoqS7viOv u3Vhg4uisSWyBmnedBZ9O1GbCynzi81QDU12M5akLAbdGhIHcLY0X2tYhc8iHc7JNDGAy._vzNTY fZpq1rJYUpFj4ztnWhs8gjqA.LvQvczQY.fq7_98z6otGTn3G1ILAE07DNIUv06LIGVCZKSusl2e Rmiu.2zsN3PqkNdVk2b72B5cbOxilzM4VxAV7rgIsoODeHectfzaxryu8k6gxELBE98TvbjFzbdi sXrWyELGvl_wo_BzK5qfnOOnPhUWE8gTF7QvD4M8v9ybHt10g4hN95K_rCsn1EZjB_LXuMZWqywJ nGbGU1XXUXooQZJf7LKD6BpVZWT6gjm3moFUM8uvTDNQ- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Wed, 15 Apr 2020 11:58:38 +0000 Received: by smtp411.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b72d69f1bcb39560ce1ce72327f8e52c; Wed, 15 Apr 2020 11:58:33 +0000 (UTC) To: Robert Kisteleki , "sidrops@ietf.org" References: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> <1f788965-aa0e-665d-0a3e-f1196b1c39c3@ripe.net> From: Stephen Kent Message-ID: <9688fef0-7f3f-479d-b8a0-2095ac0fe3a2@verizon.net> Date: Wed, 15 Apr 2020 07:58:32 -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: <1f788965-aa0e-665d-0a3e-f1196b1c39c3@ripe.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.15651 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 11:58:42 -0000 Robert, > ... > I agree. However, that's not the practice today. Which is why I latched > on to your proposal and I'm trying to highlight that we should cover this. > > Cheers, > Robert We should ask Di Ma if RPSTIR-2 still follows the design approach I cited. Steve From nobody Wed Apr 15 04:58:55 2020 Return-Path: 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 A5F8F3A0DA2 for ; Wed, 15 Apr 2020 04:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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=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 dvqjWd8YCQK2 for ; Wed, 15 Apr 2020 04:58:46 -0700 (PDT) Received: from sonic301-2.consmr.mail.bf2.yahoo.com (sonic301-2.consmr.mail.bf2.yahoo.com [74.6.129.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 6059E3A0D93 for ; Wed, 15 Apr 2020 04:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1586951925; bh=3qI9XHjqvmVcNpvVdSo2hcsVyflbOS/maKvcMnb7nVE=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From:Subject; b=JwlyUBCmUO1SiMdevZ2MkEYlf1IXyHggEIRy+4AhONLMamOrKXu2xdr5q87lbYmAPcH3nA3rC5MrRpBTLpq8XEXrPpt8otpWd34XvDorcINP/gowehGF6nu0lVWjMzPFECLaMvF1fYxSvgA3+WOK29/F9uL5Yo7drFZ3o5h6iCvdfxattBHyRpEJvRdxwo2rD3iTTa+CguClzNxtPmJXxJAo0Rq4er/dGI5DV91LTFfmUUCytjaM4fv5E8sbS1cfBLIz6zenoQwFbiPGwYB7uVbQqH37n+tOjuvNHzFZMzc/8DctPxTvtYWZsQXa+Jlom0bbu0C346cecWwbR3vcig== X-YMail-OSG: Kp8nc34VM1nIoqDT9sjkFmGMgmNsFRkd5bf1fKqFssOwFEndNGR_w_O8XdyAYiu uEZcW8p81xA3p69S8Cw9TitnYE.69Khfhd8cLlObnNxbk2oZS8OcjC_o96NOSb1mOKuffJRa4QbK dl..8GvAPrmuwy9eGZJSpfu3uTNVOumnQ0FONzuNv3PgRoIjlgrD_V7cHjpba_n3vkxHW6mBAP80 DfxXyKejKEsNl1tYe8fkitEz5Tz4Thdgv9UTzZe2YHshZZARUk2_6CNJ3PJ2c5VPJfU.wlBgMLEC ZsTP1LuKtbGALGXkyzTmnfWTjqLIkvTGASggIcQrMzS10pdNekyAOt8G8vd5ZV95FBpTQOKJVu8G LPtFcQb2mG8xfcUPtnz1WE93r0TAI3vtLwv4Fvs2g7Im2QUl3Claep0X54KILfnNFqwubuYnPrn7 XnNc4NqmiHBbPrF05tfcpFvWgwzrukaXZ3aFU3z.jGk4uDcK9Ai9LhysKnQadvITXUeWHsJNDYkU ozDsz6VVIjEuA9kLIY8v88eI0v4qxyALhzcCUjpMeTrpZ3aG8RE_fUG.OG7VsllzEN9mnVZuVHNQ .FH2jTLRWlMIRUd9YbB_VFyl5l.cE5hvAYxHWfdsYy48gvvucCzd5Y_.PQbWXZCePEMnHyDXSVfu ONmOhLJgGCKI1Ohr2FKcbXhH0GnMnolmtgqIpDL2OsPgQhWZponlyjtkt5cIqMjZtQ5yFIUZ96uO k7F4akIeRYv883tz4tROxr4HckoYAyV5DOz.GTIHsg7T3pFzhQhMSTiaaobcurH56QdCp8fTmuAt BFwiEOlrszy_jL0M6KOdtM9jqXP_tQDauTgzFxAb2ywZTKm1B_wwVLrjSs3Fzfe9rseDqMb06.QF srepN11z6SlcNu_aPc0kCrn61.jVN25LMcdw1Bq8ZUHhwZtV.09UFt.3AJ7RtpGimhvtp4xr_hGO iskG8vERu5vpXvEZbJdx3fCjof.DR0ZwFmF07_bZnmiBxMHC8CS_ufBklSZwABrVsilIv6JAot.E RlIedH1TXpXe_W.0RGA2Octxs0vpEp0mis_TQLpXDJg94pSG9hVUyRoQRIZ_vGOMxxhXdZvUHyhu JJfUxo6N3wj198mwRlX74XwYxNDwwXf0t7z9phUVHsqv8dk6xx8SSgWkY_FMHXv_yA_NPaazNysy SEXMsj7k5aSuYuPTQuNS0al1xhf6ZDEjsh9ypV1Dx.OPtwqe1fCjNCwqgvJWH95canaRqbOGNOOv Zk.vQ7jVEca0_6IVeJbnhwdgxdhLBCxCc3dPlLGTThiG5st..m2lrYz1tqaiV_OcMjVeaIuU9zpt k.yPc6w1yul4esticJZ0lObglCSlDSjzQZu.jn2ZPpeESl6On82KkG.GS6mUdDXObt8fk8jxEX7k ZdOCP8RxR96_ajMkqKr3l7NJiGpdQYHHA73TMSg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Wed, 15 Apr 2020 11:58:45 +0000 Received: by smtp414.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4c7651a8d6af5efaa3f3b62c16fb5663; Wed, 15 Apr 2020 11:58:39 +0000 (UTC) From: Stephen Kent To: Martin Hoffmann Cc: Robert Kisteleki , "sidrops@ietf.org" References: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> <20200415124611.7af291b1@glaurung.nlnetlabs.nl> Message-ID: Date: Wed, 15 Apr 2020 07:58:39 -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: <20200415124611.7af291b1@glaurung.nlnetlabs.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.15651 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 11:58:49 -0000 Martin, > ... > An attacker who can delete files can as easily replace them with > something else with the same result. So I am not sure the added code > complexity is worth it. If an attacker deletes files and replaces them with older versions or completely different files, and there is a current manifest, then the effect is nil, i.e., the older versions or different files will be ignored. If there is not a current manifest, then we are precisely in the territory that we all agree needs to be explored. Steve From nobody Wed Apr 15 04:58:58 2020 Return-Path: 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 C9CD13A0DA4 for ; Wed, 15 Apr 2020 04:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 J7iogSnnYoc9 for ; Wed, 15 Apr 2020 04:58:47 -0700 (PDT) Received: from sonic301-2.consmr.mail.bf2.yahoo.com (sonic301-2.consmr.mail.bf2.yahoo.com [74.6.129.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 0CB673A0D9D for ; Wed, 15 Apr 2020 04:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1586951925; bh=3qI9XHjqvmVcNpvVdSo2hcsVyflbOS/maKvcMnb7nVE=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From:Subject; b=JwlyUBCmUO1SiMdevZ2MkEYlf1IXyHggEIRy+4AhONLMamOrKXu2xdr5q87lbYmAPcH3nA3rC5MrRpBTLpq8XEXrPpt8otpWd34XvDorcINP/gowehGF6nu0lVWjMzPFECLaMvF1fYxSvgA3+WOK29/F9uL5Yo7drFZ3o5h6iCvdfxattBHyRpEJvRdxwo2rD3iTTa+CguClzNxtPmJXxJAo0Rq4er/dGI5DV91LTFfmUUCytjaM4fv5E8sbS1cfBLIz6zenoQwFbiPGwYB7uVbQqH37n+tOjuvNHzFZMzc/8DctPxTvtYWZsQXa+Jlom0bbu0C346cecWwbR3vcig== X-YMail-OSG: Kp8nc34VM1nIoqDT9sjkFmGMgmNsFRkd5bf1fKqFssOwFEndNGR_w_O8XdyAYiu uEZcW8p81xA3p69S8Cw9TitnYE.69Khfhd8cLlObnNxbk2oZS8OcjC_o96NOSb1mOKuffJRa4QbK dl..8GvAPrmuwy9eGZJSpfu3uTNVOumnQ0FONzuNv3PgRoIjlgrD_V7cHjpba_n3vkxHW6mBAP80 DfxXyKejKEsNl1tYe8fkitEz5Tz4Thdgv9UTzZe2YHshZZARUk2_6CNJ3PJ2c5VPJfU.wlBgMLEC ZsTP1LuKtbGALGXkyzTmnfWTjqLIkvTGASggIcQrMzS10pdNekyAOt8G8vd5ZV95FBpTQOKJVu8G LPtFcQb2mG8xfcUPtnz1WE93r0TAI3vtLwv4Fvs2g7Im2QUl3Claep0X54KILfnNFqwubuYnPrn7 XnNc4NqmiHBbPrF05tfcpFvWgwzrukaXZ3aFU3z.jGk4uDcK9Ai9LhysKnQadvITXUeWHsJNDYkU ozDsz6VVIjEuA9kLIY8v88eI0v4qxyALhzcCUjpMeTrpZ3aG8RE_fUG.OG7VsllzEN9mnVZuVHNQ .FH2jTLRWlMIRUd9YbB_VFyl5l.cE5hvAYxHWfdsYy48gvvucCzd5Y_.PQbWXZCePEMnHyDXSVfu ONmOhLJgGCKI1Ohr2FKcbXhH0GnMnolmtgqIpDL2OsPgQhWZponlyjtkt5cIqMjZtQ5yFIUZ96uO k7F4akIeRYv883tz4tROxr4HckoYAyV5DOz.GTIHsg7T3pFzhQhMSTiaaobcurH56QdCp8fTmuAt BFwiEOlrszy_jL0M6KOdtM9jqXP_tQDauTgzFxAb2ywZTKm1B_wwVLrjSs3Fzfe9rseDqMb06.QF srepN11z6SlcNu_aPc0kCrn61.jVN25LMcdw1Bq8ZUHhwZtV.09UFt.3AJ7RtpGimhvtp4xr_hGO iskG8vERu5vpXvEZbJdx3fCjof.DR0ZwFmF07_bZnmiBxMHC8CS_ufBklSZwABrVsilIv6JAot.E RlIedH1TXpXe_W.0RGA2Octxs0vpEp0mis_TQLpXDJg94pSG9hVUyRoQRIZ_vGOMxxhXdZvUHyhu JJfUxo6N3wj198mwRlX74XwYxNDwwXf0t7z9phUVHsqv8dk6xx8SSgWkY_FMHXv_yA_NPaazNysy SEXMsj7k5aSuYuPTQuNS0al1xhf6ZDEjsh9ypV1Dx.OPtwqe1fCjNCwqgvJWH95canaRqbOGNOOv Zk.vQ7jVEca0_6IVeJbnhwdgxdhLBCxCc3dPlLGTThiG5st..m2lrYz1tqaiV_OcMjVeaIuU9zpt k.yPc6w1yul4esticJZ0lObglCSlDSjzQZu.jn2ZPpeESl6On82KkG.GS6mUdDXObt8fk8jxEX7k ZdOCP8RxR96_ajMkqKr3l7NJiGpdQYHHA73TMSg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Wed, 15 Apr 2020 11:58:45 +0000 Received: by smtp414.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4c7651a8d6af5efaa3f3b62c16fb5663; Wed, 15 Apr 2020 11:58:39 +0000 (UTC) From: Stephen Kent To: Martin Hoffmann Cc: Robert Kisteleki , "sidrops@ietf.org" References: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> <20200415124611.7af291b1@glaurung.nlnetlabs.nl> Message-ID: Date: Wed, 15 Apr 2020 07:58:39 -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: <20200415124611.7af291b1@glaurung.nlnetlabs.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.15651 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 11:58:49 -0000 Martin, > ... > An attacker who can delete files can as easily replace them with > something else with the same result. So I am not sure the added code > complexity is worth it. If an attacker deletes files and replaces them with older versions or completely different files, and there is a current manifest, then the effect is nil, i.e., the older versions or different files will be ignored. If there is not a current manifest, then we are precisely in the territory that we all agree needs to be explored. Steve From nobody Wed Apr 15 06:01:48 2020 Return-Path: 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 693A33A00C0 for ; Wed, 15 Apr 2020 06:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no 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 mCGyWWYUY2Ps for ; Wed, 15 Apr 2020 06:01:45 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FD7E3A0063 for ; Wed, 15 Apr 2020 06:01:44 -0700 (PDT) Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id C07181B662; Wed, 15 Apr 2020 15:01:41 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Wed, 15 Apr 2020 15:01:41 +0200 From: Martin Hoffmann To: Stephen Kent Cc: "sidrops@ietf.org" Message-ID: <20200415150141.016d021d@glaurung.nlnetlabs.nl> In-Reply-To: References: Organization: Open Netlabs X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 13:01:46 -0000 Stephen Kent wrote: > *Overview * >=20 [...] >=20 > *Terminology* > > Missing: an object named in a Manifest, but not available for > download from a PP, is termed *missing*. An RP has no obvious way to > acquire missing objects, but operators SHOULD be warned about which > objects are missing. Since "missing" seems to be the opposite of the "present" in the case overview below, I think we need to more precisely define the meaning for both manifests and CRLs. I would define the meaning of "manifest missing": the manifest referenced in the CA certificate is not available for download from a PP. That leads to the case where there is a valid manifest at the PP but it is not the one on the CA certificate. "CRL missing" is a little more complicated, since there is two places where CRLs are referenced: in the manifest and in the EE certificates of signed objects. So we also have the case where a CRL in an EE certificate isn=E2=80=99t actually mentioned in the manifest. > *Case analysis* [...]=20 >=20 > Below is a proposed outline for the cases. The group needs to decide=20 > what action is to be taken in each case. To get that discussion started, here=E2=80=99s my proposals for these cases= (in line with what I argued earlier). > 1.Manifest present, valid, current If there is a present, valid, and current manifest, the CRL can safely be ignored for all objects. In order to avoid using partial sets of information, the entire content of the PP is ignored if any object is missing, corrupted, or invalid. Presumably this chould only be limited to objects of the same type, i.e., if there is a least one missing, corrupted, or invalid ROA, discard all ROAs. If the aim is to avoid risking accidentally marking routes as invalid, this should probably also extend to all information published by child CAs. > 2.Manifest present, valid, stale Not sure about this one. Naively I would say "use as above but warn." There=E2=80=99s also an option to distinguish based on the transport protoc= ol used for synchronizing the PP: ignore if rsync is used, use but warn if RRDP is used. > 3.Manifest present, but invalid The entire PP is ignored. > 4.Manifest not present The entire PP is ignored. This essentially ignores the CRL for any object published within the repository and essentially moves its role over to the manifest. The CRL would still be considered for objects published outside the repository, such as the proposed Resource Tagged Assertions. Kind regards, Martin From nobody Wed Apr 15 06:42:39 2020 Return-Path: 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 D59133A07E3 for ; Wed, 15 Apr 2020 06:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 IVfCrWg8fynh for ; Wed, 15 Apr 2020 06:42:31 -0700 (PDT) Received: from smtpbguseast2.qq.com (smtpbguseast2.qq.com [54.204.34.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 518FE3A07E1 for ; Wed, 15 Apr 2020 06:42:29 -0700 (PDT) X-QQ-mid: bizesmtp17t1586958144tkunyks7 Received: from [192.168.3.24] (unknown [118.198.181.5]) by esmtp6.qq.com (ESMTP) with id ; Wed, 15 Apr 2020 21:42:22 +0800 (CST) X-QQ-SSF: 00400000002000N0ZI80000A0000000 X-QQ-FEAT: eEBym+G8tbZVnYGU3H3FCvZ41OPZQ+vSdFx0n1f35ygfLCAcj0uDVZb3tc8YJ stlCAKPJbAyfBlx21H4hroLgfzh7LxgFI7gwD/CNdy89lwN625G0w37f9hCjg/XCI9ha69c rthiGdaAoeMBp11LJpnsimOQyrgtizfgrQtPbt2mJ7UOGVy0PzWvidfIt5FwtMRH2cCcR5q CnrqJuLp88u+AsI4J0toKJuwYp6MZnxY/fUAw90ETQi0JYCoGPVl/lDHfnQfb5bnoHXRVhF f8aXbEBFsrkQtGR+Jehx2+enDX+7zMot+LdzbD1c5TyDZpuwyLG+0f3VQZv2qZDppNMGELs oZmeRsndTjJG2DqYZcqrqutLkWAiQ== X-QQ-GoodBg: 2 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Di Ma In-Reply-To: <9688fef0-7f3f-479d-b8a0-2095ac0fe3a2@verizon.net> Date: Wed, 15 Apr 2020 21:42:20 +0800 Cc: "sidrops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8E30797D-C10A-4DE9-934F-011B769F220F@zdns.cn> References: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> <1f788965-aa0e-665d-0a3e-f1196b1c39c3@ripe.net> <9688fef0-7f3f-479d-b8a0-2095ac0fe3a2@verizon.net> To: Stephen Kent , Robert Kisteleki X-Mailer: Apple Mail (2.3608.80.23.2.2) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign5 X-QQ-Bgrelay: 1 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 13:42:38 -0000 > 2020=E5=B9=B44=E6=9C=8815=E6=97=A5 19:58=EF=BC=8CStephen Kent = =E5=86=99=E9=81=93=EF=BC=9A >=20 > Robert, >> ... >> I agree. However, that's not the practice today. Which is why I = latched >> on to your proposal and I'm trying to highlight that we should cover = this. >>=20 >> Cheers, >> Robert >=20 > We should ask Di Ma if RPSTIR-2 still follows the design approach I = cited. Steve is right. RPSTIR2 still follows the very design approach. =20 In terms of synchronization, RPSTIR2 keeps its incumbent local version = exactly the same with global repositories.=20 Granted, RPSTIR2 keeps the historic versions for diagnose and analysis.=20= I think we just need to keep RP in alignment with PP and then can = perform some analysis and diagnose (if necessary) to ascertain errors = (RFC 8211) to give warning or make use of SLURM (RFC8416) if the RP = operator is confident enough that he catch the wrong data and knows how = to remedy locally.=20 Di From nobody Wed Apr 15 07:00:22 2020 Return-Path: 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 AABE03A089B for ; Wed, 15 Apr 2020 07:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no 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 OK9l11gyHVHH for ; Wed, 15 Apr 2020 07:00:18 -0700 (PDT) Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.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 395EF3A0899 for ; Wed, 15 Apr 2020 07:00:16 -0700 (PDT) Received: by mail-wr1-f42.google.com with SMTP id d17so12386664wrg.11 for ; Wed, 15 Apr 2020 07:00:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=QUXziKiUfckCLwSJbvhBwUqrd/rCQJnuTOMg9xtlW/M=; b=rhUEkU6OGhQJrVXx/Phnix85mw0xQIO7z3ADt+gvn4QuzCL7AVwR4Q0Rue+fxhlBYb XRcvSpTAfZbDhjHXS6YGdBPtrEdjVmYI1EnbYnRx3U3Xmno0CCmcDamsLIN0/TEkfig3 SuI9/7QzGqeU7LOzFKmwNTogCje2ZD+s1tCkD9s+u93tyM9IhY3F+zvjUWMT1xF0h/OM V6o0i+vEBjg5FXvM2Dv35NpdPjFYWQ2q/uvDH3Dr026v+n6nm+4ZjPaosVrv3AxYuyXO y7NGuefek3ivIqFUuzVK80L+cNpZxuddiNG04YA9YqnjqRqclgWGuCOkRpRbvvuMDy+g TZOA== X-Gm-Message-State: AGi0PuY3nxwrg0nuThm6wM+Bc//dRoPOm1C5VHmD50EhEygEAxfXgySB 5ZkM7p4k6Y2A0SXjfJp1PuoHMg== X-Google-Smtp-Source: APiQypK5cNbnu71b8ETNh9lWNnB+gNS+IxOyhT4cr7sOnvTxKBkIcEqR+0bK+7Q5mNwv+TvRwH9KZQ== X-Received: by 2002:adf:ca0c:: with SMTP id o12mr8482197wrh.306.1586959214851; Wed, 15 Apr 2020 07:00:14 -0700 (PDT) Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id w3sm4911213wrc.18.2020.04.15.07.00.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Apr 2020 07:00:13 -0700 (PDT) Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id a5862a81; Wed, 15 Apr 2020 14:00:12 +0000 (UTC) Date: Wed, 15 Apr 2020 14:00:12 +0000 From: Job Snijders To: Martin Hoffmann Cc: Stephen Kent , "sidrops@ietf.org" Message-ID: <20200415140012.GB30412@vurt.meerval.net> References: <20200415150141.016d021d@glaurung.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200415150141.016d021d@glaurung.nlnetlabs.nl> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 14:00:20 -0000 Dear Martin, On Wed, Apr 15, 2020 at 03:01:41PM +0200, Martin Hoffmann wrote: > > Missing: an object named in a Manifest, but not available for > > download from a PP, is termed *missing*. An RP has no obvious way to > > acquire missing objects, but operators SHOULD be warned about which > > objects are missing. > > Since "missing" seems to be the opposite of the "present" in the case > overview below, I think we need to more precisely define the meaning > for both manifests and CRLs. > > I would define the meaning of "manifest missing": the manifest > referenced in the CA certificate is not available for download from a > PP. That leads to the case where there is a valid manifest at the PP > but it is not the one on the CA certificate. > > "CRL missing" is a little more complicated, since there is two places > where CRLs are referenced: in the manifest and in the EE certificates > of signed objects. So we also have the case where a CRL in an EE > certificate isn’t actually mentioned in the manifest. > > > *Case analysis* > [...] > > > > Below is a proposed outline for the cases. The group needs to decide > > what action is to be taken in each case. > > To get that discussion started, here’s my proposals for these cases (in > line with what I argued earlier). > > > 1.Manifest present, valid, current > > If there is a present, valid, and current manifest, the CRL can safely > be ignored for all objects. I'd like to ask you for some clarification, Stephen Kent listed 4 different cases, I parapharsed here: 1.1. Manifest present, valid, current AND CRL present, valid, current 1.2. Manifest present, valid, current AND CRL present, stale 1.3. Manifest present, valid, current AND CRL present, invalid 1.4. Manifest present, valid, current AND CRL missing When you say "can safely be ignored", do you mean, MAY be ignored, SHOULD be ignored? or MUST be ignored? In all four cases? > In order to avoid using partial sets of information, the entire > content of the PP is ignored if any object is missing, corrupted, or > invalid. It appears we are inching towards consensus on avoiding to use partial sets, I think that's good news. > Presumably this chould only be limited to objects of the same type, > i.e., if there is a least one missing, corrupted, or invalid ROA, > discard all ROAs. > > If the aim is to avoid risking accidentally marking routes as invalid, > this should probably also extend to all information published by child > CAs. Yes. Kind regards, Job From nobody Wed Apr 15 07:14:23 2020 Return-Path: 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 464653A08BB for ; Wed, 15 Apr 2020 07:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no 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 8g-pfi8xt4oY for ; Wed, 15 Apr 2020 07:14:18 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D79D3A08B7 for ; Wed, 15 Apr 2020 07:14:18 -0700 (PDT) Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id D9FCA1B87D; Wed, 15 Apr 2020 16:14:15 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Wed, 15 Apr 2020 16:14:15 +0200 From: Martin Hoffmann To: Job Snijders Cc: Stephen Kent , "sidrops@ietf.org" Message-ID: <20200415161415.29c49f4e@glaurung.nlnetlabs.nl> In-Reply-To: <20200415140012.GB30412@vurt.meerval.net> References: <20200415150141.016d021d@glaurung.nlnetlabs.nl> <20200415140012.GB30412@vurt.meerval.net> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 14:14:20 -0000 Job Snijders wrote: > On Wed, Apr 15, 2020 at 03:01:41PM +0200, Martin Hoffmann wrote: > > > > > 1.Manifest present, valid, current =20 > >=20 > > If there is a present, valid, and current manifest, the CRL can > > safely be ignored for all objects. =20 >=20 > I'd like to ask you for some clarification, Stephen Kent listed 4 > different cases, I parapharsed here: >=20 > 1.1. Manifest present, valid, current AND CRL present, valid, current > 1.2. Manifest present, valid, current AND CRL present, stale > 1.3. Manifest present, valid, current AND CRL present, invalid > 1.4. Manifest present, valid, current AND CRL missing >=20 > When you say "can safely be ignored", do you mean, MAY be ignored, > SHOULD be ignored? or MUST be ignored? In all four cases? In all cases. Since it is ignored, it doesn=E2=80=99t really matter whether= it is good or bad or ugly.=20 I suppose I would go with "SHOULD be ignored" here. > > In order to avoid using partial sets of information, the entire > > content of the PP is ignored if any object is missing, corrupted, or > > invalid. =20 >=20 > It appears we are inching towards consensus on avoiding to use partial > sets, I think that's good news. Keep in mind that there is still a possibility that partial sets are created if a resource is delegated to two separate entities and one of them goes kaputt. I have no idea how likely that is in practice. This rule should, however, cover the rather more likely case of partial sets because of partial breakage of a single publication point. Kind regards, Martin From nobody Wed Apr 15 07:33:27 2020 Return-Path: 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 86BA03A091C for ; Wed, 15 Apr 2020 07:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 Y-1SXZ329U3j for ; Wed, 15 Apr 2020 07:33:24 -0700 (PDT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 545633A08EB for ; Wed, 15 Apr 2020 07:33:23 -0700 (PDT) Received: (qmail 86396 invoked by uid 1000); 15 Apr 2020 14:33:21 -0000 Date: Wed, 15 Apr 2020 16:33:21 +0200 From: Claudio Jeker To: Martin Hoffmann Cc: Job Snijders , Stephen Kent , "sidrops@ietf.org" Message-ID: <20200415143321.GM72650@diehard.n-r-g.com> References: <20200415150141.016d021d@glaurung.nlnetlabs.nl> <20200415140012.GB30412@vurt.meerval.net> <20200415161415.29c49f4e@glaurung.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200415161415.29c49f4e@glaurung.nlnetlabs.nl> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 14:33:26 -0000 On Wed, Apr 15, 2020 at 04:14:15PM +0200, Martin Hoffmann wrote: > Job Snijders wrote: > > On Wed, Apr 15, 2020 at 03:01:41PM +0200, Martin Hoffmann wrote: > > > > > > > 1.Manifest present, valid, current > > > > > > If there is a present, valid, and current manifest, the CRL can > > > safely be ignored for all objects. > > > > I'd like to ask you for some clarification, Stephen Kent listed 4 > > different cases, I parapharsed here: > > > > 1.1. Manifest present, valid, current AND CRL present, valid, current > > 1.2. Manifest present, valid, current AND CRL present, stale > > 1.3. Manifest present, valid, current AND CRL present, invalid > > 1.4. Manifest present, valid, current AND CRL missing > > > > When you say "can safely be ignored", do you mean, MAY be ignored, > > SHOULD be ignored? or MUST be ignored? In all four cases? > > 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). 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. > > > In order to avoid using partial sets of information, the entire > > > content of the PP is ignored if any object is missing, corrupted, or > > > invalid. > > > > It appears we are inching towards consensus on avoiding to use partial > > sets, I think that's good news. > > Keep in mind that there is still a possibility that partial sets are > created if a resource is delegated to two separate entities and one of > them goes kaputt. I have no idea how likely that is in practice. This > rule should, however, cover the rather more likely case of partial sets > because of partial breakage of a single publication point. -- :wq Claudio From nobody Wed Apr 15 07:56:14 2020 Return-Path: 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 0C3763A09C5 for ; Wed, 15 Apr 2020 07:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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 (1024-bit key) header.d=nlnetlabs.nl 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 Q3EekSRvYSXr for ; Wed, 15 Apr 2020 07:56:11 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32DB3A0522 for ; Wed, 15 Apr 2020 07:56:11 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:dcf6:6c4a:3407:9446] (unknown [IPv6:2001:981:4b52:1:dcf6:6c4a:3407:9446]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 29FE21B997; Wed, 15 Apr 2020 16:56:09 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1586962569; bh=TVEiSw2MmGAQ1QRxMI3hLjPhxAssHXVhG+n0sfCEroc=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=KIktLu0TahDUHe7SdTxfnb4e4fBVTw51/ZGmxBzBqnvmHSCa1GwfpLchYdvPHR6J1 D1nPEIeeyHrk5Y+P0F/BZ/M36cURdBi/MQHYi3HesuI3miRmq7paKEG4YKcAnTkchA iXz9oLD7tx8yTTM2MQF/v55y8sYhxfstiSA/15j4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Tim Bruijnzeels In-Reply-To: <20200415161415.29c49f4e@glaurung.nlnetlabs.nl> Date: Wed, 15 Apr 2020 16:56:08 +0200 Cc: Job Snijders , Stephen Kent , "sidrops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200415150141.016d021d@glaurung.nlnetlabs.nl> <20200415140012.GB30412@vurt.meerval.net> <20200415161415.29c49f4e@glaurung.nlnetlabs.nl> To: Martin Hoffmann X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 14:56:13 -0000 > On 15 Apr 2020, at 16:14, Martin Hoffmann = wrote: >=20 > Job Snijders wrote: >> On Wed, Apr 15, 2020 at 03:01:41PM +0200, Martin Hoffmann wrote: >>>=20 >>>> 1.Manifest present, valid, current =20 >>>=20 >>> If there is a present, valid, and current manifest, the CRL can >>> safely be ignored for all objects. =20 >>=20 >> I'd like to ask you for some clarification, Stephen Kent listed 4 >> different cases, I parapharsed here: >>=20 >> 1.1. Manifest present, valid, current AND CRL present, valid, current >> 1.2. Manifest present, valid, current AND CRL present, stale >> 1.3. Manifest present, valid, current AND CRL present, invalid >> 1.4. Manifest present, valid, current AND CRL missing >>=20 >> When you say "can safely be ignored", do you mean, MAY be ignored, >> SHOULD be ignored? or MUST be ignored? In all four cases? >=20 > In all cases. Since it is ignored, it doesn=E2=80=99t really matter = whether it > is good or bad or ugly.=20 >=20 > I suppose I would go with "SHOULD be ignored" here. >=20 >>> In order to avoid using partial sets of information, the entire >>> content of the PP is ignored if any object is missing, corrupted, or >>> invalid. =20 >>=20 >> It appears we are inching towards consensus on avoiding to use = partial >> sets, I think that's good news. >=20 > Keep in mind that there is still a possibility that partial sets are > created if a resource is delegated to two separate entities and one of > them goes kaputt. I have no idea how likely that is in practice. This > rule should, however, cover the rather more likely case of partial = sets > because of partial breakage of a single publication point. A practical approach here could be to add all resources on the issuing = CA certificate for this publication point to a SLURM like ignore filter. This way one can be sure that one does not generate RPKI invalid = *announcements* because of missing information. Kind regards, Tim >=20 > Kind regards, > Martin >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Apr 15 07:57:48 2020 Return-Path: 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 A10663A09D7 for ; Wed, 15 Apr 2020 07:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 eY2pTaf95nBc for ; Wed, 15 Apr 2020 07:57:43 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FDAB3A09D8 for ; Wed, 15 Apr 2020 07:57:43 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:dcf6:6c4a:3407:9446] (unknown [IPv6:2001:981:4b52:1:dcf6:6c4a:3407:9446]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 712151B9A1; Wed, 15 Apr 2020 16:57:41 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1586962661; bh=4f4EC5CLZD1skJNXmYrfQYbRdBLmWYqp3KKEzIha4oA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=WJc6aAuIVJNoOpnLe5YoEqU7NOd8mZw8tBd4FN2W0r5PCXd+w9seld9Sga6ZcK3Gn 5b9OR2pTz+j4x7Feylx/p2uqIPUF9DmWVRkEoLmKKIUUB7YrLk1DY9niicBxti4gIY 5p6na9msyJ3M60TOYyBgyGwxKdCfJ/MQllXlHDP0= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Tim Bruijnzeels In-Reply-To: Date: Wed, 15 Apr 2020 16:57:41 +0200 Cc: Job Snijders , Stephen Kent , "sidrops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <394DD590-8233-4C55-80F8-753CA048207D@nlnetlabs.nl> References: <20200415150141.016d021d@glaurung.nlnetlabs.nl> <20200415140012.GB30412@vurt.meerval.net> <20200415161415.29c49f4e@glaurung.nlnetlabs.nl> To: Martin Hoffmann X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 14:57:46 -0000 > On 15 Apr 2020, at 16:56, Tim Bruijnzeels wrote: >=20 >=20 >=20 >> On 15 Apr 2020, at 16:14, Martin Hoffmann = wrote: >>=20 >> Job Snijders wrote: >>> On Wed, Apr 15, 2020 at 03:01:41PM +0200, Martin Hoffmann wrote: >>>>=20 >>>>> 1.Manifest present, valid, current =20 >>>>=20 >>>> If there is a present, valid, and current manifest, the CRL can >>>> safely be ignored for all objects. =20 >>>=20 >>> I'd like to ask you for some clarification, Stephen Kent listed 4 >>> different cases, I parapharsed here: >>>=20 >>> 1.1. Manifest present, valid, current AND CRL present, valid, = current >>> 1.2. Manifest present, valid, current AND CRL present, stale >>> 1.3. Manifest present, valid, current AND CRL present, invalid >>> 1.4. Manifest present, valid, current AND CRL missing >>>=20 >>> When you say "can safely be ignored", do you mean, MAY be ignored, >>> SHOULD be ignored? or MUST be ignored? In all four cases? >>=20 >> In all cases. Since it is ignored, it doesn=E2=80=99t really matter = whether it >> is good or bad or ugly.=20 >>=20 >> I suppose I would go with "SHOULD be ignored" here. >>=20 >>>> In order to avoid using partial sets of information, the entire >>>> content of the PP is ignored if any object is missing, corrupted, = or >>>> invalid. =20 >>>=20 >>> It appears we are inching towards consensus on avoiding to use = partial >>> sets, I think that's good news. >>=20 >> Keep in mind that there is still a possibility that partial sets are >> created if a resource is delegated to two separate entities and one = of >> them goes kaputt. I have no idea how likely that is in practice. This >> rule should, however, cover the rather more likely case of partial = sets >> because of partial breakage of a single publication point. >=20 > A practical approach here could be to add all resources on the issuing = CA certificate for this publication point to a SLURM like ignore filter. >=20 > This way one can be sure that one does not generate RPKI invalid = *announcements* because of missing information. To be clear.. I mean a 'virtual filter' in the context of the validation = run. Not a permanent file on disk or anything :) >=20 > Kind regards, > Tim >=20 >=20 >>=20 >> Kind regards, >> Martin >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Apr 15 08:51:30 2020 Return-Path: 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 E093F3A0B1C for ; Wed, 15 Apr 2020 08:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no 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 oTO_4dLRx_3K for ; Wed, 15 Apr 2020 08:50:25 -0700 (PDT) Received: from hrabosky.cbbtier3.att.net (braeburn.org [12.0.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id F15D43A0CFF for ; Wed, 15 Apr 2020 08:49:57 -0700 (PDT) Received: from oz.mt.att.com (zoe.cbbtier3.att.net [12.0.1.45]) by hrabosky.cbbtier3.att.net (Postfix) with ESMTP id 8E9FC31843 for ; Wed, 15 Apr 2020 15:49:56 +0000 (UTC) Received: by oz.mt.att.com (Postfix, from userid 1000) id 67A14A408AC; Wed, 15 Apr 2020 11:49:56 -0400 (EDT) X-Mailer: emacs 24.3.1 (via feedmail 11-beta-1 I); VM 8.2.0b under 24.3.1 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24215.11555.329412.270610@oz.mt.att.com> Date: Wed, 15 Apr 2020 11:49:55 -0400 From: Jay Borkenhagen To: sidrops@ietf.org In-Reply-To: <974eeeaa-32e6-45b2-860f-6b1408ae14e6@www.fastmail.com> References: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> <20200415124611.7af291b1@glaurung.nlnetlabs.nl> <974eeeaa-32e6-45b2-860f-6b1408ae14e6@www.fastmail.com> Reply-To: Jay Borkenhagen X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 15:50:27 -0000 Job Snijders writes: > On Wed, Apr 15, 2020, at 12:46, Martin Hoffmann wrote: > > An attacker who can delete files can as easily replace them with > > something else with the same result. So I am not sure the added code > > complexity is worth it. > > Agreed. > > fwiw: rpki-client runs as "openrsync -rlt --delete rsync://xxx/repository xxx/repository" > I agree with this behavior as well. Further, it leads me to make a new straw man proposal for our pre-Interim/Virtual meeting discussion. Earlier in a related thread I wrote "[...] in the context of the RPKI, we need to reach a point where all RFC-compliant RPs will generate identical sets of VRPs when presented with the same input." That statement did not generate any pushback (but feel free to disagree now if you want). Now I would like to push to see if we can take it further. Please bash this proposed goal: Each validation run of each RFC-compliant RP will generate the same set of VRPs when presented with identical input, using unexpired records from previous retrievals to deal with only complete failure to retrieve from a PP. This implies that the "cache" aspects of an RP serve two purposes: (1) reducing the amount of data to be downloaded on subsequent runs and: (2) addressing the case of a PP that is temporarily completely unreachable, for only as long as those retrieved records have not expired. In other words, RPs should assume an empty cache, except in the case where a previously-reached PP is now temporarily completely unreachable. Commence bashing. :) Jay B. From nobody Wed Apr 15 11:19:42 2020 Return-Path: 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 EBADA3A0F0A for ; Wed, 15 Apr 2020 11:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no 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 vIcBza0QySOy for ; Wed, 15 Apr 2020 11:19:40 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 034BF3A0F06 for ; Wed, 15 Apr 2020 11:19:39 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jOmdJ-0000un-No; Wed, 15 Apr 2020 18:19:33 +0000 Date: Wed, 15 Apr 2020 11:19:32 -0700 Message-ID: From: Randy Bush To: Martin Hoffmann Cc: Stephen Kent , Robert Kisteleki , "sidrops@ietf.org" In-Reply-To: <20200415124611.7af291b1@glaurung.nlnetlabs.nl> References: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> <20200415124611.7af291b1@glaurung.nlnetlabs.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 18:19:41 -0000 > An attacker who can delete files can as easily replace them with > something else with the same result. not really. From nobody Thu Apr 16 01:50:47 2020 Return-Path: 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 DE68D3A1215 for ; Thu, 16 Apr 2020 01:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Ce-j9zPtWdiH for ; Thu, 16 Apr 2020 01:50:45 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29B83A1213 for ; Thu, 16 Apr 2020 01:50:45 -0700 (PDT) Received: from allealle.ripe.net ([193.0.23.12]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jP0EN-0009gn-O0; Thu, 16 Apr 2020 10:50:43 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::a1b]) by allealle.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.3) (envelope-from ) id 1jP0EN-0004MH-LN; Thu, 16 Apr 2020 10:50:43 +0200 To: Martin Hoffmann Cc: "sidrops@ietf.org" References: <20200415150141.016d021d@glaurung.nlnetlabs.nl> From: Robert Kisteleki Autocrypt: addr=robert@ripe.net; prefer-encrypt=mutual; keydata= xsBNBEzFa6gBCADVASYXBbUF7v1D+Y9XR41SEEMiZUARlUWeP0NrFHZmRRGdR5nM/p6HguUd StIPRmdqMdyLDqBsV8XPVu6lvhcb4+ZFu/V1XFPVyPBH8U6iQ4PdGDeqFlBm3gxoDOGraGw8 bjojvASTz/Wk3ddLPm34Kb6oMI2MclC016UgrPgIj6A1Uu8qQeBDyWrk+OrWUPOUOKM7QhQg cpU4JwuaesthFvqdoPNQJi9QUfn94r14ZNDYmeJlchZiRHWO70Gwoy3ywfAM9Kyi1tx78Qc9 E5ZhGIw9qqlzqa6c6a0qhup2Zh/dhVBJ05jCDN7bUQT5tRiOV2icyX8Dsr4KaWYCsAOVABEB AAHNMVJvYmVydCBLaXN0ZWxla2kgKFJJUEUgTkNDIGtleSkgPHJvYmVydEByaXBlLm5ldD7C wHgEEwECACICGyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJWUwoeAAoJEC0ZXiKtTC3+ 04UH/jlvSR0esDGFSponUVawru+/QF61KdsNrdH6/Vs2buQvczW2Uh+S6Dic2vr2H0B1YrvL F2XpL2WJUHBUDLTA7dYTslvnHpyZrR8Sfb+h+wJ8OynxEC5wMKxfYNx2fMSk5EIU5mRjMaYg X/VkssDcoQAznNwVVYeqHYUJDMcrJhAYh44VHO208VwjPjHUDRlC+BoMGjHJnWDOAstlES8j 0r3adj2MqIHdDEjSdEx1+rbV0iZlgcDbYDex3qulOYlcZL+PJvGHzD6CkNBa8SbSN7cO0yqR OJ2sgobITOJ0GbRIbIvkUe1Iqw717CuQV/u822dFISDYOAhGYmfWGJWmkezOwE0ETMVrqAEI AKazZ2Agrv0nNFPWV69l6fEout/FaqWfyAG5V414l4yr+qVShUYzS+txA2vC+ouHvdORZ/JG xwKf6HE+YvvWS+Oa+b6h+GZfA3G43XGpQlxXrFK019TeMjhHqWprZALL4w2k6TatYT1ZW369 rORtwSgtn5ZC4uNcpZeDQddQvCjyYoknqlZqAFf1pssuGPTE8GvhrZGEp52dALYYoDIf7y/z 8fCAcy72rhMhQV02rPB49UxOEh2FZJhST0743tuMtFemBkp06B/Mcx54QT0muG8zj19oMDG3 AAaGjNP6B3qzR6F8VczR/qVhQzRvNMr8A6+y/ew/x4+48P+O/4n/I50AEQEAAcLAXwQYAQIA CQIbDAUCVlMKHgAKCRAtGV4irUwt/mvlB/sFID7mlsWAS66UyrI+tGs4Xfl59vvhRRZ4ZKiR 8VEbWbLKh/b9SoYcKt9SLEfVxJE5ebWPgIIvUSdLS6f4n9uAJteDZ4w/AVfp5a6jbfvMm7JP AMW4HtnZ3YbNevRgXdGVXN+bTLZzXoVijOKu+xHDBRNaUswaG3glrDJfUGkPQtCXFn6m6Pdw dW1/ShzwQgfuE/NXa83jhJ175P+NoQ2KG7934vu2MZdrtIqPibKuaGWMPG0L5YzPotK9ONmd taJMnuk92qqZ6S9JPwRZmogRW/sX54XvGg6RzNpdHS5C+iN01tCNJTRTlOJ1X73+RrGokvKc dp6fdfc4PHHhpcMd Organization: RIPE NCC Message-ID: <29647983-ba87-96c1-111f-a185ef142c38@ripe.net> Date: Thu, 16 Apr 2020 10:50:43 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200415150141.016d021d@glaurung.nlnetlabs.nl> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ACL-Warn: Delaying message X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a2744d85374094672b6e2a958d2a5b01812c Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 08:50:47 -0000 >> 1.Manifest present, valid, current > > If there is a present, valid, and current manifest, the CRL can safely > be ignored for all objects. While I see the benefits on reducing code complexity, I believe there have been arguments before against ignoring the CRL. > In order to avoid using partial sets of information, the entire content > of the PP is ignored if any object is missing, corrupted, or invalid. Doing so will, in the presence bit flips or non-atomic PP updates or an attacker hiding/modifying files, invalidate whole subtrees of the hierarchy. If this happens high enough in the chain, the result is invalidation a significant portion of the RPKI space. We can do better. Robert From nobody Thu Apr 16 02:33:26 2020 Return-Path: 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 2AEEB3A12ED for ; Thu, 16 Apr 2020 02:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no 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 1vPMxvrHbcqp for ; Thu, 16 Apr 2020 02:33:23 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D10C03A12EB for ; Thu, 16 Apr 2020 02:33:22 -0700 (PDT) Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 94FC91CDA2; Thu, 16 Apr 2020 11:33:20 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Thu, 16 Apr 2020 11:33:20 +0200 From: Martin Hoffmann To: Randy Bush Cc: "sidrops@ietf.org" , Stephen Kent , Robert Kisteleki Message-ID: <20200416113320.53500fa6@glaurung.nlnetlabs.nl> In-Reply-To: References: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> <20200415124611.7af291b1@glaurung.nlnetlabs.nl> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 09:33:24 -0000 Randy Bush wrote: > > An attacker who can delete files can as easily replace them with > > something else with the same result. > > not really. I cannot think of a case where an attack can manipulate the rsync exchange, impersonate the rsync server, or manipulate the file system of the legitimate rsync server in such a way that they can signal to an rsync client to delete existing files but not to replace them partially or completely. What am I missing? Kind regards, Martin From nobody Thu Apr 16 02:40:35 2020 Return-Path: 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 AF8E63A138C for ; Thu, 16 Apr 2020 02:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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 (1024-bit key) header.d=nlnetlabs.nl 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 lJ9RrMVEBnr9 for ; Thu, 16 Apr 2020 02:40:25 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F305F3A135A for ; Thu, 16 Apr 2020 02:40:20 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:b4a7:2c39:255:587f] (unknown [IPv6:2001:981:4b52:1:b4a7:2c39:255:587f]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 77F971CDDC; Thu, 16 Apr 2020 11:40:19 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1587030019; bh=MuipPggxSfdMn8bo5uNGmO4ct+SVxEyXEtQT6G5iEdI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=KOFIViFuwKVTJGsFGCPCFesASbq+aNoHqids2EPTvPrs8EEk7udkRseUYVNuEeRZW +ihMqoLQXsewFHwuIelWbi5NIsgvjxLADIX4AmtgG45NtO4eAwoGoYaApVyctZclEy syYewxKblZTbH/6bGEGU+vaHWaB4Aqh28uEr2atA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Tim Bruijnzeels In-Reply-To: <29647983-ba87-96c1-111f-a185ef142c38@ripe.net> Date: Thu, 16 Apr 2020 11:40:19 +0200 Cc: Martin Hoffmann , "sidrops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <82CFB3CE-47F5-4B0B-9A9C-084DA23FA791@nlnetlabs.nl> References: <20200415150141.016d021d@glaurung.nlnetlabs.nl> <29647983-ba87-96c1-111f-a185ef142c38@ripe.net> To: Robert Kisteleki X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 09:40:34 -0000 > On 16 Apr 2020, at 10:50, Robert Kisteleki wrote: >=20 >=20 >>> 1.Manifest present, valid, current >>=20 >> If there is a present, valid, and current manifest, the CRL can = safely >> be ignored for all objects. >=20 > While I see the benefits on reducing code complexity, I believe there > have been arguments before against ignoring the CRL. >=20 >> In order to avoid using partial sets of information, the entire = content >> of the PP is ignored if any object is missing, corrupted, or invalid. >=20 > Doing so will, in the presence bit flips or non-atomic PP updates or = an > attacker hiding/modifying files, invalidate whole subtrees of the > hierarchy. If this happens high enough in the chain, the result is > invalidation a significant portion of the RPKI space. With RRDP CAs can publish consistent atomic deltas. This was one of its = design goals. A bit flip on an HTTPS connection seems highly unlikely, if not = impossible, to me as well. Also RPs that have previous copies of files (and know their URI and = hash) do not need to be affected by intermittent issues. While I understand that it's scary to exclude all VRPs from near the = apex of the tree, the alternative is that you will need to accept that = announcements can be marked as invalid - because you *know* you do not = have the full picture. > We can do better. How? >=20 > Robert >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Apr 16 02:58:23 2020 Return-Path: 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 B96203A1362 for ; Thu, 16 Apr 2020 02:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 deHBFE1fd94f for ; Thu, 16 Apr 2020 02:58:20 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01FFC3A1366 for ; Thu, 16 Apr 2020 02:58:19 -0700 (PDT) Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 532231CE0E; Thu, 16 Apr 2020 11:58:18 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Thu, 16 Apr 2020 11:58:17 +0200 From: Martin Hoffmann To: Claudio Jeker Cc: Stephen Kent , "sidrops@ietf.org" , Job Snijders Message-ID: <20200416115817.6c3f4318@glaurung.nlnetlabs.nl> In-Reply-To: <20200415143321.GM72650@diehard.n-r-g.com> References: <20200415150141.016d021d@glaurung.nlnetlabs.nl> <20200415140012.GB30412@vurt.meerval.net> <20200415161415.29c49f4e@glaurung.nlnetlabs.nl> <20200415143321.GM72650@diehard.n-r-g.com> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 09:58:22 -0000 Claudio Jeker wrote: > On Wed, Apr 15, 2020 at 04:14:15PM +0200, Martin Hoffmann wrote: > > Job Snijders wrote: =20 > > > On Wed, Apr 15, 2020 at 03:01:41PM +0200, Martin Hoffmann wrote: =20 > > > > =20 > > > > > 1.Manifest present, valid, current =20 > > > >=20 > > > > If there is a present, valid, and current manifest, the CRL can > > > > safely be ignored for all objects. =20 > > >=20 > > > I'd like to ask you for some clarification, Stephen Kent listed 4 > > > different cases, I parapharsed here: > > >=20 > > > 1.1. Manifest present, valid, current AND CRL present, valid, > > > current 1.2. Manifest present, valid, current AND CRL present, > > > stale 1.3. Manifest present, valid, current AND CRL present, > > > invalid 1.4. Manifest present, valid, current AND CRL missing > > >=20 > > > When you say "can safely be ignored", do you mean, MAY be ignored, > > > SHOULD be ignored? or MUST be ignored? In all four cases? =20 > >=20 > > In all cases. Since it is ignored, it doesn=E2=80=99t really matter whe= ther > > it is good or bad or ugly.=20 > >=20 > > I suppose I would go with "SHOULD be ignored" here. =20 >=20 > Which CRL are we talking about? The ones listed in the manifest or > the one referenced by the manifest certificate? Isn=E2=80=99t that supposed to be the same? Each CA only issues one CRL for= all its issued certificates and replaces it upon update. Kind regards, Martin From nobody Thu Apr 16 03:02:57 2020 Return-Path: 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 CD58E3A1378 for ; Thu, 16 Apr 2020 03:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 LPqObSJ6eIFy for ; Thu, 16 Apr 2020 03:02:54 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A95083A1377 for ; Thu, 16 Apr 2020 03:02:54 -0700 (PDT) Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 88BF71CE32; Thu, 16 Apr 2020 12:02:52 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Thu, 16 Apr 2020 12:02:52 +0200 From: Martin Hoffmann To: Jay Borkenhagen Cc: sidrops@ietf.org Message-ID: <20200416120252.65db6a8d@glaurung.nlnetlabs.nl> In-Reply-To: <24215.11555.329412.270610@oz.mt.att.com> References: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> <20200415124611.7af291b1@glaurung.nlnetlabs.nl> <974eeeaa-32e6-45b2-860f-6b1408ae14e6@www.fastmail.com> <24215.11555.329412.270610@oz.mt.att.com> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 10:02:56 -0000 Jay Borkenhagen wrote: >=20 > Now I would like to push to see if we can take it further. Please > bash this proposed goal: >=20 > Each validation run of each RFC-compliant RP will generate the same > set of VRPs when presented with identical input, using unexpired > records from previous retrievals to deal with only complete failure > to retrieve from a PP. I=E2=80=99d like to limit this to: "... using records from the last success= ful retrieval ..." meaning that you can deleting unused objects after a successful retrieval is possible. I find this an excellent goal and would like the working group to produce a test data set that can be used to verify that an RP software complies with the intended interpretation of the validation rules. Kind regards, Martin From nobody Thu Apr 16 06:30:47 2020 Return-Path: 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 555AC3A081F for ; Thu, 16 Apr 2020 06:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 QrWGVm1ekMgJ for ; Thu, 16 Apr 2020 06:30:45 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDE6B3A07E1 for ; Thu, 16 Apr 2020 06:30:44 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jP4bK-0003Zq-31; Thu, 16 Apr 2020 13:30:42 +0000 Date: Thu, 16 Apr 2020 06:30:41 -0700 Message-ID: From: Randy Bush To: Martin Hoffmann Cc: "sidrops@ietf.org" , Stephen Kent , Robert Kisteleki In-Reply-To: <20200416113320.53500fa6@glaurung.nlnetlabs.nl> References: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> <20200415124611.7af291b1@glaurung.nlnetlabs.nl> <20200416113320.53500fa6@glaurung.nlnetlabs.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 13:30:46 -0000 >>> An attacker who can delete files can as easily replace them with >>> something else with the same result. >> not really. > I cannot think of a case where an attack can manipulate the rsync > exchange, impersonate the rsync server, or manipulate the file system > of the legitimate rsync server in such a way that they can signal > to an rsync client to delete existing files but not to replace them > partially or completely. > > What am I missing? 6486 4.2 fileList: This field is a sequence of FileAndHash objects. There is one FileAndHash entry for each currently valid signed object that has been published by the authority (at this publication point). Each FileAndHash is an ordered pair consisting of the name of the file in the repository publication point (directory) that contains the object in question and a hash of the file's contents. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From nobody Thu Apr 16 07:54:14 2020 Return-Path: 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 6241B3A0A4D for ; Thu, 16 Apr 2020 07:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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=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 Ed86SigP_94e for ; Thu, 16 Apr 2020 07:54:11 -0700 (PDT) Received: from sonic316-11.consmr.mail.bf2.yahoo.com (sonic316-11.consmr.mail.bf2.yahoo.com [74.6.130.121]) (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 3C5113A0A47 for ; Thu, 16 Apr 2020 07:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1587048850; bh=JHpcosb6S58skLS+kkKibLy7fs1UL3HNhG/bZ6lmvRM=; h=From:Subject:To:References:Date:In-Reply-To:From:Subject; b=H8VJcOA2togZYmLBrOuMuWvzp5QxJLuCGaVEaexbUyGUz26HM8mg9uKfhmWEek8Yx3Tl5g4HGz+QUYnv541l4nAyq/b1i4VFbMg/uBWKUrb5/C3ZKIC4X3vvsxMbmmsvKvS0uWqB28aiC1rvEo/ohGwu23gRjiS5OlU+/3KJvFzNRBpIRH5oy/AciFf8asC/KeB00PwPP8wRl8DkUTjU8sd6DY6GMkwV+hZr9GbamD99leRVk7AsKNLyo8xy3AAtSWM4tAnHofFHAlHQnMziX5voJ4nFbJCeUMPVdmndpOVVaqfPgXtvGKhSmuCUWE6MdDn5kUE/U1RowFNyzAWUzA== X-YMail-OSG: S6_o7BkVM1l5BYHrzXttos55m6jGWYTjYMQh6B_GRRnGgSthsBI5rDPYphrssCl jndp.YltvbVmgKldRwzkfBZ.fcbVe3.mynhZuVy_Ol.l19FbMAG_0uBhnEluLRspKVn2AZHWiHLF FTybMrs9_u_7H0L.ZKWORBoidUqMbHi20wsIuIoj1z8xAZBe5Zgc16Uh1d.l.i8K_TfRqG4XyS0J Eu8CiOTDZKlk1ZVvU9hvtinidQaUtd1rzR3FqMeFjRrUT_7G5mIlDw3oTPrT477wIts4ekyokuIc sUlEj9nbcoDcagLP5H0zrBYDtW8YgIBJpYS.WVnNdSNJpSb1qROGFAZ3uJln_NZX7Ul7RDlIgNzA 1afMATew16JBNVlAujE.wWEzYcH.ou.TuJZ6eMWIxP_pGFBLIfE9Vh8HVMtpOBHa7qJoShzvJg4L EXZPydMnbTDgyC3SdKTKtTuml.cAzMg7OM6LffqC9y1LnyPYTpGUYWSzxpMI4WCWl9xjy3ivytvX wWA0HheN9dEPmMkJO47dytQJEtqod70tTNzSt.rWORxK9O4sc_62XEY9NFM5ANY7BXRpFKrjLLl5 6BtQnnvoXrLgLjA4ByjUE6WIZ6DWDnagJQU58oQDsdRUD5a6M_FNfeAlgZAX978LEdtLlFdY0kbA xshv.mHcx6zTa2BmiGPLjtj9r1FgY7mbS8jn3XdFC9D5bgHbDM6O7PiBQzCxrO2d2NVMXmjQemee fLW432aexDoCYpClJ.JN3SombmYCb3ahWAFekzZMF.DXLRWool0ZoFQVSvDXStrRkLm7SOzjM3KG veip1DY1xRqpJIiFpL7KD77KmonnHLkPrCU2WdSeLNen5YneMe5zNiMssL2wvK3ph0AQPnT0eIH1 rHk3PtGl.StkxydC1kaJdZsuEHp3jE9j11ZNFW0RDk0M_T_sYp_obVetw0tGtvYD8aSgqwa0uTgc QyboppbZBMEF8XBmfF5P8qxiVAsFbaRjQzQtt2B5SZH7v3PgzkpSgp98DoDHOVuDzcSNbt12mvaW mpt4YzLUJzNzm2D_9gtZ_zpp0_x._722N3ABJ7Qz3nP1yYVmBsmO7y1pD9Fk957IufrD3gcYvgMv EVXPzkNE7.FNnOBkVvPHeMNArH34FR0A3Q8YnLfUN4P487XtgXZtkvqeNCHTpJ.FXsZKhE9JwU0p rxB97OtczRlL7reIiDgqcHuqY0o3g16RLREA9CxXGH27p5EKyBvIE9AFR4u67h19DWw3TvvbYJKQ CaBxI4b9kVB0rGN0zVE9az9ZLN96_ivBx2ph8aKEoilmVsks2fowRyG1OXzE6dtRjyi_KvtnGhUX 1MpcHe.eSxdbCQVzmVOR_Ip8q4mulDawRIX7hRuraWg1oa.uNcaxekBsGhA2C2cD_hQemX5UESrc E5rqoQRqv0lyVXp3XJQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Thu, 16 Apr 2020 14:54:10 +0000 Received: by smtp431.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 61a6580c16165c13da0a43f2ffb3ec7f; Thu, 16 Apr 2020 14:54:08 +0000 (UTC) From: Stephen Kent To: sidrops@ietf.org References: <20200415150141.016d021d@glaurung.nlnetlabs.nl> <20200415140012.GB30412@vurt.meerval.net> <20200415161415.29c49f4e@glaurung.nlnetlabs.nl> <20200415143321.GM72650@diehard.n-r-g.com> <20200416115817.6c3f4318@glaurung.nlnetlabs.nl> Message-ID: <52011f3a-d76a-ea03-6a98-bf92a118e187@verizon.net> Date: Thu, 16 Apr 2020 10:54:07 -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: <20200416115817.6c3f4318@glaurung.nlnetlabs.nl> 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 14:54:13 -0000 Martin > ... >> Which CRL are we talking about? The ones listed in the manifest or >> the one referenced by the manifest certificate? > Isn’t that supposed to be the same? Each CA only issues one CRL for all > its issued certificates and replaces it upon update. I agree. Steve From nobody Thu Apr 16 07:54:36 2020 Return-Path: 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 739513A0A54 for ; Thu, 16 Apr 2020 07:54:35 -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 9o2b209bpoDx for ; Thu, 16 Apr 2020 07:54:33 -0700 (PDT) Received: from sonic308-1.consmr.mail.bf2.yahoo.com (sonic308-1.consmr.mail.bf2.yahoo.com [74.6.130.40]) (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 8DD6F3A0A5F for ; Thu, 16 Apr 2020 07:54:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1587048872; bh=ONo8xY9KKuVAcsVaMX8pVTfbzsfZLPmWOnBYU8lkte8=; h=From:Subject:To:References:Date:In-Reply-To:From:Subject; b=NhlkXw8LSMHxLgQhhZOIsNCwnm9kv281PBkXt6cacQy/gCgTvh4gPOj8l9PLTehH2YwykhYKAfn4UITd7h90ETqxaLr0C5TZLsaWECeDKa4ZfjmgY2ym0Bh/oLS851EpI8RIOzvegcCQXAsnYvo6CpZdSjGYtIp/G02NrqrtkqckaVgX06KVrGjw1uk+LnUIPQUnaQueLtvUDoMlY9p3F2W4qw0l3606iYJtdQKp0c9/9FH0/7jDWGr4u86RBThiCt2ePWQchxWq+3kUJI9dCXvjmYm9Pzk2RybOsUMUTMy3nXLAhNDpNiOl0xMjLO0cA7gl52SVmAta1oj+kCbt0Q== X-YMail-OSG: Z61OuXoVM1lgkyC0rsSoD.QK.z_2_HTYJrH1U5SKOcHDSNtFp.JlJzOs.6Akky_ PTvGndDpOunnOeUCMjvs7w2esF1_MY0IgL6oX0c8nMBVdxXrOlJvCbS45qGU4PC93oIDsMFeTvhP J9Sj66l7G4Ea73KcsUXznwl.Bcdsbgz8svMYxbq9DlpBX.S41MKFX0OtJZgfqdW8VkhOcFbwitrL yD14YelrnaWEbX9iNMjMeXKur84o9ntXW.jXKp.LGd16fy8z.2BsZTzLiEXiWVN.Pd3SGXHP6Oyo 6P9lJiJh47I0G6unpOJebfOIFxmd9JwFlGFsCB8o5Xsp0gHWnxSpHHqpkf3Ai_e68GLjbUKLAraM O4RS9w_uSA8q7HnmSA7TxVqeN6seMKKlIX90VzkpCJVVsTqw5eV_Am9wr_BF6vZNx8kKOzMq1EnT cLhlhAkZHQoONItBvbVc9y1BtpRobttqLvkTpmTu.q4O7FYMw2USL.kk4cp.M2QiVO5BxJ1jjOgQ MNjRQ_sPHuLU4C59claYvSGCOj.w865obT2bkDh0yXRJ.cOoBhVVisnTPa0rjqDG4wEvCwrb.bVy eXazRckTFeUFbnZjxVR95PqGq5E2n5T..kvYfNd7n_6__NRuJx6YKcFWFX8SIQZHojeQp2sE3KJH CcG55l_5aE.MkbAvqG5zMOIhV0bTeogo52faS6Lwhnk0qUw7pa74HvvrUAm61Ocz6YafxX2mGzsg pr60nHLvSuDQ6A3RH6DCKoaFRsn46l8jV51Tdp_uWzCJAvZlaDZOHgwkwNCcAnJKLZCUs6tr42O5 3lqr2PqXD1X6G9ZyXtlGekxzYja0Uq.BDiGHH81BsZ91zydsrpHkXvMyU_VeyqzGzc6FG6.wpGdD aadJo42fHCfr_10NDsnsvxYbjb3Ob_f1GlGmpunbs6G4x1Lvq5Qg0cds_IoPkNJkxo5HqlO.tqjX 8hRMAr.7adUZGJZL5Smhy8Tc4MlL3UO0fytdNGccJ_D7NFy5IcHLOTqgXhH9PUqeba5v992E3vHK 8D29YwmFHwOUgaYbCXI8vXSuTYBYN11CU.lzV5vh8JKlYazafvh7.MtI6BXtqrnHWTwaouqL._0G YE_CnrY54H4kPGrWjuzF1lljQNSmEz4jbM84K5lj.PsN8xCPgARvHNS8yC06U1WHedaUI0uumGxr TKUKrH.tQFcGdI1KjRy4SNR2n92KG8BLIsLetKFoA8jQ3_1XlWDb1v6EiLuFJ0v2_ESDzLxnOEDu syGI7LbhJcqVnVWd6xtWuVbA3nkJeHyvz2TuY0vQNygYVcg7UyYsZfps_fM_26rkdD.Reg2pEnLC aAzAp6oD94xV_0SVrhtZV.8EuRuyAWyebJ_K_pn5zaL9Dvut4FkqO_Ol4uzbCKFVEnG8ZRW5bWFR N4py9WzZj6ZpK4i4TtnRAjl8oGtvhFhndRDLocpjePbPnIkdT Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.bf2.yahoo.com with HTTP; Thu, 16 Apr 2020 14:54:32 +0000 Received: by smtp419.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a62d714b92a8d88f69184d6ac30aeed4; Thu, 16 Apr 2020 14:54:27 +0000 (UTC) From: Stephen Kent To: sidrops@ietf.org References: <20200415150141.016d021d@glaurung.nlnetlabs.nl> Message-ID: Date: Thu, 16 Apr 2020 10:54:26 -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: <20200415150141.016d021d@glaurung.nlnetlabs.nl> Content-Type: multipart/alternative; boundary="------------3112700256D8E9606752CE21" Content-Language: en-US X-Mailer: WebService/1.1.15651 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 14:54:36 -0000 This is a multi-part message in MIME format. --------------3112700256D8E9606752CE21 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Martin, > Stephen Kent wrote: >> *Overview * >> > [...] >> *Terminology* >> >> Missing: an object named in a Manifest, but not available for >> download from a PP, is termed *missing*. An RP has no obvious way to >> acquire missing objects, but operators SHOULD be warned about which >> objects are missing. > Since "missing" seems to be the opposite of the "present" in the case > overview below, I think we need to more precisely define the meaning > for both manifests and CRLs. > > I would define the meaning of "manifest missing": the manifest > referenced in the CA certificate is not available for download from a > PP. That leads to the case where there is a valid manifest at the PP > but it is not the one on the CA certificate. > > "CRL missing" is a little more complicated, since there is two places > where CRLs are referenced: in the manifest and in the EE certificates > of signed objects. So we also have the case where a CRL in an EE > certificate isn’t actually mentioned in the manifest. I don't think I follow your reasoning here. For CA A, there is one PP where all of the signed objects issued by A live, ignoring the cases of key rollover or algorithm transition (Section 2 of RFC 6481, especially Figure 1). This PP contains the ROAs, a manifest, and a CRL, router certs, and any subordinate CA certs. The CRL that lives here would contain an entry for a cert associated with a manifest if that cert were revoked, and the manifest contains an entry for the CRL. If one were to encounter a CRL that contained an entry for the EE cert in the manifest, that would indicate an error by the CA. > 1.Manifest present, valid, current > > If there is a present, valid, and current manifest, the CRL can safely > be ignored for all objects. Tim has suggested that, but to do so would make the RPKI not consistent with RFC 5280. > In order to avoid using partial sets of information, the entire content > of the PP is ignored if any object is missing, corrupted, or invalid. This is not consistent with your suggestion that the CRL can safely be ignored. > Presumably this chould only be limited to objects of the same type, > i.e., if there is a least one missing, corrupted, or invalid ROA, > discard all ROAs. I'm not sure why the group-oriented approach is useful, expect perhaps for ROAs. Why would one elect to ignore some router certs if one were missing? > If the aim is to avoid risking accidentally marking routes as invalid, > this should probably also extend to all information published by child > CAs. is the concern here that ROAs issued by a subordinate CA might be treated differently if there is a missing ROA associated with the parent? >> 2.Manifest present, valid, stale > Not sure about this one. Naively I would say "use as above but warn." > There’s also an option to distinguish based on the transport protocol > used for synchronizing the PP: ignore if rsync is used, use but warn if > RRDP is used. I'm in favor of warning here, but others, I believe, have suggested, that we try to make the outcome independent of the use of rsync vs. RRDP. >> 3.Manifest present, but invalid > The entire PP is ignored. So, it's OK to ignore a CRL that is invalid, but not a manifest. Personally I believe that if a CA cannot manage to correctly generate both a CRL and a manifest, it has a serious operational problem. >> 4.Manifest not present > The entire PP is ignored. > > This essentially ignores the CRL for any object published within the > repository and essentially moves its role over to the manifest. The CRL > would still be considered for objects published outside the repository, > such as the proposed Resource Tagged Assertions. A missing manifest is a serious concern, but I would consider using cached, still valid objects for the PP, and insisting on contacting the CA or PP maintainer. Steve --------------3112700256D8E9606752CE21 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Martin,
Stephen Kent wrote:

                                    *Overview *


[...]

*Terminology*

Missing: an object named in a Manifest, but not available for
download from a PP, is termed *missing*. An RP has no obvious way to
acquire missing objects, but operators SHOULD be warned about which
objects are missing.

Since "missing" seems to be the opposite of the "present" in the case
overview below, I think we need to more precisely define the meaning
for both manifests and CRLs.

I would define the meaning of "manifest missing": the manifest
referenced in the CA certificate is not available for download from a
PP. That leads to the case where there is a valid manifest at the PP
but it is not the one on the CA certificate.

"CRL missing" is a little more complicated, since there is two places
where CRLs are referenced: in the manifest and in the EE certificates
of signed objects. So we also have the case where a CRL in an EE
certificate isn’t actually mentioned in the manifest.

I don't think I follow your reasoning here.

For CA A, there is one PP where all of the signed objects issued by A live, ignoring the cases of key rollover or algorithm transition (Section 2 of RFC 6481, especially Figure 1). This PP contains the ROAs, a manifest, and a CRL, router certs, and any subordinate CA certs. The CRL that lives here would contain an entry for a cert associated with a manifest if that cert were revoked, and the manifest contains an entry for the CRL. If one were to encounter a CRL that contained an entry for the EE cert in the manifest, that would indicate an error by the CA. 

1.Manifest present, valid, current

If there is a present, valid, and current manifest, the CRL can safely
be ignored for all objects.
Tim has suggested that, but to do so would make the RPKI not consistent with RFC 5280.
In order to avoid using partial sets of information, the entire content
of the PP is ignored if any object is missing, corrupted, or invalid.
This is not consistent with your suggestion that the CRL can safely be ignored.
Presumably this chould only be limited to objects of the same type,
i.e., if there is a least one missing, corrupted, or invalid ROA,
discard all ROAs.
I'm not sure why the group-oriented approach is useful, expect perhaps for ROAs. Why would one elect to ignore some router certs if one were missing?
If the aim is to avoid risking accidentally marking routes as invalid,
this should probably also extend to all information published by child
CAs.
is the concern here that ROAs issued by a subordinate CA might be treated differently if there is a missing ROA associated with the parent? 
2.Manifest present, valid, stale

Not sure about this one. Naively I would say "use as above but warn."
There’s also an option to distinguish based on the transport protocol
used for synchronizing the PP: ignore if rsync is used, use but warn if
RRDP is used.
I'm in favor of warning here, but others, I believe, have suggested, that we try to make the outcome independent of the use of rsync vs. RRDP.
3.Manifest present, but invalid

The entire PP is ignored.
So, it's OK to ignore a CRL that is invalid, but not a manifest. Personally I believe that if a CA cannot manage to correctly generate both a CRL and a manifest, it has a serious operational problem.
4.Manifest not present

The entire PP is ignored.

This essentially ignores the CRL for any object published within the
repository and essentially moves its role over to the manifest. The CRL
would still be considered for objects published outside the repository,
such as the proposed Resource Tagged Assertions.

A missing manifest is a serious concern, but I would consider using cached, still valid objects for the PP, and insisting on contacting the CA or PP maintainer.

Steve

--------------3112700256D8E9606752CE21-- From nobody Thu Apr 16 07:54:45 2020 Return-Path: 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 ; 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 ; 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 ; 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 To: Claudio Jeker , Martin Hoffmann Cc: Job Snijders , "sidrops@ietf.org" References: <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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Thu Apr 16 07:54:48 2020 Return-Path: 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 4D2E53A0A92 for ; Thu, 16 Apr 2020 07:54:39 -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=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 qXbabQljRNFC for ; Thu, 16 Apr 2020 07:54:38 -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 2B2933A0AA7 for ; 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 To: Claudio Jeker , Martin Hoffmann Cc: Job Snijders , "sidrops@ietf.org" References: <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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Thu Apr 16 08:02:12 2020 Return-Path: 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 7BA9F3A0AA6 for ; Thu, 16 Apr 2020 08:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 gh7CUQLOmr1K for ; Thu, 16 Apr 2020 08:02:06 -0700 (PDT) Received: from mail4.dllstx09.us.to.gin.ntt.net (mail4.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::192:26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D8E23A0AA4 for ; Thu, 16 Apr 2020 08:02:06 -0700 (PDT) Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) by mail4.dllstx09.us.to.gin.ntt.net (Postfix) with ESMTPSA id 65C50EE0072 for ; Thu, 16 Apr 2020 15:02:05 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id EA1D127C0054 for ; Thu, 16 Apr 2020 11:02:03 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute3.internal (MEProxy); Thu, 16 Apr 2020 11:02:03 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrfeehgdekgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdflohgsucfunhhijhguvghrshdfuceojhhosgesnhhtthdr nhgvtheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epjhhosgdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidquddtgeejleduheek gedqvdeffeefkeefvddtqdhjohgspeepnhhtthdrnhgvthesshhosghorhhnohhsthdrnh gvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 34B73C200A5; Thu, 16 Apr 2020 11:02:03 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1131-g3221b37-fmstable-20200415v1 Mime-Version: 1.0 Message-Id: <495aa74e-9094-458a-8524-db595d7bc6f2@www.fastmail.com> In-Reply-To: References: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> <20200415124611.7af291b1@glaurung.nlnetlabs.nl> <20200416113320.53500fa6@glaurung.nlnetlabs.nl> Date: Thu, 16 Apr 2020 17:01:42 +0200 From: "Job Snijders" To: sidrops@ietf.org Content-Type: text/plain Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 15:02:08 -0000 On Thu, Apr 16, 2020, at 15:30, Randy Bush wrote: > >>> An attacker who can delete files can as easily replace them with > >>> something else with the same result. > >> not really. > > I cannot think of a case where an attack can manipulate the rsync > > exchange, impersonate the rsync server, or manipulate the file system > > of the legitimate rsync server in such a way that they can signal > > to an rsync client to delete existing files but not to replace them > > partially or completely. > > > > What am I missing? > > 6486 4.2 > > fileList: > This field is a sequence of FileAndHash objects. There is one > FileAndHash entry for each currently valid signed object that has > been published by the authority (at this publication point). Each > FileAndHash is an ordered pair consisting of the name of the file > in the repository publication point (directory) that contains the > object in question and a hash of the file's contents. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I think I see an instance of miscommunication: I think Martin's perspective is that whether the files are deleted or modified by MITM, the RP outcome is the same: the PP has to be tossed. I don't think Martin suggested that files can trivially be replaced, just that deletion or tampering have the same effect. Right? Kind regards, Job From nobody Thu Apr 16 08:45:16 2020 Return-Path: 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 12ADF3A0CB3 for ; Thu, 16 Apr 2020 08:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no 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 qv2W0Uni20gz for ; Thu, 16 Apr 2020 08:45:12 -0700 (PDT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2885F3A0CA7 for ; Thu, 16 Apr 2020 08:45:11 -0700 (PDT) Received: (qmail 85511 invoked by uid 1000); 16 Apr 2020 15:45:09 -0000 Date: Thu, 16 Apr 2020 17:45:09 +0200 From: Claudio Jeker To: Stephen Kent Cc: Martin Hoffmann , "sidrops@ietf.org" , Job Snijders Message-ID: <20200416154509.GT72650@diehard.n-r-g.com> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9d7a9500-2ff8-e9d2-f3a5-89eeaa4a90e8@verizon.net> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 15:45:15 -0000 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. > > 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. -- :wq Claudio From nobody Thu Apr 16 08:53:37 2020 Return-Path: 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 1A9153A0CE6 for ; Thu, 16 Apr 2020 08:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no 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 SWJpI7qYhUy7 for ; Thu, 16 Apr 2020 08:53:29 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7393A0CE1 for ; Thu, 16 Apr 2020 08:53:28 -0700 (PDT) Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 98D511D66C; Thu, 16 Apr 2020 17:53:26 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Thu, 16 Apr 2020 17:53:26 +0200 From: Martin Hoffmann To: Stephen Kent Cc: sidrops@ietf.org Message-ID: <20200416175326.3f04db80@glaurung.nlnetlabs.nl> In-Reply-To: References: <20200415150141.016d021d@glaurung.nlnetlabs.nl> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 15:53:34 -0000 Stephen Kent wrote: > > Stephen Kent wrote: =20 > >> *Overview * > >> =20 > > [...] =20 > >> *Terminology* > >> > >> Missing: an object named in a Manifest, but not available for > >> download from a PP, is termed *missing*. An RP has no obvious way > >> to acquire missing objects, but operators SHOULD be warned about > >> which objects are missing. =20 > > Since "missing" seems to be the opposite of the "present" in the > > case overview below, I think we need to more precisely define the > > meaning for both manifests and CRLs. > > > > I would define the meaning of "manifest missing": the manifest > > referenced in the CA certificate is not available for download from > > a PP. That leads to the case where there is a valid manifest at the > > PP but it is not the one on the CA certificate. > > > > "CRL missing" is a little more complicated, since there is two > > places where CRLs are referenced: in the manifest and in the EE > > certificates of signed objects. So we also have the case where a > > CRL in an EE certificate isn=E2=80=99t actually mentioned in the manife= st. =20 >=20 > I don't think I follow your reasoning here. >=20 > For CA A, there is one PP where all of the signed objects issued by A=20 > live, ignoring the cases of key rollover or algorithm transition=20 > (Section 2 of RFC 6481, especially Figure 1). This PP contains the > ROAs, a manifest, and a CRL, router certs, and any subordinate CA > certs. The CRL that lives here would contain an entry for a cert > associated with a manifest if that cert were revoked, and the > manifest contains an entry for the CRL. If one were to encounter a > CRL that contained an entry for the EE cert in the manifest, that > would indicate an error by the CA. That wasn=E2=80=99t quite the case I was thinking of (although I think this= is a case worth calling out specifically to avoid confusion), but rather a case where say, a ROA=E2=80=99s EE certificate contains a URI for the CRL Distribution Point that is referring to a CRL that is not listed in the issuing CA=E2=80=99s manifest. So, when validating the EE certificate of a signed object, the CRL could be missing in the manifest and it could be present in the manifest but missing in the sense that it can=E2=80=99t be downloaded from = the publication point. I think this is a case worth clarifying since it seems to currently be left to local policy. > > 1.Manifest present, valid, current > > > > If there is a present, valid, and current manifest, the CRL can > > safely be ignored for all objects. =20 > Tim has suggested that, but to do so would make the RPKI not > consistent with RFC 5280. I=E2=80=99m not sure. In section 6.1.3, RFC 5280 says | (3) At the current time, the certificate is not revoked. This | may be determined by obtaining the appropriate CRL | (Section 6.3), by status information, or by out-of-band | mechanisms. Determining certificate revocation via lack of presence on a manifest could be construed as an "out-of-band" mechanism. > > In order to avoid using partial sets of information, the entire > > content of the PP is ignored if any object is missing, corrupted, > > or invalid. =20 > This is not consistent with your suggestion that the CRL can safely > be ignored. Sorry, indeed. Any signed object or certificate. > > Presumably this chould only be limited to objects of the same type, > > i.e., if there is a least one missing, corrupted, or invalid ROA, > > discard all ROAs. =20 > I'm not sure why the group-oriented approach is useful, expect > perhaps for ROAs. Why would one elect to ignore some router certs if > one were missing? Hm, true. So perhaps this should be defined per object type? For ROAs (and in the future ASPAs) partial sets cause hard to debug issues whereas for router keys and ghostbuster records, having to discard single objects of a set shouldn=E2=80=99t cause any harm. > > If the aim is to avoid risking accidentally marking routes as > > invalid, this should probably also extend to all information > > published by child CAs. =20 > is the concern here that ROAs issued by a subordinate CA might be=20 > treated differently if there is a missing ROA associated with the > parent? I was thinking of the possible case that the parent issues a ROA for a resource but also delegates it to a child CA which then issues additional ROAs for the same resource. If the parent ROA is missing, you cannot rule out that the was indeed the case, so in order to be safe, you=E2=80=99d have to discard all ROAs for prefixes associated with t= he parent.=20 > >> 3.Manifest present, but invalid =20 > > The entire PP is ignored. =20 > So, it's OK to ignore a CRL that is invalid, but not a manifest.=20 > Personally I believe that if a CA cannot manage to correctly generate=20 > both a CRL and a manifest, it has a serious operational problem. Indeed. However, bugs exist and unexpected things have a tendency to happen. I still fail to see how, given a strict adherence to the manifest, the CRL provides additional value for objects published within the RPKI repository. So for robustness, it may indeed be preferable to remove this additional possibility for breakage. > > This essentially ignores the CRL for any object published within the > > repository and essentially moves its role over to the manifest. The > > CRL would still be considered for objects published outside the > > repository, such as the proposed Resource Tagged Assertions. =20 >=20 > A missing manifest is a serious concern, but I would consider using=20 > cached, still valid objects for the PP, and insisting on contacting > the CA or PP maintainer. If the manifest takes over the CRL=E2=80=99s responsibility of expressing revocation, you=E2=80=99d open a window to replay revoked objects. So this translates to the question: What would you do today for a stale or missing CRL? Kind regards, Martin From nobody Thu Apr 16 08:55:37 2020 Return-Path: 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 D19663A0CF3 for ; Thu, 16 Apr 2020 08:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 V-_AKj5wVpph for ; Thu, 16 Apr 2020 08:55:34 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B20A43A0CE8 for ; Thu, 16 Apr 2020 08:55:33 -0700 (PDT) Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id EB3121D67C; Thu, 16 Apr 2020 17:55:31 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Thu, 16 Apr 2020 17:55:31 +0200 From: Martin Hoffmann To: "Job Snijders" Cc: sidrops@ietf.org Message-ID: <20200416175531.2f85de25@glaurung.nlnetlabs.nl> In-Reply-To: <495aa74e-9094-458a-8524-db595d7bc6f2@www.fastmail.com> References: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> <20200415124611.7af291b1@glaurung.nlnetlabs.nl> <20200416113320.53500fa6@glaurung.nlnetlabs.nl> <495aa74e-9094-458a-8524-db595d7bc6f2@www.fastmail.com> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 15:55:36 -0000 Job Snijders wrote: > On Thu, Apr 16, 2020, at 15:30, Randy Bush wrote: > > >>> An attacker who can delete files can as easily replace them with > > >>> something else with the same result. > > >> not really. > > > I cannot think of a case where an attack can manipulate the rsync > > > exchange, impersonate the rsync server, or manipulate the file > > > system of the legitimate rsync server in such a way that they can > > > signal to an rsync client to delete existing files but not to > > > replace them partially or completely. > > > > > > What am I missing? > > > > 6486 4.2 > > > > fileList: > > This field is a sequence of FileAndHash objects. There is one > > FileAndHash entry for each currently valid signed object that > > has been published by the authority (at this publication point). > > Each FileAndHash is an ordered pair consisting of the name of the > > file in the repository publication point (directory) that contains > > the object in question and a hash of the file's contents. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > I think I see an instance of miscommunication: > > I think Martin's perspective is that whether the files are deleted or > modified by MITM, the RP outcome is the same: the PP has to be > tossed. I don't think Martin suggested that files can trivially be > replaced, just that deletion or tampering have the same effect. > > Right? Correct. This was solely about synchronisation of a publication point, not yet about validation. Kind regards, Martin From nobody Thu Apr 16 09:54:03 2020 Return-Path: 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 8D1333A0EB2 for ; Thu, 16 Apr 2020 09:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 FuoDon-wyFvc for ; Thu, 16 Apr 2020 09:54:01 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3ED63A0EB1 for ; Thu, 16 Apr 2020 09:54:00 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jP7m2-0004JO-FU; Thu, 16 Apr 2020 16:53:58 +0000 Date: Thu, 16 Apr 2020 09:53:58 -0700 Message-ID: From: Randy Bush To: "Job Snijders" Cc: sidrops@ietf.org In-Reply-To: <495aa74e-9094-458a-8524-db595d7bc6f2@www.fastmail.com> References: <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> <20200415124611.7af291b1@glaurung.nlnetlabs.nl> <20200416113320.53500fa6@glaurung.nlnetlabs.nl> <495aa74e-9094-458a-8524-db595d7bc6f2@www.fastmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 16:54:03 -0000 > I think I see an instance of miscommunication: doh. sorry. randy From nobody Thu Apr 16 10:43:55 2020 Return-Path: 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 9D8FA3A09A4 for ; Thu, 16 Apr 2020 10:43:53 -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=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 FRbZCRrsVwte for ; Thu, 16 Apr 2020 10:43:52 -0700 (PDT) Received: from sonic302-3.consmr.mail.bf2.yahoo.com (sonic302-3.consmr.mail.bf2.yahoo.com [74.6.135.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 E74EC3A09A2 for ; Thu, 16 Apr 2020 10:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1587059031; bh=u5Cws9G4KxXYP+uQgcC+X8uwoKwbHsY0LjC8B2Jz7j8=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From:Subject; b=RsYc1vxs++fkN8fKXE5C+GW0t7+PH42k1GD1bLoVckUZb9Tm5aiTQFuZtO32PZaY0fMN8cNTCXCPDrwYmDexbS75TKhnROnkJN30MgeAY6zZ4O/L2LNBb0dlD8CVdnWN7nyHVxpyJIgw2cQgu0I/7aplzBq/HhcR2wtr2naSACsT/Stf1ogw+6+o/frZOLT1xzSu3eBBy96X7zUf6YZB0dAga4gKYTGF/O3/Fb8LJJI25BmpuXiJ4Lk2bXT29osd+IPSXLg7UhU3flg8quQFpcz6dQnWO/eedsyfkQqpsva6KRzCT+Db4YmsYJlH7wxuOCK8p7pU4NNLRVN1Gq20jA== X-YMail-OSG: Q_SH6FIVM1ktYZvT4j9G5ieymxkTLlKDRr1G5YdtxhItizzHyiEEXdxE_SvQO.5 Qibexs7EOGAZDLWyVF4PdBCZ2DuGQQHVVSlRdBbxqd5x3TM6rDsYMHMl..seWdh2G.0Lgcyaxr0Q EipLcv4NIrSLS8HtQYlAJNGhdQWYRtg8TYdgCbRvrixmMdimj5rKRF1oXJq3k5cjXaliTUB07K.o 5gl1odniMDVYOkSf3e6ZFeGmqe8di4KkpZX.26JvwwG9bsCysHByWTczXCUL60fF8RlfeGMj9ZvJ DDYvJKW34GmcLj4d0H8hzd_hnw19CbIISXQZUOdPIxZrRexZqCXI.JxbjI8ceuDxgIw8zlSFkrgL i3zFyzGznJqTqoQ1XiLeoE0paV8pLSTKVus6wD7jdn03jXMICNwN9UsrL1PJndN4LlMClIwjOS4. e8t7Ex5UCI1gmN68kI0roPKvXJPVPU4f4IRT_n3O67fGxqOCvAbejVSuXyKTrLVsLYesJ55yYdjM 56He.E0RkMNjrSjcpy3lTEKp3kJgVEF_306I3VA0LUxyXdwQmaMY0jx5rvRlN8G3Yb3AvhZsYo3T o6c_RePH.kzrY80fTs06k_mqzO7cwW6ivGQrraGi66LgLrcXAw.y6.5uxmGkB2E5GtxaCH.Ptl9b vrAhy9jtxMIBj2t3pxqfZP7hkz_VdxxQbGqY5KHfykLClD3oUFsDu84jJNBban8.1NDbLP0fB_Yl G6WGJEBNOwOYTOsoYpXcNx7Sz3GPavYG1VT1nLVs5JgQO2mQj9byv_ILBKoJ93iq4KpyhecuJqH5 VRzoFVE6DSUIomWTuxxVUeXRkOkk4KDhUFKZTJnArzT0ZRznsvOaX.L7yxS2qO2Vt2zwBD1McBHS Je7wwXo0CWtlm7ixkZLtjasrKShFn6_QKSTaqzonljVMIZgMvi25oZINZSRElfZGWqHIvTQNCQDJ TR0q3ehXjsCY67pW1aPz7GH_CgY8lU7Vv6vmhQEzygZO46Qoc90kkYvdHzybpV5xShKEa8uIrPnb Ahcg.MhgTGqcSi_.G9ajeQfEqWyvC5ovzX3amrFHTelw9S5ljXLsMuBBfIdLMjseAkrOsuKBKsQi yyGizsgjRUlbvF4IHnZmYG8mxPfNDDFXY8o_ElTfmhZ.MZim1wy4_S0BeZKYjyV.MRlAWXWQ05Yw 5fNwLXkKTuLIhPsRcmqYls6U.S3RhqwXojFW4MOerGdevKQUnetSez4lQXI18gcfXN15XGupy.nv Io9M.Cm7RWih3Nm9jnd_kjBttw1xz4Hy29YLOW._2kHGz9JhvAwnbaZOw6ingtvLsn8KpIZbAs08 4dRIotPRfGeTws5aRSGMLsxCxMV_a7717HhFyqX2F0J_lCYgRyo9BrvC0SiWIVzK8R2o54G1bYZ5 3qj2ddcTCRjoVW8wVCWWKrGiA5D5.XllXcxn9k8uNPnDtpMIpAp3K.FwP3oRz1OhI3Dis6Bw- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Thu, 16 Apr 2020 17:43:51 +0000 Received: by smtp419.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID efcd595bc35b2a6470e5a9c56ed98242; Thu, 16 Apr 2020 17:43:46 +0000 (UTC) From: Stephen Kent To: Martin Hoffmann Cc: sidrops@ietf.org References: <20200415150141.016d021d@glaurung.nlnetlabs.nl> <20200416175326.3f04db80@glaurung.nlnetlabs.nl> Message-ID: <123646a7-e1d5-e939-53fe-21f3326e79be@verizon.net> Date: Thu, 16 Apr 2020 13:43:45 -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: <20200416175326.3f04db80@glaurung.nlnetlabs.nl> 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 17:43:54 -0000 Martin, > ... > > That wasn’t quite the case I was thinking of (although I think this is > a case worth calling out specifically to avoid confusion), but rather > a case where say, a ROA’s EE certificate contains a URI for the CRL > Distribution Point that is referring to a CRL that is not listed in the > issuing CA’s manifest. This would be an error by the CA. RFC 6480 notes where the CRL is supposed to live in the repository system. > So, when validating the EE certificate of a signed object, the CRL > could be missing in the manifest and it could be present in the > manifest but missing in the sense that it can’t be downloaded from the > publication point. > > I think this is a case worth clarifying since it seems to currently be > left to local policy. I'm all in favor of reminding folks that there are a lot of details that an RP has to check, which is why Di Ma and I co-authored the recently-approved Informational RFC on this topic. This  is an example of a CA not following the requirements established in one of the many applicable RFCs, and I suspect we may have failed to cite this in the document in question. >>> 1.Manifest present, valid, current >>> >>> If there is a present, valid, and current manifest, the CRL can >>> safely be ignored for all objects. >> Tim has suggested that, but to do so would make the RPKI not >> consistent with RFC 5280. > I’m not sure. In section 6.1.3, RFC 5280 says > > | (3) At the current time, the certificate is not revoked. This > | may be determined by obtaining the appropriate CRL > | (Section 6.3), by status information, or by out-of-band > | mechanisms. > > Determining certificate revocation via lack of presence on a manifest > could be construed as an "out-of-band" mechanism. This part of 5280 is designed to accommodate OCSP as a revocation status distribution mechanism, something that was not part of X.509. The RPKI requires CAs to publish CRLs, and it states where the CRLs are to be published in the repository system (RFC 6480). > ... >>> Presumably this chould only be limited to objects of the same type, >>> i.e., if there is a least one missing, corrupted, or invalid ROA, >>> discard all ROAs. >> I'm not sure why the group-oriented approach is useful, expect >> perhaps for ROAs. Why would one elect to ignore some router certs if >> one were missing? > Hm, true. So perhaps this should be defined per object type? For ROAs > (and in the future ASPAs) partial sets cause hard to debug issues > whereas for router keys and ghostbuster records, having to discard > single objects of a set shouldn’t cause any harm. That sounds like a good argument. > >>> If the aim is to avoid risking accidentally marking routes as >>> invalid, this should probably also extend to all information >>> published by child CAs. >> is the concern here that ROAs issued by a subordinate CA might be >> treated differently if there is a missing ROA associated with the >> parent? > I was thinking of the possible case that the parent issues a ROA for a > resource but also delegates it to a child CA which then issues > additional ROAs for the same resource. If the parent ROA is missing, > you cannot rule out that the was indeed the case, so in order to be > safe, you’d have to discard all ROAs for prefixes associated with the > parent. So, the parent issues a ROA binding a range of addresses to an AS that the parent holds. But then  the parent delegates the same range to a child, which is free to bind the addresses to a different AS (that the child holds). Thus a route advertising either AS as the origin is valid. If the parent's ROA is missing, the AS bound to it is no longer considered valid, but the child's ROA is. So, why does one have to discard/ignore all other ROAs associated with the parent? > >>>> 3.Manifest present, but invalid >>> The entire PP is ignored. >> So, it's OK to ignore a CRL that is invalid, but not a manifest. >> Personally I believe that if a CA cannot manage to correctly generate >> both a CRL and a manifest, it has a serious operational problem. > Indeed. However, bugs exist and unexpected things have a tendency to > happen. I still fail to see how, given a strict adherence to the > manifest, the CRL provides additional value for objects published > within the RPKI repository. So for robustness, it may indeed be > preferable to remove this additional possibility for breakage. As I noted in my reply to Tim a while ago, if we want to view the manifest as the only critical determinant of whether a cert is revoked, then why bother checking the validity interval for the EE certs? Why not just say that if an EE cert is listed in a manifest by a a CA, then the CA is declaring it to be valid, period? One can argue that remembering to reissue certs with new validity intervals is also a burden for a CA and creates another opportunity for the CA to post inconsistent info at a PP. > >>> This essentially ignores the CRL for any object published within the >>> repository and essentially moves its role over to the manifest. The >>> CRL would still be considered for objects published outside the >>> repository, such as the proposed Resource Tagged Assertions. >> A missing manifest is a serious concern, but I would consider using >> cached, still valid objects for the PP, and insisting on contacting >> the CA or PP maintainer. > If the manifest takes over the CRL’s responsibility of expressing > revocation, you’d open a window to replay revoked objects. So this > translates to the question: What would you do today for a stale or > missing CRL? I don't understand your example. If a manifest trumps a CRL, then revoked objects would not appear on a current manifest and so replay of such objects would be ignored, right? Steve From nobody Thu Apr 16 10:44:06 2020 Return-Path: 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 91D313A09A4 for ; Thu, 16 Apr 2020 10:43:54 -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 E3M3rLJJ-7Zd for ; Thu, 16 Apr 2020 10:43:52 -0700 (PDT) Received: from sonic302-3.consmr.mail.bf2.yahoo.com (sonic302-3.consmr.mail.bf2.yahoo.com [74.6.135.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 DA68A3A09A1 for ; Thu, 16 Apr 2020 10:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1587059031; bh=u5Cws9G4KxXYP+uQgcC+X8uwoKwbHsY0LjC8B2Jz7j8=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From:Subject; b=RsYc1vxs++fkN8fKXE5C+GW0t7+PH42k1GD1bLoVckUZb9Tm5aiTQFuZtO32PZaY0fMN8cNTCXCPDrwYmDexbS75TKhnROnkJN30MgeAY6zZ4O/L2LNBb0dlD8CVdnWN7nyHVxpyJIgw2cQgu0I/7aplzBq/HhcR2wtr2naSACsT/Stf1ogw+6+o/frZOLT1xzSu3eBBy96X7zUf6YZB0dAga4gKYTGF/O3/Fb8LJJI25BmpuXiJ4Lk2bXT29osd+IPSXLg7UhU3flg8quQFpcz6dQnWO/eedsyfkQqpsva6KRzCT+Db4YmsYJlH7wxuOCK8p7pU4NNLRVN1Gq20jA== X-YMail-OSG: Q_SH6FIVM1ktYZvT4j9G5ieymxkTLlKDRr1G5YdtxhItizzHyiEEXdxE_SvQO.5 Qibexs7EOGAZDLWyVF4PdBCZ2DuGQQHVVSlRdBbxqd5x3TM6rDsYMHMl..seWdh2G.0Lgcyaxr0Q EipLcv4NIrSLS8HtQYlAJNGhdQWYRtg8TYdgCbRvrixmMdimj5rKRF1oXJq3k5cjXaliTUB07K.o 5gl1odniMDVYOkSf3e6ZFeGmqe8di4KkpZX.26JvwwG9bsCysHByWTczXCUL60fF8RlfeGMj9ZvJ DDYvJKW34GmcLj4d0H8hzd_hnw19CbIISXQZUOdPIxZrRexZqCXI.JxbjI8ceuDxgIw8zlSFkrgL i3zFyzGznJqTqoQ1XiLeoE0paV8pLSTKVus6wD7jdn03jXMICNwN9UsrL1PJndN4LlMClIwjOS4. e8t7Ex5UCI1gmN68kI0roPKvXJPVPU4f4IRT_n3O67fGxqOCvAbejVSuXyKTrLVsLYesJ55yYdjM 56He.E0RkMNjrSjcpy3lTEKp3kJgVEF_306I3VA0LUxyXdwQmaMY0jx5rvRlN8G3Yb3AvhZsYo3T o6c_RePH.kzrY80fTs06k_mqzO7cwW6ivGQrraGi66LgLrcXAw.y6.5uxmGkB2E5GtxaCH.Ptl9b vrAhy9jtxMIBj2t3pxqfZP7hkz_VdxxQbGqY5KHfykLClD3oUFsDu84jJNBban8.1NDbLP0fB_Yl G6WGJEBNOwOYTOsoYpXcNx7Sz3GPavYG1VT1nLVs5JgQO2mQj9byv_ILBKoJ93iq4KpyhecuJqH5 VRzoFVE6DSUIomWTuxxVUeXRkOkk4KDhUFKZTJnArzT0ZRznsvOaX.L7yxS2qO2Vt2zwBD1McBHS Je7wwXo0CWtlm7ixkZLtjasrKShFn6_QKSTaqzonljVMIZgMvi25oZINZSRElfZGWqHIvTQNCQDJ TR0q3ehXjsCY67pW1aPz7GH_CgY8lU7Vv6vmhQEzygZO46Qoc90kkYvdHzybpV5xShKEa8uIrPnb Ahcg.MhgTGqcSi_.G9ajeQfEqWyvC5ovzX3amrFHTelw9S5ljXLsMuBBfIdLMjseAkrOsuKBKsQi yyGizsgjRUlbvF4IHnZmYG8mxPfNDDFXY8o_ElTfmhZ.MZim1wy4_S0BeZKYjyV.MRlAWXWQ05Yw 5fNwLXkKTuLIhPsRcmqYls6U.S3RhqwXojFW4MOerGdevKQUnetSez4lQXI18gcfXN15XGupy.nv Io9M.Cm7RWih3Nm9jnd_kjBttw1xz4Hy29YLOW._2kHGz9JhvAwnbaZOw6ingtvLsn8KpIZbAs08 4dRIotPRfGeTws5aRSGMLsxCxMV_a7717HhFyqX2F0J_lCYgRyo9BrvC0SiWIVzK8R2o54G1bYZ5 3qj2ddcTCRjoVW8wVCWWKrGiA5D5.XllXcxn9k8uNPnDtpMIpAp3K.FwP3oRz1OhI3Dis6Bw- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Thu, 16 Apr 2020 17:43:51 +0000 Received: by smtp419.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID efcd595bc35b2a6470e5a9c56ed98242; Thu, 16 Apr 2020 17:43:46 +0000 (UTC) From: Stephen Kent To: Martin Hoffmann Cc: sidrops@ietf.org References: <20200415150141.016d021d@glaurung.nlnetlabs.nl> <20200416175326.3f04db80@glaurung.nlnetlabs.nl> Message-ID: <123646a7-e1d5-e939-53fe-21f3326e79be@verizon.net> Date: Thu, 16 Apr 2020 13:43:45 -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: <20200416175326.3f04db80@glaurung.nlnetlabs.nl> 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 17:43:55 -0000 Martin, > ... > > That wasn’t quite the case I was thinking of (although I think this is > a case worth calling out specifically to avoid confusion), but rather > a case where say, a ROA’s EE certificate contains a URI for the CRL > Distribution Point that is referring to a CRL that is not listed in the > issuing CA’s manifest. This would be an error by the CA. RFC 6480 notes where the CRL is supposed to live in the repository system. > So, when validating the EE certificate of a signed object, the CRL > could be missing in the manifest and it could be present in the > manifest but missing in the sense that it can’t be downloaded from the > publication point. > > I think this is a case worth clarifying since it seems to currently be > left to local policy. I'm all in favor of reminding folks that there are a lot of details that an RP has to check, which is why Di Ma and I co-authored the recently-approved Informational RFC on this topic. This  is an example of a CA not following the requirements established in one of the many applicable RFCs, and I suspect we may have failed to cite this in the document in question. >>> 1.Manifest present, valid, current >>> >>> If there is a present, valid, and current manifest, the CRL can >>> safely be ignored for all objects. >> Tim has suggested that, but to do so would make the RPKI not >> consistent with RFC 5280. > I’m not sure. In section 6.1.3, RFC 5280 says > > | (3) At the current time, the certificate is not revoked. This > | may be determined by obtaining the appropriate CRL > | (Section 6.3), by status information, or by out-of-band > | mechanisms. > > Determining certificate revocation via lack of presence on a manifest > could be construed as an "out-of-band" mechanism. This part of 5280 is designed to accommodate OCSP as a revocation status distribution mechanism, something that was not part of X.509. The RPKI requires CAs to publish CRLs, and it states where the CRLs are to be published in the repository system (RFC 6480). > ... >>> Presumably this chould only be limited to objects of the same type, >>> i.e., if there is a least one missing, corrupted, or invalid ROA, >>> discard all ROAs. >> I'm not sure why the group-oriented approach is useful, expect >> perhaps for ROAs. Why would one elect to ignore some router certs if >> one were missing? > Hm, true. So perhaps this should be defined per object type? For ROAs > (and in the future ASPAs) partial sets cause hard to debug issues > whereas for router keys and ghostbuster records, having to discard > single objects of a set shouldn’t cause any harm. That sounds like a good argument. > >>> If the aim is to avoid risking accidentally marking routes as >>> invalid, this should probably also extend to all information >>> published by child CAs. >> is the concern here that ROAs issued by a subordinate CA might be >> treated differently if there is a missing ROA associated with the >> parent? > I was thinking of the possible case that the parent issues a ROA for a > resource but also delegates it to a child CA which then issues > additional ROAs for the same resource. If the parent ROA is missing, > you cannot rule out that the was indeed the case, so in order to be > safe, you’d have to discard all ROAs for prefixes associated with the > parent. So, the parent issues a ROA binding a range of addresses to an AS that the parent holds. But then  the parent delegates the same range to a child, which is free to bind the addresses to a different AS (that the child holds). Thus a route advertising either AS as the origin is valid. If the parent's ROA is missing, the AS bound to it is no longer considered valid, but the child's ROA is. So, why does one have to discard/ignore all other ROAs associated with the parent? > >>>> 3.Manifest present, but invalid >>> The entire PP is ignored. >> So, it's OK to ignore a CRL that is invalid, but not a manifest. >> Personally I believe that if a CA cannot manage to correctly generate >> both a CRL and a manifest, it has a serious operational problem. > Indeed. However, bugs exist and unexpected things have a tendency to > happen. I still fail to see how, given a strict adherence to the > manifest, the CRL provides additional value for objects published > within the RPKI repository. So for robustness, it may indeed be > preferable to remove this additional possibility for breakage. As I noted in my reply to Tim a while ago, if we want to view the manifest as the only critical determinant of whether a cert is revoked, then why bother checking the validity interval for the EE certs? Why not just say that if an EE cert is listed in a manifest by a a CA, then the CA is declaring it to be valid, period? One can argue that remembering to reissue certs with new validity intervals is also a burden for a CA and creates another opportunity for the CA to post inconsistent info at a PP. > >>> This essentially ignores the CRL for any object published within the >>> repository and essentially moves its role over to the manifest. The >>> CRL would still be considered for objects published outside the >>> repository, such as the proposed Resource Tagged Assertions. >> A missing manifest is a serious concern, but I would consider using >> cached, still valid objects for the PP, and insisting on contacting >> the CA or PP maintainer. > If the manifest takes over the CRL’s responsibility of expressing > revocation, you’d open a window to replay revoked objects. So this > translates to the question: What would you do today for a stale or > missing CRL? I don't understand your example. If a manifest trumps a CRL, then revoked objects would not appear on a current manifest and so replay of such objects would be ignored, right? Steve From nobody Thu Apr 16 10:44:10 2020 Return-Path: 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 ; 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 ; 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 ; 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 To: Claudio Jeker Cc: Martin Hoffmann , "sidrops@ietf.org" , Job Snijders References: <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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 17:44:01 -0000 This is a multi-part message in MIME format. --------------2DDF9962A64F69379D43DDE2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 --------------2DDF9962A64F69379D43DDE2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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

--------------2DDF9962A64F69379D43DDE2-- From nobody Thu Apr 16 10:44:15 2020 Return-Path: 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 3F5B83A09A6 for ; Thu, 16 Apr 2020 10:44:01 -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=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 3zkFEwzzIlcV for ; 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 710583A09F1 for ; 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 To: Claudio Jeker Cc: Martin Hoffmann , "sidrops@ietf.org" , Job Snijders References: <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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 17:44:01 -0000 This is a multi-part message in MIME format. --------------2DDF9962A64F69379D43DDE2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 --------------2DDF9962A64F69379D43DDE2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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

--------------2DDF9962A64F69379D43DDE2-- From nobody Thu Apr 16 15:48:29 2020 Return-Path: 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 2A5183A12A3 for ; Thu, 16 Apr 2020 15:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=algebras-org.20150623.gappssmtp.com 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 F5keOWVjmmSk for ; Thu, 16 Apr 2020 15:48:26 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 0A3DA3A12A1 for ; Thu, 16 Apr 2020 15:48:25 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id f3so276284ioj.1 for ; Thu, 16 Apr 2020 15:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HE2EjKBxDJyvy3rR8dlHaN1cGtHpKYz6/FoQHfwXyPU=; b=Gy9OrbYe3Ku95RKnhFpK4rAGfI3YQAKTmtRnjY6ywtAY7t+j01lcGAtV32Xfq/7dnr UUDZ1eAPHRR7qvs/dNSp7WObsJWQ9G9W1bgtDaWaCVK6QrfOqqrygtimyaM9EtZgwm9t NMPeeIslkad/qwkYH1ADvr4WiX2uf77rNdXyX5GQiaLNk36T9MsH+SN7uZQH5mqzwBZF fSKtIFcVpFw7uS1luP86GfpF6PtGFwSWjukSK8yZRAt0ektp22s7Uk/MoPMTJhBaEUzI 5xl9sNs+FzcA33CkiHvTKUVI3R3op7+WP7j//B7o9gk2ejr5Rl93RNrJ2VmVna78Kohj 5JkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HE2EjKBxDJyvy3rR8dlHaN1cGtHpKYz6/FoQHfwXyPU=; b=E3xlqxBEKE4GfaB8KaoRfufHqg8LZpznOYqoR0I9RISPoLlQzlNFd67yOVzSWDzHs7 zUBh7ukNs1sZ9W4jNnP+3d5itlhlRi59GQYZXXREwyhk1zLYzn4eT87Cw+BbQCVDw3Ac Y+bEYeodGHJMLOAQm4nl2lR8MVZOA8jDtsyuBlsxjpJL5O3NLtiHj1vSc6S8j1xfP8mF J0nh0/w/RvwC/d18nY3LDrAAaGeU/Yc3NzZCj30AVvNZ00GRiQAABFQ04VAiadXGX/aK rXKKK60qWwSIA2mI5aEKBIo8elbx5uIKylGDjfF4LWFm5SbB/6A4HNSh3RaTbsEjyNSh eVYg== X-Gm-Message-State: AGi0PuZ6xXLoaAq8Mc4oSmeiJAAXUToPYZIc6dtPssJf7CegNiaCQ5xw Jhoxoh+0hSns7ai7lJS6zZ079eZuaEk4izan5G4V8w== X-Google-Smtp-Source: APiQypJEMMSCwo0rA8XQL1GA6tWDzgKJtwVgneO0Tmvd8qI2oV0X3WGo7i/AxLSk+laUykcyoZu+/0AZIIZ7gp3OlIA= X-Received: by 2002:a05:6602:34c:: with SMTP id w12mr252058iou.56.1587077303844; Thu, 16 Apr 2020 15:48:23 -0700 (PDT) MIME-Version: 1.0 References: <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> <8ffd835c-cd11-5af0-81bf-d8935e0e2190@verizon.net> In-Reply-To: <8ffd835c-cd11-5af0-81bf-d8935e0e2190@verizon.net> From: George Michaelson Date: Fri, 17 Apr 2020 08:48:12 +1000 Message-ID: To: Stephen Kent Cc: Claudio Jeker , "sidrops@ietf.org" , Martin Hoffmann , Job Snijders Content-Type: text/plain; charset="UTF-8" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 22:48:28 -0000 If a ROA object can be removed and a manifest proves it has been removed, and a CRL confirms it has not been revoked, the unknown question is: * what was the semantic intent of the ROA? If you have a previously acquired state of the ROA which meets the manifest checksum/sig and its not in the current CRL *ITS NOT MISSING* and you know its semantic intent. All is good. This is what maintenance of local cached state of fetching achieves. If you do NOT have a previously acquired state of the ROA, you cannot know its semantic intent. Job showed me that this means a covering aggregate ROA state which is superceded for a specific prefix can be invalidly interpreted as applying to the more specific. Any more specific. The semantic intent of unknown amounts of ROA covered space defined at this level in the CA hierarchy cannot be stated categorically because the missing ROA might modify any of them. Therefore, the ROA states of this level of the hierarchy and children, cannot be known categorically. IFF (and the FF is important) you don't have a valid ROA state cached, and you can detect from valid CRL and valid Manifest some ROA is missing, you cannot know how it modifies the routing intent in the ROA otherwise unaffected. I think therefore, you have to stop processing. But the IFF part is, if you do not have a valid prior-state fetch of the ROA. Just because "its missing" is not sufficient. If the one you have before refetch maches what the Manifest says is a signed state, you aren't missing anything. -G From nobody Fri Apr 17 01:06:12 2020 Return-Path: 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 F00C43A101D for ; Fri, 17 Apr 2020 01:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 FoK69iG0kd_v for ; Fri, 17 Apr 2020 01:06:07 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F68C3A10AE for ; Fri, 17 Apr 2020 01:05:59 -0700 (PDT) Received: from yoda.fritz.box (unknown [IPv6:2001:981:4b52:1:b4a7:2c39:255:587f]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 6A8F41E5E4; Fri, 17 Apr 2020 10:05:56 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1587110756; bh=5m0xlK28Wv/VTJ2EpO0JUAyVvRlyIBc+R0YcQK5uYeg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=hKRa3VRJuvhPFjwgAH7IrPYQT35O2Z910IJceYHW/OafbNdY0eEEhFN9wGb9qzfY2 h3GHbXZ507vziBe2ba699GNzfEX5qY68nrg+WoZ2gCgttT3CvgcfpLBBMNXloFY2yI R+hcV4JkTmoI64T6n2unyO49wqeZTaoQN95HzrS4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Tim Bruijnzeels In-Reply-To: Date: Fri, 17 Apr 2020 10:05:55 +0200 Cc: Stephen Kent , Job Snijders , "sidrops@ietf.org" , Martin Hoffmann , Claudio Jeker Content-Transfer-Encoding: quoted-printable Message-Id: References: <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> <8ffd835c-cd11-5af0-81bf-d8935e0e2190@verizon.net> To: George Michaelson X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 08:06:11 -0000 > On 17 Apr 2020, at 00:48, George Michaelson wrote: >=20 > If a ROA object can be removed and a manifest proves it has been > removed, and a CRL confirms it has not been revoked, the unknown > question is: >=20 > * what was the semantic intent of the ROA? >=20 > If you have a previously acquired state of the ROA which meets the > manifest checksum/sig and its not in the current CRL *ITS NOT MISSING* > and you know its semantic intent. All is good. This is what > maintenance of local cached state of fetching achieves. >=20 > If you do NOT have a previously acquired state of the ROA, you cannot > know its semantic intent. Job showed me that this means a covering > aggregate ROA state which is superceded for a specific prefix can be > invalidly interpreted as applying to the more specific. Any more > specific. The semantic intent of unknown amounts of ROA covered space > defined at this level in the CA hierarchy cannot be stated > categorically because the missing ROA might modify any of them. >=20 > Therefore, the ROA states of this level of the hierarchy and children, > cannot be known categorically. >=20 > IFF (and the FF is important) you don't have a valid ROA state cached, > and you can detect from valid CRL and valid Manifest some ROA is > missing, you cannot know how it modifies the routing intent in the ROA > otherwise unaffected. IFF.. I had to look that one up.. it stands for 'if and only if', right? >=20 > I think therefore, you have to stop processing. But the IFF part is, > if you do not have a valid prior-state fetch of the ROA. Just because > "its missing" is not sufficient. If the one you have before refetch > maches what the Manifest says is a signed state, you aren't missing > anything. Well, I think I agree and it's what I have been trying to say. If an = object is missing on a specific synchronisation job, but you still have = an old copy: you know the URL, you know the hash. So if a current MFT = refers to it, you can just use it. A thought I had on this is that RPs may consider treating withdraws (be = it rsync or rrdp) with prejudice. One could argue that an RP should only = forget an object seen when it has seen a positive statement that it's no = longer relevant: Object becomes relevant: - CA cert signs MFT listing object by URI and hash - The object matching the URI and hash is retrieved (rsync or RRDP, it = does not matter how) Object becomes irrelevant: - CA cert signs a new MFT where the object URI and hash combination is = removed; AND - The object was indeed validly signed under the CA cert (otherwise you open a poisoning window, I could list and delist your = objects) So, do not just remove the object because of rsync '--delete' or a = withdraw or update (publish with hash) seen in RRDP. Wait for a signed = confirmation. However, I understand that this will introduce quite some complexity = that may not work with existing implementations. There may also be = other, better ways. For example you could keep a reference counter of = MFTs referring to an object by URI and hash, and delete the object only = once: - it was marked for deletion (RRDP) and - the reference count is zero. Well at this point I should probably leave it to the people who write = the actual validation software to say something sensible - or shout at = me if you will. Just trying to contribute, don't mean to tell you how to = code :D Tim >=20 > -G >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Apr 17 01:26:12 2020 Return-Path: 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 6BFE73A108F for ; Fri, 17 Apr 2020 01:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 69kfo6u78vpS for ; Fri, 17 Apr 2020 01:26:09 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0617B3A108B for ; Fri, 17 Apr 2020 01:26:08 -0700 (PDT) Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 8EAE31E64D; Fri, 17 Apr 2020 10:26:06 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Fri, 17 Apr 2020 10:26:06 +0200 From: Martin Hoffmann To: George Michaelson Cc: Stephen Kent , Job Snijders , "sidrops@ietf.org" , Claudio Jeker Message-ID: <20200417102606.76583e78@glaurung.nlnetlabs.nl> In-Reply-To: References: <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> <8ffd835c-cd11-5af0-81bf-d8935e0e2190@verizon.net> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 08:26:11 -0000 George Michaelson wrote: > If a ROA object can be removed and a manifest proves it has been > removed, and a CRL confirms it has not been revoked, the unknown > question is: > > * what was the semantic intent of the ROA? > > If you have a previously acquired state of the ROA which meets the > manifest checksum/sig and its not in the current CRL *ITS NOT MISSING* > and you know its semantic intent. All is good. This is what > maintenance of local cached state of fetching achieves. A problem with this strategy is that it makes the resulting set of validated data depend on the point in time a cache did its last synchronisation. That is, a cache which has seen the ROA before it went off the manifest will produce a set of VRPs different from one that has either never synchronised the repository before or due to some sequence of updates at the publication point had removed the ROA as legitimately deleted. The question is: Are we fine with that? I am speaking from a perspective of someone who has to maintain and in particular test software and I would rather we had a validation strategy that depended only and exclusively on the data present after the last synchronisation. That also motivates my proposal that an object counts as revoked as soon as it disappears from the manifest. Kind regards, Martin From nobody Fri Apr 17 01:54:15 2020 Return-Path: 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 3843C3A10FC for ; Fri, 17 Apr 2020 01:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no 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 ymDpoX-rA97H for ; Fri, 17 Apr 2020 01:54:11 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DDC33A10FF for ; Fri, 17 Apr 2020 01:54:11 -0700 (PDT) Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 059851E70F; Fri, 17 Apr 2020 10:54:09 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Fri, 17 Apr 2020 10:54:08 +0200 From: Martin Hoffmann To: Stephen Kent Cc: sidrops@ietf.org Message-ID: <20200417105408.66e750b2@glaurung.nlnetlabs.nl> In-Reply-To: <123646a7-e1d5-e939-53fe-21f3326e79be@verizon.net> References: <20200415150141.016d021d@glaurung.nlnetlabs.nl> <20200416175326.3f04db80@glaurung.nlnetlabs.nl> <123646a7-e1d5-e939-53fe-21f3326e79be@verizon.net> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 08:54:13 -0000 Stephen Kent wrote: > Martin, > > ... > > > > That wasn=E2=80=99t quite the case I was thinking of (although I think = this > > is a case worth calling out specifically to avoid confusion), but > > rather a case where say, a ROA=E2=80=99s EE certificate contains a URI = for > > the CRL Distribution Point that is referring to a CRL that is not > > listed in the issuing CA=E2=80=99s manifest. =20 > This would be an error by the CA. RFC 6480 notes where the CRL is=20 > supposed to live in the repository system. I know I am being pedantic (but then implementers are surprisingly creative), but I can=E2=80=99t find normative text in RFC 6480 either that = says there must only be one CRL per CA. > >>> 1.Manifest present, valid, current > >>> > >>> If there is a present, valid, and current manifest, the CRL can > >>> safely be ignored for all objects. =20 > >> Tim has suggested that, but to do so would make the RPKI not > >> consistent with RFC 5280. =20 > > I=E2=80=99m not sure. In section 6.1.3, RFC 5280 says > > > > | (3) At the current time, the certificate is not revoked. This > > | may be determined by obtaining the appropriate CRL > > | (Section 6.3), by status information, or by out-of-band > > | mechanisms. > > > > Determining certificate revocation via lack of presence on a > > manifest could be construed as an "out-of-band" mechanism. =20 > This part of 5280 is designed to accommodate OCSP as a revocation > status distribution mechanism, something that was not part of X.509. If it intended to only allow OCSP, it should have said so. The way it is formulated now, it opens up the option to devise any appropriate mechanism. > The RPKI requires CAs to publish CRLs, and it states where the CRLs > are to be published in the repository system (RFC 6480). The RPKI can be changed based on implementation and operational experience. This ought to be done in a backwards compatible way, of course, for instance by still requiring the publication of CRLs but not considering them in validation of in-repository signed objects.=20 > >>> If the aim is to avoid risking accidentally marking routes as > >>> invalid, this should probably also extend to all information > >>> published by child CAs. =20 > >> is the concern here that ROAs issued by a subordinate CA might be > >> treated differently if there is a missing ROA associated with the > >> parent? =20 > > I was thinking of the possible case that the parent issues a ROA > > for a resource but also delegates it to a child CA which then issues > > additional ROAs for the same resource. If the parent ROA is missing, > > you cannot rule out that the was indeed the case, so in order to be > > safe, you=E2=80=99d have to discard all ROAs for prefixes associated wi= th > > the parent. =20 > So, the parent issues a ROA binding a range of addresses to an AS > that the parent holds. But then=C2=A0 the parent delegates the same range > to a child, which is free to bind the addresses to a different AS > (that the child holds). Thus a route advertising either AS as the > origin is valid. If the parent's ROA is missing, the AS bound to it > is no longer considered valid, but the child's ROA is. So, why does > one have to discard/ignore all other ROAs associated with the parent? Because if the actual route is from the ASN authorised by the child, the announcement suddenly becomes invalid instead of unknown. Given the operational split between object creation and object publication, it doesn=E2=80=99t necessarily have to be the fault of the child that that happened. > > =20 > >>>> 3.Manifest present, but invalid =20 > >>> The entire PP is ignored. =20 > >> So, it's OK to ignore a CRL that is invalid, but not a manifest. > >> Personally I believe that if a CA cannot manage to correctly > >> generate both a CRL and a manifest, it has a serious operational > >> problem. =20 > > Indeed. However, bugs exist and unexpected things have a tendency to > > happen. I still fail to see how, given a strict adherence to the > > manifest, the CRL provides additional value for objects published > > within the RPKI repository. So for robustness, it may indeed be > > preferable to remove this additional possibility for breakage. =20 > As I noted in my reply to Tim a while ago, if we want to view the=20 > manifest as the only critical determinant of whether a cert is > revoked, then why bother checking the validity interval for the EE > certs? The same reason we check them with CRLs: the possibility of replay attacks of the revocation source. Using the manifest for revocation has the exact same issues as using a CRL. All it does is drop the need to maintain two objects instead of one. > > If the manifest takes over the CRL=E2=80=99s responsibility of expressi= ng > > revocation, you=E2=80=99d open a window to replay revoked objects. So t= his > > translates to the question: What would you do today for a stale or > > missing CRL? =20 >=20 > I don't understand your example. If a manifest trumps a CRL, then=20 > revoked objects would not appear on a current manifest and so replay > of such objects would be ignored, right? The question was about _today_, as in with the current situation where a signed object=E2=80=99s certificate remains valid even if the object drop= ped off the manifest, what do you do if a current CRL cannot be obtained? The mechanism from RFC 5280 specifically states that it relies on you being able to get the current CRL, so it cannot be used at all in this case. What would your guidance be to me as an implementer of a relying party software today? Even if I allow users of my software to choose what to do (aka "local policy"), I need to pick a default that pretty much everyone will then use. Kind regards, Martin From nobody Fri Apr 17 10:07:54 2020 Return-Path: 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 6A6563A082C for ; Fri, 17 Apr 2020 10:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=unavailable autolearn_force=no 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 v8biJ9LF1t4R for ; Fri, 17 Apr 2020 10:07:43 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF88D3A08D2 for ; Fri, 17 Apr 2020 10:07:42 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jPUSY-000899-VR; Fri, 17 Apr 2020 17:07:23 +0000 Date: Fri, 17 Apr 2020 10:07:20 -0700 Message-ID: From: Randy Bush To: Tim Bruijnzeels Cc: George Michaelson , Claudio Jeker , Stephen Kent , Martin Hoffmann , "sidrops@ietf.org" , Job Snijders In-Reply-To: References: <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> <8ffd835c-cd11-5af0-81bf-d8935e0e2190@verizon.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 17:07:53 -0000 > If an object is missing on a specific synchronisation job, but you > still have an old copy: you know the URL, you know the hash. So if a > current MFT refers to it, you can just use it. but something is broken From nobody Sat Apr 18 12:26:49 2020 Return-Path: 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 8245B3A10E4 for ; Sat, 18 Apr 2020 12:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 8Xcpr1XGTd3L for ; Sat, 18 Apr 2020 12:26:46 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 002773A10C5 for ; Sat, 18 Apr 2020 12:26:45 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jPt6w-0003PP-Kc for sidrops@ietf.org; Sat, 18 Apr 2020 19:26:42 +0000 Date: Sat, 18 Apr 2020 12:26:42 -0700 Message-ID: From: Randy Bush To: SIDR Operations WG User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] agenda X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2020 19:26:48 -0000 while the agenda for monday's meeting is a sweet tribute to biff: Agenda - Interim 04/2020 1) CRL ? Manifest ? Hashbrowns? - guidance for chefs 2) other ongoing work 3) punch and pie perhaps we have more to discuss. i would like to solicit help to work on the timing mess, which is already causing problems. From: Randy Bush Subject: Re: [Sidrops] rpki rp frequency To: Jared Mauch Cc: SIDR Operations WG , Di Ma Date: Mon, 13 Apr 2020 10:30:55 -0700 >>>>> As often as necessary that the RP can synchronize with a repository. >>>> how often is 'necessary?' in units of time, please. >>> I think It is the ISP who defines what is necessary. >> what is reasonable for the good of routing in the internet? i suggest >> an hour. >> before notify, we tolerated dns propagation of a day, and it was very >> painful. that seems primitive and silly now. > Most of the IRRs are mirroring at an interval of 5 minutes or so these > days, or that was one of the last things I asked to be changed at 2914 > before I left to ensure regular sync. > I think 300s is reasonable, but 3600 (60 min) is likely the high limit. there are the questions of how frequently a CA publishes, how often an RP pulls, and how often routers pull from their RP(s). for CA publishing, a few seconds seems easily achieved with reasonable software. for RPs pulling, 600s may be optimistic in the short term given o the load it will put on publication services o and one notorious repo which is against spec but it should be achievable in a while. an hour would be the longest acceptable in my mind today. for the router(s) pulling from the RP(s), 300-3600s is a wide window. but remember, the rpki-rtr protocol does have the equivalent of dns notify, where the cache tells the router that it has some nice tasty new data. you're welcome :) i imagine that few here are old enough to remember when curtis only updated the backbone (there was only one) routing peering once a week on wednesday. if we want the internet to rely on this stuff, it's time to get into the 21st century. randy randy From nobody Mon Apr 20 00:47:56 2020 Return-Path: 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 E9E553A1393 for ; Mon, 20 Apr 2020 00:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 PwZRemcWUoa0 for ; Mon, 20 Apr 2020 00:47:52 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A56A3A1394 for ; Mon, 20 Apr 2020 00:47:52 -0700 (PDT) Received: from bufobufo.ripe.net ([193.0.23.13]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jQR9h-00016Z-R6 for sidrops@ietf.org; Mon, 20 Apr 2020 09:47:49 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::f61]) by bufobufo.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jQR9h-0002rm-Ot for sidrops@ietf.org; Mon, 20 Apr 2020 09:47:49 +0200 From: Nathalie Trenaman Content-Type: multipart/alternative; boundary="Apple-Mail=_4E236C9D-3C5A-47B3-942D-E67F6676F84F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <066BFDB3-5009-4DF1-9882-E5D84E6F5380@ripe.net> Date: Mon, 20 Apr 2020 09:47:49 +0200 To: SIDR Operations WG X-Mailer: Apple Mail (2.3608.80.23.2.2) X-ACL-Warn: Delaying message X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a772f66107ad40bb05d28a71fd0a2df16 Archived-At: Subject: [Sidrops] Reminder: SIDR Operations (sidrops) WG Virtual Meeting: 2020-04-28 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 07:47:54 -0000 --Apple-Mail=_4E236C9D-3C5A-47B3-942D-E67F6676F84F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, This is a gentle reminder: The SIDR Operations (sidrops) Working Group will hold a virtual interim meeting on 2020-04-28 from 16:00 to 18:00 = Europe/Amsterdam (14:00 to 16:00 UTC). Agenda: Agenda - Interim 04/2020 1) CRL ? Manifest ? Hashbrowns? - guidance for chefs 2) other ongoing work 3) punch and pie Please let us know if you wish to present. We still have plenty of time = in the agenda. Please send slides to sidrops-chairs@ietf.org = We will hold the meeting on WebEx. Later this week, we=E2=80=99ll = publish the link on https://datatracker.ietf.org/meeting/upcoming = Thanks, Keyur, Chris and Nathalie= --Apple-Mail=_4E236C9D-3C5A-47B3-942D-E67F6676F84F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = all,

This is a = gentle reminder:

The SIDR Operations (sidrops) Working Group will hold
a virtual interim meeting on 2020-04-28 from 16:00 to 18:00 = Europe/Amsterdam (14:00 to 16:00 UTC).

Agenda:
Agenda - Interim 04/2020

1) CRL ? Manifest ? Hashbrowns? - guidance for = chefs
2) other ongoing work
3) punch and = pie

Please let = us know if you wish to present. We still have plenty of time in the = agenda. Please send slides to sidrops-chairs@ietf.org

We will hold the meeting on WebEx. = Later this week, we=E2=80=99ll publish the link on https://datatracker.ietf.org/meeting/upcoming

Thanks,
Keyur, Chris and Nathalie
= --Apple-Mail=_4E236C9D-3C5A-47B3-942D-E67F6676F84F-- From nobody Mon Apr 20 00:52:06 2020 Return-Path: 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 3698E3A13E6 for ; Mon, 20 Apr 2020 00:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 8rMpwF1k9kQk for ; Mon, 20 Apr 2020 00:51:59 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F7D53A13E4 for ; Mon, 20 Apr 2020 00:51:59 -0700 (PDT) Received: from bufobufo.ripe.net ([193.0.23.13]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jQRDh-0001DF-7R; Mon, 20 Apr 2020 09:51:57 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::f61]) by bufobufo.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jQRDh-00034w-5D; Mon, 20 Apr 2020 09:51:57 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Nathalie Trenaman In-Reply-To: Date: Mon, 20 Apr 2020 09:51:56 +0200 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Randy Bush X-Mailer: Apple Mail (2.3608.80.23.2.2) X-ACL-Warn: Delaying message X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92ae02f0391bac90c0f42fae0397f9b2ba3 Archived-At: Subject: Re: [Sidrops] agenda X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 07:52:04 -0000 Hi Randy, Thanks for offering. We=E2=80=99ll add that to the agenda. Shall I add = it as 'RPKI refresh timers=E2=80=9D or do you have another suggestion? = Oh, and do please send slides ;) Nathalie > Op 18 apr. 2020, om 21:26 heeft Randy Bush het = volgende geschreven: >=20 > while the agenda for monday's meeting is a sweet tribute to biff: >=20 > Agenda - Interim 04/2020 >=20 > 1) CRL ? Manifest ? Hashbrowns? - guidance for chefs > 2) other ongoing work > 3) punch and pie >=20 > perhaps we have more to discuss. i would like to solicit help to work > on the timing mess, which is already causing problems. >=20 > From: Randy Bush > Subject: Re: [Sidrops] rpki rp frequency > To: Jared Mauch > Cc: SIDR Operations WG , Di Ma = > Date: Mon, 13 Apr 2020 10:30:55 -0700 >=20 > >>>>> As often as necessary that the RP can synchronize with a = repository. > >>>> how often is 'necessary?' in units of time, please. > >>> I think It is the ISP who defines what is necessary. > >> what is reasonable for the good of routing in the internet? = i suggest > >> an hour. > >> before notify, we tolerated dns propagation of a day, and it = was very > >> painful. that seems primitive and silly now. > > Most of the IRRs are mirroring at an interval of 5 minutes or = so these > > days, or that was one of the last things I asked to be changed = at 2914 > > before I left to ensure regular sync. > > I think 300s is reasonable, but 3600 (60 min) is likely the = high limit. >=20 > there are the questions of how frequently a CA publishes, how = often an > RP pulls, and how often routers pull from their RP(s). >=20 > for CA publishing, a few seconds seems easily achieved with = reasonable > software. >=20 > for RPs pulling, 600s may be optimistic in the short term given > o the load it will put on publication services > o and one notorious repo which is against spec > but it should be achievable in a while. an hour would be the = longest > acceptable in my mind today. >=20 > for the router(s) pulling from the RP(s), 300-3600s is a wide = window. > but remember, the rpki-rtr protocol does have the equivalent of = dns > notify, where the cache tells the router that it has some nice = tasty > new data. you're welcome :) >=20 > i imagine that few here are old enough to remember when curtis = only > updated the backbone (there was only one) routing peering once a = week > on wednesday. >=20 > if we want the internet to rely on this stuff, it's time to get = into the > 21st century. >=20 > randy >=20 > randy >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Mon Apr 20 03:10:28 2020 Return-Path: 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 D617A3A09F5 for ; Mon, 20 Apr 2020 03:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 5t0xI6Lpa4dv for ; Mon, 20 Apr 2020 03:10:25 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22DC93A09F4 for ; Mon, 20 Apr 2020 03:10:24 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jQTNd-0008SO-Lg; Mon, 20 Apr 2020 10:10:21 +0000 Date: Mon, 20 Apr 2020 03:10:21 -0700 Message-ID: From: Randy Bush To: Nathalie Trenaman Cc: SIDR Operations WG In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-2022-JP Archived-At: Subject: Re: [Sidrops] agenda X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 10:10:27 -0000 mornin' nathalie, > Thanks for offering. We$B!G(Bll add that to the agenda. Shall I add it as > 'RPKI refresh timers$B!I(B or do you have another suggestion? Oh, and do > please send slides ;) there will be a draft, maybe in two days. in the meantime, you can find it at draft-ymbk-rpki-rov-timing Timing Parameters in the RPKI-based Route Origin Validation Supply Chain https://github.com/randyqx/rpki-rov-timing waiting to see if co-author(s) actually author :) after the meeting, will likely ask for WG adoption. --- also for the agenda, https://datatracker.ietf.org/doc/draft-ietf-sidrops-8210bis/ The Resource Public Key Infrastructure (RPKI) to Router Protocol Version 2 which i would hope to WGLC after discussion. it would be good if folk reviewed it before alvaro does for IETF LC :) --- will have slides for you, but getting draft-ymbk-sidrops-rpki-rov-timing in good shape comes first. randy From nobody Mon Apr 20 05:00:47 2020 Return-Path: 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 648323A0BF6 for ; Mon, 20 Apr 2020 05:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.19 X-Spam-Level: X-Spam-Status: No, score=-0.19 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 EEkYe0ZQa3ZD for ; Mon, 20 Apr 2020 05:00:38 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CC623A0BF4 for ; Mon, 20 Apr 2020 05:00:33 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:d0a9:c67f:9de6:ce5e] (unknown [IPv6:2001:981:4b52:1:d0a9:c67f:9de6:ce5e]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 3373D12ED0; Mon, 20 Apr 2020 14:00:25 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1587384025; bh=3unjm5dx4m+6D+loyzCD/piO/3IQaTNkfZTYG2OE7wA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=EbH/xxzPbmn5sRD70NGMGQ/5worA6jFnl7yc9yl57hXDgICeeEAeXao9vjxs3InFt j7GBTOBtfvpP32iJlF2ixUInLBI3pwxRm/zSyKAN/PUkLCUaSOHkR5BOf+axLvN1Pa mLyfYcrv9lu6AGrhTujwCiLhCFNrNDGHwukkg2S0= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Tim Bruijnzeels In-Reply-To: <066BFDB3-5009-4DF1-9882-E5D84E6F5380@ripe.net> Date: Mon, 20 Apr 2020 14:00:24 +0200 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <066BFDB3-5009-4DF1-9882-E5D84E6F5380@ripe.net> To: Nathalie Trenaman X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Sidrops] Reminder: SIDR Operations (sidrops) WG Virtual Meeting: 2020-04-28 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 12:00:47 -0000 Hi Nathalie, all, > On 20 Apr 2020, at 09:47, Nathalie Trenaman wrote: >=20 > Hi all, >=20 > This is a gentle reminder: >=20 > The SIDR Operations (sidrops) Working Group will hold > a virtual interim meeting on 2020-04-28 from 16:00 to 18:00 = Europe/Amsterdam (14:00 to 16:00 UTC). >=20 > Agenda: > Agenda - Interim 04/2020 >=20 > 1) CRL ? Manifest ? Hashbrowns? - guidance for chefs > 2) other ongoing work > 3) punch and pie >=20 > Please let us know if you wish to present. We still have plenty of = time in the agenda. Please send slides to sidrops-chairs@ietf.org I would like to add deprecating rsync to the agenda. I believe it's time = to move on to RRDP, and I believe that doing so will help with a number = of issues regarding agenda item #1. In particular, RRDP allows publishing CRLs and MFTs and any other = updated objects, as deltas - reducing the window for inconsistent = fetches. And imperfect as it may be TLS verification in HTTPS adds a = layer of defence w.r.t. MiTM attacks - provided TLS verification could = become mandatory. I wrote a (straw-man?) draft about this last year, which was intended to = get discussion started: = https://datatracker.ietf.org/doc/draft-sidrops-bruijnzeels-deprecate-rsync= / But I am more than happy to work with others on this. And hopefully ask = for WG adoption and discussion. I am sure I am not the only one thinking = about this :) Tim >=20 > We will hold the meeting on WebEx. Later this week, we=E2=80=99ll = publish the link on https://datatracker.ietf.org/meeting/upcoming >=20 > Thanks, > Keyur, Chris and Nathalie > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Mon Apr 20 11:58:17 2020 Return-Path: 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 80E773A0F0C for ; Mon, 20 Apr 2020 11:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.011 X-Spam-Level: X-Spam-Status: No, score=0.011 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no 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 secV9oSZa71v for ; Mon, 20 Apr 2020 11:57:56 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8143A0DD2 for ; Mon, 20 Apr 2020 11:54:33 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jQbYu-0001Gm-6F; Mon, 20 Apr 2020 18:54:32 +0000 Date: Mon, 20 Apr 2020 11:54:31 -0700 Message-ID: From: Randy Bush To: Tim Bruijnzeels Cc: SIDR Operations WG User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] draft-sidrops-bruijnzeels-deprecate-rsync X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 18:58:16 -0000 > https://datatracker.ietf.org/doc/draft-sidrops-bruijnzeels-deprecate-rsync/ quite willing to discuss this and am still willing to co-author if you wish. but i am pretty firm about not breaking the running internet. to quote myself from last year great to get the draft out there. wish it was more specific about how this is operationally accomplished. e.g. from the discussion i was trying to have with you: 0 - publishers publish rcynic and some rrdp. rps use rcynic and some use rrdp 1 - all publishers offer both. 2 - then you can ask all rps to move to rrdp and prefer it 3 - you can see, at the publishers, when no rcynic requests come 4 - you can turn off rcynic at the publishers 5 - you can remove rcynic from the rps whether we like it or not, there are a significan number of rcynic-only relying parties out there. we need to help and encourage the transition. we MAY NOT break the running internet. there From nobody Mon Apr 20 19:16:18 2020 Return-Path: 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 722693A1599 for ; Mon, 20 Apr 2020 19:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 qs3zX4XQBDFF for ; Mon, 20 Apr 2020 19:16:03 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E0E23A159C for ; Mon, 20 Apr 2020 19:16:03 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jQiS9-0002W2-IB; Tue, 21 Apr 2020 02:16:01 +0000 Date: Mon, 20 Apr 2020 19:15:59 -0700 Message-ID: From: Randy Bush To: SIDR Operations WG In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] draft-sidrops-bruijnzeels-deprecate-rsync X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 02:16:17 -0000 look, no one likes rcynic. but it has carried us for a decade now, so i treat it with respect. it will take us another decade to completely get rid of it. remember, it took me eight years to get a constant changed from 4k to 16k (RFC 8654). one of the things the pandemic should be teaching us is patience. we are stewards of the internet. we do not intentionally break it. we do that enough accidentally. luckily, we can turn preventing the latter into a career :). so let us figure out the safe path to move forward, document it, and start moving down it. but the goal is some time away. and likely, by the time it is close, we will be discussing how to get rid of RRDP. randy From nobody Tue Apr 21 00:59:21 2020 Return-Path: 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 161D63A07F6 for ; Tue, 21 Apr 2020 00:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 eRcV0HhLgHbr for ; Tue, 21 Apr 2020 00:59:18 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8666F3A07F5 for ; Tue, 21 Apr 2020 00:59:18 -0700 (PDT) Received: from bufobufo.ripe.net ([193.0.23.13]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jQnoL-0005gK-11; Tue, 21 Apr 2020 09:59:17 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::cf4]) by bufobufo.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jQnoK-0005Xl-VE; Tue, 21 Apr 2020 09:59:16 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Nathalie Trenaman In-Reply-To: Date: Tue, 21 Apr 2020 09:59:16 +0200 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <7720761E-4024-40E4-9FB7-11E003BFD7A9@ripe.net> References: <066BFDB3-5009-4DF1-9882-E5D84E6F5380@ripe.net> To: Tim Bruijnzeels X-Mailer: Apple Mail (2.3608.80.23.2.2) X-ACL-Warn: Delaying message X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92ac9572a90900ada7cf5f56c8ab72700b2 Archived-At: Subject: Re: [Sidrops] Reminder: SIDR Operations (sidrops) WG Virtual Meeting: 2020-04-28 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 07:59:20 -0000 Hi Tim, > Op 20 apr. 2020, om 14:00 heeft Tim Bruijnzeels het = volgende geschreven: >=20 > Hi Nathalie, all, >=20 >=20 >> On 20 Apr 2020, at 09:47, Nathalie Trenaman = wrote: >>=20 >> Hi all, >>=20 >> This is a gentle reminder: >>=20 >> The SIDR Operations (sidrops) Working Group will hold >> a virtual interim meeting on 2020-04-28 from 16:00 to 18:00 = Europe/Amsterdam (14:00 to 16:00 UTC). >>=20 >> Agenda: >> Agenda - Interim 04/2020 >>=20 >> 1) CRL ? Manifest ? Hashbrowns? - guidance for chefs >> 2) other ongoing work >> 3) punch and pie >>=20 >> Please let us know if you wish to present. We still have plenty of = time in the agenda. Please send slides to sidrops-chairs@ietf.org >=20 > I would like to add deprecating rsync to the agenda. I believe it's = time to move on to RRDP, and I believe that doing so will help with a = number of issues regarding agenda item #1. >=20 > In particular, RRDP allows publishing CRLs and MFTs and any other = updated objects, as deltas - reducing the window for inconsistent = fetches. And imperfect as it may be TLS verification in HTTPS adds a = layer of defence w.r.t. MiTM attacks - provided TLS verification could = become mandatory. >=20 > I wrote a (straw-man?) draft about this last year, which was intended = to get discussion started: > = https://datatracker.ietf.org/doc/draft-sidrops-bruijnzeels-deprecate-rsync= / >=20 > But I am more than happy to work with others on this. And hopefully = ask for WG adoption and discussion. I am sure I am not the only one = thinking about this :) >=20 > Tim >=20 >=20 >=20 Noted, will add you.=20 Nathalie= From nobody Tue Apr 21 02:11:15 2020 Return-Path: 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 39EFE3A09C4 for ; Tue, 21 Apr 2020 02:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=nlnetlabs.nl 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 6ryl7ewMeV96 for ; Tue, 21 Apr 2020 02:11:11 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE02A3A09C2 for ; Tue, 21 Apr 2020 02:11:10 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:10c1:16a5:febc:ba2a] (unknown [IPv6:2001:981:4b52:1:10c1:16a5:febc:ba2a]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id F3DEF148CC; Tue, 21 Apr 2020 11:11:08 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1587460269; bh=PX2N0mdHIp7VmDDTX4nJEBWeehCaSg1w7CvyQewn4kU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=fDGgIFnklFGA/WwOu1CndBIS6v+K5VLXGk9trWS6BFB1Y0sg87lYlbEOdzR7kGrRd lEkr4spa1p04gSLpaKkL2yhWo9oV7I1MMJF/U0nmzHyVfWQ876iloS2k6RrHaw2aaP EZONivDvVZ0v7ELjqUWJ+i+jYbx7GiYeqdJGTwug= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Tim Bruijnzeels In-Reply-To: Date: Tue, 21 Apr 2020 11:11:08 +0200 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Randy Bush X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Sidrops] draft-sidrops-bruijnzeels-deprecate-rsync X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 09:11:15 -0000 Hi, > On 21 Apr 2020, at 04:15, Randy Bush wrote: >=20 > look, no one likes rcynic. but it has carried us for a decade now, so = i > treat it with respect. it will take us another decade to completely = get > rid of it. remember, it took me eight years to get a constant changed > from 4k to 16k (RFC 8654). one of the things the pandemic should be > teaching us is patience. For sure. And for the record: I am a big fan of rsync in other contexts. = Also it was a useful start. Still, I want to move on for reasons I won't = repeat here unless pushed :) >=20 > we are stewards of the internet. we do not intentionally break it. = we > do that enough accidentally. luckily, we can turn preventing the = latter > into a career :). >=20 > so let us figure out the safe path to move forward, document it, and > start moving down it. but the goal is some time away. and likely, by > the time it is close, we will be discussing how to get rid of RRDP. Fully agree. At the moment the document is still very open about time lines and what = can happen first. This was done this way because at the time it was not = clear to me whether we could get CA (and Repository Server) operators to = implement RRDP soon 'enough', and I did not want this to be a reason for = RP implementers not to start supporting RRDP. As it stands today I believe that Lacnic is the only major repository = which does not support RRDP yet, and everyone else either supports or is = running software which is capable. I don't believe that Lacnic is = opposed, but I believe we should also be reasonable in our expectations = especially given the pandemic that makes life hard across the globe. So, in short I am quite open to a more clear plan where we ask all = repositories to support first, then ask / demand RPs to prefer RRDP, and = eventually - after measurements - make rsync optional and/or deprecate = it completely. I will reply to you (Randy) in person to see if we can revise the draft = in time for Monday's meeting. Tim >=20 > randy >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Apr 21 04:07:19 2020 Return-Path: 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 290123A087C for ; Tue, 21 Apr 2020 04:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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 (1024-bit key) header.d=nlnetlabs.nl 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 JUy8fI-wxOsB for ; Tue, 21 Apr 2020 04:07:15 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13EE83A0879 for ; Tue, 21 Apr 2020 04:07:15 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:10c1:16a5:febc:ba2a] (unknown [IPv6:2001:981:4b52:1:10c1:16a5:febc:ba2a]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id DA91B14B46; Tue, 21 Apr 2020 13:07:12 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1587467232; bh=rx+J6zCPYPiwawJPwAdMyBNM626gohqclNE0T7GcPzw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=KWfx3bWsFX1CzanVrE5I+qqgLe+FDZSvspLdk+Z2lE4h1/QSLce/2M86uA4TGLj7n McMmFICqBQwu8JfGoRLgWArKBDba1t3GRnFJysgmveBngBnfad61Diod5cOfLmSsUj BPj89Nff+bpMeSOuA/ry4mIxFxO+PFRinEwVfJyg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Tim Bruijnzeels In-Reply-To: Date: Tue, 21 Apr 2020 13:07:12 +0200 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <3D9F48FC-822B-4C82-A5CB-D90B2746922B@nlnetlabs.nl> References: To: Randy Bush X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Sidrops] draft-sidrops-bruijnzeels-deprecate-rsync X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 11:07:17 -0000 Hi, > On 20 Apr 2020, at 20:54, Randy Bush wrote: >=20 >> = https://datatracker.ietf.org/doc/draft-sidrops-bruijnzeels-deprecate-rsync= / >=20 > quite willing to discuss this and am still willing to co-author if you > wish. but i am pretty firm about not breaking the running internet. >=20 > to quote myself from last year >=20 > great to get the draft out there. wish it was more specific about > how this is operationally accomplished. e.g. from the discussion i > was trying to have with you: >=20 > 0 - publishers publish rcynic and some rrdp. rps use rcynic and = some > use rrdp > 1 - all publishers offer both. > 2 - then you can ask all rps to move to rrdp and prefer it > 3 - you can see, at the publishers, when no rcynic requests come > 4 - you can turn off rcynic at the publishers > 5 - you can remove rcynic from the rps >=20 > whether we like it or not, there are a significan number of = rcynic-only > relying parties out there. we need to help and encourage the > transition. we MAY NOT break the running internet. I agree with your approach, now that it's really only Lacnic who still = need to do work on this. They have told me *informally* that they think = it can be done this year, but that was before covid. Still, the will is = there and it should not be show stopper. Shall I try to spin a new version with these changes and send it to both = of you by Thursday? Do you both want to co-author? Thanks Tim >=20 > there=20 >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Apr 21 04:17:50 2020 Return-Path: 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 2CBCB3A08BB for ; Tue, 21 Apr 2020 04:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 tY2tIaZXW8_f for ; Tue, 21 Apr 2020 04:17:47 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 965743A08B7 for ; Tue, 21 Apr 2020 04:17:46 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jQquP-0003f3-9d; Tue, 21 Apr 2020 11:17:45 +0000 Date: Tue, 21 Apr 2020 04:17:44 -0700 Message-ID: From: Randy Bush To: Tim Bruijnzeels Cc: SIDR Operations WG In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] draft-sidrops-bruijnzeels-deprecate-rsync X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 11:17:49 -0000 > As it stands today I believe that Lacnic is the only major repository > which does not support RRDP yet, and everyone else either supports or > is running software which is capable. that is the publishing sw, which is a small set. the long tail will be getting all the varied rps to strongly prefer rrdp, and use rcynic iff rrdp is not available. > I will reply to you (Randy) in person to see if we can revise the > draft in time for Monday's meeting. though i am also hacking on other documents, even one for sidrops, i will make time to help. randy From nobody Tue Apr 21 04:26:24 2020 Return-Path: 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 4159D3A08EA for ; Tue, 21 Apr 2020 04:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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 (1024-bit key) header.d=nlnetlabs.nl 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 jdRZMqlaaX9y for ; Tue, 21 Apr 2020 04:26:20 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65BB03A08ED for ; Tue, 21 Apr 2020 04:26:20 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:10c1:16a5:febc:ba2a] (unknown [IPv6:2001:981:4b52:1:10c1:16a5:febc:ba2a]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id C5E0714C48; Tue, 21 Apr 2020 13:26:18 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1587468378; bh=cxIKrXmUB7zu5kBWlqi7vCt/VTdcHdZXL/aMhqniiXE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=LVj9ugdBgaGeOvHTNTZoFc/d9fDyeRQaU9I3UXUfrvduGb2ZfGeuuW1ZpCoaEKCI5 T/r6AHDgpsnaQNNqrpd+IZvIqU09DoUS4t496D38FHoahk5tHfRGtxaFiLIx4i94dG d+gmLTY0lFztabJmJCXLf8vpj0ecDGlpFoD1rTeE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Tim Bruijnzeels In-Reply-To: <3D9F48FC-822B-4C82-A5CB-D90B2746922B@nlnetlabs.nl> Date: Tue, 21 Apr 2020 13:26:18 +0200 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <1FD05E35-B0E9-4BC4-BC8D-8ADC9907FF32@nlnetlabs.nl> References: <3D9F48FC-822B-4C82-A5CB-D90B2746922B@nlnetlabs.nl> To: Randy Bush X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Sidrops] draft-sidrops-bruijnzeels-deprecate-rsync X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 11:26:23 -0000 > On 21 Apr 2020, at 13:07, Tim Bruijnzeels wrote: >=20 > Hi, >=20 >> On 20 Apr 2020, at 20:54, Randy Bush wrote: >>=20 >>> = https://datatracker.ietf.org/doc/draft-sidrops-bruijnzeels-deprecate-rsync= / >>=20 >> quite willing to discuss this and am still willing to co-author if = you >> wish. but i am pretty firm about not breaking the running internet. >>=20 >> to quote myself from last year >>=20 >> great to get the draft out there. wish it was more specific about >> how this is operationally accomplished. e.g. from the discussion i >> was trying to have with you: >>=20 >> 0 - publishers publish rcynic and some rrdp. rps use rcynic and = some >> use rrdp >> 1 - all publishers offer both. >> 2 - then you can ask all rps to move to rrdp and prefer it >> 3 - you can see, at the publishers, when no rcynic requests come >> 4 - you can turn off rcynic at the publishers >> 5 - you can remove rcynic from the rps >>=20 >> whether we like it or not, there are a significan number of = rcynic-only >> relying parties out there. we need to help and encourage the >> transition. we MAY NOT break the running internet. >=20 > I agree with your approach, now that it's really only Lacnic who still = need to do work on this. They have told me *informally* that they think = it can be done this year, but that was before covid. Still, the will is = there and it should not be show stopper. My apologies lacnic, I did not mean to send this to all. Still I hope there is no harm done here. I am sure that everybody = understands that engineering resources need to be managed, especially = now. >=20 > Shall I try to spin a new version with these changes and send it to = both of you by Thursday? Do you both want to co-author? >=20 > Thanks > Tim >=20 >=20 >=20 >=20 >>=20 >> there=20 >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Apr 21 12:46:21 2020 Return-Path: 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 D7CF43A08E1 for ; Tue, 21 Apr 2020 12:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 EunLCVP7OAOW for ; Tue, 21 Apr 2020 12:46:06 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01DF83A0AE7 for ; Tue, 21 Apr 2020 12:45:29 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jQypi-00051I-Oa for sidrops@ietf.org; Tue, 21 Apr 2020 19:45:26 +0000 Resent-Message-Id: Resent-From: Randy Bush Resent-Date: Tue, 21 Apr 2020 12:45:25 -0700 Resent-To: sidrops@ietf.org Received: from psg.com ([2001:418:1::62]) by ran.psg.com with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jQyou-00050s-HS for randy@ran.psg.com; Tue, 21 Apr 2020 19:44:36 +0000 Received: from [4.31.198.44] (helo=mail.ietf.org) by psg.com with esmtps (TLS1.2) tls TLS_DH_anon_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4 (FreeBSD)) (envelope-from ) id 1jQyot-000JGo-P9 for randy@psg.com; Tue, 21 Apr 2020 19:44:35 +0000 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD8C3A08E8; Tue, 21 Apr 2020 12:44:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: "Randy Bush" , "Job Snijders" X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158749827548.5463.15001903361880084306@ietfa.amsl.com> Date: Tue, 21 Apr 2020 12:44:35 -0700 Archived-At: Subject: [Sidrops] New Version Notification for draft-ymbk-rpki-rov-timing-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 19:46:14 -0000 A new version of I-D, draft-ymbk-rpki-rov-timing-00.txt has been successfully submitted by Randy Bush and posted to the IETF repository. Name: draft-ymbk-rpki-rov-timing Revision: 00 Title: Timing Parameters in the RPKI based Route Origin Validation Supply Chain Document date: 2020-04-21 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-ymbk-rpki-rov-timing-00.txt Status: https://datatracker.ietf.org/doc/draft-ymbk-rpki-rov-timing/ Htmlized: https://tools.ietf.org/html/draft-ymbk-rpki-rov-timing-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-ymbk-rpki-rov-timing Abstract: This document explores, and makes recommendations for, timing of Resource Public Key Infrastructure publication, propagation, and use of RPKI ROV data in relying parties and routers. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Apr 21 12:58:10 2020 Return-Path: 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 47B2F3A090A for ; Tue, 21 Apr 2020 12:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 wuEVO31eiZnk for ; Tue, 21 Apr 2020 12:58:06 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 613AA3A0903 for ; Tue, 21 Apr 2020 12:58:06 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jQz1v-000528-RZ for sidrops@ietf.org; Tue, 21 Apr 2020 19:58:04 +0000 Date: Tue, 21 Apr 2020 12:58:00 -0700 Message-ID: From: Randy Bush To: SIDR Operations WG User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] draft-ymbk-rpki-rov-timing-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 19:58:08 -0000 From: internet-drafts@ietf.org Subject: New Version Notification for draft-ymbk-rpki-rov-timing-00.txt To: "Randy Bush" , "Job Snijders" Date: Tue, 21 Apr 2020 12:44:35 -0700 A new version of I-D, draft-ymbk-rpki-rov-timing-00.txt has been successfully submitted by Randy Bush and posted to the IETF repository. Name: draft-ymbk-rpki-rov-timing Revision: 00 Title: Timing Parameters in the RPKI based Route Origin Validation Supply Chain Document date: 2020-04-21 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-ymbk-rpki-rov-timing-00.txt Status: https://datatracker.ietf.org/doc/draft-ymbk-rpki-rov-timing/ Htmlized: https://tools.ietf.org/html/draft-ymbk-rpki-rov-timing-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-ymbk-rpki-rov-timing Abstract: This document explores, and makes recommendations for, timing of Resource Public Key Infrastructure publication, propagation, and use of RPKI ROV data in relying parties and routers. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed Apr 22 02:37:35 2020 Return-Path: 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 09CCF3A0C7D for ; Wed, 22 Apr 2020 02:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=aelmans-eu.20150623.gappssmtp.com 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 OPv2zZOdDkqk for ; Wed, 22 Apr 2020 02:36:24 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 819403A0C7A for ; Wed, 22 Apr 2020 02:36:24 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id f13so1529533wrm.13 for ; Wed, 22 Apr 2020 02:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aelmans-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/rNA4o44KgIvVsROD2KT4LpYWfOn/1CDKBca4VdHwCk=; b=r5zsCmo+/s4PXa7k74g3xuVd651tPpAl9NyPNtieyiOLEGasKU1eF1ylbFYEfprkha v39+A4NjV9YxRPPLqpVoMzDwsax5sQEaluxrDlWQ2ozKB3hb+pkJ+Q1fJOv7f2/xau7m CvHOiNO4177iosgTkKSkKDeOaktUaVOP05obIGcKGfQoPzdWxHPzF54jE4uD3HYmM0xW N1lcAIST1nuHmcYorzMKR8qOboJVVmL8Z30PFfWur4PrkRbtI/i+1P01KFupm0ZqCtlO WYd0fZ7yjN/SiTcFRQTOhykwzJhG/8ax237SYVV9OMTJ0FAXv+NVbNV2rnfKg/1qlu+b rf3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/rNA4o44KgIvVsROD2KT4LpYWfOn/1CDKBca4VdHwCk=; b=XtoO+Zf7FHH3+dkzXQch3GXEEXDd1NXTyS2sz/SxE5tQ5n+J7jaeeRZSCRsUBIxwhN NYdvsCpLmpZx0oWZMb83ViBW+58ZNMgMml4j+5uuHyQqQdggKJTVmd4mvfBhtxuZDCjq rydzKlHT0nnDK3hcOH6aSaEvoCeZVmCCLpp7KzRquF5MCGWsgcWQnPI/R0Cjt8F17EZR o24HmZERYO5V/EqegZYDHrBpBnr8CMeRKtElymlwR1dQl2rd4/yamgxzI7g3DWpamWIt O9fNU3xXL9ZROg/ldIKw/cj/IAxG5Y5CXQotJzDYhjE3rOj20HJY0t3lIjQAdt8umgsH mweA== X-Gm-Message-State: AGi0PuZyUC5fHrP3TbPHZ6cGdnrN+2L2go+zN8EtyypbvA+09rUGAFZq RgpjHsM4nJdRCtz9W92D9a/xn+bVRHIIeShxaJsEuQuE98Y8FsSF X-Google-Smtp-Source: APiQypIgm99QX8ZFGaElv3ro4se88KRgi9xmINBtfOxcD3wtoe8s8yZzxPC53Nv4BA4HAUgEB8BMqsfXQRzjQCA0SY8= X-Received: by 2002:adf:fdc1:: with SMTP id i1mr31748284wrs.158.1587548182415; Wed, 22 Apr 2020 02:36:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Melchior Aelmans Date: Wed, 22 Apr 2020 11:36:11 +0200 Message-ID: To: Randy Bush Cc: SIDR Operations WG Content-Type: multipart/alternative; boundary="0000000000007a214b05a3dddd23" Archived-At: Subject: Re: [Sidrops] draft-ymbk-rpki-rov-timing-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 09:36:27 -0000 --0000000000007a214b05a3dddd23 Content-Type: text/plain; charset="UTF-8" I like the Replying Party :) On Tue, Apr 21, 2020 at 9:58 PM Randy Bush wrote: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-ymbk-rpki-rov-timing-00.txt > To: "Randy Bush" , "Job Snijders" > Date: Tue, 21 Apr 2020 12:44:35 -0700 > > > A new version of I-D, draft-ymbk-rpki-rov-timing-00.txt > has been successfully submitted by Randy Bush and posted to the > IETF repository. > > Name: draft-ymbk-rpki-rov-timing > Revision: 00 > Title: Timing Parameters in the RPKI based Route Origin > Validation Supply Chain > Document date: 2020-04-21 > Group: Individual Submission > Pages: 6 > URL: > https://www.ietf.org/internet-drafts/draft-ymbk-rpki-rov-timing-00.txt > Status: > https://datatracker.ietf.org/doc/draft-ymbk-rpki-rov-timing/ > Htmlized: https://tools.ietf.org/html/draft-ymbk-rpki-rov-timing-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ymbk-rpki-rov-timing > > > Abstract: > This document explores, and makes recommendations for, timing of > Resource Public Key Infrastructure publication, propagation, and use > of RPKI ROV data in relying parties and routers. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --0000000000007a214b05a3dddd23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I like the=C2=A0Replying Party :)

On Tue, Apr 21, 2020 at 9:58 PM Randy Bush <randy@psg.com> wrote:
From: internet-drafts@ietf.org
Subject: New Version Notification for draft-ymbk-rpki-rov-timing-00.txt
To: "Randy Bush" <randy@psg.com>, "Job Snijders" <job@ntt.net>
Date: Tue, 21 Apr 2020 12:44:35 -0700


A new version of I-D, draft-ymbk-rpki-rov-timing-00.txt
has been successfully submitted by Randy Bush and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ymbk-rpki-rov-timing Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Timing Parameters in the RPKI base= d Route Origin Validation Supply Chain
Document date:=C2=A0 2020-04-21
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ymbk-rpki-rov-ti= ming-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ymbk-rpki-rov-timing/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /tools.ietf.org/html/draft-ymbk-rpki-rov-timing-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/html/draft-ymbk-rpki-rov-timing


Abstract:
=C2=A0 =C2=A0This document explores, and makes recommendations for, timing = of
=C2=A0 =C2=A0Resource Public Key Infrastructure publication, propagation, a= nd use
=C2=A0 =C2=A0of RPKI ROV data in relying parties and routers.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops
--0000000000007a214b05a3dddd23-- From nobody Wed Apr 22 04:57:14 2020 Return-Path: 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 C598E3A0A4A for ; Wed, 22 Apr 2020 04:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.901 X-Spam-Level: ** X-Spam-Status: No, score=2.901 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, GB_SUMOF=5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 oM0sKWIcnxpD for ; Wed, 22 Apr 2020 04:57:11 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239763A0A4B for ; Wed, 22 Apr 2020 04:57:11 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:143e:3685:6859:5dc0] (unknown [IPv6:2001:981:4b52:1:143e:3685:6859:5dc0]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 0AB6C16C19; Wed, 22 Apr 2020 13:57:09 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1587556629; bh=ju5WzGIe+IHCe302f3FyltJLj+FOmXGCpP9Qhke8SNc=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=dmQkizhUdbOJgWXXPp96oM9gni0S31Liudu1yQ54C93t0G+Z4V8vlOHeRuyEdPYhc W2x77SGqNdLv/a0OBNpR3uqI/oaf/n1zHCjzZrAchSpJWNpgCtaDVQ8eIVx91RSIKy XN4xCAYTrIA4wpf7sWxIpvTT5PrJ+bBDboLdpSV4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Tim Bruijnzeels In-Reply-To: Date: Wed, 22 Apr 2020 13:57:08 +0200 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <98A4118B-83F0-4BBD-BA22-794ADA475731@nlnetlabs.nl> References: To: Randy Bush X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Sidrops] draft-ymbk-rpki-rov-timing-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 11:57:13 -0000 Hi, s/rcynic/rsync/g Furthermore, I think the document could use some words on the chain = before the CA. i.e. timing of creation of ROAs in the CA w.r.t. changes = in announcements done. I would say that for planned changes ROAs should be created in advance, = X minutes where X > the sum of the timings after a CA creates a ROA and = until it's seen by routers. For unplanned changes, I guess they should = just be created ASAP, but it may help to quantify? As a side note. We are discussing moving from rsync to RRDP in another = thread. I believe that RRDP will help reduce propagation times. But I = have no doubt that further improvements can be conceived in future. It = helps to have guidance for maximum propagation times to serve as = guidance for requirements there. Tim > On 21 Apr 2020, at 21:58, Randy Bush wrote: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ymbk-rpki-rov-timing-00.txt > To: "Randy Bush" , "Job Snijders" > Date: Tue, 21 Apr 2020 12:44:35 -0700 >=20 >=20 > A new version of I-D, draft-ymbk-rpki-rov-timing-00.txt > has been successfully submitted by Randy Bush and posted to the > IETF repository. >=20 > Name: draft-ymbk-rpki-rov-timing > Revision: 00 > Title: Timing Parameters in the RPKI based Route Origin = Validation Supply Chain > Document date: 2020-04-21 > Group: Individual Submission > Pages: 6 > URL: = https://www.ietf.org/internet-drafts/draft-ymbk-rpki-rov-timing-00.txt > Status: = https://datatracker.ietf.org/doc/draft-ymbk-rpki-rov-timing/ > Htmlized: = https://tools.ietf.org/html/draft-ymbk-rpki-rov-timing-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ymbk-rpki-rov-timing >=20 >=20 > Abstract: > This document explores, and makes recommendations for, timing of > Resource Public Key Infrastructure publication, propagation, and use > of RPKI ROV data in relying parties and routers. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Apr 22 05:29:04 2020 Return-Path: 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 56F473A0B1B for ; Wed, 22 Apr 2020 05:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 8ElzNmgYSLnq for ; Wed, 22 Apr 2020 05:29:01 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 242243A0B17 for ; Wed, 22 Apr 2020 05:29:01 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jREUt-0007Hp-Hm; Wed, 22 Apr 2020 12:28:59 +0000 Date: Wed, 22 Apr 2020 05:28:59 -0700 Message-ID: From: Randy Bush To: Tim Bruijnzeels Cc: SIDR Operations WG In-Reply-To: <98A4118B-83F0-4BBD-BA22-794ADA475731@nlnetlabs.nl> References: <98A4118B-83F0-4BBD-BA22-794ADA475731@nlnetlabs.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] draft-ymbk-rpki-rov-timing-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 12:29:02 -0000 mornin' tim, thanks for review! > s/rcynic/rsync/g massimiliano already beat me up on that this morning. he had done a PR, i merged it, and then let spell check revert it . > Furthermore, I think the document could use some words on the chain > before the CA. i.e. timing of creation of ROAs in the CA w.r.t. > changes in announcements done. i am not understanding. do you mean possible CA to publication point delay? > I would say that for planned changes ROAs should be created in > advance yes. this was discussed many time in the design team. the ddos defense folk essentially said that most of the 'customers' come running in the door in panic and had never thought to do advanced planning. while i have some sympathy for that, i am not sure what we can say here other than o try to constrain the propagation time o point out that roa creation in advance of operational changes, be it circuit moves, ddos sinking, ... should be done sufficiently in advance. i'll try to do more. > As a side note. We are discussing moving from rsync to RRDP in another > thread. I believe that RRDP will help reduce propagation times. i tried to say that. will look again. > I have no doubt that further improvements can be conceived in future. > It helps to have guidance for maximum propagation times to serve as > guidance for requirements there. i am not understanding. maybe some coffee will help. thanks again. randy From nobody Wed Apr 22 05:59:26 2020 Return-Path: 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 6F50D3A0BA1 for ; Wed, 22 Apr 2020 05:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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 (1024-bit key) header.d=nlnetlabs.nl 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 VnERluGywKwO for ; Wed, 22 Apr 2020 05:59:22 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A993A0BA8 for ; Wed, 22 Apr 2020 05:59:22 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:143e:3685:6859:5dc0] (unknown [IPv6:2001:981:4b52:1:143e:3685:6859:5dc0]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id A745C16D62; Wed, 22 Apr 2020 14:59:20 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1587560360; bh=JRMbWWOKMun8MWTTzpipHMyoeGkugFKm2HonlawoGaU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ndfu+eMk1TjOzwMhlixdUAuy0ir6CHZoIrS2Ejq9Vqnu+Ma2AFFYTFoBu2wHyZWMb j905g/CN1GMLYYSU3vjBinFGdVltg1J+1NFXdLGEQJ9J9DG0jUC6AYYxFk6rYoefXm JHd3s1CfUAqtjxJvx8JiCV4rwS36qZa6ZvlG+H+8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Tim Bruijnzeels In-Reply-To: Date: Wed, 22 Apr 2020 14:59:20 +0200 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <437D9E9B-D44F-42A0-8BCF-58D0AD272BA9@nlnetlabs.nl> References: <98A4118B-83F0-4BBD-BA22-794ADA475731@nlnetlabs.nl> To: Randy Bush X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Sidrops] draft-ymbk-rpki-rov-timing-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 12:59:25 -0000 hi, > On 22 Apr 2020, at 14:28, Randy Bush wrote: >=20 > mornin' tim, >=20 > thanks for review! >=20 >> s/rcynic/rsync/g >=20 > massimiliano already beat me up on that this morning. he had done a = PR, > i merged it, and then let spell check revert it . >=20 >> Furthermore, I think the document could use some words on the chain >> before the CA. i.e. timing of creation of ROAs in the CA w.r.t. >> changes in announcements done. >=20 > i am not understanding. do you mean possible CA to publication point > delay? No I mean the delay between deciding to make a change in routing = announcements that one does, and using one's CA to create the ROAs. I.e. = before section 4 in your draft applies. >=20 >> I would say that for planned changes ROAs should be created in >> advance >=20 > yes. this was discussed many time in the design team. the ddos = defense > folk essentially said that most of the 'customers' come running in the > door in panic and had never thought to do advanced planning. while i > have some sympathy for that, i am not sure what we can say here other > than > o try to constrain the propagation time > o point out that roa creation in advance of operational changes, be = it > circuit moves, ddos sinking, ... should be done sufficiently in > advance. >=20 > i'll try to do more. >=20 >> As a side note. We are discussing moving from rsync to RRDP in = another >> thread. I believe that RRDP will help reduce propagation times. >=20 > i tried to say that. will look again. You did, this was just a lead to the following. >=20 >> I have no doubt that further improvements can be conceived in future. >> It helps to have guidance for maximum propagation times to serve as >> guidance for requirements there. >=20 > i am not understanding. maybe some coffee will help. What I am trying to say is thank you :) In more words, hopefully less confusing, I find it useful to have this = document say what the operational expectations are w.r.t. total = propagation times: Planned: 1 - Create ROAs in CA (implied in section 4, but logically a step = before the next) 2 - Let CAs publish (your section 4) 3 - Let RPs fetch and valid (section 5) 4 - Let routers fetch and apply (section 6) 5 - Do the actual announcement=20 Unplanned: 5 - Do the actual announcement Becomes: 0 - Do the actual announcement But then you will still need to keep in mind how much time 1-4 takes, = because until 4 is reached your announcement may be dropped. RRDP has a limit of 60 seconds for fetching, w.r.t. point #3 (section = 5). I think it will actually scale up to something faster if needed. = Alternatively one could thing of push mechanisms or some flooding = protocol in future. That said, it's only one kink in the chain. E.g. if = there is a delay of an hour between #1 (create ROAs) and #2 (actual = publication) then this won't matter much - yes, I am using a hyperbole = to make a point :) In any case, knowing how long the propagation from 1 through 4 can = reasonably take will help guide what to improve. >=20 > thanks again. >=20 > randy From nobody Wed Apr 22 20:32:04 2020 Return-Path: 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 7FE0A3A125C for ; Wed, 22 Apr 2020 20:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 0mWPnQJi9RHT for ; Wed, 22 Apr 2020 20:32:00 -0700 (PDT) Received: from out20-98.mail.aliyun.com (out20-98.mail.aliyun.com [115.124.20.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C74A43A1259 for ; Wed, 22 Apr 2020 20:31:58 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.5236588|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_news_journal|0.333878-0.00540025-0.660722; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03296; MF=madi@rpstir.net; NM=1; PH=DS; RN=1; RT=1; SR=0; TI=SMTPD_---.HMERo13_1587612712; Received: from 192.168.3.24(mailfrom:madi@rpstir.net fp:SMTPD_---.HMERo13_1587612712) by smtp.aliyun-inc.com(10.147.42.198); Thu, 23 Apr 2020 11:31:54 +0800 From: Di Ma Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <5A100AED-1222-4625-9199-4832C37A05DE@rpstir.net> Date: Thu, 23 Apr 2020 11:31:52 +0800 To: SIDR Operations WG X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Sidrops] Visualizing the RPKI X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 03:32:03 -0000 Hi, folks, We at ZDNS have developed a free, visualization tool, RPKI-VIZ, in order = to help people to detect and diagnose data errors. RPKIVIZ is in its beta version and we encourage you guys to provide = feedback on how we can improve it.=20 Thanks. Find more about RPKI VIZ via: https://blog.apnic.net/2020/04/23/rpkiviz-visualizing-the-rpki/ Di From nobody Thu Apr 23 07:46:14 2020 Return-Path: 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 2B0DB3A097B for ; Thu, 23 Apr 2020 07:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.919 X-Spam-Level: X-Spam-Status: No, score=-2.919 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.82, 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 VTmYMG9dkl27 for ; Thu, 23 Apr 2020 07:46:10 -0700 (PDT) Received: from sonic302-2.consmr.mail.bf2.yahoo.com (sonic302-2.consmr.mail.bf2.yahoo.com [74.6.135.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 DD40D3A097E for ; Thu, 23 Apr 2020 07:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1587653168; bh=Db/lXTraQhPg3PLIVxVhcntP6oIku9AXDpfytzwW46o=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=HMwh6uPMO1ExeUOk3PiH8Ze4cPHY+gxq9uOTT7x0YRf42qeAuDDSldWLSqoV4n7wBLqnMv3kKKG7HhvukOyM+W4yWngqgDIXzeBut0EsjwD/VRl8hRqkOkzpNSxcFjULFT0eGmuY+IfwVF9+LvGSRqOnJJQF8el8n2z7rsz5bjU3y8eWHyTsMMMVO/pvC4zraIrgTMzlmFJnSoZ15jrK9pRbfEIwRlN9IQvCQnNOFnhA3NJBv4dNtYoJ/j9fR4Qnqv8R3S9r1po4noES0hA/XMfRZdkT63ZlTlGteXdaUiRioK5a06Y6G7RPOnWmw7/m4UG1iNS/bW5IgNBrl+XqhQ== X-YMail-OSG: NXPZQbcVM1mgv86rqvz4J4YquGOkSIkIQ35AfmETSjBshXROmnwQRrJEFtewPK3 xxVxv0OHwixfGUoorlWifi_YKLMvl5BcES9Ig90DilujF137CeYIt7lflwd9.rotsv6ebaXNM3i9 AsQTQpF8uASmc40vNK4S.eFlPPdn0NWRuL1so8c1gpBnbdFSbdcaLr66tVMJTPK8.W0kTQTbGjkt GGd3D4.SCulD8rSI6znMmwyz1OTFC1jqhanLidVdnnNAxXdh._ysum6zhSJiaPlUu4zNqafAzKU1 mpWRcDRZ0lFc7gYXu6beEf__7X610VhCR6nMbFlOgTz2cqRcW9y2yu2nxR.ASAF_uCbcg15doiro vme3ZPHWvv89FQy8dnCMYxjtPqG9vno_PQVrdTC2zZ.hT8ZLEtVEhPz01psr32TwviuxQ.abQ_KJ y_F1Crbe6XuRp6GIAyyE1ppw8dtV.b1SZt14y7kYeTqs5Jm7LHakAIhFxQ1olJ7VR5cd7KVXGnpq BbcDc00lw6aYgZFHOwnkOP3nJejmn9u7sJO3riV5ILoOYPsm4mQ77v8CdN17lN1nldKY8P2k2NXL NxTNT6dt4riO.IMD3Xvr5LanKL1Y_LPGk4eD3pWz1pkQaPnEwCbIwtYBAzFH4Ub7UcZF8yoTidDd uhqyseBe.STYtGGvFy6DXrXFyg8FFNgvGT3TtpwvTlJYE_NBkQzUVlLCPjxSCfhF0p_VhNkzbGvy TFknKwvougEk_9u4gazVGO8gyUqb7DTGIxXrxNaliGzRAQHbCsDWBlemvEObxmEOxoVf9Z0P_FaT Poa2fgwjPfx4U1El7lcPLDo2A5q3eE__c7m2wVxSyE8BxjGgQZFz3flq9UenBqp3DkE7huOD93Ey hO13543x4_T2FSBz2OudlHt1w9ClrUJWCTNf97PgqWZ61PjgvthqXHKEhAS5.EV3fXDr3Sr9BaNJ eoMxsPKFbv4gjKIEcI5xYBdiKvunW8071PWvHA1UNVx7WOZcqVQYS1zxQoNFOpgdySyzrDiXwrzU dfwitrWvtSTsVbMhIuHF6TRPj5lddSuEDBZIZ_k11UMLsQo6AM2rDLewmjw0Ny8TGfAi7d2Va5iO q.dWhoXMezeQM6HEMJdl8X1qxV6zrH0Z4C2tqvhoCj6N0i0Wa1cNdF1PLIRFba8a4ed6uNjxwLg4 1ctFx6qAwahNkaqVA4WPzZXHGiFQfrXmsLNgriTpmaV55MuykSl3Q8QxldEFGe9CNdKKtMqEx4Hq 4atbt9g2L1N8vSSKSz2ESAV6mqJz2JOxakXbsSh0G3zK4LRj.BArt5s8to3jrIhaPqtrHvVPz8jo vLDMv4UxPAvMn7RPbevzMiXhqScvbYKRMrFgd1yS7elDyVT3mJLsmuwiZTvBz9KE.Zj4OvhdQXFD zLeR1lx_A4_BHhsHQFyU9FpNaYFJOPZo5IFRl6S4aMPU1GsuMWvrR2A8u6dYmgbVHM0NR Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Thu, 23 Apr 2020 14:46:08 +0000 Received: by smtp431.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1c84b367f7a6c06df3001abc04052854; Thu, 23 Apr 2020 14:46:05 +0000 (UTC) To: Martin Hoffmann Cc: sidrops@ietf.org References: <20200415150141.016d021d@glaurung.nlnetlabs.nl> <20200416175326.3f04db80@glaurung.nlnetlabs.nl> <123646a7-e1d5-e939-53fe-21f3326e79be@verizon.net> <20200417105408.66e750b2@glaurung.nlnetlabs.nl> From: Stephen Kent Message-ID: <9c6da623-270e-9141-8a30-ae600e70aff5@verizon.net> Date: Thu, 23 Apr 2020 10:46:04 -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: <20200417105408.66e750b2@glaurung.nlnetlabs.nl> Content-Type: multipart/alternative; boundary="------------825991FC31A40891EF72BD95" Content-Language: en-US X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 14:46:12 -0000 This is a multi-part message in MIME format. --------------825991FC31A40891EF72BD95 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Martin, sorry to be so tardy in replying. > Stephen Kent wrote: >> Martin, >>> ... >>> >>> That wasn’t quite the case I was thinking of (although I think this >>> is a case worth calling out specifically to avoid confusion), but >>> rather a case where say, a ROA’s EE certificate contains a URI for >>> the CRL Distribution Point that is referring to a CRL that is not >>> listed in the issuing CA’s manifest. >> This would be an error by the CA. RFC 6480 notes where the CRL is >> supposed to live in the repository system. > I know I am being pedantic (but then implementers are surprisingly > creative), but I can’t find normative text in RFC 6480 either that says > there must only be one CRL per CA. In some cases there will be more than one CRL issued by a CA, e.g., during key rollover. But I don't think that's the real issue here. The text associated with Figure 2 in 6480 (page 13) says "... the SIA extension of certificate A points to _the_ repository publication point of CA A's subordinate products, which includes certificates B and C, as well as _the_ CRL issued by A. The CRL Distribution Points (CRLDP) extension in certificates B and C both point to _the_ CRL issued by A." That text, and Figure 2 itself argue that, under normal circumstances (vs. key rollover or alg transition), there is just one CRL associated with a CA and it lives at the same PP as the other subordinate products signed by the CA. > >>>>> 1.Manifest present, valid, current >>>>> >>>>> If there is a present, valid, and current manifest, the CRL can >>>>> safely be ignored for all objects. >>>> Tim has suggested that, but to do so would make the RPKI not >>>> consistent with RFC 5280. >>> I’m not sure. In section 6.1.3, RFC 5280 says >>> >>> | (3) At the current time, the certificate is not revoked. This >>> | may be determined by obtaining the appropriate CRL >>> | (Section 6.3), by status information, or by out-of-band >>> | mechanisms. >>> >>> Determining certificate revocation via lack of presence on a >>> manifest could be construed as an "out-of-band" mechanism. >> This part of 5280 is designed to accommodate OCSP as a revocation >> status distribution mechanism, something that was not part of X.509. > If it intended to only allow OCSP, it should have said so. The way it > is formulated now, it opens up the option to devise any appropriate > mechanism. I agree that the wording is very broad; the principle author of 5280 liked it that way. But, as the PKIX chair my view is that the text was intended primarily to accommodate OCSP. There are several places in 5280 where the principle author bends over backwards to be as accommodating as possible. >> The RPKI requires CAs to publish CRLs, and it states where the CRLs >> are to be published in the repository system (RFC 6480). > The RPKI can be changed based on implementation and operational > experience. This ought to be done in a backwards compatible way, of > course, for instance by still requiring the publication of CRLs but > not considering them in validation of in-repository signed objects. I agree that operational experience is an important factor in deciding how to evolve the RPKI specs. But, I don't believe that some sloppy practices by some CAs should cause us to make major changes. In the Web PKI we have had a lot of cases where CAs have failed to behave properly, e.g., not issuing CRLs in a timely fashion. For a long time browsers, the principle RP software in this context, were content to ignore such errors. Fortunately, most browsers not provide warnings and require explicit user actions to override these errors. As a result, I think the cognizant CAs have become better. >>>>> If the aim is to avoid risking accidentally marking routes as >>>>> invalid, this should probably also extend to all information >>>>> published by child CAs. >>>> is the concern here that ROAs issued by a subordinate CA might be >>>> treated differently if there is a missing ROA associated with the >>>> parent? >>> I was thinking of the possible case that the parent issues a ROA >>> for a resource but also delegates it to a child CA which then issues >>> additional ROAs for the same resource. If the parent ROA is missing, >>> you cannot rule out that the was indeed the case, so in order to be >>> safe, you’d have to discard all ROAs for prefixes associated with >>> the parent. >> So, the parent issues a ROA binding a range of addresses to an AS >> that the parent holds. But then  the parent delegates the same range >> to a child, which is free to bind the addresses to a different AS >> (that the child holds). Thus a route advertising either AS as the >> origin is valid. If the parent's ROA is missing, the AS bound to it >> is no longer considered valid, but the child's ROA is. So, why does >> one have to discard/ignore all other ROAs associated with the parent? > Because if the actual route is from the ASN authorised by the child, > the announcement suddenly becomes invalid instead of unknown. Given the > operational split between object creation and object publication, it > doesn’t necessarily have to be the fault of the child that that > happened. OK, I see your point. > >>> >>>>>> 3.Manifest present, but invalid >>>>> The entire PP is ignored. >>>> So, it's OK to ignore a CRL that is invalid, but not a manifest. >>>> Personally I believe that if a CA cannot manage to correctly >>>> generate both a CRL and a manifest, it has a serious operational >>>> problem. >>> Indeed. However, bugs exist and unexpected things have a tendency to >>> happen. I still fail to see how, given a strict adherence to the >>> manifest, the CRL provides additional value for objects published >>> within the RPKI repository. So for robustness, it may indeed be >>> preferable to remove this additional possibility for breakage. >> As I noted in my reply to Tim a while ago, if we want to view the >> manifest as the only critical determinant of whether a cert is >> revoked, then why bother checking the validity interval for the EE >> certs? > The same reason we check them with CRLs: the possibility of replay > attacks of the revocation source. > > Using the manifest for revocation has the exact same issues as using a > CRL. All it does is drop the need to maintain two objects instead of > one. I don't think your argument above is sound. My point is that the argument for ignoring CRLs (or not generating them) is that one wants to avoid redundant checks, because a CA might fail to correctly maintain al of the signed objects that it generates. That argument could equally well be applied to checking the validity interval for the EE cert in a ROA. This is not a replay issue; a valid, current manifest can be used to verify that each ROA, including the embedded EE cert, is intact and current. >>> If the manifest takes over the CRL’s responsibility of expressing >>> revocation, you’d open a window to replay revoked objects. So this >>> translates to the question: What would you do today for a stale or >>> missing CRL? >> I don't understand your example. If a manifest trumps a CRL, then >> revoked objects would not appear on a current manifest and so replay >> of such objects would be ignored, right? > The question was about _today_, as in with the current situation where > a signed object’s certificate remains valid even if the object dropped > off the manifest, what do you do if a current CRL cannot be obtained? Some additional context is needed. If a cert has not expired, and if one has a current CRL, then the cert is valid irrespective the presence or absence of the corresponding signed object in a manifest. However, if the corresponding signed object is absent from tghe current manifest, then an RP should not rely on that object. > The mechanism from RFC 5280 specifically states that it relies on you > being able to get the current CRL, so it cannot be used at all in this > case. Ah, you've added the detail that a not stale CRL is unavailable. In that case the cert cannot be validated and should be ignored. > What would your guidance be to me as an implementer of a relying > party software today? Even if I allow users of my software to choose > what to do (aka "local policy"), I need to pick a default that pretty > much everyone will then use. If an RP does not have access to a not-stale CRL for a CA then the RP is unable to validate any certs that would have appeared on the CRL. So, all signed products of the CA in question ought be rejected. Steve --------------825991FC31A40891EF72BD95 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Martin,

sorry to be so tardy in replying.
Stephen Kent wrote:

Martin,

...

That wasn’t quite the case I was thinking of (although I think this
is a case worth calling out specifically to avoid confusion), but
rather a case where say, a ROA’s EE certificate contains a URI for
the CRL Distribution Point that is referring to a CRL that is not
listed in the issuing CA’s manifest.  

This would be an error by the CA. RFC 6480 notes where the CRL is 
supposed to live in the repository system.

I know I am being pedantic (but then implementers are surprisingly
creative), but I can’t find normative text in RFC 6480 either that says
there must only be one CRL per CA.

In some cases there will be more than one CRL issued by a CA, e.g., during key rollover. But I don't think that's the real issue here. The text associated with Figure 2 in 6480 (page 13) says "... the SIA extension of certificate A points to the repository publication point of CA A's subordinate products, which includes certificates B and C, as well as the CRL issued by A. The CRL Distribution Points (CRLDP) extension in certificates B and C both point to the CRL issued by A."  That text, and Figure 2 itself argue that, under normal circumstances (vs. key rollover or alg transition), there is just one CRL associated with a CA and it lives at the same PP as the other subordinate products signed by the CA. 



     1.Manifest present, valid, current

If there is a present, valid, and current manifest, the CRL can
safely be ignored for all objects.  

Tim has suggested that, but to do so would make the RPKI not
consistent with RFC 5280.  

I’m not sure. In section 6.1.3, RFC 5280 says

|  (3)  At the current time, the certificate is not revoked.  This
|       may be determined by obtaining the appropriate CRL
|       (Section 6.3), by status information, or by out-of-band
|       mechanisms.

Determining certificate revocation via lack of presence on a
manifest could be construed as an "out-of-band" mechanism.  

This part of 5280 is designed to accommodate OCSP as a revocation
status distribution mechanism, something that was not part of X.509.

If it intended to only allow OCSP, it should have said so. The way it
is formulated now, it opens up the option to devise any appropriate
mechanism.
I agree that the wording is very broad; the principle author of 5280 liked it that way. But, as the PKIX chair my view is that the text was intended primarily to accommodate OCSP. There are several places in 5280 where the principle author bends over backwards to be as accommodating as possible. 

      

        
The RPKI requires CAs to publish CRLs, and it states where the CRLs
are to be published in the repository system (RFC 6480).


      

      
The RPKI can be changed based on implementation and operational
experience. This ought to be done in a backwards compatible way, of
course, for instance by still requiring the publication of CRLs but
not considering them in validation of in-repository signed objects. 

    

    
I agree that operational experience is an important factor in
      deciding how to evolve the RPKI specs. But, I don't believe that
      some sloppy practices by some CAs should cause us to make major
      changes. In the Web PKI we have had a lot of cases where CAs have
      failed to behave properly, e.g., not issuing CRLs in a timely
      fashion. For a long time browsers, the principle RP software in
      this context, were content to ignore such errors. Fortunately,
      most browsers not provide warnings and require explicit user
      actions to override these errors. As a result, I think the
      cognizant CAs have become better.

    

    

      

      

        

          

            

              
If the aim is to avoid risking accidentally marking routes as
invalid, this should probably also extend to all information
published by child CAs.  


            

            
is the concern here that ROAs issued by a subordinate CA might be
treated differently if there is a missing ROA associated with the
parent?  


          

          
I was thinking of the possible case that the parent issues a ROA
for a resource but also delegates it to a child CA which then issues
additional ROAs for the same resource. If the parent ROA is missing,
you cannot rule out that the was indeed the case, so in order to be
safe, you’d have to discard all ROAs for prefixes associated with
the parent.  


        

        
So, the parent issues a ROA binding a range of addresses to an AS
that the parent holds. But then  the parent delegates the same range
to a child, which is free to bind the addresses to a different AS
(that the child holds). Thus a route advertising either AS as the
origin is valid. If the parent's ROA is missing, the AS bound to it
is no longer considered valid, but the child's ROA is. So, why does
one have to discard/ignore all other ROAs associated with the parent?


      

      
Because if the actual route is from the ASN authorised by the child,
the announcement suddenly becomes invalid instead of unknown. Given the
operational split between object creation and object publication, it
doesn’t necessarily have to be the fault of the child that that
happened.


    

    OK, I see your point.

    

      



      

        

          
 


          

            

              

                
3.Manifest present, but invalid  


              

              
The entire PP is ignored.  


            

            
So, it's OK to ignore a CRL that is invalid, but not a manifest.
Personally I believe that if a CA cannot manage to correctly
generate both a CRL and a manifest, it has a serious operational
problem.  


          

          
Indeed. However, bugs exist and unexpected things have a tendency to
happen. I still fail to see how, given a strict adherence to the
manifest, the CRL provides additional value for objects published
within the RPKI repository. So for robustness, it may indeed be
preferable to remove this additional possibility for breakage.  


        

        
As I noted in my reply to Tim a while ago, if we want to view the 
manifest as the only critical determinant of whether a cert is
revoked, then why bother checking the validity interval for the EE
certs?


      

      
The same reason we check them with CRLs: the possibility of replay
attacks of the revocation source.

Using the manifest for revocation has the exact same issues as using a
CRL. All it does is drop the need to maintain two objects instead of
one.


    

    I don't think your argument above is sound. My point is that the
    argument for ignoring CRLs (or not generating them) is that one
    wants to avoid redundant checks, because a CA might fail to
    correctly maintain al of the signed objects that it generates. That
    argument could equally well be applied to checking the validity
    interval for the EE cert in a ROA. This is not a replay issue; a
    valid, current manifest can be used to verify that each ROA,
    including the embedded EE cert, is intact and current.

    

      

      

        

          
If the manifest takes over the CRL’s responsibility of expressing
revocation, you’d open a window to replay revoked objects. So this
translates to the question: What would you do today for a stale or
missing CRL?  


        

        
I don't understand your example. If a manifest trumps a CRL, then 
revoked objects would not appear on a current manifest and so replay
of such objects would be ignored, right?


      

      
The question was about _today_, as in with the current situation where
a signed object’s certificate remains valid even if the object dropped
off the manifest, what do you do if a current CRL cannot be obtained?

    

    Some additional context is needed. If a cert has not expired, and if
    one has a current CRL, then the cert is valid irrespective the
    presence or absence of the corresponding signed object in a
    manifest. However, if the corresponding signed object is absent from
    tghe current manifest, then an RP should not rely on that object.

    

      
The mechanism from RFC 5280 specifically states that it relies on you
being able to get the current CRL, so it cannot be used at all in this
case. 

    

    Ah, you've added the detail that a not stale CRL is unavailable. In
    that case the cert cannot be validated and should be ignored.

    

      
What would your guidance be to me as an implementer of a relying
party software today? Even if I allow users of my software to choose
what to do (aka "local policy"), I need to pick a default that pretty
much everyone will then use.


    

    
If an RP does not have access to a not-stale CRL for a CA then
      the RP is unable to validate any certs that would have appeared on
      the CRL. So, all signed products of the CA in question ought be
      rejected.

    

    
Steve

    

  


--------------825991FC31A40891EF72BD95--


From nobody Thu Apr 23 07:46:32 2020
Return-Path: 
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 2DFC03A0980 for ; Thu, 23 Apr 2020 07:46:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.919
X-Spam-Level: 
X-Spam-Status: No, score=-2.919 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.82, 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 2TYjPnU6vaiH for ; Thu, 23 Apr 2020 07:46:10 -0700 (PDT)
Received: from sonic302-2.consmr.mail.bf2.yahoo.com (sonic302-2.consmr.mail.bf2.yahoo.com [74.6.135.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 DD3523A097D for ; Thu, 23 Apr 2020 07:46:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1587653168; bh=Db/lXTraQhPg3PLIVxVhcntP6oIku9AXDpfytzwW46o=;  h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject;  b=HMwh6uPMO1ExeUOk3PiH8Ze4cPHY+gxq9uOTT7x0YRf42qeAuDDSldWLSqoV4n7wBLqnMv3kKKG7HhvukOyM+W4yWngqgDIXzeBut0EsjwD/VRl8hRqkOkzpNSxcFjULFT0eGmuY+IfwVF9+LvGSRqOnJJQF8el8n2z7rsz5bjU3y8eWHyTsMMMVO/pvC4zraIrgTMzlmFJnSoZ15jrK9pRbfEIwRlN9IQvCQnNOFnhA3NJBv4dNtYoJ/j9fR4Qnqv8R3S9r1po4noES0hA/XMfRZdkT63ZlTlGteXdaUiRioK5a06Y6G7RPOnWmw7/m4UG1iNS/bW5IgNBrl+XqhQ==
X-YMail-OSG: NXPZQbcVM1mgv86rqvz4J4YquGOkSIkIQ35AfmETSjBshXROmnwQRrJEFtewPK3 xxVxv0OHwixfGUoorlWifi_YKLMvl5BcES9Ig90DilujF137CeYIt7lflwd9.rotsv6ebaXNM3i9 AsQTQpF8uASmc40vNK4S.eFlPPdn0NWRuL1so8c1gpBnbdFSbdcaLr66tVMJTPK8.W0kTQTbGjkt GGd3D4.SCulD8rSI6znMmwyz1OTFC1jqhanLidVdnnNAxXdh._ysum6zhSJiaPlUu4zNqafAzKU1 mpWRcDRZ0lFc7gYXu6beEf__7X610VhCR6nMbFlOgTz2cqRcW9y2yu2nxR.ASAF_uCbcg15doiro vme3ZPHWvv89FQy8dnCMYxjtPqG9vno_PQVrdTC2zZ.hT8ZLEtVEhPz01psr32TwviuxQ.abQ_KJ y_F1Crbe6XuRp6GIAyyE1ppw8dtV.b1SZt14y7kYeTqs5Jm7LHakAIhFxQ1olJ7VR5cd7KVXGnpq BbcDc00lw6aYgZFHOwnkOP3nJejmn9u7sJO3riV5ILoOYPsm4mQ77v8CdN17lN1nldKY8P2k2NXL NxTNT6dt4riO.IMD3Xvr5LanKL1Y_LPGk4eD3pWz1pkQaPnEwCbIwtYBAzFH4Ub7UcZF8yoTidDd uhqyseBe.STYtGGvFy6DXrXFyg8FFNgvGT3TtpwvTlJYE_NBkQzUVlLCPjxSCfhF0p_VhNkzbGvy TFknKwvougEk_9u4gazVGO8gyUqb7DTGIxXrxNaliGzRAQHbCsDWBlemvEObxmEOxoVf9Z0P_FaT Poa2fgwjPfx4U1El7lcPLDo2A5q3eE__c7m2wVxSyE8BxjGgQZFz3flq9UenBqp3DkE7huOD93Ey hO13543x4_T2FSBz2OudlHt1w9ClrUJWCTNf97PgqWZ61PjgvthqXHKEhAS5.EV3fXDr3Sr9BaNJ eoMxsPKFbv4gjKIEcI5xYBdiKvunW8071PWvHA1UNVx7WOZcqVQYS1zxQoNFOpgdySyzrDiXwrzU dfwitrWvtSTsVbMhIuHF6TRPj5lddSuEDBZIZ_k11UMLsQo6AM2rDLewmjw0Ny8TGfAi7d2Va5iO q.dWhoXMezeQM6HEMJdl8X1qxV6zrH0Z4C2tqvhoCj6N0i0Wa1cNdF1PLIRFba8a4ed6uNjxwLg4 1ctFx6qAwahNkaqVA4WPzZXHGiFQfrXmsLNgriTpmaV55MuykSl3Q8QxldEFGe9CNdKKtMqEx4Hq 4atbt9g2L1N8vSSKSz2ESAV6mqJz2JOxakXbsSh0G3zK4LRj.BArt5s8to3jrIhaPqtrHvVPz8jo vLDMv4UxPAvMn7RPbevzMiXhqScvbYKRMrFgd1yS7elDyVT3mJLsmuwiZTvBz9KE.Zj4OvhdQXFD zLeR1lx_A4_BHhsHQFyU9FpNaYFJOPZo5IFRl6S4aMPU1GsuMWvrR2A8u6dYmgbVHM0NR
Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Thu, 23 Apr 2020 14:46:08 +0000
Received: by smtp431.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1c84b367f7a6c06df3001abc04052854;  Thu, 23 Apr 2020 14:46:05 +0000 (UTC)
To: Martin Hoffmann 
Cc: sidrops@ietf.org
References:   <20200415150141.016d021d@glaurung.nlnetlabs.nl>  <20200416175326.3f04db80@glaurung.nlnetlabs.nl> <123646a7-e1d5-e939-53fe-21f3326e79be@verizon.net> <20200417105408.66e750b2@glaurung.nlnetlabs.nl>
From: Stephen Kent 
Message-ID: <9c6da623-270e-9141-8a30-ae600e70aff5@verizon.net>
Date: Thu, 23 Apr 2020 10:46:04 -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: <20200417105408.66e750b2@glaurung.nlnetlabs.nl>
Content-Type: multipart/alternative; boundary="------------825991FC31A40891EF72BD95"
Content-Language: en-US
X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Apr 2020 14:46:12 -0000

This is a multi-part message in MIME format.
--------------825991FC31A40891EF72BD95
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Martin,

sorry to be so tardy in replying.
> Stephen Kent wrote:
>> Martin,
>>> ...
>>>
>>> That wasn’t quite the case I was thinking of (although I think this
>>> is a case worth calling out specifically to avoid confusion), but
>>> rather a case where say, a ROA’s EE certificate contains a URI for
>>> the CRL Distribution Point that is referring to a CRL that is not
>>> listed in the issuing CA’s manifest.
>> This would be an error by the CA. RFC 6480 notes where the CRL is
>> supposed to live in the repository system.
> I know I am being pedantic (but then implementers are surprisingly
> creative), but I can’t find normative text in RFC 6480 either that says
> there must only be one CRL per CA.

In some cases there will be more than one CRL issued by a CA, e.g., 
during key rollover. But I don't think that's the real issue here. The 
text associated with Figure 2 in 6480 (page 13) says "... the SIA 
extension of certificate A points to _the_ repository publication point 
of CA A's subordinate products, which includes certificates B and C, as 
well as _the_ CRL issued by A. The CRL Distribution Points (CRLDP) 
extension in certificates B and C both point to _the_ CRL issued by A." 
That text, and Figure 2 itself argue that, under normal circumstances 
(vs. key rollover or alg transition), there is just one CRL associated 
with a CA and it lives at the same PP as the other subordinate products 
signed by the CA.

>
>>>>>       1.Manifest present, valid, current
>>>>>
>>>>> If there is a present, valid, and current manifest, the CRL can
>>>>> safely be ignored for all objects.
>>>> Tim has suggested that, but to do so would make the RPKI not
>>>> consistent with RFC 5280.
>>> I’m not sure. In section 6.1.3, RFC 5280 says
>>>
>>> |  (3)  At the current time, the certificate is not revoked.  This
>>> |       may be determined by obtaining the appropriate CRL
>>> |       (Section 6.3), by status information, or by out-of-band
>>> |       mechanisms.
>>>
>>> Determining certificate revocation via lack of presence on a
>>> manifest could be construed as an "out-of-band" mechanism.
>> This part of 5280 is designed to accommodate OCSP as a revocation
>> status distribution mechanism, something that was not part of X.509.
> If it intended to only allow OCSP, it should have said so. The way it
> is formulated now, it opens up the option to devise any appropriate
> mechanism.
I agree that the wording is very broad; the principle author of 5280 
liked it that way. But, as the PKIX chair my view is that the text was 
intended primarily to accommodate OCSP. There are several places in 5280 
where the principle author bends over backwards to be as accommodating 
as possible.
>> The RPKI requires CAs to publish CRLs, and it states where the CRLs
>> are to be published in the repository system (RFC 6480).
> The RPKI can be changed based on implementation and operational
> experience. This ought to be done in a backwards compatible way, of
> course, for instance by still requiring the publication of CRLs but
> not considering them in validation of in-repository signed objects.

I agree that operational experience is an important factor in deciding 
how to evolve the RPKI specs. But, I don't believe that some sloppy 
practices by some CAs should cause us to make major changes. In the Web 
PKI we have had a lot of cases where CAs have failed to behave properly, 
e.g., not issuing CRLs in a timely fashion. For a long time browsers, 
the principle RP software in this context, were content to ignore such 
errors. Fortunately, most browsers not provide warnings and require 
explicit user actions to override these errors. As a result, I think the 
cognizant CAs have become better.

>>>>> If the aim is to avoid risking accidentally marking routes as
>>>>> invalid, this should probably also extend to all information
>>>>> published by child CAs.
>>>> is the concern here that ROAs issued by a subordinate CA might be
>>>> treated differently if there is a missing ROA associated with the
>>>> parent?
>>> I was thinking of the possible case that the parent issues a ROA
>>> for a resource but also delegates it to a child CA which then issues
>>> additional ROAs for the same resource. If the parent ROA is missing,
>>> you cannot rule out that the was indeed the case, so in order to be
>>> safe, you’d have to discard all ROAs for prefixes associated with
>>> the parent.
>> So, the parent issues a ROA binding a range of addresses to an AS
>> that the parent holds. But then  the parent delegates the same range
>> to a child, which is free to bind the addresses to a different AS
>> (that the child holds). Thus a route advertising either AS as the
>> origin is valid. If the parent's ROA is missing, the AS bound to it
>> is no longer considered valid, but the child's ROA is. So, why does
>> one have to discard/ignore all other ROAs associated with the parent?
> Because if the actual route is from the ASN authorised by the child,
> the announcement suddenly becomes invalid instead of unknown. Given the
> operational split between object creation and object publication, it
> doesn’t necessarily have to be the fault of the child that that
> happened.
OK, I see your point.
>
>>>   
>>>>>> 3.Manifest present, but invalid
>>>>> The entire PP is ignored.
>>>> So, it's OK to ignore a CRL that is invalid, but not a manifest.
>>>> Personally I believe that if a CA cannot manage to correctly
>>>> generate both a CRL and a manifest, it has a serious operational
>>>> problem.
>>> Indeed. However, bugs exist and unexpected things have a tendency to
>>> happen. I still fail to see how, given a strict adherence to the
>>> manifest, the CRL provides additional value for objects published
>>> within the RPKI repository. So for robustness, it may indeed be
>>> preferable to remove this additional possibility for breakage.
>> As I noted in my reply to Tim a while ago, if we want to view the
>> manifest as the only critical determinant of whether a cert is
>> revoked, then why bother checking the validity interval for the EE
>> certs?
> The same reason we check them with CRLs: the possibility of replay
> attacks of the revocation source.
>
> Using the manifest for revocation has the exact same issues as using a
> CRL. All it does is drop the need to maintain two objects instead of
> one.
I don't think your argument above is sound. My point is that the 
argument for ignoring CRLs (or not generating them) is that one wants to 
avoid redundant checks, because a CA might fail to correctly maintain al 
of the signed objects that it generates. That argument could equally 
well be applied to checking the validity interval for the EE cert in a 
ROA. This is not a replay issue; a valid, current manifest can be used 
to verify that each ROA, including the embedded EE cert, is intact and 
current.
>>> If the manifest takes over the CRL’s responsibility of expressing
>>> revocation, you’d open a window to replay revoked objects. So this
>>> translates to the question: What would you do today for a stale or
>>> missing CRL?
>> I don't understand your example. If a manifest trumps a CRL, then
>> revoked objects would not appear on a current manifest and so replay
>> of such objects would be ignored, right?
> The question was about _today_, as in with the current situation where
> a signed object’s certificate remains valid even if the object dropped
> off the manifest, what do you do if a current CRL cannot be obtained?
Some additional context is needed. If a cert has not expired, and if one 
has a current CRL, then the cert is valid irrespective the presence or 
absence of the corresponding signed object in a manifest. However, if 
the corresponding signed object is absent from tghe current manifest, 
then an RP should not rely on that object.
> The mechanism from RFC 5280 specifically states that it relies on you
> being able to get the current CRL, so it cannot be used at all in this
> case.
Ah, you've added the detail that a not stale CRL is unavailable. In that 
case the cert cannot be validated and should be ignored.
> What would your guidance be to me as an implementer of a relying
> party software today? Even if I allow users of my software to choose
> what to do (aka "local policy"), I need to pick a default that pretty
> much everyone will then use.

If an RP does not have access to a not-stale CRL for a CA then the RP is 
unable to validate any certs that would have appeared on the CRL. So, 
all signed products of the CA in question ought be rejected.

Steve


--------------825991FC31A40891EF72BD95
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Martin,

    


    

    
sorry to be so tardy in replying.

    

    

      
Stephen Kent wrote:


      

        
Martin,


        

          
...

That wasn’t quite the case I was thinking of (although I think this
is a case worth calling out specifically to avoid confusion), but
rather a case where say, a ROA’s EE certificate contains a URI for
the CRL Distribution Point that is referring to a CRL that is not
listed in the issuing CA’s manifest.  


        

        
This would be an error by the CA. RFC 6480 notes where the CRL is 
supposed to live in the repository system.


      

      
I know I am being pedantic (but then implementers are surprisingly
creative), but I can’t find normative text in RFC 6480 either that says
there must only be one CRL per CA.

    

    
In some cases there will be more than one CRL issued by a CA,
      e.g., during key rollover. But I don't think that's the real issue
      here. The text associated with Figure 2 in 6480 (page 13) says
      "... the SIA extension of certificate A points to the
      repository publication point of CA A's subordinate products, which
      includes certificates B and C, as well as the CRL issued
      by A. The CRL Distribution Points (CRLDP) extension in
      certificates B and C both point to the CRL issued by A." 
      That text, and Figure 2 itself argue that, under normal
      circumstances (vs. key rollover or alg transition), there is just
      one CRL associated with a CA and it lives at the same PP as the
      other subordinate products signed by the CA. 

      

    

    

      



      

        

          

            

              
     1.Manifest present, valid, current

If there is a present, valid, and current manifest, the CRL can
safely be ignored for all objects.  


            

            
Tim has suggested that, but to do so would make the RPKI not
consistent with RFC 5280.  


          

          
I’m not sure. In section 6.1.3, RFC 5280 says

|  (3)  At the current time, the certificate is not revoked.  This
|       may be determined by obtaining the appropriate CRL
|       (Section 6.3), by status information, or by out-of-band
|       mechanisms.

Determining certificate revocation via lack of presence on a
manifest could be construed as an "out-of-band" mechanism.  


        

        
This part of 5280 is designed to accommodate OCSP as a revocation
status distribution mechanism, something that was not part of X.509.


      

      
If it intended to only allow OCSP, it should have said so. The way it
is formulated now, it opens up the option to devise any appropriate
mechanism.


    

    I agree that the wording is very broad; the principle author of 5280
    liked it that way. But, as the PKIX chair my view is that the text
    was intended primarily to accommodate OCSP. There are several places
    in 5280 where the principle author bends over backwards to be as
    accommodating as possible. 

    

      

      

        
The RPKI requires CAs to publish CRLs, and it states where the CRLs
are to be published in the repository system (RFC 6480).


      

      
The RPKI can be changed based on implementation and operational
experience. This ought to be done in a backwards compatible way, of
course, for instance by still requiring the publication of CRLs but
not considering them in validation of in-repository signed objects. 

    

    
I agree that operational experience is an important factor in
      deciding how to evolve the RPKI specs. But, I don't believe that
      some sloppy practices by some CAs should cause us to make major
      changes. In the Web PKI we have had a lot of cases where CAs have
      failed to behave properly, e.g., not issuing CRLs in a timely
      fashion. For a long time browsers, the principle RP software in
      this context, were content to ignore such errors. Fortunately,
      most browsers not provide warnings and require explicit user
      actions to override these errors. As a result, I think the
      cognizant CAs have become better.

    

    

      

      

        

          

            

              
If the aim is to avoid risking accidentally marking routes as
invalid, this should probably also extend to all information
published by child CAs.  


            

            
is the concern here that ROAs issued by a subordinate CA might be
treated differently if there is a missing ROA associated with the
parent?  


          

          
I was thinking of the possible case that the parent issues a ROA
for a resource but also delegates it to a child CA which then issues
additional ROAs for the same resource. If the parent ROA is missing,
you cannot rule out that the was indeed the case, so in order to be
safe, you’d have to discard all ROAs for prefixes associated with
the parent.  


        

        
So, the parent issues a ROA binding a range of addresses to an AS
that the parent holds. But then  the parent delegates the same range
to a child, which is free to bind the addresses to a different AS
(that the child holds). Thus a route advertising either AS as the
origin is valid. If the parent's ROA is missing, the AS bound to it
is no longer considered valid, but the child's ROA is. So, why does
one have to discard/ignore all other ROAs associated with the parent?


      

      
Because if the actual route is from the ASN authorised by the child,
the announcement suddenly becomes invalid instead of unknown. Given the
operational split between object creation and object publication, it
doesn’t necessarily have to be the fault of the child that that
happened.


    

    OK, I see your point.

    

      



      

        

          
 


          

            

              

                
3.Manifest present, but invalid  


              

              
The entire PP is ignored.  


            

            
So, it's OK to ignore a CRL that is invalid, but not a manifest.
Personally I believe that if a CA cannot manage to correctly
generate both a CRL and a manifest, it has a serious operational
problem.  


          

          
Indeed. However, bugs exist and unexpected things have a tendency to
happen. I still fail to see how, given a strict adherence to the
manifest, the CRL provides additional value for objects published
within the RPKI repository. So for robustness, it may indeed be
preferable to remove this additional possibility for breakage.  


        

        
As I noted in my reply to Tim a while ago, if we want to view the 
manifest as the only critical determinant of whether a cert is
revoked, then why bother checking the validity interval for the EE
certs?


      

      
The same reason we check them with CRLs: the possibility of replay
attacks of the revocation source.

Using the manifest for revocation has the exact same issues as using a
CRL. All it does is drop the need to maintain two objects instead of
one.


    

    I don't think your argument above is sound. My point is that the
    argument for ignoring CRLs (or not generating them) is that one
    wants to avoid redundant checks, because a CA might fail to
    correctly maintain al of the signed objects that it generates. That
    argument could equally well be applied to checking the validity
    interval for the EE cert in a ROA. This is not a replay issue; a
    valid, current manifest can be used to verify that each ROA,
    including the embedded EE cert, is intact and current.

    

      

      

        

          
If the manifest takes over the CRL’s responsibility of expressing
revocation, you’d open a window to replay revoked objects. So this
translates to the question: What would you do today for a stale or
missing CRL?  


        

        
I don't understand your example. If a manifest trumps a CRL, then 
revoked objects would not appear on a current manifest and so replay
of such objects would be ignored, right?


      

      
The question was about _today_, as in with the current situation where
a signed object’s certificate remains valid even if the object dropped
off the manifest, what do you do if a current CRL cannot be obtained?

    

    Some additional context is needed. If a cert has not expired, and if
    one has a current CRL, then the cert is valid irrespective the
    presence or absence of the corresponding signed object in a
    manifest. However, if the corresponding signed object is absent from
    tghe current manifest, then an RP should not rely on that object.

    

      
The mechanism from RFC 5280 specifically states that it relies on you
being able to get the current CRL, so it cannot be used at all in this
case. 

    

    Ah, you've added the detail that a not stale CRL is unavailable. In
    that case the cert cannot be validated and should be ignored.

    

      
What would your guidance be to me as an implementer of a relying
party software today? Even if I allow users of my software to choose
what to do (aka "local policy"), I need to pick a default that pretty
much everyone will then use.


    

    
If an RP does not have access to a not-stale CRL for a CA then
      the RP is unable to validate any certs that would have appeared on
      the CRL. So, all signed products of the CA in question ought be
      rejected.

    

    
Steve

    

  


--------------825991FC31A40891EF72BD95--


From nobody Fri Apr 24 04:30:19 2020
Return-Path: 
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 790E13A0927 for ; Fri, 24 Apr 2020 04:30:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 1f3dlT16Gy9L for ; Fri, 24 Apr 2020 04:30:15 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 593233A0925 for ; Fri, 24 Apr 2020 04:30:15 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jRwX6-0006Ww-RZ for sidrops@ietf.org; Fri, 24 Apr 2020 11:30:13 +0000
Date: Fri, 24 Apr 2020 04:30:12 -0700
Message-ID: 
From: Randy Bush 
To: SIDR Operations WG 
References: <158772762537.31441.15990014886210030300@ietfa.amsl.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: [Sidrops] Fwd: New Version Notification for draft-ymbk-sidrops-rpki-rov-timing-00.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Apr 2020 11:30:18 -0000

From: internet-drafts@ietf.org
To: "Jay Borkenhagen" , "Tim Bruijnzeels" ,
 "Randy Bush" , "Job Snijders" 
Subject: New Version Notification for draft-ymbk-sidrops-rpki-rov-timing-00.txt
Date: Fri, 24 Apr 2020 04:27:05 -0700

A new version of I-D, draft-ymbk-sidrops-rpki-rov-timing-00.txt
has been successfully submitted by Randy Bush and posted to the
IETF repository.

Name:		draft-ymbk-sidrops-rpki-rov-timing
Revision:	00
Title:		Timing Parameters in the RPKI based Route Origin Validation Supply Chain
Document date:	2020-04-24
Group:		Individual Submission
Pages:		8
URL:            https://www.ietf.org/internet-drafts/draft-ymbk-sidrops-rpki-rov-timing-00.txt
Status:         https://datatracker.ietf.org/doc/draft-ymbk-sidrops-rpki-rov-timing/
Htmlized:       https://tools.ietf.org/html/draft-ymbk-sidrops-rpki-rov-timing-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ymbk-sidrops-rpki-rov-timing

Abstract:
   This document explores, and makes recommendations for, timing of
   Resource Public Key Infrastructure publication of ROV data, their
   propagation, and their use in Relying Parties and routers.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



From nobody Fri Apr 24 10:44:42 2020
Return-Path: 
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 D17183A108C for ; Fri, 24 Apr 2020 10:44:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
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 dllQ92rDht6L for ; Fri, 24 Apr 2020 10:44:38 -0700 (PDT)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A8A23A108A for ; Fri, 24 Apr 2020 10:44:37 -0700 (PDT)
Received: from allealle.ripe.net ([193.0.23.12]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jS2NQ-0000GP-2E for sidrops@ietf.org; Fri, 24 Apr 2020 19:44:36 +0200
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::6f6]) by allealle.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jS2NP-0006Rm-TC for sidrops@ietf.org; Fri, 24 Apr 2020 19:44:35 +0200
From: Nathalie Trenaman 
Content-Type: multipart/alternative; boundary="Apple-Mail=_C93A4AC0-B0C2-45B7-BF2A-9FCF51EFB201"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: <9B51BF38-4ADF-4062-8A46-0D2CAA2213EE@ripe.net>
Date: Fri, 24 Apr 2020 19:44:32 +0200
To: SIDR Operations WG 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-ACL-Warn: Delaying message
X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92ae5681afeb326b217d92d0c28e7d49e69
Archived-At: 
Subject: [Sidrops] Agenda for Virtual Interim Meeting 28 April 2020
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Apr 2020 17:44:40 -0000

--Apple-Mail=_C93A4AC0-B0C2-45B7-BF2A-9FCF51EFB201
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi all,

Here is the agenda for our meeting on Tuesday 28 April 14:00 - 16:00 UTC=20=

Since this meeting will be virtual, we=E2=80=99ll be using WebEx: =
https://ietf.webex.com/meet/sidrops =

To keep the bandwidth low, when you join, please switch off your video =
and mute yourself when you=E2=80=99re not presenting.=20


SIDROPS Agenda For Virtual Interim Meeting

Session: April 23rd 2020, 14:00 - 16:00 UTC

Slides:  To Be Published
Etherpad: =
https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-sidrops-01?useMon=
ospaceFont=3Dtrue     =20
WebEx: https://ietf.webex.com/meet/sidrops
Jabber: xmpp:sidrops@jabber.ietf.org?join


1) Agenda bashing and Chair's slides - [5 minutes]

2) Stephen Kent - [60 minutes]
CRLs & Manifest & Hashbrowns - guidance for chefs

3) Randy Bush - [15 minutes]
Timing Parameters in the RPKI-based Route Origin Validation Supply Chain =
Draft
https://github.com/randyqx/rpki-rov-timing

4) Tim Bruijnzeels - [15 minutes]
Deprecating rsync Draft
=
https://datatracker.ietf.org/doc/draft-sidrops-bruijnzeels-deprecate-rsync=
/

5) Massimiliano Stucchi - [15 minutes]
AS-Cones Draft
https://max.stucchi.ch/drafts/draft-ietf-grow-rpki-as-cones.html =



Thanks,
Nathalie=20



--Apple-Mail=_C93A4AC0-B0C2-45B7-BF2A-9FCF51EFB201
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
all,

Here is the =
agenda for our meeting on Tuesday 28 April 14:00 - 16:00 =
UTC 
Since this meeting will be virtual, =
we=E2=80=99ll be using WebEx: https://ietf.webex.com/meet/sidrops
To keep the bandwidth low, when =
you join, please switch off your video and mute yourself when you=E2=80=99=
re not presenting. 


SIDROPS Agenda For Virtual Interim Meeting

Session: April 23rd 2020, 14:00 - 16:00 UTC

Slides:  To Be Published
Etherpad: https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-sidrop=
s-01?useMonospaceFont=3Dtrue     =20
WebEx: https://ietf.webex.com/meet/sidrops
Jabber: xmpp:sidrops@jabber.ietf.org?join


1) Agenda bashing and Chair's slides - [5 minutes]

2) Stephen Kent - [60 minutes]
CRLs & Manifest & Hashbrowns - guidance for chefs

3) Randy Bush - [15 minutes]
Timing Parameters in the RPKI-based Route Origin Validation Supply Chain =
Draft
https://github.com/randyqx/rpki-rov-timing

4) Tim Bruijnzeels - [15 minutes]
Deprecating rsync Draft
https://datatracker.ietf.org/doc/draft-sidrops-bruijnzeels-depr=
ecate-rsync/

5) Massimiliano Stucchi - [15 minutes]
AS-Cones Draft
https://max.stucchi.ch/drafts/draft-ietf-grow-rpki-as-cones.htm=
l


Thanks,
Nathalie =



=

--Apple-Mail=_C93A4AC0-B0C2-45B7-BF2A-9FCF51EFB201--


From nobody Sat Apr 25 05:38:15 2020
Return-Path: 
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 12ED93A0BA1 for ; Sat, 25 Apr 2020 05:38:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, 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 (1024-bit key) header.d=nlnetlabs.nl
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 kWcvmiKmvWiA for ; Sat, 25 Apr 2020 05:38:12 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B813A0D12 for ; Sat, 25 Apr 2020 05:38:12 -0700 (PDT)
Received: from [IPv6:2001:981:4b52:1:3165:cea3:8571:183d] (unknown [IPv6:2001:981:4b52:1:3165:cea3:8571:183d]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 9AF741BCCC; Sat, 25 Apr 2020 14:38:10 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl
Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1587818290; bh=ieJOo8RQ88s7Y7eV5X1NXzY4Tv2dn8p6TCuAKX/UKlI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=UsIdPhdNHCuJVuGrvvYPC/Rh2GI6KmgsK6aO+SfF88UQKc0mbq0Gnv9vwICBZsxrT qeq7WUO9IiNl5Gi6Wbm4jRTT+umElWkfxpri78Gvu2pjDlruEjul+41vFq8kxhOdPY 9+joPUr1GYbR9mVLLbjPFvTkI8vssh5kcktzOZrM=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Tim Bruijnzeels 
In-Reply-To: <9B51BF38-4ADF-4062-8A46-0D2CAA2213EE@ripe.net>
Date: Sat, 25 Apr 2020 14:38:10 +0200
Cc: SIDR Operations WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <9B51BF38-4ADF-4062-8A46-0D2CAA2213EE@ripe.net>
To: Nathalie Trenaman 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [Sidrops] Agenda for Virtual Interim Meeting 28 April 2020
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Apr 2020 12:38:14 -0000

Hi,

> On 24 Apr 2020, at 19:44, Nathalie Trenaman  wrote:
>=20
> 
>=20
> 4) Tim Bruijnzeels - [15 minutes]
> Deprecating rsync Draft
>=20
> =
https://datatracker.ietf.org/doc/draft-sidrops-bruijnzeels-deprecate-rsync=
/

I just posted a new version of the document. Major changes:
- Randy Bush and George Michaelson became co-authors
- Phased plan is made much more concrete
- Includes suggested updates to RFCs for each phase

We may find it useful to separate the document into a plan, and =
implementation for each phase, but for now this can hopefully serve to =
have a structured discussion.

Slides will be sent to Nathalie and the co-chairs in time, I promise :)

Abstract if you don't feel like clicking the link:

   This document formulates a plan of a phased transition to a state
   where RPKI repositories and Relying Party software performing RPKI
   Validation will use the RPKI Repository Delta Protocol (RRDP)
   [RFC8182] as the only mandatory to implement access protocol.

   In short this plan consists of the following phases.

   In phase 0, today's deployment, RRDP is supported by most, but not
   all Repositories, and most but not all RP software.

   In the proposed phase 1 RRDP will become mandatory to implement for
   Repositories, in addition to rsync.  This phase can start as soon as
   this document is published.

   Once the proposed updates are implemented by all Repositories phase 2
   will start.  In this phase RRDP will become mandatory to implement
   for all RP software, and rsync must no longer be used.

   Measurements will need to be done to help determine when it will be
   safe to transition to the final phase of this plan.  During this
   phase Repositories will no longer be required to provide rsync access
   for RPKI validation purposes.  However, they may still provide rsync
   access for direct access to files for other purposes, if desired, at
   a best effort basis.

   Although this document currently includes descriptions and updates to
   RFCs for each of these phases, we may find that it will be beneficial
   to have separate documents for the plan, and each phase, so that it
   might be more clear to all when the updates to RFCs take effect.






>=20
>=20
> 5) Massimiliano Stucchi - [15 minutes]
> AS-Cones Draft
>=20
> https://max.stucchi.ch/drafts/draft-ietf-grow-rpki-as-cones.html
>=20
>=20
> Thanks,
> Nathalie=20
>=20
>=20
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops


From nobody Sun Apr 26 13:28:52 2020
Return-Path: 
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 47F2E3A114F for ; Sun, 26 Apr 2020 13:28:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=gmail.com
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 tw4xcBV-ksf7 for ; Sun, 26 Apr 2020 13:28:39 -0700 (PDT)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 DA71B3A114D for ; Sun, 26 Apr 2020 13:28:38 -0700 (PDT)
Received: by mail-ot1-x335.google.com with SMTP id i27so22677698ota.7 for ; Sun, 26 Apr 2020 13:28:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CGocE/GGOSIG9HSoWJQNcq/3ikTimyqBHk9jbg4m4ig=; b=Y89zsw9NMvWHdm6bCObdhww27jeVKlFo3fME8T2ucFlJlNm+JYplMUPtx8mFqH+rtw XJIZJ7ii08x5WTPvgbN0J/sDjso6y7gt5cy40PWQj1Z4WRtOe0NVub1Wlz1KujrtNo3p 5MaeAlTnRQlCHF7tiI+zMdkzwCVkW5l4mO+dPGY7fKeAQhEh2VlSMu/mxb6GVcysvbs8 +mA6fV6KngMEV5ZhM6dnIvKH492f25m/y0af9BWwKDqYulMAa/8j9pE0XwaOCYFGanYA viLTSAROPTZF9kyTE8O51gGKmWE+q8kK3wGbZlX/ccSQj5lfTzc0tITQ+kWdbx1KYyJY TGzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CGocE/GGOSIG9HSoWJQNcq/3ikTimyqBHk9jbg4m4ig=; b=MzkLMF0b20jejEJIInN7dArfn8fvZE+nOAxZTlBbdLl7fVaZQHBajfWTssMZoyJ5d7 aNz+PY5sLsZkaVC/jpyoU5wjYgiFG+F9PP8U3rTm5jMdu+J0ccC0T5Dqo88sDF0IeiQf 5KSQUOnoVwda0hMF/nLzUT1eDjJdlzWWphaDSydZFOpr3+TrpKE22XF/teuXLaF01vGd xA0EcQgleNv7qCMTTNcUPuPg3frST+MARj77GfGI8WUbOYfjGz14naaxcd9RWuflFf3X OxXz09PdD2Ch5tJnpFTETwgmpp/r3MeXPIwZuzCKQKIRRMPaBPHaq/Vmx5fGGrv2RWHE raJw==
X-Gm-Message-State: AGi0PubW8jl3S6hydA09jwwG6o6ayitX2dujpIpYGdE/NArlpkROsWL4 MR5wx0b3mdcyHEleTfcws5w79LLPo0BPcgi40yt59Q==
X-Google-Smtp-Source: APiQypKcZSTlULE518XSUx0qHFPQy01KDCCPiGyUqqRjwyK0UKXVDr7PxQMJX5hC3kTQ44LxOvKOlpO5izvc9rtEvf4=
X-Received: by 2002:a9d:1462:: with SMTP id h89mr16583615oth.18.1587932918021;  Sun, 26 Apr 2020 13:28:38 -0700 (PDT)
MIME-Version: 1.0
References: <9B51BF38-4ADF-4062-8A46-0D2CAA2213EE@ripe.net> 
In-Reply-To: 
From: Alexander Azimov 
Date: Sun, 26 Apr 2020 23:28:25 +0300
Message-ID: 
To: Tim Bruijnzeels 
Cc: Nathalie Trenaman , SIDR Operations WG 
Content-Type: multipart/alternative; boundary="0000000000008180bc05a43771fd"
Archived-At: 
Subject: Re: [Sidrops] Agenda for Virtual Interim Meeting 28 April 2020
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Apr 2020 20:28:50 -0000

--0000000000008180bc05a43771fd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Nathalie,

If there is still a slot I would like to take 10 minutes for ASPA drafts.

=D1=81=D0=B1, 25 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 15:38, Tim Bruijnz=
eels :

> Hi,
>
> > On 24 Apr 2020, at 19:44, Nathalie Trenaman  wrote:
> >
> > 
> >
> > 4) Tim Bruijnzeels - [15 minutes]
> > Deprecating rsync Draft
> >
> >
> https://datatracker.ietf.org/doc/draft-sidrops-bruijnzeels-deprecate-rsyn=
c/
>
> I just posted a new version of the document. Major changes:
> - Randy Bush and George Michaelson became co-authors
> - Phased plan is made much more concrete
> - Includes suggested updates to RFCs for each phase
>
> We may find it useful to separate the document into a plan, and
> implementation for each phase, but for now this can hopefully serve to ha=
ve
> a structured discussion.
>
> Slides will be sent to Nathalie and the co-chairs in time, I promise :)
>
> Abstract if you don't feel like clicking the link:
>
>    This document formulates a plan of a phased transition to a state
>    where RPKI repositories and Relying Party software performing RPKI
>    Validation will use the RPKI Repository Delta Protocol (RRDP)
>    [RFC8182] as the only mandatory to implement access protocol.
>
>    In short this plan consists of the following phases.
>
>    In phase 0, today's deployment, RRDP is supported by most, but not
>    all Repositories, and most but not all RP software.
>
>    In the proposed phase 1 RRDP will become mandatory to implement for
>    Repositories, in addition to rsync.  This phase can start as soon as
>    this document is published.
>
>    Once the proposed updates are implemented by all Repositories phase 2
>    will start.  In this phase RRDP will become mandatory to implement
>    for all RP software, and rsync must no longer be used.
>
>    Measurements will need to be done to help determine when it will be
>    safe to transition to the final phase of this plan.  During this
>    phase Repositories will no longer be required to provide rsync access
>    for RPKI validation purposes.  However, they may still provide rsync
>    access for direct access to files for other purposes, if desired, at
>    a best effort basis.
>
>    Although this document currently includes descriptions and updates to
>    RFCs for each of these phases, we may find that it will be beneficial
>    to have separate documents for the plan, and each phase, so that it
>    might be more clear to all when the updates to RFCs take effect.
>
>
>
>
>
>
> >
> >
> > 5) Massimiliano Stucchi - [15 minutes]
> > AS-Cones Draft
> >
> > https://max.stucchi.ch/drafts/draft-ietf-grow-rpki-as-cones.html
> >
> >
> > Thanks,
> > Nathalie
> >
> >
> > _______________________________________________
> > Sidrops mailing list
> > Sidrops@ietf.org
> > https://www.ietf.org/mailman/listinfo/sidrops
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
>


--=20
Best regards,
Alexander Azimov

--0000000000008180bc05a43771fd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Nathalie,

If there is still a slot I wo=
uld like to take 10 minutes for ASPA drafts.

=D1=81=D0=B1, 25 =D0=B0=
=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 15:38, Tim Bruijnzeels <tim@nlnetlabs.nl>:
Hi,



> On 24 Apr 2020, at 19:44, Nathalie Trenaman <nathalie@ripe.net> wrote:

> 

> <snip />

> 

> 4) Tim Bruijnzeels - [15 minutes]

> Deprecating rsync Draft

> 

> https://datatracker.=
ietf.org/doc/draft-sidrops-bruijnzeels-deprecate-rsync/



I just posted a new version of the document. Major changes:

- Randy Bush and George Michaelson became co-authors

- Phased plan is made much more concrete

- Includes suggested updates to RFCs for each phase



We may find it useful to separate the document into a plan, and implementat=
ion for each phase, but for now this can hopefully serve to have a structur=
ed discussion.



Slides will be sent to Nathalie and the co-chairs in time, I promise :)



Abstract if you don't feel like clicking the link:



=C2=A0 =C2=A0This document formulates a plan of a phased transition to a st=
ate

=C2=A0 =C2=A0where RPKI repositories and Relying Party software performing =
RPKI

=C2=A0 =C2=A0Validation will use the RPKI Repository Delta Protocol (RRDP)<=
br>
=C2=A0 =C2=A0[RFC8182] as the only mandatory to implement access protocol.<=
br>


=C2=A0 =C2=A0In short this plan consists of the following phases.



=C2=A0 =C2=A0In phase 0, today's deployment, RRDP is supported by most,=
 but not

=C2=A0 =C2=A0all Repositories, and most but not all RP software.



=C2=A0 =C2=A0In the proposed phase 1 RRDP will become mandatory to implemen=
t for

=C2=A0 =C2=A0Repositories, in addition to rsync.=C2=A0 This phase can start=
 as soon as

=C2=A0 =C2=A0this document is published.



=C2=A0 =C2=A0Once the proposed updates are implemented by all Repositories =
phase 2

=C2=A0 =C2=A0will start.=C2=A0 In this phase RRDP will become mandatory to =
implement

=C2=A0 =C2=A0for all RP software, and rsync must no longer be used.



=C2=A0 =C2=A0Measurements will need to be done to help determine when it wi=
ll be

=C2=A0 =C2=A0safe to transition to the final phase of this plan.=C2=A0 Duri=
ng this

=C2=A0 =C2=A0phase Repositories will no longer be required to provide rsync=
 access

=C2=A0 =C2=A0for RPKI validation purposes.=C2=A0 However, they may still pr=
ovide rsync

=C2=A0 =C2=A0access for direct access to files for other purposes, if desir=
ed, at

=C2=A0 =C2=A0a best effort basis.



=C2=A0 =C2=A0Although this document currently includes descriptions and upd=
ates to

=C2=A0 =C2=A0RFCs for each of these phases, we may find that it will be ben=
eficial

=C2=A0 =C2=A0to have separate documents for the plan, and each phase, so th=
at it

=C2=A0 =C2=A0might be more clear to all when the updates to RFCs take effec=
t.













> 

> 

> 5) Massimiliano Stucchi - [15 minutes]

> AS-Cones Draft

> 

> https://max.stucchi.ch/drafts/d=
raft-ietf-grow-rpki-as-cones.html

> 

> 

> Thanks,

> Nathalie 

> 

> 

> _______________________________________________

> Sidrops mailing list

> Sidrops@ietf.org=


> https://www.ietf.org/mailman/listinfo/sidrops<=
br>


_______________________________________________

Sidrops mailing list

Sidrops@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/sidrops




-- 
Best regards,
Alexander Azi=
mov


--0000000000008180bc05a43771fd--


From nobody Mon Apr 27 09:51:08 2020
Return-Path: 
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 3E45B3A0F5B for ; Mon, 27 Apr 2020 09:51:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
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 3xv-wESuOrFc for ; Mon, 27 Apr 2020 09:51:04 -0700 (PDT)
Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A993A0F5C for ; Mon, 27 Apr 2020 09:51:04 -0700 (PDT)
Received: from bufobufo.ripe.net ([193.0.23.13]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jT6yF-000Agt-1z for sidrops@ietf.org; Mon, 27 Apr 2020 18:51:03 +0200
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::96c]) by bufobufo.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jT6yE-0003vh-VD for sidrops@ietf.org; Mon, 27 Apr 2020 18:51:03 +0200
From: Nathalie Trenaman 
Content-Type: multipart/alternative; boundary="Apple-Mail=_C6856349-B803-41AC-B9DA-27B190C433BE"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: <26451FEF-1311-489A-BCF1-173116C4A133@ripe.net>
Date: Mon, 27 Apr 2020 18:51:02 +0200
To: SIDR Operations WG 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-ACL-Warn: Delaying message
X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a434ad4bd4639eec9e71bbad62cabb3c0
Archived-At: 
Subject: [Sidrops] Updated agenda for Virtual Interim Meeting 28 April 2020
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Apr 2020 16:51:07 -0000

--Apple-Mail=_C6856349-B803-41AC-B9DA-27B190C433BE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi all,

We=E2=80=99ve received some changes to the agenda for our virtual =
interim meeting tomorrow, 28 April at 14:00 UTC.=20
Here is the latest agenda, as published =
on:https://datatracker.ietf.org/doc/agenda-interim-2020-sidrops-01-sidrops=
-01/ =


A gentle reminder: If you are presenting, please send me your slides =
ASAP, as I will be running them from my laptop during your presentation.=20=

Also, it would help remote attendees (all of us!) if you number your =
slides.=20

When you join the WebEx tomorrow, please disable your webcam and mute =
yourself to save bandwidth.=20


   SIDROPS Agenda For Virtual Interim Meeting

Session: April 23rd 2020, 14:00 - 16:00 UTC

Slides:
Etherpad: =
https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-sidrops-01?useMon=
ospaceFont=3Dtrue
WebEx: https://ietf.webex.com/meet/sidrops Jabber: =
xmpp:sidrops@jabber.ietf.org?join

1) Agenda bashing and Chair's slides - [5 minutes]

2) Job Snijders - [20 minutes]
Incomplete Data/Manifests

3) Randy Bush - [15 minutes]
Timing Parameters in the RPKI-based Route Origin Validation Supply Chain =
Draft
https://github.com/randyqx/rpki-rov-timing

4) Tim Bruijnzeels - [15 minutes]
Deprecating rsync Draft
=
https://datatracker.ietf.org/doc/draft-sidrops-bruijnzeels-deprecate-rsync=
/

5) Massimiliano Stucchi - [15 minutes]
AS-Cones Draft
https://max.stucchi.ch/drafts/draft-ietf-grow-rpki-as-cones.html

6) Alexander Azimov - [15 minutes]
ASPA Draft
https://tools.ietf.org/html/draft-ietf-sidrops-aspa-profile-02
https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-04 =


Thanks,
Nathalie Trenaman
Secretary sidrops WG=

--Apple-Mail=_C6856349-B803-41AC-B9DA-27B190C433BE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Hi =
all,

We=E2=80=99ve =
received some changes to the agenda for our virtual interim meeting =
tomorrow, 28 April at 14:00 UTC. 
Here is the latest agenda, as =
published on:https://datatracker.ietf.org/doc/agenda-interim-2020-sidrops-01=
-sidrops-01/
A =
gentle reminder: If you are presenting, please send me your slides ASAP, =
as I will be running them from my laptop during your =
presentation. 
Also, it would help remote attendees (all of us!) if you =
number your slides. 

When you join the WebEx tomorrow, please disable your webcam =
and mute yourself to save bandwidth. 


   SIDROPS Agenda For Virtual =
Interim Meeting

Session: April 23rd 2020, 14:00 - 16:00 UTC

Slides:
Etherpad: https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-sidrop=
s-01?useMonospaceFont=3Dtrue
WebEx: https://ietf.webex.com/meet/sidrops Jabber: xmpp:sidrops@jabber.ietf.org?join

1) Agenda bashing and Chair's slides - [5 minutes]

2) Job Snijders - [20 minutes]
Incomplete Data/Manifests

3) Randy Bush - [15 minutes]
Timing Parameters in the RPKI-based Route Origin Validation Supply Chain =
Draft
https://github.com/randyqx/rpki-rov-timing

4) Tim Bruijnzeels - [15 minutes]
Deprecating rsync Draft
https://datatracker.ietf.org/doc/draft-sidrops-bruijnzeels-depr=
ecate-rsync/

5) Massimiliano Stucchi - [15 minutes]
AS-Cones Draft
https://max.stucchi.ch/drafts/draft-ietf-grow-rpki-as-cones.htm=
l

6) Alexander Azimov - [15 minutes]
ASPA Draft
https://tools.ietf.org/html/draft-ietf-sidrops-aspa-profile-02<=
/a>
https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verificatio=
n-04

Thanks,
Nathalie Trenaman
Secretary sidrops =
WG
=

--Apple-Mail=_C6856349-B803-41AC-B9DA-27B190C433BE--


From nobody Mon Apr 27 10:51:55 2020
Return-Path: 
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 969C73A12B1 for ; Mon, 27 Apr 2020 10:51:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.919
X-Spam-Level: 
X-Spam-Status: No, score=-2.919 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.82, 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 BxgbIKidRn0m for ; Mon, 27 Apr 2020 10:51:50 -0700 (PDT)
Received: from sonic316-11.consmr.mail.bf2.yahoo.com (sonic316-11.consmr.mail.bf2.yahoo.com [74.6.130.121]) (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 DC3DB3A12AE for ; Mon, 27 Apr 2020 10:51:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1588009908; bh=vz84qkyFaZFFkSThTB60nGdjfgj96RJJBrnsQv4Kcsg=;  h=To:From:Subject:Date:References:From:Subject; b=CJaB9j9H5HEkfsRsedl3icEUEZmf5oWNq7cdMcIYAVC9OBedFS/AarGY4Y5gGh4+nFjwlwu4lJI1cgCHSlgpuNGF1mvPu8K1AKBKGiJeZe8cVRx/SJ2Q2kj8UHukJeYTow3H09cUTi0gqGruGY2H4l9m6Uz1Q9WqNLp07cxxthYrCbOFGiAkO83sNluy5q+VIZMRc79/CqNhEtvo3whpfoFmdRSSo5IM9sDeyUGGVsrbob3vgkXXXk103CcsEmHiLUqvFq6ci4fu01YD0e2K1uCaG5ygMCr798YuWQ2gmXRl6BKXRGKuEBM8pAQKogBnC/jEKzaVUJUpEuF6Ri+3Yw==
X-YMail-OSG: Mje3gSIVM1l9dVwOT.jiYoephbUweIw4x_hY6.ejoQcBuyKJe7TE_EGIH0wEhOf MzHpPSScrgW7MktmVYbcx.eyFkOZY9l0FhehCV8iIVmPKy5j6VHXUyU2a0zlLpbrOFD0NXEcrXS. nKjJOISq8AUZCyKXFFoHQB2NxlKtCMy0Xzh4C5fjPkcMP62veuwUHSx4pKdvc9Ja3a8d2NfvFVMI 9rAco0bnlP4CBjLKWs09yWLyr6WhwZYSlnB_kH5hHcefR4RNnpBi.Sv2eqxsJWSmweIfyaEjWAd3 4.xRKyw.SBGFVRio4cF2rm_Q2U9xx7yosfGv4cT2vvYV02ROPoTTynkbfSer8zNxSo9xu8OUiGog xoJrq3z8rL0OxtMaHhC2z1FYwumr0c6RTtfsY2vifmV3rpLIo6DsyPgiF8msufSPgDW7vpKn3nd0 65aTEP8dNEUpn4xuqkM50sEzrQsGA_pnmwCwWL7xtNWFJcEfY7B6uo2KIYQNtWw5SniqGY_WtYu. GVaHyqx62.XQwitr8o4W673I4rXUxPqtYrxmLk.nwzqX_DsgIZ_3DjAYqXLW0pvqkVyznMnUEV5L BAmVI2IFaDz5rDuaWbgJLnQjQMwzfEi6kasWB3dcSWI6crLm4gOh2MZIdVL58G8us04Fu2eH1VyE VGaNdAnaEovLStnDhA35wAwsiVga4DDP3i3yp4i9IzX7UbHRyw0KYN8GI4raXjJvXiZynQ8pp0C9 oYYp622e8egGLEWN3ywijKpamyKOIlkqVFMw237pEwYiyFPjEL4vNmtXvsZGGx0SA.j11OYNY7VZ rv.cZ3KfbY36DLySVLh2I_Za_8KCvvXdX6d7v6peC6yttrjeDvUDKiXhn.7JAWvRDajzfBiMhM8T YW7SBU68t9KyLLnKtiSD3mZLSsNkw1fr71bpxUHKTh_PpbwvOVFyzJh5o2DM5UZ.SHDyPOfOYUHQ 3.P0hoHUKpngN1EKKMhbWkshl1GvLNpAqwQcuyGJyjW.jK7uY_Qe89ZKa1n2Ze8wE9o5pg2NGxpi 8J.o.xtvYXcaBifqPwIJ5cRL0jGIQEq0K.Ic5WCZbVaenuf_FhzbAbYLkoGomDnOM9rxG2_b0QrR XFJxuiSzx7dZm896aBtbkh1G4hi9njahl2cehM63ypAOHM4NJqQMk7AAwe_NfFkEZRnZRdchRALo 243umh6uUpRTUXjIhp1fzU.z0YbxYzFLvdzia2YYSXxzt1dotPhVLbPagAs5ztTKnp93KA0.NcVM 3j0z9nlPSscx5I44LtdYNvLeUrqlK9IsFFBb9geP6Kb4cQI69PB89BfFoGUcjxxrAqyZZf6.XxP_ VJduIgarVazTw_yRC_79rDnd2kmPRvugYLwpyTpvAZfxuiNFaPrzJLJ2iTPV9xW4gpFCz8mHu4Tp sCStmQ.6N7URkMyqnm.CN9BEeGWW3ulZV0TtvI_EQ55Y7Hr6tRjMpa5CkAB4TQCJq
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Mon, 27 Apr 2020 17:51:48 +0000
Received: by smtp432.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f2c6eb526ed8cfcf32c8457247d02d01;  Mon, 27 Apr 2020 17:51:47 +0000 (UTC)
To: "sidrops@ietf.org" 
From: Stephen Kent 
Message-ID: 
Date: Mon, 27 Apr 2020 13:51:46 -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
Content-Type: multipart/alternative; boundary="------------7E3E8F1AF2C1847EDD6303DC"
Content-Language: en-US
References: 
X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: [Sidrops] comments on the AS-Cones draft
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Apr 2020 17:51:53 -0000

This is a multi-part message in MIME format.
--------------7E3E8F1AF2C1847EDD6303DC
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

I noticed that a draft describing Autonomous Systems Cones is on the 
agenda for tomorrow.

I reviewed this ID as though I were performing a SECDIR review of a 
draft. Thus my comments focus on document clarity and security, rather 
than routing-specific issues.

Section 1

The introduction needs to better explain the motivation for creating 
these objects, e.g., a desire to reproduce the functionality of the RPSL 
AS-Set data structure in the RPKI context. The allusion to RFC 6480 
should be replaced with an explicit statement that you are defining two 
new types of signed objects to be stored in the RPKI, to convey the data 
that is present in the RPSL structure. The reader should not have to 
wait until Section 3 to learn this.

Section 2:

This description is confusing, at best. The text here should cite RFC 
6488 and note that the AS-Cone and Policy Definition objects use of the 
CMS object format defined in that RFC. Note that the OIDs assigned to 
these two types of signed objects are defined later in the document. The 
ASN.1 for the 6488-level definition of signed objects should appear here.

2.1

A policy definition object contains a list of the upstream and peering 
relationships for a given Autonomous System that need an AS-Cone to be 
used for filtering.

->

A policy definition object contains a list of the upstream and peering 
relationships for a given Autonomous System that may wish to use an 
AS-Cone for filtering.

The text provides a description of the default behavior for a neighbor 
in the absence of an AS-Cone and associated policy, but it doesn’t even 
hint at the expected behavior when the AS-Cone and policy objected are 
present. I suggest adding text here to provide a preview of that 
behavior as described later.

It’s odd to call out and explain the Contact e-mail field before 
describing the other fields. I suggest describing each field in the 
Policy Definition object in this subsection. The subsequent text about 
how to accommodate multiple ASNs is confusing absent such a description. 
Also, no rationale is provided for why this restriction on ASNs is imposed.

2.1.1

The sentence here really should cite the variable ASCone when describing 
the naming convention, to avoid confusing the reader. Also, the text 
refers to a Policy object, not a Policy Definition object. Why?

2.1.2

The ASN.1 definition here should precede the discussion of fields in the 
object. Then each field should be described, in order. It’s not obvious, 
for example, why there is a LastModified time as well as a Created time. 
Neighbor is defined as a SEQUENCE vs. a SET. Is the ordering imposed by 
the SEQUENCE significant? Also, why not begin the structure with the AS 
number as an identifier? It seems odd to begin with the Neighbor 
sequence. The OID to be used in the 6488 object structure should be 
defined here.

There are two timestamps here, but the 6488 object structure optionally 
contains a timestamp that probably is equivalent to the LastModified 
variable here. The text should indicate whether the 6488 SigningTime 
value MUST be omitted, and thus LastModified is needed, or …

2.1.3

The text here is confusing. In 2.1.1 we’re told that a Policy 
(Definition?) object is named by suffixing an ASN to the string “AS” but 
here it appears that the object name also includes the ASN of the 
neighbor for which the object is destined. Which is correct?

2.2

The definition of AS-Cone is presented recursively, which is OK, but 
then it’s redundant to say, in the final sentence, that an AS-Cone can 
reference another AS-Cone.

The ASN.1 for this object should be the first part of this section, not 
buried in 2.2.4

2.2.1

This description of how the verification status of a AS-Cone is managed 
should come after the description of the semantics of the field. Also, 
it appears that the status change is the result of an e-mail exchange 
between two ASN operators. If the AS-Cone is to be consumed by other 
ASNs, how are they able to verify that the indicated status is accurate? 
This seems to be an aspect of the AS-Cone that cannot be verified using 
RPKI data- an RP is relying on the AS operator to have accurately 
reported this status. Having applied a signature to this data does not 
make it accurate.

2.2.2

Need a definition of a “third party” cone. This is the first mention of 
a responsibility for an RIR with respect to these objects. The 
discussion of such authentication is rather vague. Also, it’s not clear 
how a third party can independently verify that such authentication has 
taken place.

2.2.3

AS-Cones MUST have a unique name for the ASN they belong to. Names are 
composed of ASCII strings up to 255 characters long and cannot contain 
spaces.

In order for AS-Cones to be unique in the global routing system, their 
string name is preceded by the AS number of the ASN they are part of, 
followed by ":". For example, AS-Cone "EuropeanCustomers" for ASN 65530 
is represented as "AS65530:EuropeanCustomers" when referenced from a 
third party.

->

Each AS-Cone carries a name that MUST be globally unique. Names are 
composed of ASCII strings up to 255 characters long and cannot contain 
spaces.

To ensure uniqueness, the name for an AS-Cone begins wit ”AS” followed 
by the ASN of the AS in question, followed by a colon (“:”) and a text 
string describing the AS-Cone.

The mention of a “third party” in the original text is confusing. Also, 
why is the name a VisibleString? Only ASCII characters are allowed 
according to the opening sentence. In contrast, the VisibleString data 
type accommodate all IA5 characters. Did the text mean to say 
International ASCII, or should the ASN.1 data type be just 
PrintableString, or …?

2.2.4

As noted earlier, the syntax should begin this subsection, and the OID 
for this object in the RPKI object format should be specified here.

3.

I think this section should begin with an overview explaining how the 
data already present in the RPKI relates to these new objects. Other 
RPKI objects have clear limits on their semantics, based on the 
hierarchic structure imposed by the 3779 extensions. A similar 
explanation about how bad AS-Cones or Policy Definitions are detected 
and rejected, based on existing RPKI objects, is required here.

What is a “full AS-Cone”? The text defines a Policy Definition Object 
and an AS-Cone object, but I didn’t see an indication of what 
constitutes a “full” AS-Cone.

This section title refers to validation, but it really appears to be a 
description of how to construct AS path filters, right?

I see no description of object validation here, other than the reference 
to 6488. That reference is not sufficient to define validation for these 
two new objects. Note that every RPKI signed object using the 6488 
structure has a companion RFC that describes both the syntax and the 
validation procedure for that object. That procedure needs to be 
described here, for both object types, consistent with the section 
title. For example, if the Created or LastModified dates are in the 
future, is the object invalid? What if the Created date is later than 
the LastModified date? Are there any checks to be performed on the list 
of ASNs in an AS-Cone or Policy Object?

After the validation discussion, a new section should describe the AS 
path filter construction process. There are too many questions in the 
preceding sections for me to be confident that I can follow the details 
here, so I stooped trying to carefully examine the text. Also, there is 
reference to an “ASX Default policy” but I don’t recall seeing that term 
defined before. Finally, the process is described in a fashion that 
makes it very hard to follow, given the combination of iteration and 
recursion (as noted in step 6).

Since I stopped reviewing at Section 3, I did not review Sections 4 or 5.


--------------7E3E8F1AF2C1847EDD6303DC
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    
I noticed that a draft describing Autonomous Systems Cones
        is on the agenda for tomorrow. 

      

    

      
      I reviewed this ID as though I
        were performing a
        SECDIR review of a draft. Thus my comments focus on document
        clarity and security,
        rather than routing-specific issues.

    
 

    
 

    
Section 1

    
 

    
The introduction needs to better
        explain the
        motivation for creating these objects, e.g., a desire to
        reproduce the
        functionality of the RPSL AS-Set data structure in the RPKI
        context. The
        allusion to RFC 6480 should be replaced with an explicit
        statement that you are
        defining two new types of signed objects to be stored in the
        RPKI, to convey
        the data that is present in the RPSL structure. The reader
        should not have to
        wait until Section 3 to learn this.

    
 

    
Section 2: 

    
 

    
This description is confusing, at best. The text
        here should cite
        RFC 6488 and note that the AS-Cone and Policy Definition objects
        use of the CMS
        object format defined in that RFC. Note that the OIDs assigned
        to these two
        types of signed objects are defined later in the document. The
        ASN.1 for the
        6488-level definition of signed objects should appear here.

    
 

    
2.1

    
 

    
A policy definition object contains a list of the
        upstream and peering
        relationships for a given Autonomous System that need an AS-Cone
        to be used for
        filtering. 

    
 

    
->

    
 

    
A policy definition object contains a list of the
        upstream and peering
        relationships for a given Autonomous System that may wish to use
        an AS-Cone for
        filtering. 

    
 

    
The
        text provides a description of the default behavior for a
        neighbor in the
        absence of an AS-Cone and associated policy, but it doesn’t even
        hint at the
        expected behavior when the AS-Cone and policy objected are
        present. I suggest
        adding text here to provide a preview of that behavior as
        described later.

    
 

    
It’s
        odd to call out and explain the Contact e-mail field before
        describing the
        other fields. I suggest describing each field in the Policy
        Definition object
        in this subsection. The subsequent text about how to accommodate
        multiple ASNs
        is confusing absent such a description. Also, no rationale is
        provided for why
        this restriction on ASNs is imposed.

    
 

    
2.1.1

    
 

    
The
        sentence here really should cite the variable ASCone when
        describing the naming
        convention, to avoid confusing the reader. Also, the text refers
        to a Policy
        object, not a Policy Definition object. Why?

    
 

    
2.1.2

    
 

    
The
        ASN.1 definition here should precede the discussion of fields in
        the object.
        Then each field should be described, in order. It’s not obvious,
        for example,
        why there is a LastModified time as well as a Created time.
        Neighbor is defined
        as a SEQUENCE vs. a SET. Is the ordering imposed by the SEQUENCE
        significant?
        Also, why not begin the structure with the AS number as an
        identifier? It seems
        odd to begin with the Neighbor sequence. The OID to be used in
        the 6488 object
        structure should be defined here.

    
 

    
There
        are two timestamps here, but the 6488 object structure
        optionally contains a
        timestamp that probably is equivalent to the LastModified
        variable here. The
        text should indicate whether the 6488 SigningTime value MUST be
        omitted, and
        thus LastModified is needed, or …

    
 

    
2.1.3

    
 

    
The
        text here is confusing. In 2.1.1 we’re told that a Policy
        (Definition?) object
        is named by suffixing an ASN to the string “AS” but here it
        appears that the
        object name also includes the ASN of the neighbor for which the
        object is destined.
        Which is correct?

    
 

    
 

    
2.2

    
 

    
The
        definition of AS-Cone is presented recursively, which is OK, but
        then it’s
        redundant to say, in the final sentence, that an AS-Cone can
        reference another
        AS-Cone.

    
 

    
The
        ASN.1 for this object should be the first part of this section,
        not buried in
        2.2.4

    
 

    
2.2.1

    
 

    
This
        description of how the verification status of a AS-Cone is
        managed should come
        after the description of the semantics of the field. Also, it
        appears that the
        status change is the result of an e-mail exchange between two
        ASN operators. If
        the AS-Cone is to be consumed by other ASNs, how are they able
        to verify that
        the indicated status is accurate? This seems to be an aspect of
        the AS-Cone
        that cannot be verified using RPKI data- an RP is relying on the
        AS operator to
        have accurately reported this status. Having applied a signature
        to this data
        does not make it accurate.

    
 

    
2.2.2

    
 

    
Need
        a definition of a “third party” cone. This is the first mention
        of a
        responsibility for an RIR with respect to these objects. The
        discussion of such
        authentication is rather vague. Also, it’s not clear how a third
        party can
        independently verify that such authentication has taken place. 

    
 

    
2.2.3
      

    
AS-Cones MUST have
        a unique name
        for the ASN they belong to. Names are composed of ASCII strings
        up to 255
        characters long and cannot contain spaces. 

    
In order for
        AS-Cones to be
        unique in the global routing system, their string name is
        preceded by the AS
        number of the ASN they are part of, followed by ":". For
        example,
        AS-Cone "EuropeanCustomers" for ASN 65530 is represented as
        "AS65530:EuropeanCustomers" when referenced from a third party.

    
->

    
 

    
Each
        AS-Cone carries a name that MUST be globally unique. Names are composed of ASCII strings up to 255 characters
        long and cannot
        contain spaces. 

    
 

    
To ensure uniqueness,
        the name for an
        AS-Cone begins wit ”AS” followed by the ASN of the AS in
        question, followed by
        a colon (“:”) and a text string describing the AS-Cone.

    
 

    
The mention of a “third
        party” in the
        original text is confusing. Also, why is the name a
        VisibleString? Only ASCII
        characters are allowed according to the opening sentence. In
        contrast, the
        VisibleString data type accommodate all IA5 characters. Did the
        text mean to
        say International ASCII, or should the ASN.1 data type be just
        PrintableString,
        or …?

    
 

    
 

    
2.2.4 

    
 

    
As noted earlier, the
        syntax should
        begin this subsection, and the OID for this object in the RPKI
        object format
        should be specified here. 

    
 

    
3. 

    
 

    
I
        think this section should begin with an overview explaining how
        the data
        already present in the RPKI relates to these new objects. Other
        RPKI objects
        have clear limits on their semantics, based on the hierarchic
        structure imposed
        by the 3779 extensions. A similar explanation about how bad
        AS-Cones or Policy
        Definitions are detected and rejected, based on existing RPKI
        objects, is
        required here. 

    
 

    
What
        is a “full AS-Cone”? The text defines a Policy Definition Object
        and an AS-Cone
        object, but I didn’t see an indication of what constitutes a
        “full” AS-Cone. 

    
 

    
This
        section title refers to validation, but it really appears to be
        a description
        of how to construct AS path filters, right?

    
 

    
I
        see no description of object validation here, other than the
        reference to 6488.
        That reference is not sufficient to define validation for these
        two new
        objects. Note that every RPKI signed object using the 6488
        structure has a
        companion RFC that describes both the syntax and the validation
        procedure for
        that object. That procedure needs to be described here, for both
        object types,
        consistent with the section title. For example, if the Created
        or LastModified
        dates are in the future, is the object invalid? What if the
        Created date is
        later than the LastModified date? Are there any checks to be
        performed on the
        list of ASNs in an AS-Cone or Policy Object?

    
 

    
After
        the validation discussion, a new section should describe the AS
        path filter
        construction process. There are too many questions in the
        preceding sections
        for me to be confident that I can follow the details here, so I
        stooped trying
        to carefully examine the text. Also, there is reference to an
        “ASX Default
        policy” but I don’t recall seeing that term defined before.
        Finally, the
        process is described in a fashion that makes it very hard to
        follow, given the
        combination of iteration and recursion (as noted in step 6).

    
 

    
 

    
Since
        I stopped reviewing at Section 3, I did not review Sections 4 or
        5.

    

      






Hi Alex and Ruediger, 


 


To continue our discussion at the meeting, let’=
;s use the example you provided yesterday. Both lateral peering between AS1=
—AS2, and AS2—AS3.



 


First question, does AS1 or AS2 sign any ASPA object=
 for this pair and how?  I see description for Sibling relation repres=
entation in Section 7, but haven’t been able to find any for P2P.



 


Second question, if yes to the above question, how d=
oes AS 3 use any of the ASPA object(s) to detect the leak? And if no, how t=
o detect the leak anyway?



 


Thanks.


 


Yunan


 



















3D"10.1.1.0/24"











3D"AS

3D"AS










 






--_000_C01B0098369B2D4391851938DA6700B7179F9EABdggeml512mbschi_--

--_012_C01B0098369B2D4391851938DA6700B7179F9EABdggeml512mbschi_
Content-Type: application/octet-stream; name="image001.emz"
Content-Description: image001.emz
Content-Disposition: inline; filename="image001.emz"; size=1032;
 creation-date="Wed, 29 Apr 2020 02:21:28 GMT";
 modification-date="Wed, 29 Apr 2020 02:21:28 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

H4sIAAAAAAAEC6VVS2sUQRCueRjHqNkhiUlQibsxwWgkRMhhjY/0+tz4gEWzHtT4CEEQBE0QBQUd
0IMHD0EUhOTgRRAPmqMIQg65ePAoHuJB1B8QwUNQcPy+nunZcXHBR8E3VVNVXVVdXdNjicgF4GsY
hsRRyAcBQ3NLRd7XiWT3Ht4nYkmpXmQnjK5xiHkAvzyUGVuk2/rV+LDeE3XbFQSQzUAWQLgeS1my
FrIP2P7sPJediUHfk0AJoG+HcmUFZFK7WpbInYhh9H3K1rGi2oLBnFqa2FwlidyCGFzTBmA7eg2Y
pmV4+kARUEAXQN8GkSAtH4HuEgpmzV/QN7CEJqkEIWfHbjmL/p6XUZnA8/+ItZEm9VNkqGXkcruW
j914jZytL3uuLd6k4px+Zx/4fkf7RI/IP5K5H9LMyI71XP9i7OoA/Y0+slae2bYoH+1pn3IvduzZ
mYenovVhr3y+3imzpt4w7ofpxUxc94+7F3U+k+FDrPcfvdkW7UNk7Ip4tDMfz4GhasmNKR+ebTwX
9jBkwhAD+gBjlR/MF07vmi9AlJWx7hB4NEPUVmahBDkrwSD3lY7PWb2PYHcAzuomJdIZ+2BsBiEG
ESryOuWY+qRTJbXKb9ZiKUmv1VKPqvi3q7okTk4tSeT0N/InMdPfStr/3Ob3eZ0UD8rjjgwSnhJn
ErrbAL9d9s7QTHCvWC6/evau1ykOv2sqUt+35rHmx7tkSOTJs741XUO0k9Of/Ov5T0XaZ4LGIfqT
cz05vsDntDMW/cWp0C3HudWsJPBh47m9nToR5sA9YBQwc8MzIdDLHZpVyTbeNwBtAGXSiam3mpuZ
o74JMDG3QWaeMlACDOFK0BT1ZRGT8VFCGPMIMOHg7nA/AovWJTfjTDgLTt5ecEJZgCUDLFrb4cu4
vGtZj6H9EDhQ6RpMbVAHqT0WzBqoE5n1c16HgSLAefWUZfdD7gZ4lmDJHbP6WzPd9Xpjmx4vhKtU
9A25MGJzMgCwJ6w5VUPNPp+GXx7AZjUHS7h0WMmdXBifpikhs1euM/ISbLCM9xJQ/R/71/6b2Pit
BUZG+D/qL/vIXrBG0xf+ZzpiPQeDTZ0DXgA17gxYSH/33XvKdtuwivnNeaEOvx//RupI/3M3uCqK
zTg5wAP4T2HO5UAG2A5sARoB5uR8mJqwdX0fj0HXGqMPvBugn7mPaWPfOV+HYl4dfxj6ghyVLLLx
TsZZ6Z6TV+ejL2ti3K1AdT7amI811MpXgi0LMJeJD9FOn6uZlYbU3FDmefcDzFvjvAOYgMo/IgeF
B4wCpo+sbQz4jkYSfN+Tej8C+QCwUZ7iaagyQ3F8Y/gtT++Hda8FfIB126py/tiXNAMkH6D8E5e1
iHFQCgAA

--_012_C01B0098369B2D4391851938DA6700B7179F9EABdggeml512mbschi_
Content-Type: image/png; name="image003.png"
Content-Description: image003.png
Content-Disposition: inline; filename="image003.png"; size=232;
 creation-date="Wed, 29 Apr 2020 02:21:28 GMT";
 modification-date="Wed, 29 Apr 2020 02:21:28 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAAgAAAANCAMAAAHUG++cAAAAAXNSR0IArs4c6QAAAARnQU1BAACx
jwv8YQUAAAAhUExURQAAAFeX11+fz1ua01qa1Fub1Vqa1Fqa1Vqa1Vub1Vub1UuWDEYAAAAKdFJO
UwAgEHAwn2Dn74CVe5GCAAAACXBIWXMAAA7DAAAOwwHHb6hkAAAAOklEQVQYV2OAAC4wggB2OJsJ
yAICIIsRIgBlsHExQyXYuFgZGFjAMmiAjYMTqB3EgBqBzGCFm8fAAABHGgExY9i5XwAAAABJRU5E
rkJggg==

--_012_C01B0098369B2D4391851938DA6700B7179F9EABdggeml512mbschi_
Content-Type: application/octet-stream; name="image005.emz"
Content-Description: image005.emz
Content-Disposition: inline; filename="image005.emz"; size=813;
 creation-date="Wed, 29 Apr 2020 02:21:28 GMT";
 modification-date="Wed, 29 Apr 2020 02:21:28 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

H4sIAAAAAAAEC6VVTUtUURh+53rV0SwvkjYLme7YSKYyjeFCCulYFAoKEuoq+5DBJgj6ICoK6gYt
WrSYTeCydbRwKa1ctGnRPrBFi/5AO1dNz3M+7j2NCkXv8Nzz3PfrvOe8557JicgdoGmlDj4MOJk4
JBKEIvGlhcsiOVF5kdMwtjkHOyadIlPw6w1ERnJ/Gje686JehYIEMg7EANKN5VROBsEjIIi2dxh2
w4K+V4FFgL5DKpQecEpRdaW8jBxOX1WBzoUyIMn5kupMbaGSlA/AypgC0A1EgJMukAhw+8C9oO8R
JPR5n9Wz5ivAPRDyn9hHDKk0qIRg/qGLchN7fVvW5AGe/yesk9LQT5G5gdWHRc1Xnn/GnMc+jj3d
fUHFun7nnvD9tfYxD+NvuOv55ur0CcZv1R6fpb/Te2GaxgUzH+2+z3IFK84HvRvXTHyzIj+elWXb
1du0++H2YtPW/evNXT2fm+e71Ufvvpwz6xCpPRKcPjMfe8JUnHs/zt5SDwmW8CCcMEkEMH757c7M
9Qs7M6By2OrmMZozRG12FhbBY4Br8fPzrBaQrAfgWR1VImXrw3MImhhk/Lhqc/VJWaW1yj6xCKXo
WM3GVOZfVB1pnpJqT7n/jfxNTv9b8f3Xx79N6Unx8Hm3ksStkVcHlp7Ky6/35+L+D7MlaPLAGuB6
xBgC65nWQwvH9SEngQJATnGflOs19Y4jf7KC96rxYynNurW3Y9xt8jcbPOkgzJuLxZWVOA5XvR5b
2wzerSQp57xDANfCedj3T8AWcEDfYaH8W+/ySkKun/PwXmQG3LfRpPL7nt2Bo9Czbsb4c/nc72+o
sjyuR7wLTLwI960OxEAf4HpHOzlEf1MNEN6f9J8H+oEc4L4p2hiPvxBtDzFS/Pw1vE+gexU8Dar4
fzkjk9CjPxqMI28dOzyf1tqWYFsAONcy0FobbayN9bJ25qb4tS3iPQZav3f/DAzDzj1p/X/g2ZgE
RoADzkYCE5DdCSUo8sAawJyuthq4k1sgZfeCsQ6whlPy3tNm583m92x7qb8e1j0IRADrDlTac65R
jgKUCCD/DdbYSAVACAAA

--_012_C01B0098369B2D4391851938DA6700B7179F9EABdggeml512mbschi_
Content-Type: application/octet-stream; name="image006.emz"
Content-Description: image006.emz
Content-Disposition: inline; filename="image006.emz"; size=1051;
 creation-date="Wed, 29 Apr 2020 02:21:28 GMT";
 modification-date="Wed, 29 Apr 2020 02:21:28 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

H4sIAAAAAAAEC6VVSWsUURCuXtSO2zQxalCJMzHBLBKi5DCueeM6cYFBMx6McQlBCAiaIAoK2qAH
Dx6CKAh68CKIiOYogiDixYNH8RAPbj8ggoegYPt9r/v1tEMGohZ8XdVV9arq1at+bYnIaeB7GIbE
Icj7AEOv5ol8mCuS3XVgt4glj+eLKBhd4xDzAH55KDO2SJv1p/HOfE/UNVcQQNYBWQDhOi1lySrI
PmD7Lye57EQM+h4FSgB9m5UrCyGTmlRdIrcghtF3K1vHimoLenNqXmJzlSTyMsTgmkYA29FrwDTV
4ekDRUABrQB9F4sEabk+1rPmg8BZCJS/oYdgCY1TCUL+5h1yEr0ekSEZw/P/iHWSxvVTpG/Z4Lkm
LR++/AY5lz/vvDh9hYpT+p094ft17RM9Iv9I5t5IE4Nb13D9s+ELm+hv9JG18sw2RvloT/uUu7Bj
z87cORatD7vk66UWeWnqDeN+mF5MxHX/unFG5zMZPsZ6//7bzdE+RIbPi0c78/FMGKqWzLON58Lu
h0wYYhAf4Pry7cnC8e2TBYiyKNbtB49miNrKLJQgZ+XwZe4lHZ+zegvBrgOc1Q4l0hL7YGx6IQYR
KvJq5Zj6pEUltcoMa7GUpNdqqVNV/JvU3CROTs1J5PQ3MpuY6W8l7X9q3Ye8TooH5VFHeglPiTMO
3TWA3y57Z2giuFksl188ed/lFPvfLylS373ygeZHWqVP5OGT7pWtfbST05/8+8iXIu0TQX0f/cm5
nhxf4FPaGYv+4lToquNcbVAS+LDx3N7dHQhz4B4wBJhZ4ZkQ6OVWzapkG+9rgUaAMmng7jvNzZxR
vwQwMTdDZp4yUAIM4RrQFPVlGpPxWUIY8wgw5uC+cD8D09ZZN+OMOVNO3p5yQpmCJQNMW1vgy7jb
ANZjaA8EDlS6BlMb1EFqjwWzBupEZv2c136gCHBePWXZPZDbAJ4lWHKvrPjRQHe93tjujRbCpSr6
hlwYsTnZBLAnrDlVQ80+H4dfHsBmNQdLuDRbyZ1cGL1HU0Jmr1xn5DnYYBnvJaD6P/av/Tex8VsL
jIzws+ov+8hesEbTF/5nmmM9B4NNfQ08A2rcGbCQ/u6795TtNmIV85vzQh1+D/6N1JH+525wVRSb
cXKAB/A/wpwLgAywBVgP1APMyfkwNWHr+j4+Ad3yGO3gbQD9zH1MG/vOHu4HOGfV8fuhK8ghyYLX
ATgr7V+di34dAGN2A9W5aGMu5q+VqwTbBvk0whwzxV8PPeNvBKrj0zab+Fn4cR8mPkQ7PTNmDhen
ZpIyZ6kHYN4asxTABFT+PzkoPGAIMGfEvQ8DP3FIBN93pt4PQt4LtMsjPA1V5jOObwwz8vR+WPcq
wAdYt60qs4V9SQNA8gHKvwH5yOV5rAoAAA==

--_012_C01B0098369B2D4391851938DA6700B7179F9EABdggeml512mbschi_
Content-Type: application/octet-stream; name="image007.emz"
Content-Description: image007.emz
Content-Disposition: inline; filename="image007.emz"; size=1059;
 creation-date="Wed, 29 Apr 2020 02:21:28 GMT";
 modification-date="Wed, 29 Apr 2020 02:21:28 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

H4sIAAAAAAAEC6VVT0gVYRCft7vVGpWLmkmFvmdKliJGHl5//V5RPcPgoT4PlVkighCkEgUFtVCH
Dh0kCoI6dAkiojxKEHjo0qFjdLBDUccuRUFUtP1+3+63b3v4wGrgtzM7M9/MfPPNt5sSkdPAlyAI
vgIDkPsAQ89XiHxcLpI+cOSgSEoerRRRMDrGIeI+/LJQVlsibak/jbdXuqKuOoIA0gGkAYRrT6mU
bITsAZY3v8BlJyPQ9zhQAOjbrBxZBZnUqKpiuQUxjL5LWTpWWJvfk1ErYpujJJbrEYNrGgBsR68B
01SFpwfkgRzQCtB3jYiflGsiPWvuByYhUP6EHoLFNEMlCPmb98sp9HpCRmUaz/8j1kma0U+R3vrh
s41aHrr0AjnXPW2/8O0yFeP6nT3h+zXtEz5C/1Dm3kizw3s2cf3c2Pmd9Df60Fp6phvCfLQnfYqd
2LFrVd8+Ea4POuXDxRaZN/UGUT9ML2ajun9dP6PzmQxvI7137+WucB8iY+fEpZ35eCYMVUnm2UZz
YQ1CJgwxiAdwffHWQm5k30IOoqyOdH3g4QxRW5qFAuS0DF3iXpLxOas3EewawFndqkRaIh+MTQ9E
P0RJblK2qU9aVFyrLLIWS0l6rZbaVcm/US2P42TUslhO3pGlxEzelaT/eMebrE6KB+UpW3rmUvM9
rhJ7BrqrAO8ue2do1r+RLxafPX7daecHX9fmqe/acF/zo63SK/LgcdeG1l7ayelP/mXifZ72Wb+m
l/7kXE+OG/iEdsaiv9gluoJTqVPie7Dx3F7dORZkwF1gFDCzwjMh0Ms9mpXJ+HTJZqABoEw6dueV
5mbOqK8FTMxdkJmnCBQAQ/gMaAr74mLZZwkwdVnLk2nbk0nnM+Bak06TPW2Lk7XECXT5TTYiWrsR
iHH3AqyHhPGSQ4ACkjWY2qD2E3vM4T0iP5ZZP+d1EMgDnFdXpaxuyG0AzxIs/q6s/15Hd73e2O5O
5YK1KrxDDoysayfAnrDmRA0V+zwCvyyAzWoOFnNpTun7SV1u6i5ZTGavXGfkZdh3Ee8FoPw/9q/9
N7HxW/ONjPBL6i/7yF6wRtMX/meaIz0Hg019DswBFb4ZsJD+7t67ynIasIr5zXmhDq8b/0bqSP/z
bXBUGJtxMoAL8D9iclZD3g1sA2oA5uR8GDu2rr/HJ6FbB9QDW4DNAP3M95g2zhF72AdwzhgrGX8Q
7zkZkDR4FYCz0v7luei3FWCuLqA8F23MxfyVchVg2y7vJphjsfjboGf8HUB5fNqWEj8NP+7DxIdo
JWfGzOGaxExSPgjHbqANqDBLPkxA6f+TgcIFRgFzRtz7GPADh/QT4PuBxHs/5MPAFnmIp6HSfEbx
jWFRntwP694IeADrtlRptrAvqQNIHkD5N1z7J5WsCgAA

--_012_C01B0098369B2D4391851938DA6700B7179F9EABdggeml512mbschi_
Content-Type: image/png; name="image008.png"
Content-Description: image008.png
Content-Disposition: inline; filename="image008.png"; size=420;
 creation-date="Wed, 29 Apr 2020 02:21:28 GMT";
 modification-date="Wed, 29 Apr 2020 02:21:28 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAEsAAAANCAMAAAGhllM/AAAAAXNSR0IArs4c6QAAAARnQU1BAACx
jwv8YQUAAABRUExURQAAAFeX11qa1V+f31mZ0l+fz1ua01+f1Fqa1Fub1Fub1Vub1Vub01mZ1Vqa
1Vqa1Fub1Vqb1Vub1Vub1Fub1Fqa1Vub1Vqa1Vub1Vua1lyb1NOxHssAAAAbdFJOUwAghwgoEHAY
MJefp0BQv2DPj9ffeOeA7/84SCUGtwAAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAC1SURBVChTvZHb
EoIwDEQLVkSMgQLGyP9/qAvNg8xgrZfxPJDtTpLSxG2gFlecli8JKwstejMtAUk/hFjqQgwrnvWb
+CiT1b0PkQQetGdVzWnSWsyCWYRudnhFQZUwfmMp8mYC0r2pDTyNsahX7cxLIFmPrHYm/k1BhCEI
XsQd9jEgBhzh1paRxHNW2oxHz1GkxA2YHNbPXIqMcG3yZ7jXKuqvqIka9JoveVjqxzR6KQ+mf4dz
dzyOCiiBF1jYAAAAAElFTkSuQmCC

--_012_C01B0098369B2D4391851938DA6700B7179F9EABdggeml512mbschi_
Content-Type: image/png; name="image009.png"
Content-Description: image009.png
Content-Disposition: inline; filename="image009.png"; size=513;
 creation-date="Wed, 29 Apr 2020 02:21:28 GMT";
 modification-date="Wed, 29 Apr 2020 02:21:28 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAGgAAAAlCAYAAACu2qwTAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO
xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAGBSURBVGje
7ZftjcMgDIYZofPw66bxHMkGbJAtWIZhXEgvKR+GouiqQu99JVdt6tjgBxyiGBpS27b9rOuqFEoB
QBAAARAEQBAAAdD4sqRYG/fNgBwbrVhpw+k0LZMPpw4jezHOVd+e/MFH88nH0tPfm3iLM6xV7zg/
DMgZ7SeimUhnA34U8Lky89+9ca76duYPQM4YHlYU78iT3vKIQ0RzAEqKFg94X2XEtlqMzjhXfbvy
/xbbtndg/P+eM1ywswOSJrC3j6xo7wLUk1+CWECOd1DUDmcHJBbvVUH+EFBP/nM3NFpk/H9ymACg
dwPKDgfFBlTtjvAVLe6Tz6BX+RtjKeAc15RkdchjAyoesOkpyhkSJyYVvdc39Wvlr58oJThcWwAz
7CBxZcWrVLpe6e9ynF5f8kfk7F2nlr/Wao/3m9p8ZgQ0o9qHg3H1TwCV7zYABAEQAEEABAEQAEEA
BEAoBQBBAARAEABBAARAEAABEDQUoPAFNp4ty3LbAYUP2Lh2B6WaqndH7933AAAAAElFTkSuQmCC

--_012_C01B0098369B2D4391851938DA6700B7179F9EABdggeml512mbschi_
Content-Type: image/png; name="image010.png"
Content-Description: image010.png
Content-Disposition: inline; filename="image010.png"; size=1838;
 creation-date="Wed, 29 Apr 2020 02:21:28 GMT";
 modification-date="Wed, 29 Apr 2020 02:21:28 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAIoAAABACAYAAADF9O+2AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO
xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAauSURBVHja
7Z1LTBtnEMc59phjjzn2mGOPfUB4OGAgIU0ITShKKxRFVcCY9bKlNeUR1zxlaghgXkkToYZGcmkp
SoUoitpUFSpVK6uHSImiiKQlosYhFBSQvvq/sO16uzY29ppd71j6R8iPFeH77cw3882Ms5qamrK0
Fud0vlwtuCvL6r1fW7nBxexa38brNT4G5TuurRY0XA/KlcuNh6TXc+uGn+Iz5Y7e8Yu8q9jlcr2U
jt+ZFCnNLvx+Y1teBe/pK7D77ufYRv4udN5aK+2cZyd67rLTV35lZ4YCcelU38/iZ4rds8zSOLH6
Ro1vG+BUcR0OTmg5QotoQFBgOc7wvYPhxdyyCBNBq+tbdrL3p7ihiFcAp6hlejuPu7qaY/OFqoQu
O1kaA4AiAXLUPhqyXr69VT74W8rhiGpx+n9hRR9/uR52UX8RMDoF5SABiQZMts33rLKhx+V0Og/R
AusAlGre/a4eAFEK+x9r6/RGnn1kuaax7TVa5AMCBXdqGdc/U+j8YlVPgKhZGERQ5xo8HbTQaQbF
JrS8ml8/slTaPvdCr4AoVdz61Vqhfeh3uEla8DSAgjsTOQ+Eq0aBRFKZ50eWZx9dudjoKqJF1xCU
Cv7TvuLmqVWjAaLcuxz74MafBItGoFQKnlajQyIJeypLw3Xa5KYalPNC14XCjyZXMgESuWWx8Fef
UFY3RaDARFuEGxkFiTwisnBjS4LTeZggSAIUmGaYaD2Hv0nDEt6UW7jRhxQN7RMUpMCRDsddl6mQ
SCrtvMNKuCtzBMI+QHmb7/VY277ZyHRIJOHwEifdBEMCoNicLa/kc+MrmexylHrLu8AK6kce0mFi
AqCgzgNH+GaBRJ69pVR/nKBcENxnCxs/D5oNEim/kmsfC1IUFAco+XW+JZhhM4IiWhX3LEO5JUER
AxTxsM9xLSOyr8kk4lDLQnuVGKCc43u6rW0zW2YGhSKgOEBB3akZ8iZ751XmGToFCAwVUJCFRYGP
2SGRNrXZtuENcj8qoJzk+m+WtH9nekgkoa0EPUgEhwIU9N1o0VJhVKHFBP1IBIcCFHTtJdKQtW9N
LrPHwWXGq702G2J4PF68t/d18N4Hj+j8J92goPNO+zv1HvMHmQoM0vMh5pV+jgaT7BrR35O8UDaJ
GluCQwEK+nzTYk3CMPgXNyMXefd5bxzX8D5gbGE2wHjlNTSoVUEUSHAo9yhpiHjExYW7EMHYZP5J
OSg7ACR0LQ1BgdAcbzYQTnsDh98bWDgUFRTs8tPhdnZg2PlZ7n5gKRJxJ+kA5Wjd2JrZzn3C/+/K
8sFAsGIo4FQDJquwyb+eDrfjlW9GlQu9a1ni2dASKNqBIvsbPAnrUgQoSFtr7nZUHqruRox+ZK7p
gEDBBt9sSTcFKKIiQMHoCO1AecQWWJSHaoi78/5YexatQREPB2t9GyaBI+bfIgKUN2uHNzUDRbQQ
KlHN7vP+xVCk9dCBRUHyEUlIs21m97QoGHqjVemjuFGNZTkW/9ubxHRJ8k2v/KEBMMe7v0fC7a7p
QfEFRiNAMXvBEhUwKUAJA4JQ+X9RD9LVSFsTJLuHgs1Tm1W8+5Lp8igDgSNqgPwLSrXgOnXsw5vP
CJIdYTAhNYWpgIIwEDUYZmrRiCZ0IKATgcBQAQX/UE0K1aLEBQrqRLVOvOldsKg5tuHnNCQwBihm
6jemOpQkQIHQKYeOObOCglN0GrATByiwKvn24T+MOKMtaWvSPvcCky4JiDhAMeteBWc7GARIIXEC
oEBmS8Bh2jVGoxMMCYKCOwsTqc2QVzHrAWBKQIGqhA7e2uwPZTIkOxMiP3uKvmsCYZ+giFEQ7+ku
aZ3KyP0KIKGZsykCRczY8gP+0k9m1zMNFIxExWhUAiBFoECljoH54x3zhpl9v5fgUuFaafFTDAry
K6WOoR9OdN0xPCxwpXCptPAagALh/AOnqtbmqedGjIbEadXCBEGiNSiS3uG7mhApGKkiDqUDSKjR
gJw0ggIhnLTUD98vcc/q3hXh7AqWkLKuBwCK5IpOOry38PWyehyZASuCmXQ0EvSAQZGEL6xGZlMv
wODoAYDAilAiTUeg6AUYAIJGNpxTESA6BkUJDO7qosu3mZbQoP8GFfMY2wFA6Pt3DASKfMN71tHj
BjToRESVP2pyk6mgQ6SFsVkIczGWAk1aaKvA/H5aSIOCotz4oiUEBdwYUINFhptARRlU1DK9XdQ2
w+TChAXpdUwWwGfQqIbZahTmZigoaoKbQNkhVMV1OCodnU65zvOuaul1mk9vYlBIxtM/WRyVHTC6
Ub8AAAAASUVORK5CYII=

--_012_C01B0098369B2D4391851938DA6700B7179F9EABdggeml512mbschi_
Content-Type: image/png; name="image011.png"
Content-Description: image011.png
Content-Disposition: inline; filename="image011.png"; size=3071;
 creation-date="Wed, 29 Apr 2020 02:21:28 GMT";
 modification-date="Wed, 29 Apr 2020 02:21:28 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAANcAAABFCAYAAADZ03P9AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO
xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAt/SURBVHja
7V1dcBPXFfZjH/uYxzzmMY95TFsI/pfsJBSHP9dDGSbDdAAj765VJ3ItbEU1xmOPANmSfyi0TEM8
o9AAMeMhDNOmaUidFFR3hikkkyGkJkQ2f2YwM9v9VlqzklerlbR3tas9nvlm7NWPpbv3u+ec75x7
bk1vb28Na3CBwAt7/KEtm7lj73u4sfmNnbHln+2PiUAd/4el+u5TKTVquRNLyuObDsbv4jVv8aPT
e4WQNxAI/NSKz0wglAtmb7y/p//VHfxwuN4Xu7mxc+Jx4zvv32/5/SfiG8OfiluOfSluHU8awpaj
/5Rf4w3PiQ09p5d+cSD+pMk3vtDBDfKd/uArdBMJriAXrEp793Bow4HYCixQ88CsuHn0H4aJZBRv
jvxdbA6eewarByvY4R/yhUKhn9ANJVQdueD2bRVGxzZ2xh96Dp1baTv+L9MJldeySVaw+XcfPtrQ
GbsPYpPbSKgKcimkes03uewZmF19a+yaZaTKBQgNYm/yTaSIZARHk2uPEP61HUilR7Lf9PTX0k2u
XiDmRmyvRmcg+JJjyQWLsJmPzDQFPliyE6m0SNbgP53aLoyOUDzmXKSV5nD7m12Rj6AaI57XU5o3
cdPL+ZRmq+dB0StFQ1f8Zkt47qldSZULT//5FU9X7JqdVjSCPuBxbBNGjipKc1Ng5kHr4cuyalxM
PJ+rNP98f+wZyAalmfMHX7YNuTr8g0JD98m7v4xcdQSpctXFem7q+7f94R00ee1roRC/SwRYhcfh
CV1kojSDbFCakUtlrTQbetJOYeSIpy+xbGc30Iib2NTz59Qu/9DbNJntA38g8CLctkrE74rSLLmP
P7IQwQo+AZOx6d0z95xKKjVw4xp/+8f/7e0JNdPErrAYIbnpqNh57eDUA7htlVy4QTJFBIP1hBVl
Tq5qIpaaYHBvqbqjcviVMNRbx03fQ8WO3bwbWM9a3+Q9M5TmvA9gdccq72RXUFdJFE7csSKoJWTH
VS3c8U89fWcfOkFp3spH4uXEY5oXkS9o6D61WI3EUitJjfz01/D5aeJbowDWc5N3Xj/yV8fMEW//
x48bu2I3SlWa110AUxHgFVNc61TgRmMlpcnPFsg1whI4cU5BsYQLW4rSrDkQyA1VO7EUQEEkiZ4d
NgvRhNPnEzy4UpTmdQoOWFrN7qCWUgRLTVUc5gMpnJZDZ1NuVZqz/kD2Gkk2txBrrYpjYHYVEiwR
wjy0+0cOefvOLlWf0nxqEZpEUeSCawTT5zZiKYNWx5/4gdRDc1CNKZxSlOa1X+oOxm47sbTJLKB2
DcWhRI7y4IZFGgRDOV0hFTEda/mDr6DC2K3EUqzXhs74CsVe5eWxILe7QWlG+IQwqiC5dgrDRzz9
F1bdTC5ZOQzMPMD2BiJKicogH5lx0o6J8ufLB0vY16hLLlQHu2G1obwXO7jR+wFnan0Ti/kKfuVq
DGwyczuxFGD/kFmFm24BXGlUMrDYImJ3eN+7+LSNj5zUJBcqk+1WQFlRU9+beLRLCO0h0hgHCnFR
L+jWOYO9YVrqYQ12e7pxxckHLDRYcIg0xuH2sCKf0lyDngSWtEI7syh+l1oUBa3H5pZF/Hw3f0P/
PYw+j7EKRHgOFOTKFeQuV5rRVjA39qpBXwH2H+CGmEiJGsRQri+LEeV3TQJ+K14Vc3/wGvM/K3J9
yPkRcQwqhBRW5FWaa9AtxxKrJZEhMf8kmzyZ65GS3k8Ur86xWYXQx4GIY0zIQG7QTbWoxXg8NVYo
hQJIdevbDCmeiIkzZZKEIbkA9KOnpqKFgcM1cAYAxeraSnMNzJkVLmGaCOnf1a5h5FbGy8sXj+WN
vdi4hXrqDyEbLdzxS62HrzgqXpcXeVauYd/ZJx1CeN9zcvUmHlnhEkbUXzJ3oDKWyJhYkY6/WIoa
nr4PH249/uUXbWP/vgRI145tG08GFGyPJ2u3j197FWiLJl3bi8OaelST4nWZVErszmZhlhvt8KPT
a+RirfTILqHGj6ZLJ68uKrcx30AzXH1ky8WfWmmPfNKqEEi6tk9NLoV0GeLNZ70+dv2W+vG28etH
soiZec8MMW1nHduiX70kf24Dnw2xKfN4i0m8rjfHSkduhU8NXCB2g6Ol8ok65jn9fO1YyhpiAWiF
XPLkjCRfVBOoADEXSifmV0w6CGc+s/x58P93R6/mjT0RmzozXmdDLuSLkTdeIxfTAcoXG2WuJ+aX
s7+kjuWSY7Ni4rISgcY16DFeKauRQ0xeIZb0+4AuMaW/cx4fUL2WN0rMtuiCN1s9TcKz2af1XLYL
M4N4PUNIViEF8sXIG6vzXMxMu/zl9SzU/PNYS9ddPLP+eUWLIGVIqk6AHjFhgbKIJ1nIfMTUIK2C
ebyv+n8yTx6bFa/nzh+GizTyxsq2JddvksyFGzdNIr5aI2UsOakzPgtqq8daaTY3XrdGEEMHYaVd
n3VyqkPg6T+/ulMY6nOrAphxI7PGZFvs+p9yrRZ7cpkZrxv1qEwmFyUCs4GKFTcfN6SyXHcQt+2O
JvNuv2FagGBWvC65hIk56+IutRhGJSw6ao8ryTWe3CehfXf0vwXbHWCVZnUvTIvXtSwgI6uVK4ZR
8aXaJQx+tNIhDPVQ9YUxWFP07RzgHLgm3/hCFrlo20AatAuZ9nGZKYatVTe7pT98tUnwlQRttM3x
fEIXRRw3m0UuYGf3yKD30F8euHVgcGYuDqUm0hQRnwmjY3K3YiKW5hzK2ptT54t/j6DMfeb8CmrC
LhFhigP1u3wOuTqjM3Zf3fcya7DcGHtBJd3km0rROV12roy3P3Ir4teRy9I9OnYZFMkVhktMRCkN
SLgj8e52ciHnl3tAw7rBglqGk9XdkPfCilvfNfENtbAuHbD4LPNdTkC+Ym/NAevwDwqevsRyNQ9I
scfBEPIDuR3keFyrEvZfWEVLeEPkSpv76jm4TAt0oiQJG6ZYLZ2W1rqDtoU/erolNPu42gak+d2Z
H3f5Bw8QMcyD2w5hWFukdQ5jKDxoQjTR+t7co2oZDFhjWGUihLlw0/FBCgoVHhgaOC839tnrg5cd
vyp5+z9+DGtMZGADrOBYyd2SwsH54Xo7KAwNGtS0Vj56GSKHE1VEJPgQYxGxSNwwT8Q4v7JdGB3R
G4uiBg4qIs4OdlLSEDe6rmtqkcQL66T5Rn7662qu9Hlj6MrTVn78b4VSOMX71v7gy8gNOSF4xeqC
lZSqL6wnWAM3dbsa4y/EWV5u/HMjudGSBg9vDHUIhYp2rIrGACBjXshsExgKHNIijFPvLTlBxyJg
rjdx8f8YbXVe1gCiAhjbDuxCMoVUUHAoOWyP/FdD98m71VDtAze3rmvidjFnCJgyiGsk859OYYJb
/cVRC4kkJpHKftjbE2oGwZxc3ItOug3c5DfFhhemDiSq6jHB0Syyuf+CyFI1whduDp57hoYyKDbG
KkmT2cYWrCt+02lJZlhcHEeLFtWl7FBn5m+384cDEBPQ0RfdpVCSX46ChJUPOz3hgqJ3A75wBzfI
u7lTk5MAdwpxOlIiTojDMFdhcXHec6nf2ZJBRfs27HVB5TBaT8HaIDYCYH1g5dTAUSzK46i4xmuw
bwhbqOGCUhW7c4GUCFIjlQgfDFfxSBYW8VW53lBl3ATJ2iA2AmB9YOXUwBlHyuMko1enVI/wAYun
nUiGDmhY+GFhzTj8kG42oWLA4gmSQYyq1AZdxFUIWeAhocWgmWEG3WSCLQQPiFIQwmA9rKjuQOoI
+7DkjcFSyMLCQ6KbS7ANIITBeiA2h3uG2BuqsBl5MlSLoK8g+tujPyVSR9jgyLJPJd1Ugj2tmeSe
IfaGKoxjrpBDVQQvuHGI1QC1lYM1Uq43D8ymBbLguWewiGhgioade/zhdqsav9KNJDgCyKEqghfc
OMRqgKJAA7BGyvUd/HBYFse4Qb5Sh8fTjSMQGOH/gyyQiJxRDxgAAAAASUVORK5CYII=

--_012_C01B0098369B2D4391851938DA6700B7179F9EABdggeml512mbschi_--


From nobody Wed Apr 29 05:26:37 2020
Return-Path: 
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 4A9063A0E15 for ; Wed, 29 Apr 2020 05:26:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, 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 (1024-bit key) header.d=nlnetlabs.nl
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 2h_VfLvuMlkn for ; Wed, 29 Apr 2020 05:26:32 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E83C3A0E19 for ; Wed, 29 Apr 2020 05:26:32 -0700 (PDT)
Received: from [IPv6:2001:981:4b52:1:512c:a84e:aa06:4f21] (unknown [IPv6:2001:981:4b52:1:512c:a84e:aa06:4f21]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id C0E0821055; Wed, 29 Apr 2020 14:26:29 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl
Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1588163189; bh=87qfwGyg/f//qP3zWyVzYPIzHwK6Dxg0P40veMny7+8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=zGB03VXkJF4hj8+IqcqNy+DKD+CKpOmrKutzqtEnXdf0yAowLLtLCP62R0Q2Ykw6n 1BPbEH+tNJDNWy2FpuPxBrM3f90yUB6Hfz2J+IwFrrWthJRW38Jv8CGhD41Wk58LPd 9TkK5851/YJpXhEHzh8iZ49jHhMgILLpIK6OKImk=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Tim Bruijnzeels 
In-Reply-To: 
Date: Wed, 29 Apr 2020 14:26:29 +0200
Cc: Jay Borkenhagen , sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <12F90135-5597-490B-947F-F588C2ED3B48@nlnetlabs.nl>
References: <87pnbrspdr.wl-morrowc@ops-netman.net> <24232.24434.41224.396200@oz.mt.att.com> 
To: Job Snijders 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [Sidrops] ASPA duplicates
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Apr 2020 12:26:35 -0000

Hi,

> On 28 Apr 2020, at 19:03, Job Snijders  wrote:
>=20
> On Tue, Apr 28, 2020, at 18:53, Jay Borkenhagen wrote:
>> The current ASPA Verification draft:
>>=20
>> https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-04
>>=20
>> .... says in Section 3 "For a selected Customer AS MAY exist only
>> single ASPA object."
>>=20
>> I concur that an ASPA object should list every authorized upstream =
ASN
>> to avoid possible race conditions, and as such it makes sense for =
only
>> a single ASPA object to exist at any point in time.
>>=20
>> But how is that uniqueness to be ensured?  What should RPs do if
>> multiple validated ASPA objects are ever found to exist?
>=20
> Good question. What should it do?

In my mind it's good to that CAs can create a single ASPA object for a =
customer ASN they hold for all their provider(*) ASNs.

But, I think it may be better to cover that CAs SHOULD (or even MUST if =
you will) combine all provider ASNs on a single ASPA objects as a =
separate BCP, and leave a bit more flexibility in the profile and =
validation drafts. This makes it easier to change things, should we find =
that we need to change our minds on what is best.

I don't think that RPs have to check whether the CA did indeed use a =
single ASPA object for a customer ASN. I think it should just validate =
all ASPA objects it finds, and build a list Verified Asn Relations . Furthermore, I think that  8210bis =
should then specify that the RP (cache) MUST exclude duplicates when =
sending these relations to routers.

And veering a bit further into that document, I am not sure why those =
updates should be sent as a single PDU containing all current provider =
ASNs. I think it make sense to do the same as with ROAs where =
'announcement' (add) or 'withdraw' VRPs (excluding duplicates) are sent =
over RTR. I read the comment about race conditions, but I don't see how =
this is an issue when such PDUs are sent as a typical exchange (section =
8.2) between a Cache Response and End of Data PDUs.

*) relations as defined in draft, not necessarily the business relation.

> I expect such duplicates *will* exist if ASPA were to be deployed for =
real: in cases where an ASN is transferred from one RIR to another RIR =
and one wishes to make before break.

Well in that case one would expect objects for the same customer ASN in =
different parts of the RPKI tree.

But a similar issue could also come up if a parent issues the same ASN =
to multiple children. Which could be a working model if a large =
operation operates the same ASN globally, but has different teams =
managing it. In that case an organisation could chooses to run a =
delegated CA and issue certificates to child CAs in use by those teams. =
(I am not sure how likely this is, you have much more operational =
insight than I do, but it's definitely possible under the standards).

In those cases any of those CAs can issue valid ASPA objects, and they =
should be combined as above.

Furthermore, the security considerations (section 8) of the AS path =
verification draft can use some additional words to warn that this also =
means that any ASPA issuer can potentially invalidate other users of the =
same ASN if they exist.

Maybe the idea of multiple parties operating the same ASN is ludicrous, =
but then I think it would be good to have words that discourage =
delegating the same ASN to multiple CAs, and similarly, discourage =
issuing ASPA for customer ASNs that are also delegated.

Note that this issue is somewhat similar to ROAs for prefixes which are =
also (partially) delegated, or received by multiple organisations.




>=20
> Kind regards,
>=20
> Job
>=20
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops


From nobody Wed Apr 29 06:18:58 2020
Return-Path: 
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 EAC773A0F08; Wed, 29 Apr 2020 06:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, 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 (1024-bit key) header.d=nlnetlabs.nl
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 bERL5JuBg6Rx; Wed, 29 Apr 2020 06:18:55 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6499C3A0F06; Wed, 29 Apr 2020 06:18:31 -0700 (PDT)
Received: from [IPv6:2001:981:4b52:1:512c:a84e:aa06:4f21] (unknown [IPv6:2001:981:4b52:1:512c:a84e:aa06:4f21]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 7E36E21149; Wed, 29 Apr 2020 15:18:29 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl
Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1588166309; bh=67TOTCglg3qqWmHg5co9zxnL+RMMiXEnvgoVOgdAfx0=; h=From:Date:Subject:Cc:To; b=OLdK8st8KiSJRZEsYHHA/5L5/e+Eij1w/ChsTYe6hwveRhQqIeGu/wEBSD4PcKWKo Jj/hEA4skdV489BL5OudbeMJ2tDj9vlixQnKSGzLyWsSAJUndPC8DzzR0JRhMRWhoN t6KnwFgClaxPhEzYj7Qqkjmn0I0TJqyA1u8ziIcA=
From: Tim Bruijnzeels 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Wed, 29 Apr 2020 15:18:29 +0200
Cc: SIDR Operations WG 
To: SIDROps Chairs 
Message-Id: <29748EA5-6016-4E6D-9261-A069F7431390@nlnetlabs.nl>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: [Sidrops] Adopt draft-sidrops-bruijnzeels-deprecate-rsync?
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Apr 2020 13:18:57 -0000

Dear co-chairs, WG,

As mentioned yesterday I would like ask the chairs to do a call for =
adoption on:
=
https://datatracker.ietf.org/doc/draft-sidrops-bruijnzeels-deprecate-rsync=
/

I am also more than happy to discuss the content, and adapt following =
discussion, but maybe this is better done if adopted :)

Thanks
Tim=