From nobody Sun Jan 3 18:58:56 2021 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 12C7E3A1581 for ; Sun, 3 Jan 2021 18:58:54 -0800 (PST) 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_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 TJdOYR_dYE2X for ; Sun, 3 Jan 2021 18:58:49 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C0D3A157D for ; Sun, 3 Jan 2021 18:58:48 -0800 (PST) Received: from smtp.freedom.nl (unknown [10.10.3.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id DA4CC609E7 for ; Mon, 4 Jan 2021 02:58:45 +0000 (UTC) Received: from smtp.freedom.nl (smtp.freedom.nl [116.202.65.211]) by soverin.net Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 3a368986; Mon, 4 Jan 2021 02:58:43 +0000 (UTC) Date: Mon, 4 Jan 2021 02:58:43 +0000 From: Job Snijders To: Tim Bruijnzeels Cc: SIDR Operations WG Message-ID: References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> <62CCDADA-E2B5-4354-82E5-995837633307@nlnetlabs.nl> <953B1447-1253-4EA2-A805-5DAB9CD394D6@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <953B1447-1253-4EA2-A805-5DAB9CD394D6@nlnetlabs.nl> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] 6486bis: referenced object validation 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, 04 Jan 2021 02:58:54 -0000 On Fri, Dec 04, 2020 at 04:58:02PM +0100, Tim Bruijnzeels wrote: > > The December 1st, 2020 case is definitely one I'd add to the testbed > > archive. > > It would be. I think this is an effort in itself. Do you have a > proposal in mind? At this URL http://rpkiviews.org/ i am trying to re-publish data I collected after having made some attempt with OpenBSD's 'rpki-client' to validate the RPKI data. one view: http://www.rpkiviews.org/adrian.sobornost.net/rpkidata/2020/12/01/ and a bit later I added a second instance with a different view: http://josephine.sobornost.net/josephine.sobornost.net/rpkidata/2021/01/01/ Kind regards, Job From nobody Mon Jan 4 09:11:10 2021 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 3D73D3A0E88 for ; Mon, 4 Jan 2021 09:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=1-4-5-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 KBrumMHwNGaC for ; Mon, 4 Jan 2021 09:11:07 -0800 (PST) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 72A6D3A0E7A for ; Mon, 4 Jan 2021 09:11:07 -0800 (PST) Received: by mail-ej1-x630.google.com with SMTP id q22so37810179eja.2 for ; Mon, 04 Jan 2021 09:11:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1-4-5-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ei3grCO8NCZmqwptGbm3tj8q++KjaICg9s5BPEZq/eU=; b=Kem2mJ+PItcW5r8TJ+4csolk047uiu7ZScfTlFJpCT9NZgj2duf6TQik9uGuP02tqr XFT1MzPGyr8RhB+DkuEIuwqURfdI+Tt1tmdu59XSr3u5kBqIsd722JHwdSffBHJkD5M1 5/6PovF9WSoz5fzKNPMLdvpTKLaKSAM0frJOcHC6TXBmcr1/EP5A2Q5mP45Ib/vxo6uE /WpYuxIeqm0BW8VIsannAZP1iO2gAjmGHQ6PgvuNTkA/Qr6MMB4ZLdsC0nF8rWaR+dWt 98l1M6CYq7/qallk8pVq2/O2m41pu8BXBdQUJyTYoRQW+3xRKrnOGj/KaBqoEiNpOarv NCDA== 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=Ei3grCO8NCZmqwptGbm3tj8q++KjaICg9s5BPEZq/eU=; b=h3DBIuWSLVDKCcZtCaH9NiihAwh7nZ4WwlGRvQ0yNRAbgMQNnuzeM7a5VpS9kpSHSC mN+wrctSIwnBGhmA0wI+bFjn9wT4WbhpmycNWoV26/S0udJSUCMZCj5/r0i9bCaWb0II 5JTHgdJe7jzip3UBj0IwXyqqDfMbTrv2DSrLYZwDa4siD/GvfqFgpCkRuzC/yerCEO9O Z2Qn252SBuYTObqVS3jj4oL/4/imeP5hPcVIwmjXCRs97nkURIuK3hqIaEwqgyVWF7GH Gr1Jq8gInfuhEQdXIw0wPf6X0avWIlPKPzpmr4GnFopa5ra656FeA48r7oxr0d6tDHig eZNA== X-Gm-Message-State: AOAM533vjnNW7dgs978o1uRINjMUcL934iaAwrjC06qgRabuD65rG+NP NK9P143PhvWXwVc29LvmXgGvjnR2cZCUJ3jtoo6nHw== X-Google-Smtp-Source: ABdhPJzRmE0zzmLTjdvIz0JhlIIQL4naQEAskBGJR3hQ/9rZDZZV5lycLKH4IEOXCKdoZl40dyF/2rtpNDPF2G5vh2s= X-Received: by 2002:a17:907:3fa3:: with SMTP id hr35mr67449043ejc.71.1609780265512; Mon, 04 Jan 2021 09:11:05 -0800 (PST) MIME-Version: 1.0 References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> <62CCDADA-E2B5-4354-82E5-995837633307@nlnetlabs.nl> <953B1447-1253-4EA2-A805-5DAB9CD394D6@nlnetlabs.nl> In-Reply-To: From: Tony Tauber Date: Mon, 4 Jan 2021 12:10:54 -0500 Message-ID: To: Job Snijders Cc: Tim Bruijnzeels , SIDR Operations WG Content-Type: multipart/alternative; boundary="000000000000e4878c05b8162c32" Archived-At: Subject: Re: [Sidrops] 6486bis: referenced object validation 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, 04 Jan 2021 17:11:09 -0000 --000000000000e4878c05b8162c32 Content-Type: text/plain; charset="UTF-8" On Sun, Jan 3, 2021 at 9:58 PM Job Snijders wrote: > On Fri, Dec 04, 2020 at 04:58:02PM +0100, Tim Bruijnzeels wrote: > > > The December 1st, 2020 case is definitely one I'd add to the testbed > > > archive. > > > > It would be. I think this is an effort in itself. Do you have a > > proposal in mind? > > At this URL http://rpkiviews.org/ i am trying to re-publish data I > collected after having made some attempt with OpenBSD's 'rpki-client' to > validate the RPKI data. > > one view: > > http://www.rpkiviews.org/adrian.sobornost.net/rpkidata/2020/12/01/ > > and a bit later I added a second instance with a different view: > > > http://josephine.sobornost.net/josephine.sobornost.net/rpkidata/2021/01/01/ > Nice work. When you say "different view", what does that mean? The structure of the data is different or the location in the internet where the collection was performed from ("vantage point"?) was different? (The latter perhaps being interesting should reachability of any TALs or Publication Points be different.) Tony --000000000000e4878c05b8162c32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jan 3, 2021 at 9:58 PM Job Snijde= rs <job@sobornost.net> wrote= :
On Fri, Dec 04, 2020 at 04:58:02PM +0100, Tim Bruijnzeels wrot= e:
> > The December 1st, 2020 case is definitely one I'd add to the = testbed
> > archive.
>
> It would be. I think this is an effort in itself. Do you have a
> proposal in mind?

At this URL http://rpkiviews.org/ i am trying to re-publish data I
collected after having made some attempt with OpenBSD's 'rpki-clien= t' to
validate the RPKI data.

one view:

=C2=A0 =C2=A0 http://www.rpkiviews= .org/adrian.sobornost.net/rpkidata/2020/12/01/

and a bit later I added a second instance with a different view:

=C2=A0 =C2=A0 http://jose= phine.sobornost.net/josephine.sobornost.net/rpkidata/2021/01/01/
=C2=A0

Nice work.
When you sa= y "different view", what does that mean?=C2=A0
The= structure of the data is different or the location in the internet where t= he collection was performed from ("vantage point"?) was different= ?
(The latter perhaps being interesting should reachability = of any TALs or Publication Points be different.)

Tony
=
--000000000000e4878c05b8162c32-- From nobody Mon Jan 4 11:40:20 2021 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 AF1D63A0FF3 for ; Mon, 4 Jan 2021 11:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.019 X-Spam-Level: X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 P53H9OLykHBi for ; Mon, 4 Jan 2021 11:40:14 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A63A63A0FF2 for ; Mon, 4 Jan 2021 11:40:14 -0800 (PST) Received: from smtp.freedom.nl (unknown [10.10.3.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 2CB5060100 for ; Mon, 4 Jan 2021 19:40:12 +0000 (UTC) Received: from smtp.freedom.nl (smtp.freedom.nl [116.202.65.211]) by soverin.net Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id b6d4f53f; Mon, 4 Jan 2021 19:40:10 +0000 (UTC) Date: Mon, 4 Jan 2021 19:40:09 +0000 From: Job Snijders To: sidrops@ietf.org Message-ID: References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> <62CCDADA-E2B5-4354-82E5-995837633307@nlnetlabs.nl> <953B1447-1253-4EA2-A805-5DAB9CD394D6@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [Sidrops] www.rpkiviews.org - geographically diverse vantage points 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, 04 Jan 2021 19:40:18 -0000 On Mon, Jan 04, 2021 at 12:10:54PM -0500, Tony Tauber wrote: > > At this URL http://rpkiviews.org/ i am trying to re-publish data I > > collected after having made some attempt with OpenBSD's 'rpki-client' to > > validate the RPKI data. > > > > one view: > > > > http://www.rpkiviews.org/adrian.sobornost.net/rpkidata/2020/12/01/ > > > > and a bit later I added a second instance with a different view: > > > > http://josephine.sobornost.net/josephine.sobornost.net/rpkidata/2021/01/01/ > > Nice work. > When you say "different view", what does that mean? > The structure of the data is different or the location in the internet > where the collection was performed from ("vantage point"?) was different? You are spot on, its just the location that is different. It'll be important to keep an eye on 'the RPKI' from multiple angles in the default-free zone. I imagine we have to include in the risk model how cache instances Relying Parties might see different objects coming out of publication servers depending on where they are connected to the Internet. Citing RFC 7115 Section 6: """ Like the DNS, the global RPKI presents only a loosely consistent view, depending on timing, updating, fetching, etc. Thus, one cache or router may have different data about a particular prefix than another cache or router. There is no 'fix' for this, it is the nature of distributed data with distributed caches. """ As we can't 'fix' it, at least we can monitor and record it (just like the weather! :-). Adrian.sobornost.net is generously hosted by NTT in their Dallas, TX, USA facility. Josephine.sobornost.net is generously hosted by XS4ALL in their Amsterdam, NL facility. I've updated the page to provide more detail. > (The latter perhaps being interesting should reachability of any TALs or > Publication Points be different.) yup! *** REQUEST TO THE GROUP *** If others are willing to set up similarly structured data collection efforts, I can help in two ways: 1) add links towards such initiatives from the www.rpkiviews.org page. 2) I myself can configure your data collection server through SSH, all that is required is a POSIX compliant system with... LOTS of disk space. It would be incredible valuable to have public viewpoints located in the African, Asian, and South American segments of the Internet. Kind regards, Job From nobody Tue Jan 5 00:54:04 2021 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 E422C3A0F74 for ; Tue, 5 Jan 2021 00:54:03 -0800 (PST) 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=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 u5VK5XKqECPt for ; Tue, 5 Jan 2021 00:54:01 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A560C3A0F4A for ; Tue, 5 Jan 2021 00:54:01 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 8243F6087E for ; Tue, 5 Jan 2021 08:53:59 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1609836839; bh=nHqq9R0kC9wzLkJ2AOHp4t4oSaqaWC7qkHto/deuJ6w=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=mUTmFzf8Qk5pkEvvOqY5EqYCVStkr15qb1/hos5ep5pbww4tW+PN8sbGL/nIJjkGS YyKwgPejsPbPN8PvMH+4LpoornU28WTDQEI/eCdwmUuFngn3ig9ShX33pH/6goqXO7 7I1qKocWLIKLQAy5zMVDlcN6QC0PhQSn/O1d4O53vyqQQvd2yoeXXNtvX05RtKtReE 1lza/V2OCMlpo9zq8s16PQ7F/r2lajZuRCwoApR8Gwywc3gY9pDa+Hqr7M2sjyOfVn fkOQlxyzFkwx64DWVDZiI1xNXIHHT0a9mcVuAovWOJKr89zXGUd3w95C9LDcm6HYr0 6woazYcF0Obkw== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Tim Bruijnzeels In-Reply-To: Date: Tue, 5 Jan 2021 09:53:57 +0100 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <90FE66C4-864C-4CED-87A0-FB9B0744297D@nlnetlabs.nl> References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> <62CCDADA-E2B5-4354-82E5-995837633307@nlnetlabs.nl> <953B1447-1253-4EA2-A805-5DAB9CD394D6@nlnetlabs.nl> To: Job Snijders Archived-At: Subject: Re: [Sidrops] www.rpkiviews.org - geographically diverse vantage points 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, 05 Jan 2021 08:54:04 -0000 Hi Job, all, > On 4 Jan 2021, at 20:40, Job Snijders wrote: >=20 > On Mon, Jan 04, 2021 at 12:10:54PM -0500, Tony Tauber wrote: >>> At this URL http://rpkiviews.org/ i am trying to re-publish data I >>> collected after having made some attempt with OpenBSD's = 'rpki-client' to >>> validate the RPKI data. >>>=20 >>> one view: >>>=20 >>> = http://www.rpkiviews.org/adrian.sobornost.net/rpkidata/2020/12/01/ >>>=20 >>> and a bit later I added a second instance with a different view: >>>=20 >>> = http://josephine.sobornost.net/josephine.sobornost.net/rpkidata/2021/01/01= / >>=20 >> Nice work. >> When you say "different view", what does that mean? >> The structure of the data is different or the location in the = internet >> where the collection was performed from ("vantage point"?) was = different? >=20 > You are spot on, its just the location that is different. It'll be > important to keep an eye on 'the RPKI' from multiple angles in the > default-free zone. >=20 > I imagine we have to include in the risk model how cache instances > Relying Parties might see different objects coming out of publication > servers depending on where they are connected to the Internet.=20 >=20 > Citing RFC 7115 Section 6: >=20 > """ > Like the DNS, the global RPKI presents only a loosely consistent > view, depending on timing, updating, fetching, etc. Thus, one = cache > or router may have different data about a particular prefix than > another cache or router. There is no 'fix' for this, it is the > nature of distributed data with distributed caches. > """ >=20 > As we can't 'fix' it, at least we can monitor and record it (just like > the weather! :-). >=20 > Adrian.sobornost.net is generously hosted by NTT in their Dallas, TX, > USA facility. Josephine.sobornost.net is generously hosted by XS4ALL = in > their Amsterdam, NL facility. I've updated the page to provide more > detail. >=20 >> (The latter perhaps being interesting should reachability of any TALs = or >> Publication Points be different.) >=20 > yup! >=20 > *** REQUEST TO THE GROUP *** >=20 > If others are willing to set up similarly structured data collection > efforts, I can help in two ways: >=20 > 1) add links towards such initiatives from the www.rpkiviews.org > page. > 2) I myself can configure your data collection server through SSH, > all that is required is a POSIX compliant system with... LOTS of > disk space. >=20 > It would be incredible valuable to have public viewpoints located in = the > African, Asian, and South American segments of the Internet.=20 I think geographically diverse vantage points are indeed valuable. However, a lot (most) publication points only have a single point of = presence, so I suspect that a significant part of the variation in data = seen is due to timing differences rather than geography / net topology. Not a criticism.. just saying it would be good to keep this in mind when = analysing differences. Tim >=20 > Kind regards, >=20 > Job >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Jan 5 03:52:34 2021 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 8B4703A089C for ; Tue, 5 Jan 2021 03:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 f7ZzXnc2GCfp for ; Tue, 5 Jan 2021 03:52:30 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B00CD3A08B0 for ; Tue, 5 Jan 2021 03:52:29 -0800 (PST) Received: from smtp.freedom.nl (unknown [10.10.3.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id B4DB960896 for ; Tue, 5 Jan 2021 11:52:27 +0000 (UTC) Received: from smtp.freedom.nl (smtp.freedom.nl [116.202.65.211]) by soverin.net Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 2f5f9311; Tue, 5 Jan 2021 11:52:25 +0000 (UTC) Date: Tue, 5 Jan 2021 11:52:25 +0000 From: Job Snijders To: Tim Bruijnzeels Cc: sidrops@ietf.org Message-ID: References: <62CCDADA-E2B5-4354-82E5-995837633307@nlnetlabs.nl> <953B1447-1253-4EA2-A805-5DAB9CD394D6@nlnetlabs.nl> <90FE66C4-864C-4CED-87A0-FB9B0744297D@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90FE66C4-864C-4CED-87A0-FB9B0744297D@nlnetlabs.nl> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] www.rpkiviews.org - geographically diverse vantage points 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, 05 Jan 2021 11:52:34 -0000 Hi Tim, On Tue, Jan 05, 2021 at 09:53:57AM +0100, Tim Bruijnzeels wrote: > I think geographically diverse vantage points are indeed valuable. > > However, a lot (most) publication points only have a single point of > presence, so I suspect that a significant part of the variation in > data seen is due to timing differences rather than geography / net > topology. Yes, timing also plays a big role in it all. > Not a criticism.. just saying it would be good to keep this in mind > when analysing differences. Yeah, analysing differences is a tedious chore, there is an infinite number of 'pathways' from signer to validator. Just looking at the 5 TAs I observed the following: ARIN: 3 x A & 3 x AAAA DNS records for rpki.arin.net and also rrdp.arin.net, making for (at least) 12 points of presence. LACNIC: similar to ARIN RIPE: 1 x A + 1 x AAAA record for rpki.ripe.net, RRDP is distributed through a CDN with a 100+ points of presence. APNIC: one IPv4 address and separately one IPv6 address AFRINIC: similar to APNIC. The above description of course is just the 'expected steady state', Separately, there might be situations in which a publication point's IP prefixes are hijacked in some way (be it via BGP or DNS trickery), temporarily creating a 'multiple POP' situation. In really complex cases one might even have to correlate routeviews with rpkiviews, all the while keeping in mind that the two planes can influence each other to some degree. Debugging the RPKI is hard work. Kind regards, Job From nobody Fri Jan 8 05:56:56 2021 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 0D61F3A0EF1 for ; Fri, 8 Jan 2021 05:56:55 -0800 (PST) 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, 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=ripe.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 fHJFtAbEwCW4 for ; Fri, 8 Jan 2021 05:56:53 -0800 (PST) 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 3F4253A0EEF for ; Fri, 8 Jan 2021 05:56:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Date:Message-Id:Subject:Mime-Version:Content-Type:From: CC; bh=/wguQE0b4GJuRgIIy0P3CtCWHoDqZHlhu+5iA+I6B44=; b=IUKP3M5uImdVePQtlfEYQT PYU7eltwyqTUEPuHMipvAjjTQv27iizPqAgJfg7glKoDKnLFB+vIfiTA4b33BTa/euwE6lXbBUVkf GDMgTkLsBdqW7S3X0+D7qBSZ34Sugfiyp/xdinilpvbwqGoscNDj8Rk1ZaGUwFJ5gBO+2RvgR9J6O cc4MYv/p6IXMZxA7QjSPZkFB7ZJXWGKNoZlyt4ddR+YxREAlrc5pvH+59pfxTvhNS8U/3MwaXEMKC mLhZCLXtgE8NnnIsQUXqiDBkbE8mYUMFSkqlT8O6TIDuKIJyHpJ6P0doPQ/77l4tLQiRmHuJuwpRd TiVjiGLvCPrg==; Received: from allealle.ripe.net ([193.0.23.12]:60030) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kxsG3-0009ci-0x for sidrops@ietf.org; Fri, 08 Jan 2021 14:56:51 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::4e8]) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kxsG2-0007yh-TE for sidrops@ietf.org; Fri, 08 Jan 2021 14:56:50 +0100 From: Nathalie Trenaman Content-Type: multipart/alternative; boundary="Apple-Mail=_B0150580-E0EF-4BB4-9FEE-760210CCC2CE" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <11932542-611A-4DDC-AD2D-3356E0CB44ED@ripe.net> Date: Fri, 8 Jan 2021 14:56:50 +0100 To: SIDR Operations WG X-Mailer: Apple Mail (2.3608.120.23.2.4) X-ACL-Warn: Delaying message X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92ad877974b5264846697abd34648897c52 Archived-At: Subject: [Sidrops] RPKI Outage Post-Mortem 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, 08 Jan 2021 13:56:55 -0000 --Apple-Mail=_B0150580-E0EF-4BB4-9FEE-760210CCC2CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Summary:=20 Yesterday, on 7 January 2021, an issue with our RPKI software caused an = inconsistent certificate to be published from 15:29-16:20 (UTC+1). This = may have resulted in outages. We strongly recommend network operators = update their Relying Party software to the latest version. Details:=20 At 15:06 (UTC+1) yesterday, we processed an outgoing transfer of IP = resources to another RIR service region. This caused our system to = update the corresponding RPKI certificates in our Certificate Authority = (CA).=20 Unfortunately, our RPKI software published the updated parent = certificate (production CA) ahead of its child certificate (member CA). = As a result, in the period immediately after the updated parent was = published, the child certificate (updated later) contained resources = that were no longer on the updated parent, and the child certificate = over-claimed. This was resolved once the child certificate was updated. Currently we have three separate processes: * One that updates the resources in the registry in RPKI (every 15min)=20= * One that updates the resources of the RIPE production CA (parent of = all member CA) from the registry (1h, takes ~5 min)=20 * One that updates the resources for member CAs from the registry (1h, = takes ~40 min) If there is an outgoing transfer and the member CA update runs before = the production CA update, the situation with over-claiming occurs. The = update of the member CA needs to happen at the same time (i.e. same RRDP = delta), or before the production CA resources are reduced. This does not = happen the other way around (and so is not an issue with incoming = resources).=20 Some older Relying Parties had applied a strict manifest handling = interpretation in their validator software. This meant that they were = configured to reject all certificates in the manifest if a single entry = was invalid. As a consequence, all RPKI certificates covering RIPE = resources were rejected by these validators during this period. Based on our access logs, we estimate that 327 instances of Relying = Party software were impacted. On Monday 11 January, we will implement a fix so that every time a RIPE = NCC certificate changes, we will look at all members to see if their = certificates are over-claiming and force an immediate re-issue if so. = This approach does not give us a 100% bullet-proof fix to the problem, = but it reduces the period of over-claiming from an hour to a couple of = minutes.=20 We will work on reducing this time to less than a minute, to further = reduce the potential for inconsistency. In the longer term, we will work = on implementing atomic publishing of data for this type of situation.=20 In the meantime, we strongly recommend that network operators update = their RPKI Relying Party software to the latest version:=20 * Routinator 0.8.2=20 * rpki-client 6.8p1=20 * FORT 1.4.2=20 * octorpki 1.2.2=20 * RIPE NCC 3.2-2020.12.10.13.57 Best regards, Nathalie Trenaman Routing Security Programme Manager RIPE NCC= --Apple-Mail=_B0150580-E0EF-4BB4-9FEE-760210CCC2CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Summary: 
Yesterday, on 7 January 2021, an issue with = our RPKI software caused an inconsistent certificate to be published = from 15:29-16:20 (UTC+1). This may have resulted in outages. We strongly = recommend network operators update their Relying Party software to the = latest version.

Details: 
At 15:06 (UTC+1) yesterday, we processed an = outgoing transfer of IP resources to another RIR service region. This = caused our system to update the corresponding RPKI certificates in our = Certificate Authority (CA). 

Unfortunately, our RPKI software published the updated = parent certificate (production CA) ahead of its child certificate = (member CA). As a result, in the period immediately after the updated = parent was published, the child certificate (updated later) contained = resources that were no longer on the updated parent, and the child = certificate over-claimed. This was resolved once the child certificate = was updated.

Currently we have three separate processes:
* One that = updates the resources in the registry in RPKI (every = 15min) 
* One that updates the resources of the RIPE = production CA (parent of all member CA) from the registry (1h, takes ~5 = min) 
* One that updates the resources for member CAs from = the registry (1h, takes ~40 min)

If there is an outgoing transfer and the member CA = update runs before the production CA update, the situation with = over-claiming occurs. The update of the member CA needs to happen at the = same time (i.e. same RRDP delta), or before the production CA resources = are reduced. This does not happen the other way around (and so is not an = issue with incoming resources). 

Some older Relying Parties had applied a strict = manifest handling interpretation in their validator software. This meant = that they were configured to reject all certificates in the manifest if = a single entry was invalid. As a consequence, all RPKI certificates = covering RIPE resources were rejected by these validators during this = period.

Based on our access logs, we estimate that 327 instances of = Relying Party software were impacted.

On Monday 11 January, we will implement a fix so that = every time a RIPE NCC certificate changes, we will look at all members = to see if their certificates are over-claiming and force an immediate = re-issue if so. This approach does not give us a 100% bullet-proof fix = to the problem, but it reduces the period of over-claiming from an hour = to a couple of minutes. 
We will work on reducing this time to less = than a minute, to further reduce the potential for inconsistency. In the = longer term, we will work on implementing atomic publishing of data for = this type of situation. 

In the meantime, we strongly recommend that = network operators update their RPKI Relying Party software to the latest = version: 
* Routinator 0.8.2 
* rpki-client 6.8p1 
* FORT = 1.4.2 
* octorpki 1.2.2 
* RIPE NCC 3.2-2020.12.10.13.57

Best = regards,

Nathalie Trenaman
Routing = Security Programme Manager
RIPE = NCC
= --Apple-Mail=_B0150580-E0EF-4BB4-9FEE-760210CCC2CE-- From nobody Fri Jan 8 07:33:16 2021 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 ACCAD3A105F for ; Fri, 8 Jan 2021 07:33:15 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 ZLW18SdjwM4H for ; Fri, 8 Jan 2021 07:33:13 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00DF93A105E for ; Fri, 8 Jan 2021 07:33:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5D0BA300B45 for ; Fri, 8 Jan 2021 10:33:10 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ebYXuUZ4Ff3A for ; Fri, 8 Jan 2021 10:33:07 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 5B77A300BC5; Fri, 8 Jan 2021 10:33:07 -0500 (EST) From: Russ Housley Message-Id: <61BBD255-5126-491F-AA25-3F793A00AB20@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C58BA7EA-3206-42EF-99E1-B64C0E3A8387" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Fri, 8 Jan 2021 10:33:08 -0500 In-Reply-To: <11932542-611A-4DDC-AD2D-3356E0CB44ED@ripe.net> Cc: SIDR Operations WG To: Nathalie Trenaman References: <11932542-611A-4DDC-AD2D-3356E0CB44ED@ripe.net> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Sidrops] RPKI Outage Post-Mortem 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, 08 Jan 2021 15:33:16 -0000 --Apple-Mail=_C58BA7EA-3206-42EF-99E1-B64C0E3A8387 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Nathalie: Thanks for the transparency and the clear description of the events. Russ > On Jan 8, 2021, at 8:56 AM, Nathalie Trenaman = wrote: >=20 > Summary:=20 > Yesterday, on 7 January 2021, an issue with our RPKI software caused = an inconsistent certificate to be published from 15:29-16:20 (UTC+1). = This may have resulted in outages. We strongly recommend network = operators update their Relying Party software to the latest version. >=20 > Details:=20 > At 15:06 (UTC+1) yesterday, we processed an outgoing transfer of IP = resources to another RIR service region. This caused our system to = update the corresponding RPKI certificates in our Certificate Authority = (CA).=20 >=20 > Unfortunately, our RPKI software published the updated parent = certificate (production CA) ahead of its child certificate (member CA). = As a result, in the period immediately after the updated parent was = published, the child certificate (updated later) contained resources = that were no longer on the updated parent, and the child certificate = over-claimed. This was resolved once the child certificate was updated. >=20 > Currently we have three separate processes: > * One that updates the resources in the registry in RPKI (every 15min)=20= > * One that updates the resources of the RIPE production CA (parent of = all member CA) from the registry (1h, takes ~5 min)=20 > * One that updates the resources for member CAs from the registry (1h, = takes ~40 min) >=20 > If there is an outgoing transfer and the member CA update runs before = the production CA update, the situation with over-claiming occurs. The = update of the member CA needs to happen at the same time (i.e. same RRDP = delta), or before the production CA resources are reduced. This does not = happen the other way around (and so is not an issue with incoming = resources).=20 >=20 > Some older Relying Parties had applied a strict manifest handling = interpretation in their validator software. This meant that they were = configured to reject all certificates in the manifest if a single entry = was invalid. As a consequence, all RPKI certificates covering RIPE = resources were rejected by these validators during this period. >=20 > Based on our access logs, we estimate that 327 instances of Relying = Party software were impacted. >=20 > On Monday 11 January, we will implement a fix so that every time a = RIPE NCC certificate changes, we will look at all members to see if = their certificates are over-claiming and force an immediate re-issue if = so. This approach does not give us a 100% bullet-proof fix to the = problem, but it reduces the period of over-claiming from an hour to a = couple of minutes.=20 > We will work on reducing this time to less than a minute, to further = reduce the potential for inconsistency. In the longer term, we will work = on implementing atomic publishing of data for this type of situation.=20 >=20 > In the meantime, we strongly recommend that network operators update = their RPKI Relying Party software to the latest version:=20 > * Routinator 0.8.2=20 > * rpki-client 6.8p1=20 > * FORT 1.4.2=20 > * octorpki 1.2.2=20 > * RIPE NCC 3.2-2020.12.10.13.57 >=20 > Best regards, >=20 > Nathalie Trenaman > Routing Security Programme Manager > RIPE NCC > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops --Apple-Mail=_C58BA7EA-3206-42EF-99E1-B64C0E3A8387 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Nathalie:

Thanks for the transparency and the clear description of the = events.

Russ


On Jan = 8, 2021, at 8:56 AM, Nathalie Trenaman <nathalie@ripe.net> = wrote:

Summary: 
Yesterday, on 7 January 2021, an issue with = our RPKI software caused an inconsistent certificate to be published = from 15:29-16:20 (UTC+1). This may have resulted in outages. We strongly = recommend network operators update their Relying Party software to the = latest version.

Details: 
At 15:06 (UTC+1) yesterday, we processed an = outgoing transfer of IP resources to another RIR service region. This = caused our system to update the corresponding RPKI certificates in our = Certificate Authority (CA). 

Unfortunately, our RPKI software published the updated = parent certificate (production CA) ahead of its child certificate = (member CA). As a result, in the period immediately after the updated = parent was published, the child certificate (updated later) contained = resources that were no longer on the updated parent, and the child = certificate over-claimed. This was resolved once the child certificate = was updated.

Currently we have three separate processes:
* One that = updates the resources in the registry in RPKI (every = 15min) 
* One that updates the resources of the RIPE = production CA (parent of all member CA) from the registry (1h, takes ~5 = min) 
* One that updates the resources for member CAs from = the registry (1h, takes ~40 min)

If there is an outgoing transfer and the member CA = update runs before the production CA update, the situation with = over-claiming occurs. The update of the member CA needs to happen at the = same time (i.e. same RRDP delta), or before the production CA resources = are reduced. This does not happen the other way around (and so is not an = issue with incoming resources). 

Some older Relying Parties had applied a strict = manifest handling interpretation in their validator software. This meant = that they were configured to reject all certificates in the manifest if = a single entry was invalid. As a consequence, all RPKI certificates = covering RIPE resources were rejected by these validators during this = period.

Based on our access logs, we estimate that 327 instances of = Relying Party software were impacted.

On Monday 11 January, we will implement a fix so that = every time a RIPE NCC certificate changes, we will look at all members = to see if their certificates are over-claiming and force an immediate = re-issue if so. This approach does not give us a 100% bullet-proof fix = to the problem, but it reduces the period of over-claiming from an hour = to a couple of minutes. 
We will work on reducing this time to less = than a minute, to further reduce the potential for inconsistency. In the = longer term, we will work on implementing atomic publishing of data for = this type of situation. 

In the meantime, we strongly recommend that = network operators update their RPKI Relying Party software to the latest = version: 
* Routinator 0.8.2 
* rpki-client 6.8p1 
* FORT = 1.4.2 
* octorpki 1.2.2 
* RIPE NCC 3.2-2020.12.10.13.57

Best = regards,

Nathalie Trenaman
Routing = Security Programme Manager
RIPE = NCC
_______________________________________________
Sidrops mailing list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

= --Apple-Mail=_C58BA7EA-3206-42EF-99E1-B64C0E3A8387-- From nobody Fri Jan 8 07:34:52 2021 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 DE4C33A105F for ; Fri, 8 Jan 2021 07:34:51 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=1-4-5-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 xrZwxoXjBm5O for ; Fri, 8 Jan 2021 07:34:50 -0800 (PST) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 79FF33A105E for ; Fri, 8 Jan 2021 07:34:50 -0800 (PST) Received: by mail-ej1-x635.google.com with SMTP id jx16so14986704ejb.10 for ; Fri, 08 Jan 2021 07:34:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1-4-5-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g72aljaKUUhzXszS6jodQEHkBJQQNmH0liN0hd7HKaQ=; b=WNWRevITCwkzHrbBZp+5L7fKlc+YR3o4hRpD9J0fwGh3qfEBaUJ7V9cp9P1I8Icky1 fTg6aJNP89SCypaMkTX3NoJKHPawe1ppELe18H6JvtcpvmfsxQs7G5mo8hd2x6oCdJ0D Ju27uBvQZb0cn+6XXwfk41hZnSN06YK8e1ZOgCpGv3+m0lnyE6+wpA6CXIh0bN7bt8ls 5SjvSwQlYlfVuUNAVzrpbr/+J0X7GdzUrm22MTgn9bahRkGtm5/Yy7hjh+9dTeD7jqoD t0T7Br6iJezaWiisx7bdnPeOHvIyAx6OZsWGLpoxjoTneXtGmheaq1vlRLo6JxUM+6Ln Ds7Q== 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=g72aljaKUUhzXszS6jodQEHkBJQQNmH0liN0hd7HKaQ=; b=CrAk++SQ4UOYtvh5sFmkQEPWda0tnpy5fZVTxvrj12LbIJ4aGDCqYBAvIrDRHDO7FD DVWjEDiNmCercNZGBX1PBzUjv37wrH8xTI53ET3FNNhqykfcEbchn7yoUjoUBdDTgwdU aEwemFZbDXfxtVYlsk73imQhOMzgA90qwILqq0Dyn/ZNw6zW4AOfNLEa9AKwuNx+wlYF TGrZWbdzVC/9I0ZR3CN/DgbpS1mxCNssAgo1WAGvqxjI+bYjJxZVCqQ2lYgQ7OZoCta8 KvEIpdskImXZgTT3N6F8Y51GSO5CELVVQ68cZc+zXw/hxc3NptxBRFukYgz8jUtM5N00 ka9A== X-Gm-Message-State: AOAM531TFaFKQHwQEbbZ8Y3bDUNv0IZOtQOcFLPCtrOb9vaXhQIFakVl 2FJ+jqtTVNArfYIvvo4sh6k3qGFCCe29UBAfQ4Dzzw== X-Google-Smtp-Source: ABdhPJzo0iXg0tz8+DdRkjwypt8r+YR/EgUkRtd5a7tDEQsVYvDWjWGV10K1vTzDayH6oAqHXNAPrJWcAKPf/IAKWbY= X-Received: by 2002:a17:906:2f8b:: with SMTP id w11mr2903614eji.246.1610120088789; Fri, 08 Jan 2021 07:34:48 -0800 (PST) MIME-Version: 1.0 References: <11932542-611A-4DDC-AD2D-3356E0CB44ED@ripe.net> In-Reply-To: <11932542-611A-4DDC-AD2D-3356E0CB44ED@ripe.net> From: Tony Tauber Date: Fri, 8 Jan 2021 10:34:37 -0500 Message-ID: To: Nathalie Trenaman Cc: SIDR Operations WG Content-Type: multipart/alternative; boundary="000000000000f03efc05b8654b6e" Archived-At: Subject: Re: [Sidrops] RPKI Outage Post-Mortem 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, 08 Jan 2021 15:34:52 -0000 --000000000000f03efc05b8654b6e Content-Type: text/plain; charset="UTF-8" On Fri, Jan 8, 2021 at 8:56 AM Nathalie Trenaman wrote: > Some older Relying Parties had applied a strict manifest handling > interpretation in their validator software. This meant that they were > configured to reject all certificates in the manifest if a single entry was > invalid. As a consequence, all RPKI certificates covering RIPE resources > were rejected by these validators during this period. > > Based on our access logs, we estimate that 327 instances of Relying Party > software were impacted. > Hi Nathalie, Thank you for the detailed write-up. I'm curious how you arrived at this estimate of "...327 instances impacted"? I'm guessing many more instances are out there querying RIPEs repository, even w/in the outage window. But maybe I'm mistaken? Tony --000000000000f03efc05b8654b6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jan 8, 2021 at 8:56 AM Nathalie Trenaman <nathalie@ripe.net> wrote:
<snip>
Some older Relying Parties had applied a strict manifest handling i= nterpretation in their validator software. This meant that they were config= ured to reject all certificates in the manifest if a single entry was inval= id. As a consequence, all RPKI certificates covering RIPE resources were re= jected by these validators during this period.

Based on our access logs, we estima= te that 327 instances of Relying Party software were impacted.

Hi Nathalie,

Thank you for the detailed write-up.

I'm curious how you arrived at this estimate of "...327 inst= ances impacted"?

I'm guessing man= y more instances are out there querying RIPEs repository, even w/in the out= age window.
But maybe I'm mistaken?

Tony
=C2=A0
--000000000000f03efc05b8654b6e-- From nobody Mon Jan 11 00:40:23 2021 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 999933A16FF for ; Mon, 11 Jan 2021 00:40:21 -0800 (PST) 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, 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=ripe.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 aVYlV2RPRWxO for ; Mon, 11 Jan 2021 00:40:20 -0800 (PST) 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 6DFD53A0EFA for ; Mon, 11 Jan 2021 00:40:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Cc:Date:Subject:Mime-Version:Content-Type:Message-Id: From; bh=aG440ghX1+yuaxJfHrJkNtQ7lMk5ot1JFOF6t3tv1vI=; b=oYvOo8zYl5wKL8o8M0mW 76D2PsR5UVmPjlLddPR6hYAnVtYBaa/VBX18Vu8spVD5o258RpHKDWvPdpGZ5Y0b48AMLkRwqoxLO Grfa7nRmPTtcngE7YNVtIm55jSQABZzxKh5tmjFHtQE7iNsMLgLh63j2OkQXP4Uali4br5Ds1XghB yZSqH6tNqKR8MYn2ovPl5sFGxKRGB0OFklwx4j3MxWPQpqwV36UcImgwzwfN+gsxjz/sYgI2BtIgj oND+gGVfOy2zc2ZvhwLFRyEL+0vrqowlfNunErDL3LnQwTps9QW2ixWYE3AIs2HaJOTmIZqSPMM6G VXoUP1I5O7dd0w==; Received: from allealle.ripe.net ([193.0.23.12]:51360) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kyskL-0008uj-Q2; Mon, 11 Jan 2021 09:40:17 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::50e]) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kyskL-0006G5-NA; Mon, 11 Jan 2021 09:40:17 +0100 From: Nathalie Trenaman Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6F359678-8D78-48F8-9A73-D3BA20678C62" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 11 Jan 2021 09:40:17 +0100 In-Reply-To: Cc: SIDR Operations WG To: Tony Tauber References: <11932542-611A-4DDC-AD2D-3356E0CB44ED@ripe.net> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-ACL-Warn: Delaying message X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a1e8ce56982d5343daab751b9025d1f78 Archived-At: Subject: Re: [Sidrops] RPKI Outage Post-Mortem 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, 11 Jan 2021 08:40:22 -0000 --Apple-Mail=_6F359678-8D78-48F8-9A73-D3BA20678C62 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Tony, > Op 8 jan. 2021, om 16:34 heeft Tony Tauber het = volgende geschreven: >=20 > On Fri, Jan 8, 2021 at 8:56 AM Nathalie Trenaman > wrote: > > Some older Relying Parties had applied a strict manifest handling = interpretation in their validator software. This meant that they were = configured to reject all certificates in the manifest if a single entry = was invalid. As a consequence, all RPKI certificates covering RIPE = resources were rejected by these validators during this period. >=20 > Based on our access logs, we estimate that 327 instances of Relying = Party software were impacted. >=20 > Hi Nathalie, >=20 > Thank you for the detailed write-up. >=20 > I'm curious how you arrived at this estimate of "...327 instances = impacted"? >=20 > I'm guessing many more instances are out there querying RIPEs = repository, even w/in the outage window. > But maybe I'm mistaken? >=20 > Tony We can see the user agent that connects to our repository. So we can see = the type of Relying Party software and the version number. Based on = this, plus the knowledge which versions were impacted we made this = estimation.=20 You are right that there are many more instances querying the repo, but = not all of them were impacted. Nathalie --Apple-Mail=_6F359678-8D78-48F8-9A73-D3BA20678C62 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Tony,

Op 8 jan. 2021, om 16:34 heeft Tony Tauber = <ttauber@1-4-5.net> het volgende geschreven:

On Fri, Jan 8, 2021 at 8:56 AM Nathalie Trenaman <nathalie@ripe.net> = wrote:
<snip>
Some = older Relying Parties had applied a strict manifest handling = interpretation in their validator software. This meant that they were = configured to reject all certificates in the manifest if a single entry = was invalid. As a consequence, all RPKI certificates covering RIPE = resources were rejected by these validators during this = period.

Based = on our access logs, we estimate that 327 instances of Relying Party = software were impacted.

Hi = Nathalie,

Thank = you for the detailed write-up.

I'm = curious how you arrived at this estimate of "...327 instances = impacted"?

I'm = guessing many more instances are out there querying RIPEs repository, = even w/in the outage window.
But = maybe I'm mistaken?

Tony

We can see the user agent that connects to our = repository. So we can see the type of Relying Party software and the = version number. Based on this, plus the knowledge which versions were = impacted we made this estimation. 
You are right that = there are many more instances querying the repo, but not all of them = were impacted.

Nathalie

= --Apple-Mail=_6F359678-8D78-48F8-9A73-D3BA20678C62-- From nobody Mon Jan 11 01:54:01 2021 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 63B743A044A for ; Mon, 11 Jan 2021 01:54:00 -0800 (PST) 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 62bMhBBD9bRU for ; Mon, 11 Jan 2021 01:53:57 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C58D3A0418 for ; Mon, 11 Jan 2021 01:53:56 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 4AB5160118; Mon, 11 Jan 2021 09:53:54 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1610358833; bh=JlpevwCjSTYgQQeUQ9y1IKfAHdvzrp1gFOtGSopsrKU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=bJmob/UXwPn/5DRibvM1zQ9j4uKa0wjFx+U/yc6kY1LPDmvQyPHG1RysFwr/LAhdy 9ADfVdFZPT3XGV/SYQNQQI/LnvpTmMhxjWnvoq2pxBwtlPJMJlKX5EibSy9ODpEI4n 30EHnGNoN1OwZ0lVGMujkna60YEz2vlzmC9PTHtGGg2pSSISACkmTNDTqybbIX9U6L rzfPbKfo2uC35Gcxhiuhq5iUCUfFJSgHhhKF1m+ttD6CE7lqS1Il6O8a5N4QhTJxqb RRJc9bbOsWuwJFjPBFp8g7I81X46garV9tnEAKSqYx+ep8yReEKnXPn1DtU5TUUqOJ /V3nmB/ozjiqw== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Tim Bruijnzeels In-Reply-To: <20201230144836.ytg4u2gobkv4uzqn@benm-laptop> Date: Mon, 11 Jan 2021 10:53:51 +0100 Cc: Job Snijders , Ben Maddison Content-Transfer-Encoding: quoted-printable Message-Id: <3BA339C3-EADC-449E-B5B2-7A4880E16EDA@nlnetlabs.nl> References: <20201229101412.GA56136@diehard.n-r-g.com> <49a8e314-7b3f-0e8d-6e20-7d055fb1a076@verizon.net> <20201229151639.GD56136@diehard.n-r-g.com> <20201230144836.ytg4u2gobkv4uzqn@benm-laptop> To: SIDR Operations WG Archived-At: Subject: Re: [Sidrops] feedback on draft-michaelson-rpki-rta 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, 11 Jan 2021 09:54:00 -0000 Dear all, Apologies for top-posting, but I wanted to send a readable response = highlighting the motivations for the RTA draft and the implementation = experience so-far by the co-authors of this draft. - Use-cases Please bear in mind that this document is specifically intended as a = generic profile, without constraining use cases. This is why it includes = the following flexibility: - multiple signatures - publish in the RPKI, or not - option to include the full validation path CAs and CRLS in the CMS (think TLS, where validation does not require the assembly of a local = cache of signed objects) The use case is intentionally _not_ limited to secure routing and = publishing in the RPKI may not be necessary in envisaged cases. - Publishing in the RPKI If the RTA is to be published in the RPKI then indeed the filename = extension for the detached signature '.rta' as suggest by Job makes = sense. However, in many cases there will be no need to publish these RTA = files in the global RPKI. The RTA is in essence a detached signature, = and as such they are meaningless if an RP does not know which file they = were supposed to sign. The file (or object) which has been signed with a = detached signature has no role in a CA=E2=80=99s publication point of = signed objects and SHOULD NOT (MUST NOT?) be published in a CA=E2=80=99s = publication point. - Need for multiple signatures One case here is that an organisation which operates under multiple = parents, e.g. two RIRs or an RIR and an NIR, will receive resources on = different CA certificates. Similarly organisations under a single RIR = may receive multiple certificates if they hold resources transferred = from another region, or if they hold so-called legacy resources where = another RIR is the majority holder in the IANA registry. Yet, these = organisations may wish to make statements about a set of resources that = crosses these boundaries.=20 There can also be cases where different organisations want to make a = joint statement about shared resources. We do not know what case that = might be, but as said above - in this phase the profile allows for = arbitrary use cases. - Multi-signing vs multiple single-signing It is true that requiring single signing for RTAs simplifies the = specification. And for some use cases where multiple signatures would be = required - multiple single signed RTAs would do fine. However, with multi-signing relying parties can be sure they have seen = the complete set of resources, and expected signatures based on a single = file. There is no guessing for the RP as to whether they have seen = everything relevant. Question is of course whether this justifies the additional complexity. - Multi-sign: Complexity for CA Having implemented this in Krill I believe that the complexity is not = that bad. Essentially this boils down to letting CAs generate keypairs = for the EE certificates and agree on a set of resources. Note that the = SET of SKIs of these EE certificates and the agreed resource set are = part of the signed content. Then one CA can be the first to add their EE = certificate containing its resources and sign with the associated = private key, and then the next CA (which may be another CA cert held by = the same organisation) can add their signature. For use cases where only a single signature is needed the CA can of = course just sign things without the need to synchronise with other = parties. - Multi-sign: Complexity for RPs (note, I will use an informal description here) For single signed the RP needs to verify that all resources on the RTA = are contained by the EE certificate, which is validly signed all the way = back up to a known TA. The RTA MAY include CAs and CRLs needed for this = verification. If they are, and if the CRLs are not stale, they will be = used for validation. If they are not present, stale or invalid, then the = RP can look at the public RPKI and find CA certificates and CRLs there. For multi signed the process is not changed much. But rather than doing = this once, the RP will need to do this N times *and* it will need to = verify that the union of resources in the EE certificates used for = signing include the described resources. If N =3D=3D 1 then this does not increase the complexity. If N > 1 then = there may be some fragility, because any of the paths can fail, but it = is reasonable to state that if multiple signatures are required then it = is a requirement that the RTA MUST be considered invalid if the = validation of any signature or EE certificate fails. Tim > On 30 Dec 2020, at 15:48, Ben Maddison = wrote: >=20 > On 12/29, Job Snijders wrote: >> On Tue, Dec 29, 2020 at 04:16:39PM +0100, Claudio Jeker wrote: >>> Up until now all objects only had a single EE cert and a single SID = and >>> all the linking done with the SKI was a 1-to-1 mapping resulting in = a >>> simple tree structure with the trust anchor as root. >>> This draft allows for multiple EE certs and so multiple paths up to = the >>> trust anchors. This makes handling RTA a lot more complex than any = other >>> object under RPKI. It also results in a lot more failure conditions = since >>> there are more EE certs involved in the validation process. >>=20 >> >>=20 >> It is possible the RTA authors forsee use cases where the 'multiple >> signatures' offers irreplaceable value, I'm not sure. >=20 > FWIW, all the use cases that I have in mind for RTA need only a single > signer. > I have been trying to think of some creative uses that can't be solved > by separate objects, and I can't think of any. >=20 > Thus, if this change can speed up implementation then I'm all for it. >=20 > Cheers, >=20 > Ben > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Mon Jan 11 05:39:47 2021 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 786943A0BFC for ; Mon, 11 Jan 2021 05:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.869 X-Spam-Level: X-Spam-Status: No, score=-9.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 0jWlQyV6U_Sz for ; Mon, 11 Jan 2021 05:39:43 -0800 (PST) Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) (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 957573A0B58 for ; Mon, 11 Jan 2021 05:39:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1610372384; x=1641908384; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=8gpEllEcFO9W+CTyZWNuIL4aKkQetGAJjQKPJ2Goyvw=; b=Z2RmYPEMInDYK+tCMm+PiPyL65QkZp7DtqZKMwhcQ6TiKMrPsP9khOBC mEu61YBuCKlDhIz2Gf6JAIZ+aQp6mbRVXxkHEFr6JCghTMI3rm0jP72uH ek2FKc+Odo3jfd9B3vCed2l7i3QeUghJJOc47hjl5eecIwSvmFJiqW7/7 s=; X-IronPort-AV: E=Sophos;i="5.79,338,1602547200"; d="scan'208";a="111242931" Thread-Topic: [Sidrops] feedback on draft-michaelson-rpki-rta Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1a-821c648d.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 11 Jan 2021 13:39:36 +0000 Received: from EX13D10EUA002.ant.amazon.com (iad12-ws-svc-p26-lb9-vlan3.iad.amazon.com [10.40.163.38]) by email-inbound-relay-1a-821c648d.us-east-1.amazon.com (Postfix) with ESMTPS id 3A1E8A1E56; Mon, 11 Jan 2021 13:39:34 +0000 (UTC) Received: from EX13D10EUA002.ant.amazon.com (10.43.165.64) by EX13D10EUA002.ant.amazon.com (10.43.165.64) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 11 Jan 2021 13:39:34 +0000 Received: from EX13D10EUA002.ant.amazon.com ([10.43.165.64]) by EX13D10EUA002.ant.amazon.com ([10.43.165.64]) with mapi id 15.00.1497.010; Mon, 11 Jan 2021 13:39:34 +0000 From: "Korsback, Fredrik" To: Tim Bruijnzeels , SIDR Operations WG Thread-Index: AQHW26+zCu0LU4poFE22Cf0wLyGGd6oN31UAgAAgawCAAA18gIAAJpqAgAALToCAAX8wAIASiaCAgABP04A= Date: Mon, 11 Jan 2021 13:39:33 +0000 Message-ID: <8D48337E-A7A0-4C81-973D-0160BE5C6A2B@amazon.com> References: <20201229101412.GA56136@diehard.n-r-g.com> <49a8e314-7b3f-0e8d-6e20-7d055fb1a076@verizon.net> <20201229151639.GD56136@diehard.n-r-g.com> <20201230144836.ytg4u2gobkv4uzqn@benm-laptop> <3BA339C3-EADC-449E-B5B2-7A4880E16EDA@nlnetlabs.nl> In-Reply-To: <3BA339C3-EADC-449E-B5B2-7A4880E16EDA@nlnetlabs.nl> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.164.195] Content-Type: text/plain; charset="utf-8" Content-ID: <9E39FAE64AA6A146921E37C939A83EEF@amazon.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Sidrops] feedback on draft-michaelson-rpki-rta 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, 11 Jan 2021 13:39:46 -0000 SGkuDQoNClNvIG9uZSB0aGluZyBJJ20gZmFpbGluZyB0byBzZWUgaXMgdGhlIG1vdGl2YXRpb24g d2h5IHdlIHN0ZXAgYXdheSBmcm9tIHRoZSBmYWlybHkgc2ltcGxlICJzdGF5IHdpdGhpbiBhIHNp bmdsZSBUQS1jb25lIiBtb2RlbCB3ZSBoYXZlIGluICJyZWd1bGFyIiBSUEtJLiBFdmVuIGlmIGlt cGxlbWVudGluZyBhIE11bHRpLXNpZ25hdG9yeSBzdXBwb3J0IHNlZW1zIHNpbXBsZSBlbm91Z2gg Zm9yIHlvdXIgaW1wbGVtZW50YXRpb25zLCB3ZSBkbyBub3Qga25vdyB0aGUgZnVsbCBleHRlbnQg b2Ygd2hpY2ggc29mdHdhcmUgaXMgb3V0IGluIHRoZSB3aWxkIHRoYXQgbWF5IG9yIG1heSBub3Qg bmVlZCBmdWxsIHJlZmFjdG9ycyB0byBoYW5kbGUgdGhpcy4gDQoNCllvdSBicmluZyB1cCAiSG93 ZXZlciwgd2l0aCBtdWx0aS1zaWduaW5nIHJlbHlpbmcgcGFydGllcyBjYW4gYmUgc3VyZSB0aGV5 IGhhdmUgc2VlbiB0aGUgY29tcGxldGUgc2V0IG9mIHJlc291cmNlcywgYW5kIGV4cGVjdGVkIHNp Z25hdHVyZXMgYmFzZWQgb24gYSBzaW5nbGUgZmlsZS4gVGhlcmUgaXMgbm8gZ3Vlc3NpbmcgZm9y IHRoZSBSUCBhcyB0byB3aGV0aGVyIHRoZXkgaGF2ZSBzZWVuIGV2ZXJ5dGhpbmcgcmVsZXZhbnQu IiBXb3VsZG7igJl0IHRoaXMgYWxzbyBnbyB0aGUgb3Bwb3NpdGUgd2F5IGFzIHdlbGw/IElmIGEg VEEgZ29lcyBkb3duIGFuZC9vciBpcyBub3QgaW5jbHVkZWQgaW4geW91ciBzZXQgb2YgVEFzLCB0 aGUgbXVsdGktc2lnbmVkIG9iamVjdCBnb2VzIG91dD8gSW5jcmVhc2luZyB0aGUgYmxhc3QtcmFk aXVzLiBXaXRoIE11bHRpcGxlIHNpbmdsZS1zaWduaW5nIHRoaXMgYmxhc3QgcmFkaXVzIHNob3Vs ZCBsZXNzZW4uIA0KDQpPdXIgdXNlY2FzZSBpcyBmYWlybHkgb2J2aW91cyBvbiB3aGF0IHdlIHdv dWxkIGxpa2UgdG8gdXNlIFJUQSBmb3IgKGh0dHBzOi8vZG9jcy5hd3MuYW1hem9uLmNvbS9BV1NF QzIvbGF0ZXN0L1VzZXJHdWlkZS9lYzItYnlvaXAuaHRtbCNieW9pcC1jZXJ0aWZpY2F0ZSkgc2lu Y2Ugd2UgYWxyZWFkeSBoYXZlIGEgcG9vci1tYW5zLXZlcnNpb24gb2YgaXQgaW1wbGVtZW50ZWQg YW5kIHVzZWQgdG9kYXkuIEdldHRpbmcgc2ltcGxlIFJUQSBvYmplY3RzIHdvdWxkIG1ha2Ugb3Vy IEJZT0lQLXByb2Nlc3MgYSBsb3Qgc2ltcGxlciwgbWFrZSBpdCBnbyBmYXN0ZXIgYW5kIHJlZHVj ZSB0aGUgYW1vdW50IG9mIGh1bWFucyBpbnZvbHZlZC4gSSBjYW4ndCBzZWUgYW55IG91dGNvbWUg d2hlcmUgbXVsdGktc2lnbmluZyBtYWtlcyBzZW5zZSBvdmVyIG11bHRpcGxlIHNpbmdsZS1zaWdu aW5nIGFuZCBrZWVwaW5nIHJlY2VudCBvdXRhZ2VzLCBzbG93IHNvZnR3YXJlLXVwZGF0ZXMsIGFu ZCB0aGUgZmFpcmx5IHNsb3cgYWRvcHRpb24gb2YgUlBLSSBpbiBtaW5kIGl0IHNlZW1zIHRoYXQg ImtlZXAgaXQgc2ltcGxlIiBpcyBnb2luZyB0byBoZWxwIHdpdGggdGhlc2UgdGhpbmdzLiBBdCBs ZWFzdCBtb3JlIHRoYW4gd2hhdCB0aGlzIG11bHRpLXNpZ25pbmcgcGFyYWRpZ20gY2FuIGdpdmUg dXMuIA0KDQpIYXBweSB0byBoZWFyIG1vcmUgY29tbWVudHMgb3Igc29tZSB0cmliYWwga25vd2xl ZGdlIEkganVzdCBkb27igJl0IHVuZGVyc3RhbmQgaW4gdGhpcyBkZXNpZ24gY2hvaWNlIHRob3Vn aC4gDQoNCi0tDQpGcmVkcmlrIEtvcnNiw6Rjaw0KQVdTIA0KDQrvu79PbiAyMDIxLTAxLTExLCAx MDo1NCwgIlNpZHJvcHMgb24gYmVoYWxmIG9mIFRpbSBCcnVpam56ZWVscyIgPHNpZHJvcHMtYm91 bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgdGltQG5sbmV0bGFicy5ubD4gd3JvdGU6DQoNCiAg ICBEZWFyIGFsbCwNCg0KICAgIEFwb2xvZ2llcyBmb3IgdG9wLXBvc3RpbmcsIGJ1dCBJIHdhbnRl ZCB0byBzZW5kIGEgcmVhZGFibGUgcmVzcG9uc2UgaGlnaGxpZ2h0aW5nIHRoZSBtb3RpdmF0aW9u cyBmb3IgdGhlIFJUQSBkcmFmdCBhbmQgdGhlIGltcGxlbWVudGF0aW9uIGV4cGVyaWVuY2Ugc28t ZmFyIGJ5IHRoZSBjby1hdXRob3JzIG9mIHRoaXMgZHJhZnQuDQoNCg0KICAgIC0gVXNlLWNhc2Vz DQoNCiAgICBQbGVhc2UgYmVhciBpbiBtaW5kIHRoYXQgdGhpcyBkb2N1bWVudCBpcyBzcGVjaWZp Y2FsbHkgaW50ZW5kZWQgYXMgYSBnZW5lcmljIHByb2ZpbGUsIHdpdGhvdXQgY29uc3RyYWluaW5n IHVzZSBjYXNlcy4gVGhpcyBpcyB3aHkgaXQgaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBmbGV4aWJp bGl0eToNCiAgICAgLSBtdWx0aXBsZSBzaWduYXR1cmVzDQogICAgIC0gcHVibGlzaCBpbiB0aGUg UlBLSSwgb3Igbm90DQogICAgIC0gb3B0aW9uIHRvIGluY2x1ZGUgdGhlIGZ1bGwgdmFsaWRhdGlv biBwYXRoIENBcyBhbmQgQ1JMUyBpbiB0aGUgQ01TDQogICAgICAgKHRoaW5rIFRMUywgd2hlcmUg dmFsaWRhdGlvbiBkb2VzIG5vdCByZXF1aXJlIHRoZSBhc3NlbWJseSBvZiBhIGxvY2FsIGNhY2hl IG9mIHNpZ25lZCBvYmplY3RzKQ0KDQogICAgVGhlIHVzZSBjYXNlIGlzIGludGVudGlvbmFsbHkg X25vdF8gbGltaXRlZCB0byBzZWN1cmUgcm91dGluZyBhbmQgcHVibGlzaGluZyBpbiB0aGUgUlBL SSBtYXkgbm90IGJlIG5lY2Vzc2FyeSBpbiBlbnZpc2FnZWQgY2FzZXMuDQoNCg0KICAgIC0gUHVi bGlzaGluZyBpbiB0aGUgUlBLSQ0KDQogICAgSWYgdGhlIFJUQSBpcyB0byBiZSBwdWJsaXNoZWQg aW4gdGhlIFJQS0kgdGhlbiBpbmRlZWQgdGhlIGZpbGVuYW1lIGV4dGVuc2lvbiBmb3IgdGhlIGRl dGFjaGVkIHNpZ25hdHVyZSAnLnJ0YScgYXMgc3VnZ2VzdCBieSBKb2IgbWFrZXMgc2Vuc2UuIEhv d2V2ZXIsIGluIG1hbnkgY2FzZXMgdGhlcmUgd2lsbCBiZSBubyBuZWVkIHRvIHB1Ymxpc2ggdGhl c2UgUlRBIGZpbGVzIGluIHRoZSBnbG9iYWwgUlBLSS4gVGhlIFJUQSBpcyBpbiBlc3NlbmNlIGEg ZGV0YWNoZWQgc2lnbmF0dXJlLCBhbmQgYXMgc3VjaCB0aGV5IGFyZSBtZWFuaW5nbGVzcyBpZiBh biBSUCBkb2VzIG5vdCBrbm93IHdoaWNoIGZpbGUgdGhleSB3ZXJlIHN1cHBvc2VkIHRvIHNpZ24u IFRoZSBmaWxlIChvciBvYmplY3QpIHdoaWNoIGhhcyBiZWVuIHNpZ25lZCB3aXRoIGEgZGV0YWNo ZWQgc2lnbmF0dXJlIGhhcyBubyByb2xlIGluIGEgQ0HigJlzIHB1YmxpY2F0aW9uIHBvaW50IG9m IHNpZ25lZCBvYmplY3RzIGFuZCBTSE9VTEQgTk9UIChNVVNUIE5PVD8pIGJlIHB1Ymxpc2hlZCBp biBhIENB4oCZcyBwdWJsaWNhdGlvbiBwb2ludC4NCg0KDQogICAgLSBOZWVkIGZvciBtdWx0aXBs ZSBzaWduYXR1cmVzDQoNCiAgICBPbmUgY2FzZSBoZXJlIGlzIHRoYXQgYW4gb3JnYW5pc2F0aW9u IHdoaWNoIG9wZXJhdGVzIHVuZGVyIG11bHRpcGxlIHBhcmVudHMsIGUuZy4gdHdvIFJJUnMgb3Ig YW4gUklSIGFuZCBhbiBOSVIsIHdpbGwgcmVjZWl2ZSByZXNvdXJjZXMgb24gZGlmZmVyZW50IENB IGNlcnRpZmljYXRlcy4gU2ltaWxhcmx5IG9yZ2FuaXNhdGlvbnMgdW5kZXIgYSBzaW5nbGUgUklS IG1heSByZWNlaXZlIG11bHRpcGxlIGNlcnRpZmljYXRlcyBpZiB0aGV5IGhvbGQgcmVzb3VyY2Vz IHRyYW5zZmVycmVkIGZyb20gYW5vdGhlciByZWdpb24sIG9yIGlmIHRoZXkgaG9sZCBzby1jYWxs ZWQgbGVnYWN5IHJlc291cmNlcyB3aGVyZSBhbm90aGVyIFJJUiBpcyB0aGUgbWFqb3JpdHkgaG9s ZGVyIGluIHRoZSBJQU5BIHJlZ2lzdHJ5LiBZZXQsIHRoZXNlIG9yZ2FuaXNhdGlvbnMgbWF5IHdp c2ggdG8gbWFrZSBzdGF0ZW1lbnRzIGFib3V0IGEgc2V0IG9mIHJlc291cmNlcyB0aGF0IGNyb3Nz ZXMgdGhlc2UgYm91bmRhcmllcy4NCg0KICAgIFRoZXJlIGNhbiBhbHNvIGJlIGNhc2VzIHdoZXJl IGRpZmZlcmVudCBvcmdhbmlzYXRpb25zIHdhbnQgdG8gbWFrZSBhIGpvaW50IHN0YXRlbWVudCBh Ym91dCBzaGFyZWQgcmVzb3VyY2VzLiBXZSBkbyBub3Qga25vdyB3aGF0IGNhc2UgdGhhdCBtaWdo dCBiZSwgYnV0IGFzIHNhaWQgYWJvdmUgLSBpbiB0aGlzIHBoYXNlIHRoZSBwcm9maWxlIGFsbG93 cyBmb3IgYXJiaXRyYXJ5IHVzZSBjYXNlcy4NCg0KDQogICAgLSBNdWx0aS1zaWduaW5nIHZzIG11 bHRpcGxlIHNpbmdsZS1zaWduaW5nDQoNCiAgICBJdCBpcyB0cnVlIHRoYXQgcmVxdWlyaW5nIHNp bmdsZSBzaWduaW5nIGZvciBSVEFzIHNpbXBsaWZpZXMgdGhlIHNwZWNpZmljYXRpb24uIEFuZCBm b3Igc29tZSB1c2UgY2FzZXMgd2hlcmUgbXVsdGlwbGUgc2lnbmF0dXJlcyB3b3VsZCBiZSByZXF1 aXJlZCAtIG11bHRpcGxlIHNpbmdsZSBzaWduZWQgUlRBcyB3b3VsZCBkbyBmaW5lLg0KDQogICAg SG93ZXZlciwgd2l0aCBtdWx0aS1zaWduaW5nIHJlbHlpbmcgcGFydGllcyBjYW4gYmUgc3VyZSB0 aGV5IGhhdmUgc2VlbiB0aGUgY29tcGxldGUgc2V0IG9mIHJlc291cmNlcywgYW5kIGV4cGVjdGVk IHNpZ25hdHVyZXMgYmFzZWQgb24gYSBzaW5nbGUgZmlsZS4gVGhlcmUgaXMgbm8gZ3Vlc3Npbmcg Zm9yIHRoZSBSUCBhcyB0byB3aGV0aGVyIHRoZXkgaGF2ZSBzZWVuIGV2ZXJ5dGhpbmcgcmVsZXZh bnQuDQoNCiAgICBRdWVzdGlvbiBpcyBvZiBjb3Vyc2Ugd2hldGhlciB0aGlzIGp1c3RpZmllcyB0 aGUgYWRkaXRpb25hbCBjb21wbGV4aXR5Lg0KDQoNCiAgICAtIE11bHRpLXNpZ246IENvbXBsZXhp dHkgZm9yIENBDQoNCiAgICBIYXZpbmcgaW1wbGVtZW50ZWQgdGhpcyBpbiBLcmlsbCBJIGJlbGll dmUgdGhhdCB0aGUgY29tcGxleGl0eSBpcyBub3QgdGhhdCBiYWQuIEVzc2VudGlhbGx5IHRoaXMg Ym9pbHMgZG93biB0byBsZXR0aW5nIENBcyBnZW5lcmF0ZSBrZXlwYWlycyBmb3IgdGhlIEVFIGNl cnRpZmljYXRlcyBhbmQgYWdyZWUgb24gYSBzZXQgb2YgcmVzb3VyY2VzLiBOb3RlIHRoYXQgdGhl IFNFVCBvZiBTS0lzIG9mIHRoZXNlIEVFIGNlcnRpZmljYXRlcyBhbmQgdGhlIGFncmVlZCByZXNv dXJjZSBzZXQgYXJlIHBhcnQgb2YgdGhlIHNpZ25lZCBjb250ZW50LiBUaGVuIG9uZSBDQSBjYW4g YmUgdGhlIGZpcnN0IHRvIGFkZCB0aGVpciBFRSBjZXJ0aWZpY2F0ZSBjb250YWluaW5nIGl0cyBy ZXNvdXJjZXMgYW5kIHNpZ24gd2l0aCB0aGUgYXNzb2NpYXRlZCBwcml2YXRlIGtleSwgYW5kIHRo ZW4gdGhlIG5leHQgQ0EgKHdoaWNoIG1heSBiZSBhbm90aGVyIENBIGNlcnQgaGVsZCBieSB0aGUg c2FtZSBvcmdhbmlzYXRpb24pIGNhbiBhZGQgdGhlaXIgc2lnbmF0dXJlLg0KDQogICAgRm9yIHVz ZSBjYXNlcyB3aGVyZSBvbmx5IGEgc2luZ2xlIHNpZ25hdHVyZSBpcyBuZWVkZWQgdGhlIENBIGNh biBvZiBjb3Vyc2UganVzdCBzaWduIHRoaW5ncyB3aXRob3V0IHRoZSBuZWVkIHRvIHN5bmNocm9u aXNlIHdpdGggb3RoZXIgcGFydGllcy4NCg0KICAgIC0gTXVsdGktc2lnbjogQ29tcGxleGl0eSBm b3IgUlBzDQoNCiAgICAobm90ZSwgSSB3aWxsIHVzZSBhbiBpbmZvcm1hbCBkZXNjcmlwdGlvbiBo ZXJlKQ0KDQogICAgRm9yIHNpbmdsZSBzaWduZWQgdGhlIFJQIG5lZWRzIHRvIHZlcmlmeSB0aGF0 IGFsbCByZXNvdXJjZXMgb24gdGhlIFJUQSBhcmUgY29udGFpbmVkIGJ5IHRoZSBFRSBjZXJ0aWZp Y2F0ZSwgd2hpY2ggaXMgdmFsaWRseSBzaWduZWQgYWxsIHRoZSB3YXkgYmFjayB1cCB0byBhIGtu b3duIFRBLiBUaGUgUlRBIE1BWSBpbmNsdWRlIENBcyBhbmQgQ1JMcyBuZWVkZWQgZm9yIHRoaXMg dmVyaWZpY2F0aW9uLiBJZiB0aGV5IGFyZSwgYW5kIGlmIHRoZSBDUkxzIGFyZSBub3Qgc3RhbGUs IHRoZXkgd2lsbCBiZSB1c2VkIGZvciB2YWxpZGF0aW9uLiBJZiB0aGV5IGFyZSBub3QgcHJlc2Vu dCwgc3RhbGUgb3IgaW52YWxpZCwgdGhlbiB0aGUgUlAgY2FuIGxvb2sgYXQgdGhlIHB1YmxpYyBS UEtJIGFuZCBmaW5kIENBIGNlcnRpZmljYXRlcyBhbmQgQ1JMcyB0aGVyZS4NCg0KICAgIEZvciBt dWx0aSBzaWduZWQgdGhlIHByb2Nlc3MgaXMgbm90IGNoYW5nZWQgbXVjaC4gQnV0IHJhdGhlciB0 aGFuIGRvaW5nIHRoaXMgb25jZSwgdGhlIFJQIHdpbGwgbmVlZCB0byBkbyB0aGlzIE4gdGltZXMg KmFuZCogaXQgd2lsbCBuZWVkIHRvIHZlcmlmeSB0aGF0IHRoZSB1bmlvbiBvZiByZXNvdXJjZXMg aW4gdGhlIEVFIGNlcnRpZmljYXRlcyB1c2VkIGZvciBzaWduaW5nIGluY2x1ZGUgdGhlIGRlc2Ny aWJlZCByZXNvdXJjZXMuDQoNCiAgICBJZiBOID09IDEgdGhlbiB0aGlzIGRvZXMgbm90IGluY3Jl YXNlIHRoZSBjb21wbGV4aXR5LiBJZiBOID4gMSB0aGVuIHRoZXJlIG1heSBiZSBzb21lIGZyYWdp bGl0eSwgYmVjYXVzZSBhbnkgb2YgdGhlIHBhdGhzIGNhbiBmYWlsLCBidXQgaXQgaXMgcmVhc29u YWJsZSB0byBzdGF0ZSB0aGF0IGlmIG11bHRpcGxlIHNpZ25hdHVyZXMgYXJlIHJlcXVpcmVkIHRo ZW4gaXQgaXMgYSByZXF1aXJlbWVudCB0aGF0IHRoZSBSVEEgTVVTVCBiZSBjb25zaWRlcmVkIGlu dmFsaWQgaWYgdGhlIHZhbGlkYXRpb24gb2YgYW55IHNpZ25hdHVyZSBvciBFRSBjZXJ0aWZpY2F0 ZSBmYWlscy4NCg0KDQogICAgVGltDQoNCg0KICAgID4gT24gMzAgRGVjIDIwMjAsIGF0IDE1OjQ4 LCBCZW4gTWFkZGlzb24gPGJlbm09NDB3b3Jrb25saW5lLmFmcmljYUBkbWFyYy5pZXRmLm9yZz4g d3JvdGU6DQogICAgPg0KICAgID4gT24gMTIvMjksIEpvYiBTbmlqZGVycyB3cm90ZToNCiAgICA+ PiBPbiBUdWUsIERlYyAyOSwgMjAyMCBhdCAwNDoxNjozOVBNICswMTAwLCBDbGF1ZGlvIEpla2Vy IHdyb3RlOg0KICAgID4+PiBVcCB1bnRpbCBub3cgYWxsIG9iamVjdHMgb25seSBoYWQgYSBzaW5n bGUgRUUgY2VydCBhbmQgYSBzaW5nbGUgU0lEIGFuZA0KICAgID4+PiBhbGwgdGhlIGxpbmtpbmcg ZG9uZSB3aXRoIHRoZSBTS0kgd2FzIGEgMS10by0xIG1hcHBpbmcgcmVzdWx0aW5nIGluIGENCiAg ICA+Pj4gc2ltcGxlIHRyZWUgc3RydWN0dXJlIHdpdGggdGhlIHRydXN0IGFuY2hvciBhcyByb290 Lg0KICAgID4+PiBUaGlzIGRyYWZ0IGFsbG93cyBmb3IgbXVsdGlwbGUgRUUgY2VydHMgYW5kIHNv IG11bHRpcGxlIHBhdGhzIHVwIHRvIHRoZQ0KICAgID4+PiB0cnVzdCBhbmNob3JzLiBUaGlzIG1h a2VzIGhhbmRsaW5nIFJUQSBhIGxvdCBtb3JlIGNvbXBsZXggdGhhbiBhbnkgb3RoZXINCiAgICA+ Pj4gb2JqZWN0IHVuZGVyIFJQS0kuIEl0IGFsc28gcmVzdWx0cyBpbiBhIGxvdCBtb3JlIGZhaWx1 cmUgY29uZGl0aW9ucyBzaW5jZQ0KICAgID4+PiB0aGVyZSBhcmUgbW9yZSBFRSBjZXJ0cyBpbnZv bHZlZCBpbiB0aGUgdmFsaWRhdGlvbiBwcm9jZXNzLg0KICAgID4+DQogICAgPj4gPHNuaXAvPg0K ICAgID4+DQogICAgPj4gSXQgaXMgcG9zc2libGUgdGhlIFJUQSBhdXRob3JzIGZvcnNlZSB1c2Ug Y2FzZXMgd2hlcmUgdGhlICdtdWx0aXBsZQ0KICAgID4+IHNpZ25hdHVyZXMnIG9mZmVycyBpcnJl cGxhY2VhYmxlIHZhbHVlLCBJJ20gbm90IHN1cmUuDQogICAgPg0KICAgID4gRldJVywgYWxsIHRo ZSB1c2UgY2FzZXMgdGhhdCBJIGhhdmUgaW4gbWluZCBmb3IgUlRBIG5lZWQgb25seSBhIHNpbmds ZQ0KICAgID4gc2lnbmVyLg0KICAgID4gSSBoYXZlIGJlZW4gdHJ5aW5nIHRvIHRoaW5rIG9mIHNv bWUgY3JlYXRpdmUgdXNlcyB0aGF0IGNhbid0IGJlIHNvbHZlZA0KICAgID4gYnkgc2VwYXJhdGUg b2JqZWN0cywgYW5kIEkgY2FuJ3QgdGhpbmsgb2YgYW55Lg0KICAgID4NCiAgICA+IFRodXMsIGlm IHRoaXMgY2hhbmdlIGNhbiBzcGVlZCB1cCBpbXBsZW1lbnRhdGlvbiB0aGVuIEknbSBhbGwgZm9y IGl0Lg0KICAgID4NCiAgICA+IENoZWVycywNCiAgICA+DQogICAgPiBCZW4NCiAgICA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiBTaWRyb3Bz IG1haWxpbmcgbGlzdA0KICAgID4gU2lkcm9wc0BpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRyb3BzDQoNCiAgICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIFNpZHJvcHMgbWFpbGluZyBsaXN0 DQogICAgU2lkcm9wc0BpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2lkcm9wcw0KDQo= From nobody Mon Jan 11 07:28:46 2021 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 A800B3A0EF9 for ; Mon, 11 Jan 2021 07:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=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 k5NbsiD52b_L for ; Mon, 11 Jan 2021 07:28:42 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1238A3A0EF3 for ; Mon, 11 Jan 2021 07:28:41 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 20F5F60118; Mon, 11 Jan 2021 15:28:40 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1610378919; bh=vpGQlRAm+dsslQDAYtirXEO7sEhApbGaSzVZMLI6zrg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=oOf8pXEEqVWja5Q6mfNreO2oVeFLoqcgjM7zqNqhKelsylxZqrAReQUK/X0zYu3wq RWdBShIT2qg3hR423J+UFlbxIxEj2Jdk1dx9mekpWYUwHmXpylyDbcdtFKvXBDcuS2 Ln8VZtQ5teJx7wdmJtrmXclAnf/NzAMrdYEvBR5LG0B+LUDKtaK/THAejSQM+UCJc6 Z1LwKfzL47aCbXII4cQQsfgVZSy+k5BL4EvgyFKWd5z+ZMcNFvldcDO4uhYsWkpS6t ScwawtgFPHn2qmPVWVnkAtL/z3NzORGKs8JiFsGMu1cQHk9Or3W3raLWRCi6+mnfFE GqsAnGKP+PYmg== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Tim Bruijnzeels In-Reply-To: <8D48337E-A7A0-4C81-973D-0160BE5C6A2B@amazon.com> Date: Mon, 11 Jan 2021 16:28:37 +0100 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <20201229101412.GA56136@diehard.n-r-g.com> <49a8e314-7b3f-0e8d-6e20-7d055fb1a076@verizon.net> <20201229151639.GD56136@diehard.n-r-g.com> <20201230144836.ytg4u2gobkv4uzqn@benm-laptop> <3BA339C3-EADC-449E-B5B2-7A4880E16EDA@nlnetlabs.nl> <8D48337E-A7A0-4C81-973D-0160BE5C6A2B@amazon.com> To: "Korsback, Fredrik" Archived-At: Subject: Re: [Sidrops] feedback on draft-michaelson-rpki-rta 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, 11 Jan 2021 15:28:45 -0000 Hi Fredrik, group, There is a trade-off in complexity vs flexibility. So I think we need to = have a discussion about quantifying both sides of the equation. On 11 Jan 2021, at 14:39, Korsback, Fredrik wrote: >=20 > Hi. >=20 > So one thing I'm failing to see is the motivation why we step away = from the fairly simple "stay within a single TA-cone" model we have in = "regular" RPKI. Multi-signing as specified can be under the same TA, or different TAs. For most organisations the use case would be that they have multiple = certificates under a single parent. While some organisations would have = certificates under multiple parents, potentially under different TAs. > Even if implementing a Multi-signatory support seems simple enough for = your implementations, we do not know the full extent of which software = is out in the wild that may or may not need full refactors to handle = this. Sure, I am trying to share our experience. I am quite happy to listen to = other points of view, but this might help to quantify just how much more = complicated this really is. I suspect that the biggest challenge to RP software here is the notion = of bottom-up validation of an RTA file found out-of-band. And we argued = that the added challenge of validating multiple EE certificates in that = RTA file, verifying that they combined contain all resources in the RTA = and they are all present, is not that much harder. > You bring up "However, with multi-signing relying parties can be sure = they have seen the complete set of resources, and expected signatures = based on a single file. There is no guessing for the RP as to whether = they have seen everything relevant." Wouldn=E2=80=99t this also go the = opposite way as well? If a TA goes down and/or is not included in your = set of TAs, the multi-signed object goes out? Increasing the = blast-radius. With Multiple single-signing this blast radius should = lessen.=20 >=20 > Our usecase is fairly obvious on what we would like to use RTA for = (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-byoip.html#byoip-= certificate) since we already have a poor-mans-version of it implemented = and used today. Getting simple RTA objects would make our BYOIP-process = a lot simpler, make it go faster and reduce the amount of humans = involved. It looks like your use case expects a single prefix or range to be = signed. In that case single signed RTA will suffice. > I can't see any outcome where multi-signing makes sense over multiple = single-signing If your process would accept a set of different resources, then = multi-sign could help the end-user experience. Speaking for Krill we = intentionally let the operator focus on their intent, and not the 'how'. = I.e. you can specify a prefix and ASN and then Krill will figure out = under which CA certificate (if you have multiple) a ROA will be issued. = Similarly a user could declare intent to create an RTA for resources = spanning CA certificates, and the software would just deal with it. And = they would just get a single RTA file to upload to your system, rather = than -potentially- multiple. This can simplify the steps for the user. > and keeping recent outages, slow software-updates, and the fairly slow = adoption of RPKI in mind it seems that "keep it simple" is going to help = with these things. At least more than what this multi-signing paradigm = can give us. The trade-off is the complexity in server and RP software vs flexibility = and usability for operators using the software. I understand that there is a resistance against complexity, I share this = aversion. I myself was skeptical until I started coding. It's just that = based on my implementation experience so-far this complexity is not that = bad and it allows for flexibility in use cases. The fragility in practice depends on the use case. If your challenge is = for single prefixes or ranges then they will in essence by single signed = - even if the 1 EE is in a set of 1(*). So, if you only require single = prefix then you can just not give the option for sets. For resource *sets* things depend: if you want to do a one-off = validation of an RTA then this fragility is limited, if you want to be = able to check at any time whether the RTA is still valid then the = outcome is still similar to multiple single-signed: in that case you = would have to recheck all RTAs individually and conclude that things are = no longer valid if there is an issue with any one of them. So rejecting = the multi-signed RTA would be a feature in this case. Tim (*): Theoretically a CA could hold adjacent, or overlapping, resources = in multiple CA certificates. But in practice this would be extremely = unlikely. >=20 > Happy to hear more comments or some tribal knowledge I just don=E2=80=99= t understand in this design choice though.=20 >=20 > -- > Fredrik Korsb=C3=A4ck > AWS=20 >=20 > =EF=BB=BFOn 2021-01-11, 10:54, "Sidrops on behalf of Tim Bruijnzeels" = wrote: >=20 > Dear all, >=20 > Apologies for top-posting, but I wanted to send a readable response = highlighting the motivations for the RTA draft and the implementation = experience so-far by the co-authors of this draft. >=20 >=20 > - Use-cases >=20 > Please bear in mind that this document is specifically intended as = a generic profile, without constraining use cases. This is why it = includes the following flexibility: > - multiple signatures > - publish in the RPKI, or not > - option to include the full validation path CAs and CRLS in the = CMS > (think TLS, where validation does not require the assembly of a = local cache of signed objects) >=20 > The use case is intentionally _not_ limited to secure routing and = publishing in the RPKI may not be necessary in envisaged cases. >=20 >=20 > - Publishing in the RPKI >=20 > If the RTA is to be published in the RPKI then indeed the filename = extension for the detached signature '.rta' as suggest by Job makes = sense. However, in many cases there will be no need to publish these RTA = files in the global RPKI. The RTA is in essence a detached signature, = and as such they are meaningless if an RP does not know which file they = were supposed to sign. The file (or object) which has been signed with a = detached signature has no role in a CA=E2=80=99s publication point of = signed objects and SHOULD NOT (MUST NOT?) be published in a CA=E2=80=99s = publication point. >=20 >=20 > - Need for multiple signatures >=20 > One case here is that an organisation which operates under multiple = parents, e.g. two RIRs or an RIR and an NIR, will receive resources on = different CA certificates. Similarly organisations under a single RIR = may receive multiple certificates if they hold resources transferred = from another region, or if they hold so-called legacy resources where = another RIR is the majority holder in the IANA registry. Yet, these = organisations may wish to make statements about a set of resources that = crosses these boundaries. >=20 > There can also be cases where different organisations want to make = a joint statement about shared resources. We do not know what case that = might be, but as said above - in this phase the profile allows for = arbitrary use cases. >=20 >=20 > - Multi-signing vs multiple single-signing >=20 > It is true that requiring single signing for RTAs simplifies the = specification. And for some use cases where multiple signatures would be = required - multiple single signed RTAs would do fine. >=20 > However, with multi-signing relying parties can be sure they have = seen the complete set of resources, and expected signatures based on a = single file. There is no guessing for the RP as to whether they have = seen everything relevant. >=20 > Question is of course whether this justifies the additional = complexity. >=20 >=20 > - Multi-sign: Complexity for CA >=20 > Having implemented this in Krill I believe that the complexity is = not that bad. Essentially this boils down to letting CAs generate = keypairs for the EE certificates and agree on a set of resources. Note = that the SET of SKIs of these EE certificates and the agreed resource = set are part of the signed content. Then one CA can be the first to add = their EE certificate containing its resources and sign with the = associated private key, and then the next CA (which may be another CA = cert held by the same organisation) can add their signature. >=20 > For use cases where only a single signature is needed the CA can of = course just sign things without the need to synchronise with other = parties. >=20 > - Multi-sign: Complexity for RPs >=20 > (note, I will use an informal description here) >=20 > For single signed the RP needs to verify that all resources on the = RTA are contained by the EE certificate, which is validly signed all the = way back up to a known TA. The RTA MAY include CAs and CRLs needed for = this verification. If they are, and if the CRLs are not stale, they will = be used for validation. If they are not present, stale or invalid, then = the RP can look at the public RPKI and find CA certificates and CRLs = there. >=20 > For multi signed the process is not changed much. But rather than = doing this once, the RP will need to do this N times *and* it will need = to verify that the union of resources in the EE certificates used for = signing include the described resources. >=20 > If N =3D=3D 1 then this does not increase the complexity. If N > 1 = then there may be some fragility, because any of the paths can fail, but = it is reasonable to state that if multiple signatures are required then = it is a requirement that the RTA MUST be considered invalid if the = validation of any signature or EE certificate fails. >=20 >=20 > Tim >=20 >=20 >> On 30 Dec 2020, at 15:48, Ben Maddison = wrote: >>=20 >> On 12/29, Job Snijders wrote: >>> On Tue, Dec 29, 2020 at 04:16:39PM +0100, Claudio Jeker wrote: >>>> Up until now all objects only had a single EE cert and a single SID = and >>>> all the linking done with the SKI was a 1-to-1 mapping resulting in = a >>>> simple tree structure with the trust anchor as root. >>>> This draft allows for multiple EE certs and so multiple paths up to = the >>>> trust anchors. This makes handling RTA a lot more complex than any = other >>>> object under RPKI. It also results in a lot more failure conditions = since >>>> there are more EE certs involved in the validation process. >>>=20 >>> >>>=20 >>> It is possible the RTA authors forsee use cases where the 'multiple >>> signatures' offers irreplaceable value, I'm not sure. >>=20 >> FWIW, all the use cases that I have in mind for RTA need only a = single >> signer. >> I have been trying to think of some creative uses that can't be = solved >> by separate objects, and I can't think of any. >>=20 >> Thus, if this change can speed up implementation then I'm all for it. >>=20 >> Cheers, >>=20 >> Ben >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops >=20 From nobody Mon Jan 11 07:31:29 2021 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 A6B953A0F06 for ; Mon, 11 Jan 2021 07:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 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, NICE_REPLY_A=-0.262, 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 nfTIal1SjQq0 for ; Mon, 11 Jan 2021 07:31:26 -0800 (PST) Received: from sonic306-2.consmr.mail.bf2.yahoo.com (sonic306-2.consmr.mail.bf2.yahoo.com [74.6.132.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 806743A0F04 for ; Mon, 11 Jan 2021 07:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1610379084; bh=MLoGoXX8RB/jcEFor1nn8a2T9niZNoItn87T9mFAF+Q=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=ue7W0JkwoSlwLYEmYN6UDCMw77v1u/ohhlKew0VfihOV2/J8tQ52TYolNfOVwCwSXq/BOPJhkGfn6mCma6NFuaEPX0TyMx/i4REvGx+jwtEwxeo45ROG1MyxY2fytVraI2MupQ43DSM1H2slISZKSFmyxotj7X6uPEE0bMt9bwa7N44wtvayt3Z2l8TJ+R6FT3WWCiANWLC5ae6rMiyKTIQ5cpBZ8ZNbSw5zm2bvtGf40qU+XfZDgGyfJkiIiSm01A3wC5m1b6sAHhv17spnwXVpOIO5nnBuhh9ZQqaHkjMt265eX7QSBv5epRqH+2RPAnJgZ1nqk3rTKYdjIWz6bQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1610379084; bh=9ZG6AQarY7r2x/M3AYGkXsAbBN+JAXmXRKE9FbkOiwZ=; h=Subject:To:From:Date:From:Subject; b=qOTbn1HC+nyTDDSXSdbrSOV9Kvq15LBwtdtzK8uIzp18foCKDtwLUoGj9j5Qf/hKdVcaSolC8hTYhc0fDDCNa2VVzwXF0Udz5Nbj2AymJFAvwsxCZOnJr7PxPvLxpU0lMfpsnH+CQkR4ZVi79MS1WBN1J9c/SWCushc0sV5KpRtmer1wjWjhEquTCtOOm1ztVR5zd1Y3ob0OF+rGTGjzGmwlEbyCtLG1t3y+pJzhoqxAbSNk7YkhX9pBH3reskvWue8FBWpiou2lllzobU4Byqm1HwKQX8Z7V//D4Um5V7gsnyfuZFxoGZXP4xjZ0SQ21pAGFcI66d9ZdIiy5ugr/g== X-YMail-OSG: yCf0bdsVM1nhjOFtf.ANIQmUZj73fVcYd..YdvB1HTm3o3T1CBpWAnKyWpfumPT ytFuWztbFLsgvR2UM4nEPWyVD.d.5zJ4XXHMUyUJ503B1wQfO0ILbvnpES9K81TAXOe0PkQjtaoK jxbf3Cre0nv0U5VWDiUFAdcrTWtXm0vyMdnNREeEgl7UeVVqdq66sCZWWQybWwb7Yh0UQhBW21yC fGIx1YqyQd_UOJbV8F9nMQKva1bM6AtvqfA4V3z5yOa1iluf_duokho9lWOIukrnB1TkeewADSYe vt.PizVuJhKKy2DtoswDQhUhk4cQJDvNuVF2Zm8.wKH0Ez3hRVhWjbOhdX9H81g5I5CeGBET9_n. pOBmxHp7lmGe9FKdp3Ruz_vH5q3PRxphVSRNP2ObGVEpAvMzthjf79eVHDL6EEwRyrYmQNTUycoK re.xFMiF5zUoel0fap35uVOKndII1rkPYwNrCW80uPG8nB9QTdfk8etXK8xQo0QRUMfKe46eVr26 e_vpQHeG.SYSjF34ZSQyKUId7Jp55Zx0S7C5R9._0UNhNUDNGu8PjRsnwOQk0eh8RuvTciNWUVA3 bq_xZoaKSxV61ztHLbgczyAtwhu5BFT6ybGD7OBonllPjYJLq1ctm5ZYmIQT9AEOm7yhppq43Oux iYf9zZFKP16LbGvyjHTP8ZY_qP7jKX7lL5k.BIvwJlAQ8SlfMCxn9Unh5BPBpcKMKNxNT3DmMvDp qABVbvIVtQFm0KZZeYZym.rtqW_8dgfTQDD6aSOQqJn6kbjV0_XIIKnfXD82c2ahbGt4fqLoc4xU omXmsSiogUA.ysXnxRPs2VNtnlb2tdiWOFU5KsovWY6KlAtD8m4d8kkObDXObjNKIPM1Lh5IVig_ g5sQAiNifdQcSjQkJiJ6mYuFMJ9mBMiDcFb8BzjegcIWuLucV9pAiTCMoFUAZ0wNyF1ayoPwd.uu T46_hm5lEK2cvX4.oekDzhJnuPKxI3njgCwmjA7KOcWTHwxRS.s_albMils0QCuEugwr_6agwMpk VcPT9UUVukLG9DErMuZeVlGXKDJj246SPr8tzkfZcj1IR5kYHBaOsPCH_a_XpfdooRIl.WkP.IPS oozircHdEJYgR3FiSVSL8r7a9C9vnbNQb1XXRazyoFMr7lyFb2c56bKYZT17HzDgOEXuPDPQ.dz0 JUsl709OF8Csa0EMVyekGSGVZJYjoPR83gwveAyzXfk_kw_qFhnELlgQvZy8xT2J3GQ8APmYqNhn EsBYpc00o90jpPxiKccoYFN.PxrxeqFWJBcNQihlSR8lOGYTh8qPhRIFqr_dKt9PQRUkV9IYS0yY EgISMyqh6ZwqeaZB3lGa_bskwvezo9d0gzGGFWWmnTM2JgwZI1KHbvEQbg_Nwu2wibtl_2.nDeT7 Biq0vy7_LBQC7F7k1ykGGvILwMW5xmb_yRII01JAMKQvpVzFYkkIHVvynTSoAYhQ2yx86MADOkCQ AxEHfjg3aUkEwciGtEMUsaQmCoL96uHZWZuuQwxREW0Z.Cn55PLOfNJzVK6ROlK4bQRHsMMoXg7d hVCvAB41RVY6toRtBv6a.0XWnXJ.i8KdaI6g9605cg.q2jJG3WAlDKlVyWyV38dsx.AI4GwcwG7g wT87g9wj4b0NVABrliLmpoMBf9b7K1HQ_mfQ__BIP1ELGE_u4dRSZb3IQ3orR9yAJ1ySEWUiu1XA syGIc04cVS25GfEN3TZggDX716L7O9nmOeu7JnJIQrv27kJ_X7G0BTWyezo1r7x3amtF_aekEZwh e_w7q2aqGNgZHxZtmF2UPlV1IEYxlEkEqipq8Ng.Snt.tLgw5Ys3c0VnyagR9NtMpVzrb3dg_BC6 tNcEr9Ml.Xjb.oiLiwuHBGdLIyt1QRS7o8mu9._lB9cHsQ.0YH77kzJet3WzZWv5aJzKjco4CnUK pjSpA7T3YbWIrQ6C0.JBEIvp6.ZlqvxcXXzmcij_1vTATqb5qingXYDrvO6o1CNnjc0M.CY7Ve6g RbNprj5RcUECN9VYQ_dBve8umNgROw1XED4vdthWiBXl.XnPAWFbAZnamEbutQHsT316K9AugwFP Tc511deP7J7WS18Uw7Ja.oqZbpqFFYF9x9f6vKxo3ddIKM.tT.lR0MjO4.s42SmFtKrEPpgiur_a 67xmT47J5iNwJ2l9ZusSZFIgnLgWV21QZQxUz4jnpQQCbmuVmk0OYtw84AiPHf3YgEQMsNEinhFl joSxjR_v4kZrMyyJFj5Te7gBgPPs0AXU3O6IH7D2oHL_FOyeJ1pnkC2.nuGMT1tTJGQkQadh6z.R 7xzVvzoozaGTcVV0rAOC37Fu_5q7H1UdO_PG.NsnrZiDxW6I861sWCAQ5NE5Qt9bS2Uf.JKyrzv8 CGiqR9ed7RIJdJfYZm6fBEjkoosJJZum_S19feLBj_igT68xCbFr9j3VW2gfcPfLgEfFlnip6dps _0eNArf0Qqw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Mon, 11 Jan 2021 15:31:24 +0000 Received: by smtp410.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 588cf9148e37fdbd0c1a2e9a064f25ce; Mon, 11 Jan 2021 15:31:21 +0000 (UTC) To: sidrops@ietf.org References: <20201229101412.GA56136@diehard.n-r-g.com> <49a8e314-7b3f-0e8d-6e20-7d055fb1a076@verizon.net> <20201229151639.GD56136@diehard.n-r-g.com> <20201230144836.ytg4u2gobkv4uzqn@benm-laptop> <3BA339C3-EADC-449E-B5B2-7A4880E16EDA@nlnetlabs.nl> From: Stephen Kent Message-ID: <523f7597-7de9-d8db-f9d0-eb3b9b08f5ed@verizon.net> Date: Mon, 11 Jan 2021 10:31:21 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <3BA339C3-EADC-449E-B5B2-7A4880E16EDA@nlnetlabs.nl> Content-Type: multipart/alternative; boundary="------------3EAFF5FD4A13FC928DED92AC" Content-Language: en-US X-Mailer: WebService/1.1.17501 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.8) Archived-At: Subject: Re: [Sidrops] feedback on draft-michaelson-rpki-rta 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, 11 Jan 2021 15:31:28 -0000 This is a multi-part message in MIME format. --------------3EAFF5FD4A13FC928DED92AC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Tim, You said: The use case is intentionally*_not_ limited to secure routing* and publishing in the RPKI may not be necessary in envisaged cases. The CP (RFC 6484) imposes constraints on the set of uses for certs issued under the RPKI (and thus containing the designated policy OID). As noted in the introduction, RPKI certs are "designed exclusively for use in support of validation of claims related to current INR holdings." Using ANY cert containing the OID defined in the CP for ageneric set of cases violates the CP. Thus it is inappropriate to publish a spec that uses certs issued under the RPKI (whether published in the repository system or not) for applicatons inconsistent with the CP. Steve --------------3EAFF5FD4A13FC928DED92AC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Tim,

You said:
The use case is intentionally _not_ limited to secure routing and publishing in the RPKI may not be necessary in envisaged cases.
The CP (RFC 6484) imposes constraints on the set of uses for certs issued under the RPKI (and thus containing the designated policy OID). As noted in the introduction, RPKI certs are "designed exclusively for use in support of validation of claims related to current INR holdings." Using ANY cert containing the OID defined in the CP for a generic set of cases violates the CP. Thus it is inappropriate to publish a spec that uses certs issued under the RPKI (whether published in the repository system or not) for applicatons inconsistent with the CP.

Steve


 --------------3EAFF5FD4A13FC928DED92AC-- From nobody Mon Jan 11 14:34:32 2021 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 0D5453A140D for ; Mon, 11 Jan 2021 14:34:30 -0800 (PST) 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 oeVbnpz0F-74 for ; Mon, 11 Jan 2021 14:34:27 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 ECDC43A140A for ; Mon, 11 Jan 2021 14:34:26 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id u21so738378lja.0 for ; Mon, 11 Jan 2021 14:34:26 -0800 (PST) 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:content-transfer-encoding; bh=ViMJ5tUUtyTN2sRXQUExqmk/X/54oOh2wJ36ZkMvmfo=; b=RxUvjnM3xK0wiYLuKkOY1p9C05RpkF4seHvIBYkdclrNZdYeiU3rN616p2tNwJfMju iQkGjkAEqVt0QqrNfSo5R6l+ZcQXXvszT9KZR4JAmC+l2TgVPsa3Ir90Uxk3vHiGPqvI zA9vwhwen8pDeCoHE+FLqgQAeCBRsMBhOt31zXKijdrhp6PNVTAOJ6BqWj+61KaaQSAW DU90DJF00W6CbAFWpzMkFlkOfiX0455fxW0vpPpTJCgEH2ocYh14SrpHQgjeahPMPoTi hGmXSw+sZPllQh2PPwLcM95mOZdmbsPvB4LOrXDB9XuBzWa0xIdFBzXGcNMC31meXHHo Qrpg== 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=ViMJ5tUUtyTN2sRXQUExqmk/X/54oOh2wJ36ZkMvmfo=; b=kkgh/o/ORcdwtAwBa05CV82ZD+zS762pc5+SokN0i9nB3wRbVsPlMf+4055aQF7sQk 05SsOFMTkRQD1swXIgXON4UEaY2mTbrE9V9YWwHfzoGEL0U/5CLeUEYE6Q62l+oPrehZ +J8m7Y3uUqyytNi5sucevdiaS7GZK072RJ9PlUep2jFG8lFAK5umSQ8dt+Y78yx+odqO 7ia1ts8PBr9oxdxe/2kln7jRfooay82NJEIXzLgaRUVuGDymfz/0XJvYb9UwwOl9jXjV 2m9eAVrIq4CLELI+6rAWD5h2olBvvfhUR7TL/2tMoQ/7oAAvSQYyWkgDSVP12xP+45lF Jg+Q== X-Gm-Message-State: AOAM533RfInyQoxf2ihHDcbzadQOn/3paJhhoDKJn480bQL/s4oLmND9 chGSBUNUsX55dJZG/eP4Wz8JGFTVZwkY0FJ7/A0QFRJhezArXQ== X-Google-Smtp-Source: ABdhPJxwqY4dSECDuEaE2P0wWWbgqd2prJvUI5VcIQLBm96ROmH+4BIZYRMHqqVYFB+OCuGJLhy/yaj3mPIVjzqrJok= X-Received: by 2002:a05:651c:2049:: with SMTP id t9mr733264ljo.58.1610404464370; Mon, 11 Jan 2021 14:34:24 -0800 (PST) MIME-Version: 1.0 References: <20201229101412.GA56136@diehard.n-r-g.com> <49a8e314-7b3f-0e8d-6e20-7d055fb1a076@verizon.net> <20201229151639.GD56136@diehard.n-r-g.com> <20201230144836.ytg4u2gobkv4uzqn@benm-laptop> <3BA339C3-EADC-449E-B5B2-7A4880E16EDA@nlnetlabs.nl> <523f7597-7de9-d8db-f9d0-eb3b9b08f5ed@verizon.net> In-Reply-To: <523f7597-7de9-d8db-f9d0-eb3b9b08f5ed@verizon.net> From: George Michaelson Date: Tue, 12 Jan 2021 08:34:13 +1000 Message-ID: To: Stephen Kent Cc: SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] feedback on draft-michaelson-rpki-rta 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, 11 Jan 2021 22:34:30 -0000 The use case is to tag other information with INR. The note Tim made was that the intent of RTA is not limited to secure routing, not that it is intended to be used for signing without reference to INR. -G On Tue, Jan 12, 2021 at 1:31 AM Stephen Kent wrote: > > Tim, > > You said: > > The use case is intentionally _not_ limited to secure routing and publish= ing in the RPKI may not be necessary in envisaged cases. > > The CP (RFC 6484) imposes constraints on the set of uses for certs issued= under the RPKI (and thus containing the designated policy OID). As noted i= n the introduction, RPKI certs are "designed exclusively for use in support= of validation of claims related to current INR holdings." Using ANY cert c= ontaining the OID defined in the CP for a generic set of cases violates the= CP. Thus it is inappropriate to publish a spec that uses certs issued unde= r the RPKI (whether published in the repository system or not) for applicat= ons inconsistent with the CP. > > Steve > > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Jan 12 06:58:21 2021 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 971F93A1378 for ; Tue, 12 Jan 2021 06:58:18 -0800 (PST) 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, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-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=workonline.africa 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 gdmZ-itPCLN2 for ; Tue, 12 Jan 2021 06:58:15 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2088.outbound.protection.outlook.com [40.107.22.88]) (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 1E1003A1379 for ; Tue, 12 Jan 2021 06:58:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MroUaKUMKkhVH4cgGbSl9Kibs3XOFCyOZjxi2DriHGnRQB1FPAYBmcqFHWSJFuC1K751zNMZ8RM/tqHQyweVYHuIhpNb5MZjSWQK/RkwS8BWyCG5rDu4Vj6daPG2GdPqaJJbiNULF1Yh99wahFGl/0h0MfNQoCc8dSppwBuLKcvsZQ0+fVWs6Y0SpAtgKIb3UjH3b5C4dFqFOGpHj6ooxYi/wzPgkOroiLUgad05jT06HKcsV5p0eR4LuXUQhdmXswQvStoOvDdZbfurwWu2oYjQoEg9k3bbSvAYkelTjrAURaVyUYZd8bocUzRuSLyTm6fJp+PrJO2ofI0pjphA3w== 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=YELZFMDUlp853DYWPrAT9bUXPmoxVjXtdJkQVle0Wio=; b=h3xUazrCRcaEzXsU88n/RdQCpLYFnFdhuBgpisAWxBV5C+2vQxGNR9g5E4sUn2zAXGs83HIPbIL6L89i3J5/hc17Jke1DmtNnvJEFuS21fNJ0IFo8NP8PrZH8TRo9/m5CtOi081dqHgRR/R80Gi67y0dNLhs8X7Jghaf176Cn/poOBkfxBC2ClRLDkizruoR66LmvCTYD1Wasvo18ixKaTYUxYyQz5wIxcZOvU6CpB5zcPJMB75QiYp8urAE+LsN16t1s0z5JW3ZRDDExRGnvo9vZTYdsTefoWCqsiZDTqSAvcd0IJloENhWf2qrErfRNzXC9mmtDmsCJzRNhRqVyw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=workonline.africa; dmarc=pass action=none header.from=workonline.africa; dkim=pass header.d=workonline.africa; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=workonline.africa; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YELZFMDUlp853DYWPrAT9bUXPmoxVjXtdJkQVle0Wio=; b=tOUKw9rOXY4KMMYKRXNOBdcfg3ZSUVV5GOCZN3CCwIv69QEUR7WprDpa3qztg+lgGarU2+v8rjMo1QNL9n/LSzSo/DgMqTEt8PCTfTk1a+Qn5uRipH5gmbs/q1sHbon+94tBXOgOnR2tzN7yN7ncmOi3G5DNEQV9nAUZCLN/HHg= Authentication-Results: nlnetlabs.nl; dkim=none (message not signed) header.d=none;nlnetlabs.nl; dmarc=none action=none header.from=workonline.africa; Received: from DB8P190MB0746.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:12a::24) by DB6P190MB0453.EURP190.PROD.OUTLOOK.COM (2603:10a6:6:32::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.8; Tue, 12 Jan 2021 14:58:08 +0000 Received: from DB8P190MB0746.EURP190.PROD.OUTLOOK.COM ([fe80::a8b1:5eb6:5886:96c2]) by DB8P190MB0746.EURP190.PROD.OUTLOOK.COM ([fe80::a8b1:5eb6:5886:96c2%3]) with mapi id 15.20.3742.012; Tue, 12 Jan 2021 14:58:08 +0000 Date: Tue, 12 Jan 2021 16:58:00 +0200 From: Ben Maddison To: Tim Bruijnzeels Cc: SIDR Operations WG , Job Snijders Message-ID: <20210112145800.nocjbd4millmbx4i@benm-laptop> References: <20201229101412.GA56136@diehard.n-r-g.com> <49a8e314-7b3f-0e8d-6e20-7d055fb1a076@verizon.net> <20201229151639.GD56136@diehard.n-r-g.com> <20201230144836.ytg4u2gobkv4uzqn@benm-laptop> <3BA339C3-EADC-449E-B5B2-7A4880E16EDA@nlnetlabs.nl> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="yvqbgsawf3vjytn6" Content-Disposition: inline In-Reply-To: <3BA339C3-EADC-449E-B5B2-7A4880E16EDA@nlnetlabs.nl> X-Originating-IP: [165.0.73.66] X-ClientProxiedBy: CTXP275CA0043.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:1::31) To DB8P190MB0746.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:12a::24) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (165.0.73.66) by CTXP275CA0043.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:1::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.9 via Frontend Transport; Tue, 12 Jan 2021 14:58:07 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 03c9f096-d0b6-4e2a-fd54-08d8b70a7920 X-MS-TrafficTypeDiagnostic: DB6P190MB0453: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ppOj2rIn5B/A+od3/1Ke5wzAj4OoUwd7yy3qWo8C6ahl4QTGQFLqlIl42bOdmutCwt2Ly74ksbxvdbDLS2sbIBoxgLsx9ewPS57tvAQaFH39ascSFywTaPO7omF3w9hCLTTNYXB2TLM4Q9bqSb4+9Z4Up3bIKuIDGh8XYKeYxKAxotqFEC2a7gFgmaNU0puiLBgM+cGtJX2KwkRvAmrGjcCld/Y/BZdAtJQQLKycJz3qZ5ZxLpJlLNGG5w00igXbquN6qXoiJg+YrrJOU03WwFAYuCObMYGU0MeX0akDvbIgSO4FtuhO+xoYs0134AUt15wmaJ8JumongPB44GpSjenvRcQQgUWJtwzPPQg47IkbT5EP0NuuACzBQ6OkYT3Qf3C7NnjZpz2eZaTKSkNJIFgW3q9wAI/O1ylzDFD3u3eOXqVs9fsoDK+iuf0/ZtuBr1yvcBP4TVd8S8WtF5bzmQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P190MB0746.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(7916004)(396003)(39830400003)(136003)(376002)(346002)(366004)(186003)(316002)(956004)(478600001)(44144004)(8676002)(26005)(9686003)(54906003)(6496006)(1076003)(16526019)(6916009)(6666004)(66556008)(5660300002)(21480400003)(66946007)(6486002)(66476007)(33716001)(2906002)(52116002)(83380400001)(86362001)(4326008)(8936002)(46492008)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?DQB3k6UKP+n2Z1SZCo2+sxKlTNkM0PJh2YiM278RnzPwYmna8pNvdFypJYaC?= =?us-ascii?Q?/KRyDeBY/Pp2KfBu3e1EfqRArqDD7N/FqPi+uhpw1z9BLJQUIv2axSEtwms0?= =?us-ascii?Q?88XSMmGu7DC9iS83kCCNgBZw+h5CxkWF6kW7/Dhbm8sAlP9yBGQZUDknQj19?= =?us-ascii?Q?dnH9AKOeOD1AlMy2jiUgleLrC3uiM9jCJ79psQJLpCZX9YyMahAPKRrT6kej?= =?us-ascii?Q?u2LBbZ45zHET+76dyBeVahGqhcKE+x+OKdPOG++wr1eaCNlEjld76lK6GFoq?= =?us-ascii?Q?67oF+sO6xzvQq5HOK2cZ/Ypd99OCqYMS14cs8myHm2LjrowIKw/xan0gN6av?= =?us-ascii?Q?igcO6er2EigR7QbAz3gtPmzjOLBcad1cjTGAMGMZr/79SLhqSTEQdmZvwAsj?= =?us-ascii?Q?LXL8WlldTUKHNNrzELsT4uJwSX841v+4GkM73HA4ypO95CSAvvAjbMmKaET9?= =?us-ascii?Q?myihQC40U22O8hCQFqZSpf+cSfntUKf7ySimRrJeck5jnwKmfQ5x01K1Nu/+?= =?us-ascii?Q?nZSGzK2QHQlZt3GgKftE38Q4U5GpMihtXXMMS0WIdPbov5NjE/Bo2AZ4bwlY?= =?us-ascii?Q?2fiBAYYM1duwrgHqsh3tUP7g4HFX4hc3xUKXfShrOcyWALb2gmwFOp9iXV9a?= =?us-ascii?Q?dX65CLsME3V0pf0aPFRaaLaw31QeF2RTGVMhWiH59SeVaUoxm770Va/niO0U?= =?us-ascii?Q?Vjsv3EQVxucaUYHTBFuODDwOH37GqbUl+AMmydUnznHDeDPG6MYs04SFp5Al?= =?us-ascii?Q?fWE8rykNU8A3+Fj/8lKcqW2RqWbGciUSHtwfTZdSGrdVIW56pQF8d1rjeYeR?= =?us-ascii?Q?Xby4ACwkvkKeYoovplmLNM1jtlTAoIBRCNTPFQea0XSewffakIMC+dnVcasl?= =?us-ascii?Q?UpKsJE0jUuJSR9TBkD4YhqBTYTKUyB5jVV1PPcL8Kz8RA7gFAr8b4DSVEtyC?= =?us-ascii?Q?IhE0litEzaQEBIiLl/FLUYtISeOM8Si9BXh/VzxllGxq8Q+wbk7aGzkbFQFu?= =?us-ascii?Q?DS4G?= X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-AuthSource: DB8P190MB0746.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2021 14:58:08.1382 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7 X-MS-Exchange-CrossTenant-Network-Message-Id: 03c9f096-d0b6-4e2a-fd54-08d8b70a7920 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: XQQbd5pU1Spnp8/QYucMIHuPEDRIOUfu0uVrdpgZtJsQDLOvmqFxB5BxxIXhuTs9mO3o4ZNHS9CBbkELvHHsyw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0453 Archived-At: Subject: Re: [Sidrops] feedback on draft-michaelson-rpki-rta 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, 12 Jan 2021 14:58:19 -0000 --yvqbgsawf3vjytn6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Tim, all, Happy new year... hopefully :-) On 01/11, Tim Bruijnzeels wrote: > Dear all, >=20 > > > - Multi-sign: Complexity for RPs >=20 > (note, I will use an informal description here) >=20 > For single signed the RP needs to verify that all resources on the RTA ar= e contained by the EE certificate, which is validly signed all the way back= up to a known TA. The RTA MAY include CAs and CRLs needed for this verific= ation. If they are, and if the CRLs are not stale, they will be used for va= lidation. If they are not present, stale or invalid, then the RP can look a= t the public RPKI and find CA certificates and CRLs there. >=20 > For multi signed the process is not changed much. But rather than doing t= his once, the RP will need to do this N times *and* it will need to verify = that the union of resources in the EE certificates used for signing include= the described resources. >=20 This was kinda the point I was making when I said that I couldn't think of any use-cases for which multiple RTAs wouldn't work: The above logic works just the same if you instead have N RTAs over the same signed data, and require that the union of `resources` from each be the same as the set described in the signed data. Doing it this way seems to present the advantage of decoupling the rpki-validation of the CMS blob from the application-specific-validation of the underlying data. Every use case for this will require tooling to perform additional validation of the signed data against the RTA (at least verifying the digest, probably more), so this doesn't introduce a new step in the process, it just moves responsibility for it out of the RTA spec. > If N =3D=3D 1 then this does not increase the complexity. If N > 1 then t= here may be some fragility, because any of the paths can fail, but it is re= asonable to state that if multiple signatures are required then it is a req= uirement that the RTA MUST be considered invalid if the validation of any s= ignature or EE certificate fails. >=20 It arguably also adds flexibility, in that the consequences of having an incomplete set can be application-specific. In some cases, a partial set may be useful, in others it may render all the RTAs useless. When I started writing this email, I was mostly agnostic other than insofar as this may speed-up or delay implementation. Having thought about it, I actually think the multiple RTAs pattern is better than the multiple signer pattern. Cheers, Ben --yvqbgsawf3vjytn6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEadkaB2uV5dm5UllaOkYk/rSLaGAFAl/9uPcACgkQOkYk/rSL aGChqg//Xjxsh235tle5Uw9Kmcpy0oAevgMvhxAyxxqnZXfxjRTyO6pCxuV1t7Wh 7Ko9epkBuuyftAswPK/pPGVsLLLxS9ktUoEYJzMJB5xJH26qFOOO/t1dxSMS2M9G RmbybfGksNiyJBMK28+w72O5GGyiE0yaiOZsZ1hxnKYGvQOVPnzSli4vYiooY/hV I/F50IXdhMAiTk0JeCQOS5oZrdFY5QRyWEgWsULP8Bly/gl/2QXKnZ5+JQhCE65t btSM5Suq9CBPv8oc15qxIpv6SXc8Sfk2lNU76QhzXCTDcVDZ0hIIaKY5T79ZJODf MbH2KFEgoIti//J9lxByx9sHem6EgNghhHKzpGzNOonshO345c2r7HnzC+ByPUGS C9nmPL3rpV46hPW1R/0O6g41fHqXEbvgUz4PTvM5EUHSpn6Mk7/tnI6imJZUvRoB okvZXLs0KOJaY6nmhtm0GFv66Kjh8MMCOlwy3WfnwjcPmOecqP9OgNV94SE+evHN a42Ky+w6L2wqcb77pwdw0kGlFVmK0kkR8Dp0dmgsKY/z/ljkvw57+M23fuRq6Vpu JZWXPkOlST/abkZSnclV/oKIqJ50hwludqgJrfrqfpdmg/71h5Ou3MHcl37M+T3O O7slQ0bFLr70IxZn3GeR8DdUBpr4trVktMwFinFMSc3Mt25mifg= =c+1y -----END PGP SIGNATURE----- --yvqbgsawf3vjytn6-- From nobody Tue Jan 12 07:50:23 2021 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 68BD83A09E0 for ; Tue, 12 Jan 2021 07:50:21 -0800 (PST) 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=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 42a-eIubctsK for ; Tue, 12 Jan 2021 07:50:19 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C48D3A09D7 for ; Tue, 12 Jan 2021 07:50:19 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 760D5600E3; Tue, 12 Jan 2021 15:50:17 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1610466617; bh=uXgK339W4lJDZ8CJxejCYw9+hsLvK95xfC9502OHELE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=PWMen31uedWk5281D85F8kaXKvdGye82QNeuO9sirbZcIUDejVkkQkIphISIexIwH ge9NjaH5p1dkHGBCT9rMaTQ1xYRgZqBxX5SF/EknYzz0yjDPH7Emi4LPM5LJqqJb56 FG9oJP4sd9UVXxOeCBc0EJZHnHx+8jkH2MKg1Z+nqBCDHIOMD78jeeNLrnNwj16uXT fgUIOIVorphrTTKudXJDG5xWRiuOYYxmYXxqWo59wrZ5Q3HwCvQO/hL9FxrUtTrx/6 3/vSzhdrapc+6YqiRd2hJiXpWQqA+Gh5cp6k0KJgVr1lBSBrgoFm0TXMxvEZUmV/Lv EGVCgNPJov0/w== Date: Tue, 12 Jan 2021 16:50:15 +0100 From: Martin Hoffmann To: Ben Maddison Cc: SIDR Operations WG Message-ID: <20210112165015.52a524bf@glaurung.nlnetlabs.nl> In-Reply-To: <20210112145800.nocjbd4millmbx4i@benm-laptop> References: <20201229101412.GA56136@diehard.n-r-g.com> <49a8e314-7b3f-0e8d-6e20-7d055fb1a076@verizon.net> <20201229151639.GD56136@diehard.n-r-g.com> <20201230144836.ytg4u2gobkv4uzqn@benm-laptop> <3BA339C3-EADC-449E-B5B2-7A4880E16EDA@nlnetlabs.nl> <20210112145800.nocjbd4millmbx4i@benm-laptop> Organization: NLnet Labs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] feedback on draft-michaelson-rpki-rta 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, 12 Jan 2021 15:50:22 -0000 Ben Maddison wrote: >=20 > This was kinda the point I was making when I said that I couldn't > think of any use-cases for which multiple RTAs wouldn't work: >=20 > The above logic works just the same if you instead have N RTAs over > the same signed data, and require that the union of `resources` from > each be the same as the set described in the signed data. >=20 > Doing it this way seems to present the advantage of decoupling the > rpki-validation of the CMS blob from the > application-specific-validation of the underlying data. A drawback of this is, however, that you cannot decide anymore whether your document is truly "RTA invalid" or if you are just missing some of the data. Or, turned around, somehow loosing an RTA from the set makes the underlying data seem invalid even though it isn=E2=80=99t. This is quite similar to the situation we have in origin validation where loosing a ROA from the set may make a route invalid. Forcing all relevant data into a single object avoids this problem and makes an invalid a definitive invalid. > Every use case for this will require tooling to perform additional > validation of the signed data against the RTA (at least verifying the > digest, probably more), so this doesn't introduce a new step in the > process, it just moves responsibility for it out of the RTA spec. I=E2=80=99m not sure that is a desirable outcome. In its currently proposed form, RTA processing in its generic, application independent form handles all of the processing related to resources. You give it an RTA and a hash and it returns either a set of valid resources or a validation error. All of the application specific processing can be easily built around that. If RTAs are split, the application has to call into this interface multiple times and then has to decide how to merge the multiple results. That means each application has to define how to do that and both ends have to correctly do that. The work of dealing with resources under multiple parents has to be done. I think doing it once in a well-defined way is a better approach. - Martin From nobody Tue Jan 12 10:46:36 2021 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 8B0853A1022 for ; Tue, 12 Jan 2021 10:46:31 -0800 (PST) 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, 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 B8qG3yAf0WSu for ; Tue, 12 Jan 2021 10:46:28 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDF1A3A0FEA for ; Tue, 12 Jan 2021 10:46:26 -0800 (PST) Received: from smtp.freedom.nl (unknown [10.10.3.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 88A12600E9 for ; Tue, 12 Jan 2021 18:46:23 +0000 (UTC) Received: from smtp.freedom.nl (smtp.freedom.nl [116.202.65.211]) by soverin.net Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id bf80d078; Tue, 12 Jan 2021 19:17:05 +0000 (UTC) Date: Tue, 12 Jan 2021 19:17:05 +0000 From: Job Snijders To: sidrops@ietf.org Message-ID: References: <20201229101412.GA56136@diehard.n-r-g.com> <49a8e314-7b3f-0e8d-6e20-7d055fb1a076@verizon.net> <20201229151639.GD56136@diehard.n-r-g.com> <20201230144836.ytg4u2gobkv4uzqn@benm-laptop> <3BA339C3-EADC-449E-B5B2-7A4880E16EDA@nlnetlabs.nl> <20210112145800.nocjbd4millmbx4i@benm-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210112145800.nocjbd4millmbx4i@benm-laptop> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] feedback on draft-michaelson-rpki-rta 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, 12 Jan 2021 18:46:35 -0000 On Tue, Jan 12, 2021 at 04:58:00PM +0200, Ben Maddison wrote: > > If N == 1 then this does not increase the complexity. If N > 1 then > > there may be some fragility, because any of the paths can fail, but > > it is reasonable to state that if multiple signatures are required > > then it is a requirement that the RTA MUST be considered invalid if > > the validation of any signature or EE certificate fails. > > It arguably also adds flexibility, in that the consequences of having > an incomplete set can be application-specific. In some cases, a > partial set may be useful, in others it may render all the RTAs > useless. > > When I started writing this email, I was mostly agnostic other than > insofar as this may speed-up or delay implementation. > > Having thought about it, I actually think the multiple RTAs pattern is > better than the multiple signer pattern. 1/ We should be cognizant Relying Parties might not have all applicable Trust Anchors in common with each other. Lacking a single common Trust Anchors will invalidate the entire multiple-SignerInfo RTA. Troubleshooting such cases in a multiple-SignerInfo will be harder compared to each RTA object containing a single SignerInfo (and thus is bound to a single Trust Anchor). 2/ The complexity of Multiple-SignerInfo in a Multiple-Trust Anchors context is further compounded when one takes into consideration any additional variances resulting from different X509 Certificate Policies (RFC 6487 & RFC 8360) on different validation paths towards a single multiple-SignerInfo RTA. 3/ I think SIDROPS needs to take a hard look at whether significant increases of complexity are a wise move at this phase of global RPKI deployment. 'Mixing' of Trust Anchor trees at this 'pre-validation stage' is a big unknown for the working group, it has not been done before. Contrary to Martin's comment "The work of dealing with resources under multiple parents has to be done." ... that's just not true, this is not work that *has* to be done, it is entirely avoidable. Given how much problems some validator implementers had in 2020 (and still have!) to just get manifest & CRL basics right, makes me very skeptical about the group's ability to now suddenly perform at a much more advanced level. 4/ Last but not least: if we follow a single-SignerInfo model, all the RIRs/NIRs should be able to fairly easy to implement a web tool for: 'copy+paste attested object's hash here -> click which resource should sign -> download resulting RTA'. Implementing single-SignerInfo RTA at the RIR-hosted CA level can be straight forward, as such hosted services only needs to concern themselves with a single Trust Anchor (themselves) and there won't be passing around of RTAs for co-signing. The RIR-hosted portal also doesn't need to see the actual digital object being attested, just the hash. I fear multiple-signerinfo RTA would see lack of adoption in that part of the ecosystem, and "just use krill" is not the answer. Summary: * multiple people have indicated immediate use-cases for single SignerInfo * multiple people have voiced concerns about multiple-signerInfo * I've expressed a willingness to facilitate a single SignerInfo implementation, but I'm not willing to implement or support multiple SignerInfo. I hope the authors reconsider so we can get down to the business of deploying RTA! :-) Kind regards, Job From nobody Tue Jan 12 10:56:54 2021 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 B1A0E3A0DE2 for ; Tue, 12 Jan 2021 10:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 S4YdHdMdA2kc for ; Tue, 12 Jan 2021 10:56:50 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 586083A0FC2 for ; Tue, 12 Jan 2021 10:56:50 -0800 (PST) Received: from smtp.freedom.nl (unknown [10.10.3.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 7BC44600E9 for ; Tue, 12 Jan 2021 18:56:48 +0000 (UTC) Received: from smtp.freedom.nl (smtp.freedom.nl [116.202.65.211]) by soverin.net Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id c16753a8; Tue, 12 Jan 2021 19:27:28 +0000 (UTC) Date: Tue, 12 Jan 2021 19:27:27 +0000 From: Job Snijders To: sidrops@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [Sidrops] RFC 8360 / 6487 (Was: RPKI Outage Post-Mortem) 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, 12 Jan 2021 18:56:53 -0000 Dear group (specifically George, Geoff, Tim, Carlos, Andrew & Daniel), I'd like to ask SIDROPS to read this message https://www.ripe.net/ripe/mail/archives/routing-wg/2021-January/004220.html (please ignore point 1 & 2 as those are now resolved) What is the current plan to get RFC 8360 deployed at scale? Is this on anyone's radar? The spec has in the making for ~ 8 years and seems to contain a lot of valuable insight. To me RFC 8360 seems to be to RPKI what RFC 7606 is to BGP. A revision to increase operational robustness, except... 7606 actually got deployed :-) Which of the Trust Anchor will be first to flip the switch? Or... do CA implementers & operators consider jumping to the new RFC 8360 codepoint too risky of a move... and should an alternative strategy be devised? Was it (in hindsight) a mistake to not deprecate RFC 6487, but instead specify a new optional alternative policy? Kind regards, Job From nobody Fri Jan 15 03:22:08 2021 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 A5EB83A0B12 for ; Fri, 15 Jan 2021 03:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=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 e1vRZbkxR-lO for ; Fri, 15 Jan 2021 03:22:05 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E0C33A0B08 for ; Fri, 15 Jan 2021 03:22:05 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 18437606C4 for ; Fri, 15 Jan 2021 11:22:02 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1610709721; bh=lJxqn+lxJmSzRSA9XSMYSnsR8/qdKSZhB6r5e/iUIDc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=kswRPHTUSbPvMHWaJNt225YO9m38MdO3zKsoo28s+lyD891vFWNVVK3jxCFdjWSt1 wAbZ1aA022W2NdRKbl7sfTMMa74Rgf5wzAEpWUKumCOeCWhGF8c+HQtXshJHCG/X44 mUVz3NfIt2FvtPaL3OiroWd9eh3S6RsRwkJxPRQsjy2wyxBGRQaTe5SBuuh8EN1e4E C00qQLhMY35twKjxkJM7oadM9PYMv/u4njs2otfNtAShwgtVwtYVauk/QN3yxeRffh 3SNO9XB9b/hsyLLaEq8cbePLkOB+9uvg+u8ORiEXk7gDAJCJj7nKhTpp4JxUAmpbsv fTfydKj2OWNqQ== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Tim Bruijnzeels In-Reply-To: Date: Fri, 15 Jan 2021 12:21:50 +0100 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2528A2B4-D5C6-4803-847E-3D138D4C5E14@nlnetlabs.nl> References: To: Job Snijders Archived-At: Subject: Re: [Sidrops] RFC 8360 / 6487 (Was: RPKI Outage Post-Mortem) 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, 15 Jan 2021 11:22:08 -0000 Hi Job, all, This might be of renewed interest: https://tools.ietf.org/html/draft-va-sidrops-deploy-reconsidered-01 Presented at IETF104: = https://www.ietf.org/proceedings/104/slides/slides-104-sidrops-deployment-= of-validation-reconsidered-00 The 8360 approach had some controversy in the past. But I would be happy = to see a constructive discussion on its deployability. The document = above is an attempt at starting that dialogue. Tim > On 12 Jan 2021, at 20:27, Job Snijders wrote: >=20 > Dear group (specifically George, Geoff, Tim, Carlos, Andrew & Daniel), >=20 > I'd like to ask SIDROPS to read this message > = https://www.ripe.net/ripe/mail/archives/routing-wg/2021-January/004220.htm= l > (please ignore point 1 & 2 as those are now resolved)=20 >=20 > What is the current plan to get RFC 8360 deployed at scale? Is this on > anyone's radar? >=20 > The spec has in the making for ~ 8 years and seems to contain a lot of > valuable insight. To me RFC 8360 seems to be to RPKI what RFC 7606 is = to > BGP. A revision to increase operational robustness, except... 7606 > actually got deployed :-) >=20 > Which of the Trust Anchor will be first to flip the switch? >=20 > Or... do CA implementers & operators consider jumping to the new RFC > 8360 codepoint too risky of a move... and should an alternative = strategy > be devised? >=20 > Was it (in hindsight) a mistake to not deprecate RFC 6487, but instead > specify a new optional alternative policy? >=20 > Kind regards, >=20 > Job >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Jan 15 05:30:23 2021 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 35BF83A0D00 for ; Fri, 15 Jan 2021 05:30:21 -0800 (PST) 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=fastly.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 hPxmkQEj44wU for ; Fri, 15 Jan 2021 05:30:19 -0800 (PST) Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (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 898013A0CFE for ; Fri, 15 Jan 2021 05:30:19 -0800 (PST) Received: by mail-wr1-x441.google.com with SMTP id a12so9263562wrv.8 for ; Fri, 15 Jan 2021 05:30:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=r30X/y6aDipgSRkJ20Ji/X6bxp4JmHEd9ULGFY963gk=; b=L6lh4k30kKoEcK57hU/bc1AJxNLLtbX8qkty49wl4VMYYKPwsPZSyx+qNNng33Aff3 nJVdvOz2AT+wM+UHTb4S6uyfGEvUdlDWqe7/nVjequUcp5CP12w4g0FSG9L8MrzVUdOu cgb+9x5PlU8f6GzwfcP2KIvFLpDNmnBlReIbE= 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:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=r30X/y6aDipgSRkJ20Ji/X6bxp4JmHEd9ULGFY963gk=; b=PW29uCZYSEYYuTNKMK/Ht5lhzyUrlhjOcOD3S4FqCRBlVIqRVD7G743SV3h75QsToh Afqed2POQtI+WBttAp5pefd7oFtgDwUVatGy7AB69Y3+EZov0Ew1w/cWWZF2mHv63Ij+ 6ZOEFY/Uf9rZkcZ21nfxYzDjgv4QnJ8poaGx2D7/RLKzl0aO1pj3fytNf05OfRP0lT5u ZrXspTszZ5IoHSRsGVCRzyEjtnQWu7ZcdGTs2bnMJJ0LQhAJl4AyX83CK5Dbg4IRnfe2 1CJt69zCsBnIy5CsRBPxn/JrP6wgr3z+2giPiR8fGk+gqKJSXvWJGtHJ8BHBL/PQSgoY UuZA== X-Gm-Message-State: AOAM530SetcTcI4excu7FQ7K+Mw2MsO5anvG+EFh46m9r32UxuL1hiZ2 MfymKdX4ykJoiy6xtDOMuT+3r42ntqdJAfNb1EForz6tFF0qWORrev54zy5Et0PRrmh6pXITj4k PPS6meyE9/IeVZWxxljCCOn4Zycrg5NCfpX/sadf+0xIlTKyD9+2+ZkyLxg== X-Google-Smtp-Source: ABdhPJyE8suUjt7FBn+GZ83MTEs6xwpJJJGpIz0BWKkyO8Mgo4RId6VVVGecgP8RhYSLf4Eay8LLlQ== X-Received: by 2002:a5d:40d2:: with SMTP id b18mr12956436wrq.369.1610717417425; Fri, 15 Jan 2021 05:30:17 -0800 (PST) Received: from snel (mieli.sobornost.net. [45.138.228.4]) by smtp.gmail.com with ESMTPSA id c16sm14648942wrx.51.2021.01.15.05.30.15 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Jan 2021 05:30:17 -0800 (PST) Received: by snel (sSMTP sendmail emulation); Fri, 15 Jan 2021 14:30:15 +0100 Date: Fri, 15 Jan 2021 14:30:15 +0100 From: Job Snijders To: sidrops@ietf.org Message-ID: References: <2528A2B4-D5C6-4803-847E-3D138D4C5E14@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2528A2B4-D5C6-4803-847E-3D138D4C5E14@nlnetlabs.nl> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] RFC 8360 / 6487 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, 15 Jan 2021 13:30:21 -0000 Dear Tim, On Fri, Jan 15, 2021 at 12:21:50PM +0100, Tim Bruijnzeels wrote: > This might be of renewed interest: > https://tools.ietf.org/html/draft-va-sidrops-deploy-reconsidered-01 > > Presented at IETF104: > https://www.ietf.org/proceedings/104/slides/slides-104-sidrops-deployment-of-validation-reconsidered-00 Thank you for these pointers, very informative. It is now clear to me rpki-client has some work to do in order to participate in progressing the deployment of the reconsidered validation strategy in some form. It all starts with implementing support for RFC 8360 :-) > The 8360 approach had some controversy in the past. But I would be > happy to see a constructive discussion on its deployability. The > document above is an attempt at starting that dialogue. There being an OID (and thus a role for CAs to play in deploying 8360) is a double-edged sword: one the one hand a large enough CA could attempt to force the market to adopt the reconsidered validation strategy by setting the new OID, on the other hand the CA might not be large enough to pull that off. It seems in the best interest of Relying Parties to not reject overclaiming CAs, and in the best interest of CAs for their constituent Relying Parties to use the revised strategy. I think George aptly characterizes this as a 'community-wide risk'. To me it seems the way the incentives are stacked, deploying a revised strategy /should/ exclusively be a 'validator problem', rather than something where CAs need to take action. However, a new OID having been defined makes deployment a challenge which cannot exclusively be resolved by just upgrading the validators, now it potentially involves tens of thousands of Certificate Authorities. I can imagine how some controversy came to be. Looking at my publication point's log files it appears 95% of relying parties upgrade *at least* once every 15 months. Any deployment plan with *more* dependencies than 'just RPs upgrading their validators', will have to take such numbers into consideration, and unfortunately there is the risk of new (not revised) validators joining the ecosystem in the next 15 months. I have some todo items on this topic, I'll report back later. Thanks again for your information and pointer to deploy-reconsidered draft! Kind regards, Job From nobody Tue Jan 19 21:43:36 2021 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 D2C9A3A0D50 for ; Tue, 19 Jan 2021 21:43:34 -0800 (PST) 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 nZmuYQTUXumN for ; Tue, 19 Jan 2021 21:43:31 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 058B13A0D64 for ; Tue, 19 Jan 2021 21:43:29 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id v67so32538974lfa.0 for ; Tue, 19 Jan 2021 21:43:29 -0800 (PST) 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=qBF/kKwLCiOG0GqQgo4alL+Lfvt7f6i77igWGB4YTQY=; b=VGkHyXcghkmCCTio7TVOYZaJTC0Z78QwRmbU8QGSuLYIPGp+ZXcLM2L0zoZUitPzS3 jiyBJtdjUWhJU2C1+TVVGY4/6ufREs2du9nwYAnrkvv+hAC+VH5VzNjzaKJrKT7Vb1Bo FyQVA17eg9dWdtAA6JfB0RWjvxLlmYvka7vNsAoKl1lcUhjP/FvSyK0fhQOpUJ8pU7FH YjxkcivrtqVADuxCA9RJwJo1912CE/8H2kgALW9JmQh3LMOJLVgpLIpZtONnY5Gc5Isf arFOWnouJ3LDNPAuyojiaaWpEWDdemqdn8Lp11APRCT1580icONGaYjFtKgjCkj9YBJe NbKQ== 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=qBF/kKwLCiOG0GqQgo4alL+Lfvt7f6i77igWGB4YTQY=; b=jiF/LyPwLJYFp3kybd7tB58tq3QpS1NRuR0sM9YCel0UHzMKpS5MK/qTZT6qcY8aEn ysPiTl37r0O8T6RuH/93xTroFq0Yo2UJGhmDpG4nCxtgvib7natKnXD6eFe1RdbP6vAG FFhsi5BT0QwatVCUQgFNWKYUqYFwMph3Qfa/F/lhfTgXbIJJlVS6AnYaMVYryXBbLcnb TMwRy7kXeC6MLnAD+WNPxBjV3HcPBKTTgb+92KvhE63WmLES8YCcQPLhbp0HQRvRR58M QYCkl4vI4Vrzoi7RY88BLxV87+PSC1+P8hLht77uOGLtR+D7pc/4YMF8PikAQplCrN5z vagg== X-Gm-Message-State: AOAM531nT1YZGFiVxK9HmJg3sskWrCu98/PjRG3Wew2tPVtspS/ngqDX eAPKzsz93noYra2Nqq+OVZI1Ur85FqAd6szYUikWkw== X-Google-Smtp-Source: ABdhPJyRCQ40SDHuvuDA444yskq1tbxArO0qSZBSeZmYOOpua7beYbdo38gmK1waUy2Y7wOQnHYwR3vzOQwWNTuwRUM= X-Received: by 2002:ac2:4943:: with SMTP id o3mr674335lfi.384.1611121408041; Tue, 19 Jan 2021 21:43:28 -0800 (PST) MIME-Version: 1.0 References: <20201229101412.GA56136@diehard.n-r-g.com> <49a8e314-7b3f-0e8d-6e20-7d055fb1a076@verizon.net> <20201229151639.GD56136@diehard.n-r-g.com> <20201230144836.ytg4u2gobkv4uzqn@benm-laptop> <3BA339C3-EADC-449E-B5B2-7A4880E16EDA@nlnetlabs.nl> <20210112145800.nocjbd4millmbx4i@benm-laptop> In-Reply-To: From: George Michaelson Date: Wed, 20 Jan 2021 15:43:16 +1000 Message-ID: To: Job Snijders Cc: SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] feedback on draft-michaelson-rpki-rta 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, 20 Jan 2021 05:43:35 -0000 On Wed, Jan 13, 2021 at 4:46 AM Job Snijders wrote: > > On Tue, Jan 12 > Summary: > > * multiple people have indicated immediate use-cases for single SignerInfo I agree. I think there is good convergence to understanding this drive. It is easy to sell the idea of an RTA with only one EE certificate signing its contents. > * multiple people have voiced concerns about multiple-signerInfo I think it is not clear why we want this. I need to try and be clear about this: APNIC operates a set of subsidiary CA under our trust anchor which follow the path of entry of INR into our duty of care. So, for our members in particular, it is not unusual to want to make assertions about "all my holdings" which innately demand more than one CA be brought into play. This is not multiple signing entities, it is one entity, controlling a set of EE certificates which are neccessary to make the signing assertion over the list of INR related to the context. It is true that when we designed RTA we did design it to encompass discretely different entities (people) sending a cryptographically verifiable statement of intent or meaning which bound them together mutually. So, we still see utility in this, but I understand how people in routing contexts don't see that right now. But, the thing is we are not looking to solve only routing-active (BGP) problems in RPKI: we are looking to provisioning and other contexts, where it would be logistically hard to have to deal with a number of discrete parts to be assembled to make the assertion, compared to being able to use one: An example here is the JSON submission path in BYOIP, which really expects a singleton to be passed in. in APNIC, neccessarily, this is a set of EE signing. > * I've expressed a willingness to facilitate a single SignerInfo > implementation, but I'm not willing to implement or support multiple > SignerInfo. Job I think this is an unhelpful assertion. Of course you own your own code, but choosing to ignore work which is well formed, ASN1 and is capable of being multiple signing EE certificates is I think wrong. We have two valid inter-operable multiple signing implementations already. If you could reconsider, and at the very least demonstate that you can manage a singly signed instance, but inside the wrapper in ASN.1 which is innately capable of being multiply signed, I think it is very likely this will permit well formed, singly signed things to become normal inside this form of CMS which can be used by other people to say things which demand multiple signings. I can easily conceive of things in ASPA or customer-cone which could benefit from tying somebody else's AS and the IP, which innately demand both partys signal intent. You just said you are not willing to think about implementing improvements to routing security which could leverage that. > > I hope the authors reconsider so we can get down to the business of > deploying RTA! :-) I very much hope you re-consider, and understand why we have chosen to retain multiple signing capability in the CMS wrapper: We see a lot of problems with demanding asset holders go into multiple, discrete, unrelated assertions to declare intent over the whole of their holdings, and we think this is a situation which is very likely to become more common, especially as people become bound into inheritance of INR which lie in different regions, but one ASNs assertion of routing. Russ Housely has been kind enough to act as an ASN.1 "expert" and reviewed our logic, and made some changes in the formalisms of how we declare the ASN.1 for the CMS, but without changing the on-the-wire encoding. I have included this in the 00 revision, posted to the WG under the WG name. cheers -George From nobody Wed Jan 20 01:21:57 2021 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 A19823A0D14 for ; Wed, 20 Jan 2021 01:21:55 -0800 (PST) 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=fastly.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 gzjCNV3Pb3as for ; Wed, 20 Jan 2021 01:21:54 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 503283A0DF3 for ; Wed, 20 Jan 2021 01:21:54 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id y187so2159309wmd.3 for ; Wed, 20 Jan 2021 01:21:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=z9xhpmuOmkssFIx3y4zhi0peEwa2odNEmHYsiQg7G6Q=; b=SKSxOMln4LVzDT4dhiHUIDQsGhqcf+CdgBnHIscPtf05CwweBrkBKm4vOP91vUvRrX 2Bi+pgQ6SL+ADz3BaUTg114/hzGYmDV5p/UoQSYxhJPGKzDkPOJk0mFUR+IMmSND6PWy B8nPO/XYc5qjeF2cak/+SvaA/F50RUUSpl4j8= 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:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=z9xhpmuOmkssFIx3y4zhi0peEwa2odNEmHYsiQg7G6Q=; b=kY+jvpweqHTR61rpjfhR0mNA2KzwEbG0ipDKinzh9bVsduW56OAD8KKylUYQr74wxd 3nd0W1Oxzp9cF3+evspZz6DPndf/xk6uhv06mfpWDBOn54fS67le1wO8nwpErMeB+uHW N7jdd/V6ohFeR1uhblEg0cV/fBIRXD3WRMjUvNkch/zsio1U88BxsNu1ViFHCU/VfR3W al0LgvroIjluT151qiQ6UO+JyG2NXfmY1jea63SdeyM2Hj+eTAbyu1XLzOK5ccc7PULM u1tFGVES+eC9hYvymqCP/zkp6FcOHGzVsvGL9+Ub13nwdH9sXGm1X50VpF+zoLOvj6fy 4pLA== X-Gm-Message-State: AOAM531PI0F4LnVBPYwNYwCBfEOHtTHruBs9w/LJ1EtaMm7P4wF949OP H+vr0+ByPOwZtz1pGeU6yD2LaD37GT1L+Tj3MkZ5MGEAkjadBVYD0N6QTGNBrEImNWZx11nFj3n 8RKdvu+KKmU2COJHaOlJA5a2JQq4vZuITjGNFPJCjcgU3XG4QWs74RH955Q== X-Google-Smtp-Source: ABdhPJyU/q878KLcGP9bLlqsvGrJXTgWUVmtUgMpiqum8yDpqmjszgcOtamXEJ5MPAl0du+5PwEOqQ== X-Received: by 2002:a1c:6208:: with SMTP id w8mr3502252wmb.24.1611134512271; Wed, 20 Jan 2021 01:21:52 -0800 (PST) Received: from snel (mieli.sobornost.net. [45.138.228.4]) by smtp.gmail.com with ESMTPSA id w4sm2755889wmc.13.2021.01.20.01.21.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Jan 2021 01:21:51 -0800 (PST) Date: Wed, 20 Jan 2021 10:21:49 +0100 From: Job Snijders To: sidrops@ietf.org Message-ID: References: <20201229101412.GA56136@diehard.n-r-g.com> <49a8e314-7b3f-0e8d-6e20-7d055fb1a076@verizon.net> <20201229151639.GD56136@diehard.n-r-g.com> <20201230144836.ytg4u2gobkv4uzqn@benm-laptop> <3BA339C3-EADC-449E-B5B2-7A4880E16EDA@nlnetlabs.nl> <20210112145800.nocjbd4millmbx4i@benm-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] feedback on draft-michaelson-rpki-rta 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, 20 Jan 2021 09:21:56 -0000 Dear George, On Wed, Jan 20, 2021 at 03:43:16PM +1000, George Michaelson wrote: > We have two valid inter-operable multiple signing implementations > already. I hope you will document these efforts and share with the group an implementation report outlining the interopability characteristics. I've requested both signing implementers for validatable samples of a singleton-SignerInfo and a multiple-SignerInfo RTA. So far I received only one singleton-SignerInfo RTA (thank you Tim!). Can you or anyone else share with me a multiple-SignerInfo RTA validatable through a single common Trust Anchor such as the APNIC TA? Can you or anyone else share with me a multiple-SignerInfo RTA with signatures from multiple CAs under multiple common TAs (RIPE + APNIC)? Kind regards, Job From nobody Thu Jan 21 14:42:48 2021 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 4DFB23A02BC; Thu, 21 Jan 2021 14:42:47 -0800 (PST) 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: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <161126896728.10607.1268293191442965109@ietfa.amsl.com> Date: Thu, 21 Jan 2021 14:42:47 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-rta-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: Thu, 21 Jan 2021 22:42:47 -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 : A profile for Resource Tagged Attestations (RTAs) Authors : George G. Michaelson Geoff Huston Tom Harrison Tim Bruijnzeels Martin Hoffmann Filename : draft-ietf-sidrops-rpki-rta-00.txt Pages : 13 Date : 2021-01-17 Abstract: This document defines a Cryptographic Message Syntax (CMS) profile for a general purpose Resource Tagged Attestation (RTA), for use with the Resource Public Key Infrastructure (RPKI). The objective is to allow an attestation, in the form of an arbitrary digital object, to be signed "with resources", and for validation to provide an outcome of "valid with resources". The profile is intended to provide for the signing of an attestation with an arbitrary set of resources. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-rta/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-rpki-rta-00 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rta-00 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 Thu Jan 21 14:55:27 2021 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 6A3F03A0AE1 for ; Thu, 21 Jan 2021 14:55:25 -0800 (PST) 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 F9NMuQEApc3i for ; Thu, 21 Jan 2021 14:55:21 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 038E23A0ADD for ; Thu, 21 Jan 2021 14:55:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8F77E300B22 for ; Thu, 21 Jan 2021 17:55:18 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id k0kAfgYjHRrH for ; Thu, 21 Jan 2021 17:55:17 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 26B93300512 for ; Thu, 21 Jan 2021 17:55:17 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Thu, 21 Jan 2021 17:55:18 -0500 References: <161126896728.10607.1268293191442965109@ietfa.amsl.com> To: sidrops@ietf.org In-Reply-To: <161126896728.10607.1268293191442965109@ietfa.amsl.com> Message-Id: <2C62020A-117B-4410-8813-91CAD514A749@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-rta-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: Thu, 21 Jan 2021 22:55:25 -0000 The ASN.1 module compiles after replacing "TBD" with a reasonable = placeholder. Russ > On Jan 21, 2021, at 5:42 PM, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > Title : A profile for Resource Tagged Attestations = (RTAs) > Authors : George G. Michaelson > Geoff Huston > Tom Harrison > Tim Bruijnzeels > Martin Hoffmann > Filename : draft-ietf-sidrops-rpki-rta-00.txt > Pages : 13 > Date : 2021-01-17 >=20 > Abstract: > This document defines a Cryptographic Message Syntax (CMS) profile > for a general purpose Resource Tagged Attestation (RTA), for use = with > the Resource Public Key Infrastructure (RPKI). The objective is to > allow an attestation, in the form of an arbitrary digital object, to > be signed "with resources", and for validation to provide an outcome > of "valid with resources". The profile is intended to provide for > the signing of an attestation with an arbitrary set of resources. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-rta/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sidrops-rpki-rta-00 > https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rta-00 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Jan 21 15:13:43 2021 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 8CF7F3A0C6C; Thu, 21 Jan 2021 15:13:41 -0800 (PST) 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: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <161127082151.21120.11094489854098963782@ietfa.amsl.com> Date: Thu, 21 Jan 2021 15:13:41 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-rov-timing-01.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: Thu, 21 Jan 2021 23:13:42 -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 : Timing Parameters in the RPKI based Route Origin Validation Supply Chain Authors : Randy Bush Jay Borkenhagen Tim Bruijnzeels Job Snijders Filename : draft-ietf-sidrops-rpki-rov-timing-01.txt Pages : 8 Date : 2021-01-21 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-rov-timing/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-rpki-rov-timing-01 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rov-timing-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rpki-rov-timing-01 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 Thu Jan 21 22:21:14 2021 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 25D8F3A0E3B for ; Thu, 21 Jan 2021 22:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=SxD1RULb; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kJwowx+o 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 GC1SORC4O9yL for ; Thu, 21 Jan 2021 22:21:09 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A558F3A1113 for ; Thu, 21 Jan 2021 22:21:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10829; q=dns/txt; s=iport; t=1611296469; x=1612506069; h=from:to:subject:date:message-id:mime-version; bh=zOS4CnaHO50ZOUAaw7hvcTBdIyyJ8atDzd/aFUmaZEQ=; b=SxD1RULbkKtf5gn3ZuFPBHyQglTz9sr7dkWHrFI9Y6ruLe+Qu1x2IzWJ 0ls9zVTiE565kJZ4dIjhEu7h64tG7OUR9iZaVuNu4etxq+7zlEkTfr6zh jLlzU1NoMVFIMkIhg3wLBoHL6D4YduWrINu5AuLwlheVlSGkCU/ItDJh2 g=; X-IPAS-Result: =?us-ascii?q?A0C0AAB5bApg/5BdJa1iHQEBAQEJARIBBQUBQIE8BwELA?= =?us-ascii?q?YEiMFEHdlsvL4gIA44MlCaEc4EugSUDVAsBAQENAQEjCgIEAQGESgKBdwIlN?= =?us-ascii?q?QgOAgMBAQEDAgMBAQEBBQEBAQIBBgRxhWEBC4YnEwEBOBEBgQAmAQQbgx+Bf?= =?us-ascii?q?lcDLgEOpm8CiiV0gTSDBQEBBoE3AoNYGIIRAwaBOAGCdYZQhBobgUE/gRFDh?= =?us-ascii?q?XEBAQOBXiuDIIIsgzAUJAMWAhdudiIsmlWMOZE/CoJ3iS+SW6Jvj26EL4scl?= =?us-ascii?q?jUCAgICBAUCDgEBBoFXATiBV3AVgyRQFwINjiGDcYUUhUR0NwIGCgEBAwl8i?= =?us-ascii?q?iNcAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3AOa3Vox+wI9ZRq/9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZRaN5PhxghnOR4qIo/5Hiu+DtafmVCRA5Juaq3kNfdRKUA?= =?us-ascii?q?NNksQZmQEsQavnQU32JfLndWo2ScJFUlI2/nynPw5SAsmtL1HXq2e5uDgVHB?= =?us-ascii?q?i3PAFpJ+PzT4jVicn/1+2795DJJQtSgz/oarJpJxLwpgLU5cQ=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,365,1602547200"; d="scan'208,217";a="630748857" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jan 2021 06:21:06 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 10M6L5fQ009853 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 22 Jan 2021 06:21:06 GMT Received: from xfe-aln-003.cisco.com (173.37.135.123) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 22 Jan 2021 00:21:03 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Fri, 22 Jan 2021 00:21:03 -0600 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 22 Jan 2021 01:21:02 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N6Nj4aXYJw/8DCTV5Lzyn4/HrAkp3S2q4H8RawE4p8PsFcbmmBFaz1X7iDuWVKPfcRmbSthJn/3W95RVglY+s0UHVuXwtepUVS9K8hg1v6G6vGmVNpfaV3i9Eoc3B+I7AuCJvii2PKohqxZwTF3tyPn/ETCQVlpaZgSsCNDBfGwmf0/ctR1UlwxmxZnUy0hBL5mPkGKxe+8vzehWGAMIWGhPm7fbxv9GG4LSo0EOgg80tXsu6srtCrcseu4ZOr6SdJS4VUSp9D6NkuFUfArVgDkePi8+67002+2nqpfXZUvHby9lNgURRszTJZ1UfZ1WKKHvXk1fczWnjkpdeCcI0Q== 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=x9OuuJC6OJyguUF1xNFo4BynGqgiSK0TyNBlS5J57C4=; b=KenyPE1vAu4km+N47Vo/RCYyuIWbIcIu3CwDR6reUHN5aLp8MCr8eg08Slj+5puU/aexQ7UCPV4bBBDhpuUlwFCDV9IYrPz6aHLEdxB0o59cXOM42qRxeQ22V/0ZLGhvKc0EonZefSqHvRNnkkIhOzdbBHS3h6ywL3hsJTiC8HxEJEl0fzWXyJ1mp9U7GltWQC2nRCkIEQC7E6ZgYd+DJMjtAudJc6k1uvEGxt8zK0mRaW5RGQEocNqsB+CODBVJSnOK80MesT5R9jPFbVBapXlCPNy5tJ+8NU4qDp4Qmsa6CXRYJVmoiQl7tlqnc4eYNZErKRd/JmMu++CGIyzLDw== 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=x9OuuJC6OJyguUF1xNFo4BynGqgiSK0TyNBlS5J57C4=; b=kJwowx+o49oePunAZpNZFJHiQQ2xvL1UWVBIOMIOUsWW/BIWdyfNMGstUsZ2jtFiLyBqQ0D/InQMTECOXns1sXj1VviRz6Z6DfKSpShki0GFlEv9d6VoBBuhsSvCCkcU4hsjaegLl1int3Il2riqlSy9kC53jYChzIhpD8KJodI= Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by BY5PR11MB4193.namprd11.prod.outlook.com (2603:10b6:a03:1c8::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.13; Fri, 22 Jan 2021 06:21:01 +0000 Received: from BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::2581:444d:50af:1701]) by BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::2581:444d:50af:1701%4]) with mapi id 15.20.3784.014; Fri, 22 Jan 2021 06:21:01 +0000 From: "Jakob Heitz (jheitz)" To: "sidrops@ietf.org" Thread-Topic: ASPA verification algorithm error Thread-Index: AdbwhlK9z1axTpzkRWyI9nY082H2KA== Date: Fri, 22 Jan 2021 06:21:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2601:647:5701:46e0:7da1:c99e:fdf4:e3c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: efb88127-dc25-4c9d-4c10-08d8be9de424 x-ms-traffictypediagnostic: BY5PR11MB4193: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BH7tungeSTO5mIPvR4AHqOpJdhRTtCu/MTesrsWsV03+lHeB4wN5iOf4LbuJtwSOuON4ST/2zyrUtMIRrF08cfO20vcHd16XnBQEtYQ8OYVU5igRqO87riuvk1fslb8S5iOftS5oYodEvsjSXjJN/Z+JuTAXeNnVyDCTGSikvpljg313lz6sF0w/92W0G0pZpqhW0yYll4fcQ3K7vUR0oBCcwSoQqY1s9GPn6apReNneQDcPxXPXtg4t0gR55qQxUy59DcXEhIOJG72ptx3o1MS+IJmtylCFMsR0hWHzzsgjGxEHJE3dcT4VtXK2Cz84jfyToGYfNVNh64atOB68d4tKIcd6shZQr6wFv0p6EAf5+dRi7RJLsbf5hbbAZmT+PDUye2AUc5/xHz5c/qOmX0GmRppig/15cpHXiuoWi61txgWQcUQoAdofXMPnHPk1fvjXXz6WaFc8mxo1tuJCtg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3207.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(136003)(346002)(366004)(376002)(396003)(66476007)(7696005)(5660300002)(71200400001)(6506007)(8936002)(66946007)(64756008)(76116006)(66556008)(86362001)(316002)(66446008)(8676002)(3480700007)(15650500001)(478600001)(186003)(83380400001)(166002)(52536014)(9686003)(6916009)(2906002)(55016002)(33656002)(966005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?ISe3MAEBigjDuzZ+0A/11CmLldMppBc08SeMK1PcSUYlVkkHCdj/57vZex/X?= =?us-ascii?Q?UOlcSK2H2+fnAFK7jBIbukQf9uQlBwOBYjM8eufQU5H4A78qrs6neBEATgQZ?= =?us-ascii?Q?1oo74nCOlt1VG1lMdJdCZ2nHThYs9YUtPRXj23ThEvoAto6wdZhanwISDqN2?= =?us-ascii?Q?b3bLaQEm5Be8R94XPBFbGhkx4+cXZlXLLEqT0mP49nQjC1l1lau0XWv8Jiy3?= =?us-ascii?Q?zUPWl4+XDMbX3bMCZq1U41jnteUZHJdnnXLF9E5UFSZiu+/GwAXuDdsGKOhD?= =?us-ascii?Q?KqX5Fq/fZClJ5nb2rnMxiWO2oMtD+ZDPz0UMA0ZlvpBno6S2ROk6wbIFVmIx?= =?us-ascii?Q?BeZTPmcEUUQ13e9Eu7VUxnX24AXZoVSoRz4DVPxzBy5YezaMyieO7qLRyAab?= =?us-ascii?Q?9H5Vma0mIMlxvTCahf5KPoJ7yT1NQ2AXSE5CLEGNo/YiSnwLYM2ERyYwIlOC?= =?us-ascii?Q?b/lWVGDX0sZGxTXcIz31LZqjSiT9pctuR8Ldg64aWQpOEB5BHAfWmWpwumFd?= =?us-ascii?Q?Dss+/uvwOtqn1l27GAI2ZzNlKiVWrHmKYh9j1EQVcoq/Y+F9jy7Y5wPzXWiy?= =?us-ascii?Q?cYd4tLAbMYqWQ1kQDPEFHjbZxLy3WLMcIQ1ys32ctD1pEW+MBtreeF57TZ9f?= =?us-ascii?Q?7IfTdNgVs+h/NVWr7etqUtIhRXXbm4FrH+ugAb3Bu+jIuIdn69aCcqK4ne3w?= =?us-ascii?Q?2vuziIwRAcoJZ7r+fmdyDZKD9dc/qu1mGU07Fx6PIPKHDRv5zEs9crXcTPxZ?= =?us-ascii?Q?bT86eIspDH/38DQRKI1aOPRM07IjFnNFy26+Q2JXR1RzoU98uGn9pnIeZ5v0?= =?us-ascii?Q?/Hnyr7gYA09dal4tFQ9BQrlAUyy1AMsw/G/ORPjIXXl30pRngkxRNPGwCL55?= =?us-ascii?Q?aOl6npQZTUm1vWr2F8Ym6xY1SGyxFPhEJvyHD1gRaFbu7nBmmW+2ekh/U8UE?= =?us-ascii?Q?QfYySEl9imj5Js/mVc58q6THmW5PPqDdsPdk689LDaq4xmwgJxI8mGlikK4x?= =?us-ascii?Q?3VVzw7JKgK00WLMCYmfPATUCXNsr1efsSa8WGjBb2tdcMXI=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR11MB320714401DE9AFBF5D24C832C0A09BYAPR11MB3207namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3207.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: efb88127-dc25-4c9d-4c10-08d8be9de424 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2021 06:21:01.8292 (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: aeSPX0vLWXaw5QAk1zHuOdavmRyIIErSqLG/Z/YboGG59sKUx2ql/JZownU9GR6ssN1odFlPvYVtl9BSzvbfzQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4193 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: [Sidrops] ASPA verification algorithm error 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, 22 Jan 2021 06:21:13 -0000 --_000_BYAPR11MB320714401DE9AFBF5D24C832C0A09BYAPR11MB3207namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Consider the as-path (1 2 3 4), where 1 attests that 2 is its provider 4 attests that 3 is its provider 2 and 3 make no attestations. Then the path is valid. The algorithm in https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verifi= cation-06 would incorrectly return "unknown" Here is a working algorithm: * The received AS-path is prepared: * Remove duplicate ASNs. * Prepend own ASN. * May also prepend Forwarded-to ASN to detect own leak. (optional) * For every sequence (A, B, C) of consecutive ASes in an AS-path: * If A attests that B is not a provider and C attests that B is not = a provider, then B leaked the route: B is transiting for free. The segment is invalid. * If either A or C attests that B is a provider, then the AS-path se= gment (A, B, C) is valid. * Else if either A or C make no attestation, then the leak state is = unknown. Even if B lists both A and C as providers, it is not necessarily a= leak, because either A or C could consider B as a provider for some of the= ir routes, even though they don't attest to it. * If all the path segments are valid, then the whole path is valid. * If any of the path segments is invalid, then the whole path is invali= d. * Else, at least one path segment is unknown and one more rule must be = applied: for any sequence of ASes (A, B1, ..., Bn, C), if A attests that B1= is not a provider and C attests that Bn is not a provider, then the AS-pat= h is invalid. This is for any number of Bx greater than 1. Regards, Jakob. --_000_BYAPR11MB320714401DE9AFBF5D24C832C0A09BYAPR11MB3207namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Consi= der the as-path (1 2 3 4), where

1 att= ests that 2 is its provider

4 att= ests that 3 is its provider

2 and= 3 make no attestations.

Then = the path is valid.

The a= lgorithm in https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-06

would= incorrectly return "unknown"

=  

Here = is a working algorithm:

=  

  • The received AS-path is prepared:<= /span>
    • Remove duplicate ASNs.
      • =
    • Prepend own ASN.
    • May also prepend Forwarded-to ASN to detect own lea= k. (optional)
  • For every sequence (A, B, C) of consecutive A= Ses in an AS-path:
    • If A attests that B is not a provider and C a= ttests that B is not a provider,
      then B leaked the route: B is transiting for free. The segment is invalid.<= o:p>
    • If either A or C attest= s that B is a provider, then the AS-path segment  (A, B, C) is valid.<= o:p>
    • Else if either A or C m= ake no attestation, then the leak state is unknown. Even if B lists both A = and C as providers, it is not necessarily a leak, because either A or C could consider B as a provider for some of their routes, even thoug= h they don’t attest to it.
  • If all the path segments are valid, then the = whole path is valid.
  • If= any of the path segments is invalid, then the whole path is invalid.<= /o:p>
  • Else, at least one path segm= ent is unknown and one more rule must be applied: for any sequence of ASes = (A, B1, ..., Bn, C), if A attests that B1 is not a provider and C attests that Bn is not a provider, then the AS-path is invalid. This= is for any number of Bx greater than 1.

=  

=  

=  

Regar= ds,

Jakob= .

 

--_000_BYAPR11MB320714401DE9AFBF5D24C832C0A09BYAPR11MB3207namp_--