From nobody Mon Feb 1 07:08: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 891033A1243 for ; Mon, 1 Feb 2021 07:08:13 -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, RCVD_IN_DNSWL_BLOCKED=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 HB-7wlXy2jRw for ; Mon, 1 Feb 2021 07:08:12 -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 5CDAA3A1209 for ; Mon, 1 Feb 2021 07:08:12 -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=F0ynNA0QRJ0h3qhCIP2t0whg5IjgDVb2SstuWjFM84c=; b=VvGoOXaTHJ+WvZJ2DbLxig Ap5gE1gvxVgpeV1f96Hed/4gFjh7dR4z09jOTnoorkSb5AiZGoJKxZGhFC+om/6rLPmXmgVFkb/3U uXmO8eOT79ZP9wMNL0DX3gqa0Gom5f0pGy80jQPF6y6gbyKnbjU2hGGAONdlGW5Fr3+SykbMXtjEW gY7pNDzbR2b9pTta8fYXouLaTbGiXrI7b3OZN4ri+RAZzKWvo3szUkObP4GBLt/0lsbmhn5+O6GDk /NKzpVkL8oYT23Oc75oydINi8sMS/88ZguHcUXiCgEk73T8Nx364Xm1hSV5HVVyNyCIR8qUO+MIkO Jm15mG2cUfJg==; Received: from bufobufo.ripe.net ([193.0.23.13]:34348) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1l6aoF-0002I7-1t for sidrops@ietf.org; Mon, 01 Feb 2021 16:08:11 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::4a6]) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1l6aoE-0004uk-Pw for sidrops@ietf.org; Mon, 01 Feb 2021 16:08:10 +0100 From: Nathalie Trenaman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Reply-To: SIDROps Chairs Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: Date: Mon, 1 Feb 2021 16:08:10 +0100 To: SIDR Operations WG X-Mailer: Apple Mail (2.3608.120.23.2.4) X-ACL-Warn: Delaying message X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a599a04071ee0ded260b4040b5e4496cc Archived-At: Subject: [Sidrops] IETF110 -- Online -- Call for Agenda Items 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, 01 Feb 2021 15:08:20 -0000 Hi all, =20 SIDROPS will meet online at IETF-110 from Monday, March 8th till Friday, = March 12th from 12:00 - 18:00 (UTC).=20 The exact meeting slot for SIDROPS has not been announced yet.=20 Please forward any SIDROPS agenda items you may have to Chris, Keyur and = me.=20 =20 Regards, Chris, Keyur and Nathalie= From nobody Tue Feb 2 07:57:15 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 E8C163A1BE3 for ; Tue, 2 Feb 2021 07:57:13 -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 55Ie6_shyzUl for ; Tue, 2 Feb 2021 07:57:12 -0800 (PST) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (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 E35273A1C79 for ; Tue, 2 Feb 2021 07:57:04 -0800 (PST) Received: by mail-wr1-x444.google.com with SMTP id v15so21043169wrx.4 for ; Tue, 02 Feb 2021 07:57:04 -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=3cxFw4J3uYAvDsvkhcNssDltARZXHKsySAQd9yVukPA=; b=wyprcMzTOnw3NrBC9QcUNrT3WQ4D3yAV/yLHq+vuOIuULTubPU58GBkdQUFXaDr74x caDmE2nhTglzAL7olw0Gf2Rc/N6Hxx6GUzDN3lEdum/3ZxxnjI0MKlqBNXqyMd6ddmqE W4XMWHP7fV2yuBlAv5yNBnhTv9dTDczH+ikP8= 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=3cxFw4J3uYAvDsvkhcNssDltARZXHKsySAQd9yVukPA=; b=ePgJqgZ/wwERvu4KEKSwi/mZRJVhW5bI3VvFcSsZDfg340lcITd926/R1f+XvqVDa5 o1I9kqvQsPBAUykc18xQ9bQ+EkBw39h1Y12c2Mf4a56T+Fb9GhuhXeV4AWiSaqX2JlLL zcyTAWhJfecILvJH8eFqfrtwLy0AHyV/pvHKO11RX+A+0SK0Cv5M03y3Qg6Jv6MC/2m6 bGtBQleQ+n2LK0uTdcmJD9D30ZFNDzUe+l1UrcnMa43zL12wGCKtYyOsN6l5Iyrn957x k6EWez1AWhe5mLMWDKp9sVwmmP7MYu+0vmPbpw+KhvxGbBg8vNyDcnm1Ga3y9Um5uDjJ CZUA== X-Gm-Message-State: AOAM533GLRwHHF/xYnOJJwp5Fy563ccqTcO/mfWmIrb2CKGmWHICw4ei RK7JhEvdhGA1W6WExF+FWyEzcMKTdHHPosSMUL5J+/tzWwenaXNkryrV/H6ffgLo/qpcKxXipH6 ZfQd0AeGtU4zzJZ9iPIa5mQONjtkanfp8Ho+bxRBbu7xlIU0+qN/BdtdoQg== X-Google-Smtp-Source: ABdhPJxqcscsuEQdisNl6Or2WVvVc0zFdlH2HH3BH5fJU/B7JUgk8VhXEYPOe+r8VlbbRwXXSXIVVw== X-Received: by 2002:a5d:50c1:: with SMTP id f1mr24960910wrt.235.1612281422789; Tue, 02 Feb 2021 07:57:02 -0800 (PST) Received: from snel (mieli.sobornost.net. [45.138.228.4]) by smtp.gmail.com with ESMTPSA id t8sm3445258wmq.36.2021.02.02.07.57.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Feb 2021 07:57:02 -0800 (PST) Date: Tue, 2 Feb 2021 16:57:00 +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: Tue, 02 Feb 2021 15:57:14 -0000 Dear group, authors, I've consulted with various subject matter experts, and at George's request I again reconsidered. Unfortunately I could not arrive at a different conclusion about the current RTA proposal, it is too complicated for me to support. It appears I'm not the only one questioning the current RTA approach: Tim offered a very insightful and honest write-up [1], I'll cherry-pick from what he and others wrote: "It is true that requiring single signing for RTAs simplifies the specification." Stephen Kent states [2]: "Your characterization of the added complexity and validation failure possibilities is worrisome" Fredrik Krosback says [3]: "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." Rob Austin on RFC 6488 (August 2010) [4]: "As an implementor I really want to use a common code path to validate the common portions of all objects of this general form, and would really prefer a single specification of what that code should do. :)" Richard L. Barnes (August 2010) [5]: "This document (red: RFC 6488) seems like a good approach to maintaining some sort of long-term architectural sanity in the RPKI, maybe even something that could simplify tool-building." For rpki-client (and I suspect FORT and OctoRPKI too) the above statements hold true: I think single-signer RTA can be implemented in a relatively short span of time (repurposing existing code such as the ROA codepaths). On the other hand multiple-signer requires significant refactoring. As for the suggestion to just not support RTAs produced by multiple-signers: I'm not comfortable with latent capabilities, this is security orientedd software after all. Today's latent capability is tomorrow's landmine. So... if the authors wish to deviate from RFC 6488, are they willing to do the real legwork and write 6488bis to change the below part? "Additionally, the SignerInfos set MUST contain only a single SingerInfo object" If the authors really wish to continue RTA with the innate ability for multiple signers within a single RTA object, I'll step out of the way. Endless bickering does not help us here. However, I hope there will be understanding if I spin up a 'competing' draft to address a similar solution space as RTA covers, this time in full compliance with RFC 6488. OIDs are cheap and the market usually favors simplicity. Kind regards, Job [1]: https://mailarchive.ietf.org/arch/msg/sidrops/pSIibdv-x7NgV1D9tDBx1HvYTTo/ [2]: https://mailarchive.ietf.org/arch/msg/sidrops/gx5SQI8DzRFnU2DZrZdH6rdW8Tc/ [3]: https://mailarchive.ietf.org/arch/msg/sidrops/hNKSvMFXIQzbH5TsiDgFqy-lqpE/ [4]: https://mailarchive.ietf.org/arch/msg/sidr/Zo3Hg1AwqqUi4tD1fWmd2aqTANU/ [5]: https://mailarchive.ietf.org/arch/msg/sidr/esWy85UvfjvO7N95pfZHBYQGOVY/ From nobody Tue Feb 2 08:56: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 0AF663A0C03 for ; Tue, 2 Feb 2021 08:56:22 -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 ncW7detofuBs for ; Tue, 2 Feb 2021 08:56:16 -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 7989B3A0C06 for ; Tue, 2 Feb 2021 08:56:16 -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 566E7601B3; Tue, 2 Feb 2021 16:56:14 +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=1612284973; bh=01/Glh2CSkUEuxR45rni9f08jr7IISfnfwP61LcUKJc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=f0WWrbniwk5Ybk2l/1WdTLe3djxiNnL4OKa0Zp3ksK/4ZWKV0ID0O0u9M4uHY9mhb H8ZzGNNO7sQ7uNNWgXXtxMBhV2XO7v45LB3/wyiublQHL+j8gAt8agD1VKuey30LUQ 1rIb4iMpzKZxirtbFhLKO2Qw81vCPap6ocno2E6DuX4hc6Sqe2rnpPfpgCEZJITVOX d2WzxWmDCbe44qDFmpAYcjRt0AqDIFfZcjy4+Zvz61VBcG6SHS3m8DBHdKhU628uw1 wmTWqR5WRzawFRE+30K+ryjeTSMF/xI4mxzPqA6hwGX6C5PeljjEVNP15DF6mRM5Vz cWXzu0hqoGebg== Date: Tue, 2 Feb 2021 17:56:08 +0100 From: Martin Hoffmann To: Job Snijders Cc: sidrops@ietf.org Message-ID: <20210202175608.0e8a58cb@glaurung.nlnetlabs.nl> In-Reply-To: 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, 02 Feb 2021 16:56:22 -0000 Job Snijders wrote: >=20 > I've consulted with various subject matter experts, and at George's > request I again reconsidered. Unfortunately I could not arrive at a > different conclusion about the current RTA proposal, it is too > complicated for me to support. There=E2=80=99s a detail I would like to point out: You can only use the existing software more or less unchanged if you distribute RTAs through the regular RPKI repository system. I think doing so is a bad idea for two reasons. For one, an RTA is an exchange between a very small number of participants -- typically just two --, but distribution via the RPKI repository system results in every single relying party having to downloading the object. That strikes me as rather wasteful. At the very least relying parties need to download the object and calculate a hash over them to determine whether the manifest is valid. Every one needs to do that. Yet only really one or two parties actually care. Second, distribution through the RPKI repository is actually quite cumbersome as it involves a kind of break of gauge: You exchange documents in whatever way you choose (likely some kind of HTTP API) but then have to stop, fire up an RPKI relying party tool and wait until it sees the promised object. Because there uncertainties in timing of RPKI publication, you need to be prepared to wait for quite a bit. If, conversely, the RTA can be distributed by any other means, i.e., it is just a file, it can be transferred as part of your document exchange. Bundle it with your document for automated processing or upload it manually via a browser. No waiting involved: both parties know that the RTA has been transmitted. But if you allow that, you can=E2=80=99t use RFC 6488 signed objects anymor= e -- or, well, not properly since at the very least you don=E2=80=99t have the a signedObject SIA rsync URI anymore. (And yes, the current draft glances over this fact.) So, if you have to change your code anyway, why not allow it to deal with a legitimate, existing use case? In addition to allow multiple signatures, the draft also allows the signer to include all necessary certificates and CRLs so that for validation you wouldn=E2=80=99t even need to access the RPKI repository sys= tem at all. Needless to say, doing that requires quite a bit of different code but, I do believe that this is worth it, as it seriously streamlines any process that involves validating RTAs as it can now be done in a library pretty much without keeping state. =20 - Martin From nobody Wed Feb 3 05:32:06 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 CC9CB3A09B5 for ; Wed, 3 Feb 2021 05:32:04 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_Klyckl4xfm for ; Wed, 3 Feb 2021 05:32:00 -0800 (PST) Received: from out20-99.mail.aliyun.com (out20-99.mail.aliyun.com [115.124.20.99]) (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 1FCAF3A09A8 for ; Wed, 3 Feb 2021 05:31:57 -0800 (PST) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.2282033|-1; BR=01201311R161ec; CH=green; DM=|CONTINUE|false|; DS=AD|ad_other|0.208926-0.627013-0.164061; FP=0|0|0|0|0|-1|-1|-1; HT=ay29a033018047204; MF=madi@rpstir.net; NM=1; PH=DS; RN=1; RT=1; SR=0; TI=SMTPD_---.JUeRidK_1612359105; Received: from 172.20.10.2(mailfrom:madi@rpstir.net fp:SMTPD_---.JUeRidK_1612359105) by smtp.aliyun-inc.com(10.147.40.200); Wed, 03 Feb 2021 21:31:47 +0800 From: Di Ma Content-Type: multipart/alternative; boundary="Apple-Mail=_246AB132-9F07-4D51-88E7-96876CC77B4B" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Message-Id: <80E4B38F-E277-466C-8D89-4921A5AC4F01@rpstir.net> References: To: SIDR Operations WG Date: Wed, 3 Feb 2021 21:31:42 +0800 X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: [Sidrops] APNIC SIG-RoutingSecurity Call for Presentations 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, 03 Feb 2021 13:32:05 -0000 --Apple-Mail=_246AB132-9F07-4D51-88E7-96876CC77B4B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, folks, As co-chair of APNIC Routing Security SIG, I am inviting you to share = with your insights related to Routing Security at this SIG meeting = during APRICOT 2021. See you there! Di =20 > =E4=B8=8B=E9=9D=A2=E6=98=AF=E8=A2=AB=E8=BD=AC=E5=8F=91=E7=9A=84=E9=82=AE= =E4=BB=B6=EF=BC=9A >=20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: Aftab Siddiqui via SIG Routing Security = > =E4=B8=BB=E9=A2=98: [SIG-RoutingSecurity] Call for Presentations > =E6=97=A5=E6=9C=9F: 2021=E5=B9=B42=E6=9C=883=E6=97=A5 GMT+8 21:05:39 > =E6=94=B6=E4=BB=B6=E4=BA=BA: sig-routingsecurity@apnic.net > =E5=9B=9E=E5=A4=8D=EF=BC=8D=E6=94=B6=E4=BB=B6=E4=BA=BA: Aftab Siddiqui = >=20 > Dear Routing Security SIG members, >=20 > As you all know we have an upcoming Routing Security SIG meeting = during APRICOT 2021 on 3rd March 2021 = (https://2021.apricot.net/program/schedule/#/day/10 = ). SIG Chairs are = looking for presentations covering topics covering "Routing Security" = from engineering, operations and research point of view.=20 >=20 > We are looking for interesting ideas as well if you think you have a = problem/solution/idea related to Routing Security, RPKI (ROA, ROV, = SLURM, RP etc), etc please do share it with us and we are happy to help. >=20 > ****************************************************************** > Routing Security SIG-March 2021 :=C2=AD Call For Presentation > ****************************************************************** > Call For Presentation Open: 3rd February 2021 (NOW) > Deadline For Proposal submission: 22nd February 2021 > Paper Confirmation: 26th February 2021 >=20 > Please submit the presentation by email to = sig-routingsecurity-chair@apnic.net = >=20 > on behalf of SIG Chairs >=20 > Di Ma, Rupesh Shrestha, Aftab Siddiqui >=20 > _______________________________________________ > SIG Routing Security mailing list -- sig-routingsecurity@apnic.net > To unsubscribe send an email to sig-routingsecurity-leave@apnic.net --Apple-Mail=_246AB132-9F07-4D51-88E7-96876CC77B4B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = folks,

As co-chair = of APNIC Routing Security SIG,  I am inviting you to share with = your insights related to Routing Security at this SIG meeting during = APRICOT 2021.

See you there!

Di
 

=E4=B8=8B=E9=9D=A2=E6=98=AF=E8=A2=AB=E8=BD=AC=E5=8F=91=E7=9A=84= =E9=82=AE=E4=BB=B6=EF=BC=9A

=E5=8F=91=E4= =BB=B6=E4=BA=BA: Aftab Siddiqui via SIG Routing Security <sig-routingsecurity@apnic.net>
=E4=B8=BB=E9= =A2=98: [SIG-RoutingSecurity] Call for Presentations
=E6=97=A5=E6= =9C=9F: 2021=E5=B9=B42=E6=9C=88= 3=E6=97=A5 GMT+8 21:05:39
=E6=94=B6=E4=BB=B6=E4=BA= =BA: sig-routingsecurity@apnic.net
=E5=9B=9E=E5=A4=8D=EF=BC=8D=E6=94=B6=E4=BB=B6=E4=BA=BA: = Aftab Siddiqui <aftab.siddiqui@gmail.com>
Dear Routing Security SIG members,

As you all = know we have an upcoming Routing Security SIG meeting during APRICOT = 2021 on 3rd March 2021 (https://2021.apricot.net/program/schedule/#/day/10). SIG = Chairs are looking for presentations covering topics covering = "Routing Security" from engineering, operations and research point of = view. 

We are looking for interesting ideas as = well if you think you have a problem/solution/idea related to Routing = Security, RPKI (ROA, ROV, SLURM, RP etc), etc please do share it with us = and we are happy to help.

***************************************************************= ***
Routing Security SIG-March 2021 :=C2=AD Call For = Presentation
***************************************************************= ***
Call For Presentation Open:  3rd February 2021 = (NOW)
Deadline For Proposal submission: 22nd February = 2021
Paper Confirmation: 26th February 2021

Please submit the presentation by email to sig-routingsecurity-chair@apnic.net


on behalf of SIG Chairs

Di Ma, Rupesh Shrestha, Aftab = Siddiqui

_______________________________________________
SIG = Routing Security mailing list -- sig-routingsecurity@apnic.net
To = unsubscribe send an email to sig-routingsecurity-leave@apnic.net

= --Apple-Mail=_246AB132-9F07-4D51-88E7-96876CC77B4B-- From nobody Thu Feb 4 09:33:15 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 5050C3A09BB for ; Thu, 4 Feb 2021 09:33:13 -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 3FXfvPsCsHvL for ; Thu, 4 Feb 2021 09:33:11 -0800 (PST) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 B26233A1626 for ; Thu, 4 Feb 2021 09:33:11 -0800 (PST) Received: by mail-wr1-x42d.google.com with SMTP id u14so4523577wri.3 for ; Thu, 04 Feb 2021 09:33:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:subject:message-id:mime-version:content-disposition; bh=Xq47yl74RWt8T+xijl5VIOxRGLf+6quMxJKNhBDg6QI=; b=D7+FowI83STth6KeYNgL4Xnz4ejM+fVnKeA1CYZCKfk1eOQbKsOdRjjaBO/Ps2uc5t Upxk+IE2VoSv0yeIOWV/A1DJSfWScQfoQDEEIsDeQf+Ki/m8VF8/50Hx/93d3f2lf5Bx P1eNA8hHkU+2g+j+c6vSzKPBIOcKWFOHVffcA= 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:mime-version :content-disposition; bh=Xq47yl74RWt8T+xijl5VIOxRGLf+6quMxJKNhBDg6QI=; b=lTflQ9Gqjz49TyadtYyYNNrtGdDKNZ0g9kAj1D2wOtKpmMyj97WYJQg3DxgJr8K0/p qt+DvqtZrw3lNvxstG081/js3GJSBSk1nAnp908udDuBGP3KFuOgHiKQ9U9vKM4smBwE mYoFRc+9f9qm4muj+CvUKhcI6ebcLy1kGSf1raFxwr6MFV8BtPHTOgzFRvqJ6dWN60ZE ylJG6o8ji13ckd/YXr7DjzjSQ1rbIen1tcGZNFVLzjuqacSo1nwGh3aNWkAeJUApM/EV BVC7doEQ4uN/jie4aPP/nzcDRqSZRoaYhMMHtNJJ8CR4R1ESQxlpMKEWEcsqwAs3n80m Eo4g== X-Gm-Message-State: AOAM531Luv2QQYFtT7nP89CPnbjs5ZMMm5/2DSLDb4YqWWpD88cdmCvO /YCumCXLMBDlTo8B24VNgsVfHU2u+T9Ew5OY59NWhI9dWMtaljwGkmA/FLTB2DVF7b20ARMqF2y mKGvxmA12NSvdnP4p6y3fQzBiFh980BH/xTiQNgfIL3xuByfA/UGLcAg= X-Google-Smtp-Source: ABdhPJwFM+e5vNJBzDvWS+n532WF4CcGSDigoWumABW4htgJXyLF5bN1l3V8+ud4e+rDqwWy0FELaQ== X-Received: by 2002:adf:e68e:: with SMTP id r14mr507742wrm.242.1612459989575; Thu, 04 Feb 2021 09:33:09 -0800 (PST) Received: from snel (mieli.sobornost.net. [45.138.228.4]) by smtp.gmail.com with ESMTPSA id w2sm7269654wmg.27.2021.02.04.09.33.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Feb 2021 09:33:09 -0800 (PST) Date: Thu, 4 Feb 2021 18:33:06 +0100 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] RPKI Signed Checklists - draft-spaghetti-sidrops-rpki-rsc-00 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, 04 Feb 2021 17:33:13 -0000 Dear Working Group, I've produced a specification which at a high level might appear similar to RTA, but has fundamentally different semantics. RTA enables multiple signers to attest exactly one hash for an unnamed digital object, but RSC on the other hand enables a single signer to attest one or more named digital objects. I believe the ability to pass filenames around will greatly improve operations for administrators. Another advantage of RSC should be that in closely following the RFC 6488 template the burden of implementation is significantly reduced. I would appreciate the working group taking a look and considering adoption. After adoption the IANA early allocation procedure can be used to obtain OIDs, after which running code can demonstrated, and then perhaps onwards to deployment. Kind regards, Job ----- Forwarded message from internet-drafts@ietf.org ----- Date: Thu, 04 Feb 2021 09:20:26 -0800 From: internet-drafts@ietf.org To: Job Snijders Subject: New Version Notification for draft-spaghetti-sidrops-rpki-rsc-00.txt A new version of I-D, draft-spaghetti-sidrops-rpki-rsc-00.txt has been successfully submitted by Job Snijders and posted to the IETF repository. Name: draft-spaghetti-sidrops-rpki-rsc Revision: 00 Title: RPKI Signed Checklists Document date: 2021-02-04 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/archive/id/draft-spaghetti-sidrops-rpki-rsc-00.txt Status: https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-rsc/ Htmlized: https://datatracker.ietf.org/doc/html/draft-spaghetti-sidrops-rpki-rsc Htmlized: https://tools.ietf.org/html/draft-spaghetti-sidrops-rpki-rsc-00 Abstract: This document defines a Cryptographic Message Syntax (CMS) profile for a general purpose listing of checksums (a 'checklist'), for use with the Resource Public Key Infrastructure (RPKI). The objective is to allow an attestation, in the form of a listing of one or more checksums of arbitrary digital objects (files), to be signed "with resources", and for validation to provide a means to confirm a specific Internet Resource Holder produced the signed checklist. The profile is intended to provide for the signing of a checksum listing with an arbitrary set of Internet Number Resources. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ----- End forwarded message ----- From nobody Thu Feb 4 09:55:58 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 887103A16D9 for ; Thu, 4 Feb 2021 09:55:56 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=netorgft1331857.onmicrosoft.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 jB0vRj-b3CD9 for ; Thu, 4 Feb 2021 09:55:55 -0800 (PST) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2060.outbound.protection.outlook.com [40.107.236.60]) (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 EEE983A16D8 for ; Thu, 4 Feb 2021 09:55:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Nh32cjkbAdw4+ZqiJH0KhWWP84BOMFTIW589QLqTfnRpwSUzoSoaZBlaVWRyBHgkL3pIEDLTQ3J70Pdh76UVtdR60sl2U6GInA3l4E5dpQy5F0QdfBkyc9seV68pegPIzc4ESAy/UlgjXoBxZar3kwpSTsc+lsCC1gfCsMM41/ITeajAhP9YE0P4o26MZ9oz7h7/s4DuRyJiDU5qrQbKFxdqaWlOGnT6thT1bZZCgdmC8fq+QigPubabpxL+LeKKRXcqu8CMFTsXgX44HExlPe0lukTfbO68V7+9DRnqzMnyhZbGa3fdesnizVoAmcdA8DnQAGd9kHG4NlR3ekxVYA== 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=gUJaFXkVlYDNOkyuowik6ckF6v8G4q9nAImzL9egcFQ=; b=iFUGBfTUDhTa8BujwrMwtfbs7Bvpx9MZaIl49pkOY70zQ9Tck/rQMx/B1Nu/E/y/okyuN2YJqvBN0tfAe+OZD7XXp21u1mafSobGAPB5KBteCbBsy0mzSCdaurS4G3EpHkNzAoh97/iB6EWyRmgXlegddfZK/BiiavJ6du27G+IPUjMSePPJcLsEzKL1S8rgy27hLMF2HnjIIICjZiaewjX0ZZzvfy/n63czptvIbt0caPVF7ztltLZEUYpblgSMVezMKUVQWC1Xc5fJXLE0UL3A1vipWpNaQF/vgTCm344KGGQZChYjaulnHRCirFR5rPRNm64HY/MnkdHbu7j7kg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gUJaFXkVlYDNOkyuowik6ckF6v8G4q9nAImzL9egcFQ=; b=YaQb6REhDEE4HXDMVuGmwaEflv8/DNoNueR+szedJNQcJsTg2j7VVHYgCYWqb1ZAuwC7WLnqiKlFVtTr/05nlOxkB07tjKlwVxKa4QJdtfh7DppflZO4dgpmKr4fOQnvk3Iq4MRLbw80H6YXClJDRSL+d3cQJtCtmY0o5mqILcw= Received: from BYAPR18MB2696.namprd18.prod.outlook.com (2603:10b6:a03:10b::26) by BYAPR18MB2358.namprd18.prod.outlook.com (2603:10b6:a03:131::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.20; Thu, 4 Feb 2021 17:55:50 +0000 Received: from BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::4da:5576:f7bc:a3cc]) by BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::4da:5576:f7bc:a3cc%7]) with mapi id 15.20.3825.020; Thu, 4 Feb 2021 17:55:50 +0000 From: Keyur Patel To: "sidrops@ietf.org" Thread-Topic: [WGLC] draft-sidrops-bgpsec-validation-signaling-05 - Ends 28/December/2020 Thread-Index: AQHWz/2G0uiuHC7tYUqy/kTJhhgF2qpIF9oA Date: Thu, 4 Feb 2021 17:55:50 +0000 Message-ID: <0A9E50DF-E0DC-4D6D-9587-497189E1D938@arrcus.com> References: <33FBAE0F-1D61-4EC3-82D0-11807AC24687@arrcus.com> In-Reply-To: <33FBAE0F-1D61-4EC3-82D0-11807AC24687@arrcus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arrcus.com; x-originating-ip: [70.234.233.187] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 69f86063-93cf-4acf-d169-08d8c9361bea x-ms-traffictypediagnostic: BYAPR18MB2358: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MLmqj5CB7hjgGCjN5I4x3gd5drKNf2+bvtHwaZMQiFj4rWfRHTyc2HGAO82r2mt5vSrByXo3rR38siog6zIjvWZY1aPdwtVl65xiGAvYKruRy9siDAs5rl3c94sgPkz3HTSdDpI7YLM7Er1LHsGvVweD8OIUTdrtSMZkKeYCSa6U6JDYLrg5RyrENf/ZknXt0p0xcKeoCcnKtF5HrEgR5sgg/OKtJsIT7cgAGFtaBCMde01hQuhWdjhno8X1jy66Wibx3zQKCktefNyw8jJ+H3fMFCu2ZosJPScrrukzItfghfbEZEzuvs/nfhN4zwET9aTNSiTQaP+aQ1tutAmjkK54cQfhpvVXq3hQfjod4wNesglyxQuLN2IFLrLfdc+fEr12SsEl6loDpKfAfzRTMvNBS/SZIFPj48Q1JT5Ux+ibnAp+dSO9JAhJgW2bAGTwY8KsN0UMKiOs0JFVMrHYzuyZLRFDeXOkZKihEUvFEqgB1UYe3NMRvNExOY0VDgNn8xoutnji7ASE4cp+lIYWDp+DIDMn6fg04QYL2Ff0guUBqQz4wczwctA4n92V6h5NW1GS8b3c/qVpECswTiG6BRqh0XqOFHi64Od3ncBZFsl+CwUdUrZVuLre8kMMsJwDup0Gd3EgAwDP/Cj/QUPV3A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR18MB2696.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(136003)(39830400003)(366004)(396003)(376002)(76116006)(36756003)(6506007)(53546011)(6512007)(316002)(5660300002)(966005)(8936002)(166002)(8676002)(26005)(2906002)(186003)(6916009)(71200400001)(66556008)(6486002)(66446008)(64756008)(83380400001)(2616005)(66946007)(86362001)(4744005)(33656002)(478600001)(66476007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: kgX3gyBGYEAKBb0zdaT6Lb3STzlquSP4WMdd3GcSVjS9ygI37Vw+Ll2JfE+DqpE5ZT7BX4GHNRvbSgaty7OycWQzfoA6K/BOfql4yngSO8f/S0s0dV7IxL3SZnwcwn9sK3j678bjLoHjN50RF+bB7luCq8jaPFBVdDh/SWETTbDpClto0fJvrHjbdewvgwGnGaCop3aYjVaYaUiJciiLB/gCOKRXz/kpk50gJL0yiL3dNK3mGjz0iV2N7QXjG/8vIblRF7EVrCxYzwDBHCwFZzQHCHg+HmBeDHrBTUdUSmfB0O8LafY54b4U7HI/AsbHv3bOr6sUOn4Xp1vyGefhKDit0MmnPdHnCIfhDX84qQAf2sO8TR3lKpHh+i8RdbmzLf/RrdMb7QSQS83gJd1tKmJ6qlYw3zcX1zFdXsNIuVbaxWLwj0obBj+Mn/FSBrnpsGrqa0b23oI/peHTdBZ2/cSS9lwmwBylQq46h8JF5+vyiY0tjNbB8vPDWTI6Ym8RneMSa34LnudBOoXys50WA3GGtCDdhlbqxw+3r2QhiXuXL3gnaV2Ntpop2fr2TM7vsLWOIefu6lzFpV+DOmk687/cD7yD9x2nU9q4dVwKfZ37sNf6cfvI6nwuYmwMl1mOdXpn53STkNrx63S6WjQ/N/ZXOXaYDDvaCr7rF4nUn6YX84vmPNH4eY10ukXkgBnvitc628HH8pO0INCxOGiRowZT1LfYQDOY3TMweCYmcMwxCTC226gDGvYs2u79nktQ x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_0A9E50DFE0DC4D6D9587497189E1D938arrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR18MB2696.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 69f86063-93cf-4acf-d169-08d8c9361bea X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2021 17:55:50.5356 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nJ83f7WF8nEEoOXvv/+1MGb0NF+A7uv0z1kZqu0e5qWxYyyqjDOf2EKscHxF1pMAHquV1tvj7P7yFpYYcSJWuQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2358 Archived-At: Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-05 - Ends 28/December/2020 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 17:55:57 -0000 --_000_0A9E50DFE0DC4D6D9587497189E1D938arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9sa3MsDQoNClRoZSBXR0xDIGlzIG5vdyBjbG9zZWQuIFRoZXJlIHdhc27igJl0IGVub3VnaCBj b25zZW5zdXMgdG8gcHJvZ3Jlc3MgdGhlIGRyYWZ0IGZ1cnRoZXIuDQoNClJlZ2FyZHMsDQpDaHJp cywgTmF0aGFsaWUgJiBLZXl1cg0KDQpGcm9tOiBLZXl1ciBQYXRlbCA8a2V5dXJAYXJyY3VzLmNv bT4NCkRhdGU6IEZyaWRheSwgRGVjZW1iZXIgMTEsIDIwMjAgYXQgMTI6MzggUE0NClRvOiAic2lk cm9wc0BpZXRmLm9yZyIgPHNpZHJvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbV0dMQ10gZHJhZnQt c2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmctMDUgLSBFbmRzIDI4L0RlY2VtYmVy LzIwMjANCg0KSGkgRm9sa3M6DQoNCkEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaGFzIGJlZW4g cmUtb3BlbmVkIGZvciBkcmFmdC1zaWRyb3BzLWJncHNlYy12YWxpZGF0aW9uLXNpZ25hbGluZy0w NSwg4oCcQkdQc2VjIFZhbGlkYXRpb24gU3RhdGUgU2lnbmFsaW5n4oCdLiBQbGVhc2UgcmVwbHkg dG8gdGhlIGxpc3Qgd2l0aCB5b3VyIGNvbW1lbnRzLiBUaGUgV0dMQyB3aWxsIGVuZCBvbiBEZWNl bWJlciAyOCwgMjAyMC4NCg0KVGhlIGxhdGVzdCBkcmFmdCBjYW4gYmUgZm91bmQgYXQ6ICBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1z aWduYWxpbmctMDUuDQoNClJlZ2FyZHMsDQpDaHJpcywgTmF0aGFsaWUgJiBLZXl1cg0KDQoNCg== --_000_0A9E50DFE0DC4D6D9587497189E1D938arrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjND MTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNw YWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWls U3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIg dmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+Rm9sa3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5UaGUgV0dMQyBpcyBub3cgY2xvc2VkLiBUaGVyZSB3YXNu4oCZdCBlbm91Z2ggY29uc2Vu c3VzIHRvIHByb2dyZXNzIHRoZSBkcmFmdCBmdXJ0aGVyLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJs YWNrIj5DaHJpcywgTmF0aGFsaWUgJmFtcDsgS2V5dXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRv d3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5LZXl1ciBQYXRlbCAm bHQ7a2V5dXJAYXJyY3VzLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCBEZWNlbWJl ciAxMSwgMjAyMCBhdCAxMjozOCBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7c2lkcm9wc0BpZXRm Lm9yZyZxdW90OyAmbHQ7c2lkcm9wc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ W1dHTENdIGRyYWZ0LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFsaW5nLTA1IC0gRW5k cyAyOC9EZWNlbWJlci8yMDIwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5IaSBGb2xrczo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRv d3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtv cnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1z aXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFj aW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkEgd29ya2luZyBncm91cCBsYXN0 IGNhbGwgaGFzIGJlZW4gcmUtb3BlbmVkIGZvciBkcmFmdC1zaWRyb3BzLWJncHNlYy12YWxpZGF0 aW9uLXNpZ25hbGluZy0wNSwg4oCcQkdQc2VjIFZhbGlkYXRpb24gU3RhdGUgU2lnbmFsaW5n4oCd LiBQbGVhc2UgcmVwbHkgdG8gdGhlIGxpc3Qgd2l0aCB5b3VyIGNvbW1lbnRzLiBUaGU8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V0dMQzxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj53aWxsDQogZW5kIG9uIERlY2Vt YmVyIDI4LCAyMDIwLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRl eHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQt c3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJn YigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1h bGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+VGhlIGxhdGVzdCBkcmFmdCBjYW4gYmUgZm91bmQgYXQ6PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zaWRyb3BzLWJncHNlYy12YWxpZGF0 aW9uLXNpZ25hbGluZy0wNSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNpZHJv cHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFsaW5nLTA1PC9hPi4mbmJzcDs8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7 Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7 d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRl eHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQt c3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SZWdhcmRzLDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjog cmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0 LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87 LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5DaHJpcywgTmF0aGFsaWUgJmFtcDsgS2V5dXI8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJn YigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1h bGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_0A9E50DFE0DC4D6D9587497189E1D938arrcuscom_-- From nobody Thu Feb 4 10:07: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 838D83A16E6 for ; Thu, 4 Feb 2021 10:07:55 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.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 uOulFUs77Sgs for ; Thu, 4 Feb 2021 10:07:54 -0800 (PST) Received: from NAM04-MW2-obe.outbound.protection.outlook.com (mail-mw2nam08on2085.outbound.protection.outlook.com [40.107.101.85]) (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 0D7213A16E3 for ; Thu, 4 Feb 2021 10:07:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=isfLurJ8i6fnQIg1pSwuBlX9y0iAW6Io3gyq+xMjq0TknGZ42t7b64Qy8YdeAjIYzvGqPrSQ6jF4B3E+sxYhoXk9jSoODhlbMtOc2ApMNr7mmTTYXpuM6hOtASqSv2/ykrxL2zukIFugH0rvRss7jZ3rFNmdQXtVkKSXvk7YVv7Ed9xUi5AwJCDQrM5KtrOeRnGBDwMnTvn6duPCK+0M2tmkIwpL9gPSq9BNXkXCO79fecSy8TiKr4nm3I3xysfDYGhQeHN5Ka7SSeKdI9qHTXjUIJoOn7T1XlElAdLwygcRF/TnjkxyuqZn7binzefyKMMqDz+qwqLrZ+34marLtQ== 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=9PpYqX+JtKrD0nfmR+59XVZbddiz9knTLi6sV+FndbM=; b=iFdvk2rdaOgmK+mk1859uJcSDQ5M3dT73AcwgG7TrOZSdZKw5SBd3AJnBjtJxQSy4oj14uc5oozj+PYQsfVC92myC9FTqjcNlPiPaqtjWVN0zwFk24duW8zI1xGnuKJiO68oZls4uJqxDALsXiX1TWNNnLOv3ulHTlcJLQmm4ey9bsFArADAA6vbG0pPwemru18Ocbo+MPTAToBy0rQ8sP5WLAsC18I6+vbFVgpCFKptcZNHoPro7bFHagBvj5NeWZlDg8vRI+cs77zyiBrmpoG1FmzOQNhvfFrL7hxtaXCSrhwqgReUNiWerXIhdoYCRa+GfQFb/Hvb/UTBEkuIsA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9PpYqX+JtKrD0nfmR+59XVZbddiz9knTLi6sV+FndbM=; b=q5AXd/5divT7Hieb+qvPc6oQlcDqMUXBPRK2K0lqjwoco0WwystYX/115Rk7k9HMS4Yt+Nc4HrBkaxPgfofl+zpk0zRKSXDJDCZw7yUbCCYQd6S/Vrd17JYDqwxiLgEt08RrqtVl0PJ6+gcsWQHkap66eGC5p+u+3HzFmQpxnNY= Received: from BYAPR18MB2696.namprd18.prod.outlook.com (2603:10b6:a03:10b::26) by BY5PR18MB3233.namprd18.prod.outlook.com (2603:10b6:a03:1aa::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.23; Thu, 4 Feb 2021 18:07:50 +0000 Received: from BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::4da:5576:f7bc:a3cc]) by BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::4da:5576:f7bc:a3cc%7]) with mapi id 15.20.3825.020; Thu, 4 Feb 2021 18:07:50 +0000 From: Keyur Patel To: "sidrops@ietf.org" Thread-Topic: WG Adoption call for draft-spaghetti-sidrops-rpki-rsc-00 (2/4-2/18) Thread-Index: AQHW+yCmcVVmFXR6hU6f8AXpwCdjIA== Date: Thu, 4 Feb 2021 18:07:50 +0000 Message-ID: <9AF56E34-80E5-41C7-A89E-176192A11AB7@arrcus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arrcus.com; x-originating-ip: [70.234.233.187] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 64843a7e-83d0-4bf7-6a5f-08d8c937c937 x-ms-traffictypediagnostic: BY5PR18MB3233: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2958; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7BKthCbwkFzGa3vcnWWPGmvRLLyZK2hwbKvo+yxZH3kzgA2RoWu8HIoZtgwp1+HLBnSntKVxVuVpeFCbl0DJVKvV+gZw0NxOyx2RnymHtT5wdkWsPhR3B0i5J0X1aLivt90gG7R7wRbxG+3ljjR6OMEpS/dQHgveKlidacCmLdVPjM+C5gg2jQug0s6/du7q46iD63vHnGKF3ki0lYAg2SeAouLOOSWTGrHkNh9XqEBD/DKcijDMTYsrrP4uqz2j7b8n5BqiURhTPywXe6I0KIe/EN9mLkGB2VhrZtuLIkRpJY0lO67DPBV5GaLLboyv5gSykzeVPAGJ/Z1DmLt7md6MLB/fMb6B4WHvdlBy7j8+6jKR+PnVBgC1mt/7qxxqBv507ufU9dcWLcW1Y0mAPj9ovxkuvpYTKDbYMEc9veNuUuh4eMLd9fdK5WenW8x+V332gUGff1Rs7Ui5AipAMJ+ujtZUh82puZvho+XLRJjxQH3zO1go5GUkmzD8DcbRenFAn0bvaLdvukviqqKPPdJLPkdAF5I6z7m8LIveWMsXJqQv09k/zcrCHlwaLOPa1kiOsTgFX6P/buC5RJQzTJspokVc458vNK97jFMnyrChCSyOCpk3+tMNGvJbRd8iWKBSY7oMRKNM9HWqWw0rSQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR18MB2696.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(39830400003)(346002)(136003)(376002)(366004)(396003)(26005)(6506007)(166002)(8936002)(36756003)(316002)(83380400001)(6512007)(186003)(86362001)(9326002)(558084003)(33656002)(66946007)(2616005)(66446008)(64756008)(66556008)(66476007)(478600001)(6486002)(966005)(76116006)(2906002)(5660300002)(6916009)(8676002)(71200400001)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?MExaY1U1dGwrQjNOcjBRMmhhN1NMK0dXdURaMmloZmFhTlg0SExoWXFLc3ow?= =?utf-8?B?cFYxcnhnd29OQ2s3NFFxVi9UYWZHWTdWdTNkT3ZNNWN2Mkp3cFVNYjgwdTNn?= =?utf-8?B?TktRUjVJK3JUeVkrMWRYZ3JUdUFrclo3TVp3RDdwZElVNWZaNU9yaTQ5TkdM?= =?utf-8?B?NEwweW1xUDJZSStwWW5WckhzNCtSVFZ0bnQvZXdPeGM3YmRBazhvSWd5SkEr?= =?utf-8?B?b0RSSzR4QTBWd3VZbUo2UTVvMUc3VUt1VjRSbjZPdXBpVHBQdTNmUEJCTjZ1?= =?utf-8?B?aVI4YnUxVjlSZjd1TTJjY2ViaDdzemUwZlBzMmQ2WklJMjAyQ0MrVXF3Z0Js?= =?utf-8?B?UWc1S3R4dkpGWE4yYlplTWVodFJoZStZUlBZRUUzUEoyVU5nV1pDUzJaNHVQ?= =?utf-8?B?bE92dUVoQ0tDalNSUFF1ejRqdWExRTRGcEs2MTVQZEVVa3Y5aWovQmtwL1dw?= =?utf-8?B?WGIvK3h4VDNtM1ZNYnpHWEE4Qjc3MGhxRi95WjduNURuYmZURHY2d0Vhdkpv?= =?utf-8?B?K1RBdEJ5SlFEL1NwYkZNVnZ3WkJFQUN0TnM4SXpMZFlPdG5rRjYyaVphN0RS?= =?utf-8?B?bjk2OFBFRlVacXhFQlY4ZFVrN2lLK2RuWVNnT20rNVZmaGN1c1BTdWtsSzYy?= =?utf-8?B?QlZPU1hMUXl3SHBwaWFTNFU1SktpRHhyUDZ4UkdkN3o3U1EyNSt2OWZ5bTAx?= =?utf-8?B?bjJTT1E5ZnRZUS9yRDB0Lzh6Y3ZBWk9IRjkyTDNIekhaeFYvWHl2aXNLdDQw?= =?utf-8?B?NHRuQW1UcDlYK00vZCtLYVhnVDQrYm9zUm9YVWpSY0xyRDJ2dUxxSit3MGdW?= =?utf-8?B?cFhYZHBjWFpDLzZMZEZxZmJFMzZoT2JhblEvckRwODZVS05wK0o0TVFMZkhi?= =?utf-8?B?YXhMc2FBVkJYdlFseThkeXEzamZJNklzc2FlZUZPTitzelJxazZhS0tvZERk?= =?utf-8?B?Z2FFb2tJMHE4S0RhdDBjVHREdXBNUmhUaVNhRnRPemt5VmxKRTdmVlpKM25I?= =?utf-8?B?azBNNEM2aEZ2d0pNL0ovcEVHZklRYUtaMk9UVzE4ekFBN0JDRjVmU0RVSTAz?= =?utf-8?B?enJpRldiTkpuVXYyWCtUSTZpR2dIb1N6aTl6cy94WDNkM09PUjlldldoZFZW?= =?utf-8?B?V0IxM1A4WUNhUm94WCtuMCtSRG9lZzVYdHVkM0dPc09VODNMLzh1T0thZmdP?= =?utf-8?B?SEhaSGlockxHUm95VlUxditvcm9PdWtiZmdzbjQzbjlMMWs2Uy9CdEM3VjRK?= =?utf-8?B?eGU3NkRiT1RiSnhncVlGUmVvOHBhUi9NSU9CY29LOFlvaHgvWnZrMkxaVzY2?= =?utf-8?B?KzZWbzN2TElqL0xYS2dkaXNEK3hia2E2aWZld3A4UjMwdWlWbjVMSnBXTUFE?= =?utf-8?B?aVBVU3ZlY0ZMUWxvOEhFRmJpK0ZSc2VESklCdWlFU0RHUWxqS1pmZHhXcmdz?= =?utf-8?B?TmNVVFVCSFBOazgwbXBFZjZ4NEFRV2w0eHNlOW9Zam5EZC9TL3V4SkZUalh0?= =?utf-8?B?T0toU3M2SjMyV3dkK1RrdmpSZnpyM01RV1ZhNkQ2dkt6R2kxTXAraFZZRGRo?= =?utf-8?B?VDhSV3RyVzNXQXFpRHlJRCtjdTZhZ1VKcktoUUxXNFhreUpLUEFDU3lEUkRk?= =?utf-8?B?ZTdWejBYMDVtUmRBVjRzWTBUVDhCM3Q1WFBPZkVRZ1pzd2dCWnlmS05vaHJS?= =?utf-8?B?YXdqUHhyb0hYTVp6cWZhZFZIc2hBS3lNeHltZHQ1K3hlSEpqbWZ4TlFzclJO?= =?utf-8?B?dzZWdkR6ckgvU0ZwWkdRcGlOVHdNWGVUeFR4d21tQUl4Ny9Zb2JJQ29xYnY2?= =?utf-8?B?NGJiTEVoL0xOU0Ric0xaZz09?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_9AF56E3480E541C7A89E176192A11AB7arrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR18MB2696.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 64843a7e-83d0-4bf7-6a5f-08d8c937c937 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2021 18:07:50.8661 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7UVmyl5eW7pQfUeFjfzdhw4i5bLQkGcObEzUxmVGFXsECMrwBJq9TVdqenhGpx2wBPRiqjBv3ICiQ0ndyhQhvg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR18MB3233 Archived-At: Subject: [Sidrops] WG Adoption call for draft-spaghetti-sidrops-rpki-rsc-00 (2/4-2/18) 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, 04 Feb 2021 18:07:56 -0000 --_000_9AF56E3480E541C7A89E176192A11AB7arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRm9sa3MsDQoNCg0KVGhlIGRyYWZ0IGF1dGhvciBoYXMgcmVxdWVzdGVkIFNJRFJPUFMgd29y a2luZyBncm91cCBhZG9wdGlvbiBjYWxsIG9mIOKAnFJQS0kgU2lnbmVkIENoZWNrbGlzdHPigJ0s IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNwYWdoZXR0aS1zaWRyb3Bz LXJwa2ktcnNjLy4NCg0KDQoNCg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbGlz dC4gVGhpcyBhZG9wdGlvbiBjYWxsIHdpbGwgY29uY2x1ZGUgb24gRmVicnVhcnkgMTggMjAyMS4N Cg0KDQoNClJlZ2FyZHMsDQoNCkNocmlzLCBOYXRoYWxpZSAmIEtleXVyDQoNCg0K --_000_9AF56E3480E541C7A89E176192A11AB7arrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <2622E249B31ED44A934D35748CAE6DC0@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjND MTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28t c3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUt bmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiIgc3R5bGU9IndvcmQtd3JhcDpi cmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMjEyNTI5Ij5IaSBGb2xrcyw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImNhcmV0LWNvbG9yOiBy Z2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQt YWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzst d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMyMTI1MjkiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBo YW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXpl LWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5n OjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzIxMjUyOSI+VGhlIGRyYWZ0IGF1dGhvciBoYXMg cmVxdWVzdGVkIFNJRFJPUFMgd29ya2luZyBncm91cCBhZG9wdGlvbiBjYWxsIG9mIOKAnDwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlJQS0kgU2lnbmVkIENoZWNrbGlzdHPigJ0sPHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNwYWdoZXR0aS1zaWRyb3BzLXJw a2ktcnNjLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc3BhZ2hldHRp LXNpZHJvcHMtcnBraS1yc2MvPC9hPjwvc3Bhbj4uPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMyMTI1MjkiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iY2FyZXQtY29sb3I6IHJn YigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1h bGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzIxMjUyOSI+UGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbGlz dC4gVGhpcyBhZG9wdGlvbiBjYWxsIHdpbGwgY29uY2x1ZGUgb24gRmVicnVhcnkgMTggMjAyMS48 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmUgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJr aXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMTI1MjkiPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtp dC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3 b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIxMjUyOSI+UmVnYXJkcyw8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmUgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJr aXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMTI1MjkiPkNocmlzLCBO YXRoYWxpZSAmYW1wOyBLZXl1cjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNv bG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRv O3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDog YXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9AF56E3480E541C7A89E176192A11AB7arrcuscom_-- From nobody Thu Feb 4 10:18:20 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 DB85E3A114B; Thu, 4 Feb 2021 10:18:19 -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.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <161246269986.15191.17141903931767483802@ietfa.amsl.com> Date: Thu, 04 Feb 2021 10:18:19 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-8210bis-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, 04 Feb 2021 18:18:20 -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 : The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2 Authors : Randy Bush Rob Austein Filename : draft-ietf-sidrops-8210bis-01.txt Pages : 37 Date : 2021-02-04 Abstract: In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 2 of the RPKI-Router protocol. RFC 6810 describes version 0, and RFC 8210 describes version 1. This document updates RFC 8210. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-8210bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-8210bis-01 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-8210bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-8210bis-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 Feb 4 12:33: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 E75D53A17D3 for ; Thu, 4 Feb 2021 12:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D09t83lIhZSB for ; Thu, 4 Feb 2021 12:33:52 -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 5AF523A17CE for ; Thu, 4 Feb 2021 12:33:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B2D65300B76 for ; Thu, 4 Feb 2021 15:33:49 -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 VCItxCiWZmAe for ; Thu, 4 Feb 2021 15:33:47 -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 9B778300A55; Thu, 4 Feb 2021 15:33:47 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: Date: Thu, 4 Feb 2021 15:33:48 -0500 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1F85B137-8A11-4D96-81BB-6DAC40002277@vigilsec.com> References: To: Job Snijders X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Sidrops] RPKI Signed Checklists - draft-spaghetti-sidrops-rpki-rsc-00 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, 04 Feb 2021 20:33:56 -0000 Job: I have one suggestion for the ASN.1 module. I'd rather see the hash of = the file as an OCTET STRING (instead of a BIT STRING). This would be = more in line with CMS. Below is the resulting module if you accept this suggestion. After = filing in the TBDs, this module does compile. Russ =3D =3D =3D =3D =3D =3D =3D =3D =3D RpkiSignedChecklist-2021 { iso(1) member-body(2) us(840) rsadsi(113549) =20 pkcs(1) pkcs9(9) smime(16) mod(0) TBD }=20 =20 DEFINITIONS EXPLICIT TAGS ::=3D BEGIN IMPORTS CONTENT-TYPE, Digest, DigestAlgorithmIdentifier FROM CryptographicMessageSyntax-2009 -- in [RFC5911] { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) } ASIdOrRange, IPAddressFamily FROM IPAddrAndASCertExtn -- in [RFC3779] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident(30) } ; ct-rpkiSignedChecklist CONTENT-TYPE ::=3D { TYPE RpkiSignedChecklist IDENTIFIED BY id-ct-signedChecklist } =20 id-ct-signedChecklist OBJECT IDENTIFIER ::=3D { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) id-smime(16) id-ct(1) TBD } RpkiSignedChecklist ::=3D SEQUENCE { version [0] INTEGER DEFAULT 0, resources ResourceBlock, digestAlgorithm DigestAlgorithmIdentifier, checkList SEQUENCE SIZE (1..MAX) OF FileAndHash } FileAndHash ::=3D SEQUENCE { file IA5String, hash Digest } ResourceBlock ::=3D SEQUENCE { asID [0] AsList OPTIONAL, ipAddrBlocks [1] IPList OPTIONAL } -- at least one of asID or ipAddrBlocks MUST be present ( WITH COMPONENTS { ..., asID PRESENT} | WITH COMPONENTS { ..., ipAddrBlocks PRESENT } ) =20 AsList ::=3D SEQUENCE (SIZE(1..MAX)) OF ASIdOrRange IPList ::=3D SEQUENCE (SIZE(1..MAX)) OF IPAddressFamily END > On Feb 4, 2021, at 12:33 PM, Job Snijders = wrote: >=20 > Dear Working Group, >=20 > I've produced a specification which at a high level might appear = similar > to RTA, but has fundamentally different semantics. >=20 > RTA enables multiple signers to attest exactly one hash for an unnamed > digital object, but RSC on the other hand enables a single signer to > attest one or more named digital objects. >=20 > I believe the ability to pass filenames around will greatly improve > operations for administrators. >=20 > Another advantage of RSC should be that in closely following the RFC > 6488 template the burden of implementation is significantly reduced. >=20 > I would appreciate the working group taking a look and considering > adoption. After adoption the IANA early allocation procedure can be = used > to obtain OIDs, after which running code can demonstrated, and then > perhaps onwards to deployment. >=20 > Kind regards, >=20 > Job >=20 > ----- Forwarded message from internet-drafts@ietf.org ----- >=20 > Date: Thu, 04 Feb 2021 09:20:26 -0800 > From: internet-drafts@ietf.org > To: Job Snijders > Subject: New Version Notification for = draft-spaghetti-sidrops-rpki-rsc-00.txt >=20 >=20 > A new version of I-D, draft-spaghetti-sidrops-rpki-rsc-00.txt > has been successfully submitted by Job Snijders and posted to the > IETF repository. >=20 > Name: draft-spaghetti-sidrops-rpki-rsc > Revision: 00 > Title: RPKI Signed Checklists > Document date: 2021-02-04 > Group: Individual Submission > Pages: 8 > URL: = https://www.ietf.org/archive/id/draft-spaghetti-sidrops-rpki-rsc-00.txt > Status: = https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-rsc/ > Htmlized: = https://datatracker.ietf.org/doc/html/draft-spaghetti-sidrops-rpki-rsc > Htmlized: = https://tools.ietf.org/html/draft-spaghetti-sidrops-rpki-rsc-00 >=20 >=20 > Abstract: > This document defines a Cryptographic Message Syntax (CMS) profile > for a general purpose listing of checksums (a 'checklist'), for use > with the Resource Public Key Infrastructure (RPKI). The objective = is > to allow an attestation, in the form of a listing of one or more > checksums of arbitrary digital objects (files), to be signed "with > resources", and for validation to provide a means to confirm a > specific Internet Resource Holder produced the signed checklist. = The > profile is intended to provide for the signing of a checksum listing > with an arbitrary set of Internet Number Resources. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 > ----- End forwarded message ----- >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Feb 4 13:02: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 8F0793A184F for ; Thu, 4 Feb 2021 13:02:16 -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 fg_X2e5H1WZS for ; Thu, 4 Feb 2021 13:02:14 -0800 (PST) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF723A1838 for ; Thu, 4 Feb 2021 13:02:14 -0800 (PST) Received: by mail-wm1-x32b.google.com with SMTP id u14so4196584wmq.4 for ; Thu, 04 Feb 2021 13:02:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=21szlORnvBi1uW7D7hhrmlEdMBmmDy2g7KgCfjUoLhk=; b=rZr+/YQ1a0VJQ3cp6jEktQ6ZKiw28QYfQ/GdJ9mA++LaCJI3Pq6myfTxEM6P/qK7fB 8H2duXctQ1UuN1Ob9akm2XobFweVH5J0sNhwoM1NmyToEwIrT9CtUqXJf6rNleh4Oj2r u295JRcTgKx3eqS+XKQ7Jcvdy9OSbm1BDve1o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=21szlORnvBi1uW7D7hhrmlEdMBmmDy2g7KgCfjUoLhk=; b=PmgOpvM4KzYPhfCXYG1Gd6/ar9fFaIHM05XfJaUkRGmNWz2veARHJEY6mItNhROghL iH+zCJznUrjyG4pVTZunZ2ayhNJWv03XcYDvWa6JO/suui68aNgW6DC87iY8jKoW11pm dPximS8Xvlj2RZ9700qLyMS5h19jykl582NCmz27CekOu2Pg02yPAg/q6xpoYrqZAUrg xKZtW7jhSGIneqyB0DL21IX2Mp29yvybOANnhDYSe301b6tWi1ILWL5P/2PrGcnJiXk4 m0MDFMA3f1ent0nuSPFcwfrZoZk8Mw5rzwtWrbsKiR0mG0OMCifnpaPyaGgVAvL4xRCn rliw== X-Gm-Message-State: AOAM531LEHV2MoHzODEAgbrhUtzyqsSJv7yojFj64WUQkcUmGEcVVwzL x8fEuEulbAgrUOZjTtBx4prV4Q== X-Google-Smtp-Source: ABdhPJxFRPdiN71GGPS2aHKzkZpYfBAPmX8mDkc56pu/ucSRVeYv5utIxHYbScIAZVLQTbbkpeWK9Q== X-Received: by 2002:a1c:2094:: with SMTP id g142mr846986wmg.101.1612472532915; Thu, 04 Feb 2021 13:02:12 -0800 (PST) Received: from snel (mieli.sobornost.net. [45.138.228.4]) by smtp.gmail.com with ESMTPSA id e11sm9634714wrx.14.2021.02.04.13.02.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Feb 2021 13:02:12 -0800 (PST) Date: Thu, 4 Feb 2021 22:02:10 +0100 From: Job Snijders To: Russ Housley Cc: sidrops@ietf.org Message-ID: References: <1F85B137-8A11-4D96-81BB-6DAC40002277@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1F85B137-8A11-4D96-81BB-6DAC40002277@vigilsec.com> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] RPKI Signed Checklists - draft-spaghetti-sidrops-rpki-rsc-00 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, 04 Feb 2021 21:02:18 -0000 On Thu, Feb 04, 2021 at 03:33:48PM -0500, Russ Housley wrote: > Job: > > I have one suggestion for the ASN.1 module. I'd rather see the hash > of the file as an OCTET STRING (instead of a BIT STRING). This would > be more in line with CMS. > > Below is the resulting module if you accept this suggestion. After > filing in the TBDs, this module does compile. Thank you Russ! I appreciate your suggestion and will incorporate it. Kind regards, Job From nobody Thu Feb 4 14:05: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 4BC583A18A9 for ; Thu, 4 Feb 2021 14:05:12 -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 fG_5iWslBBUf for ; Thu, 4 Feb 2021 14:05:09 -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 B1E023A18A8 for ; Thu, 4 Feb 2021 14:05:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0B000300BD0 for ; Thu, 4 Feb 2021 17:05:07 -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 DWUCCtE8mmdo for ; Thu, 4 Feb 2021 17:05:05 -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 3E166300A55; Thu, 4 Feb 2021 17:05:05 -0500 (EST) From: Russ Housley Message-Id: <1AE0C159-6339-4922-840D-37F98C182C8E@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_605DE3BB-6D8D-46C8-8122-2A5CD362F51B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Thu, 4 Feb 2021 17:05:06 -0500 In-Reply-To: <9AF56E34-80E5-41C7-A89E-176192A11AB7@arrcus.com> Cc: "sidrops@ietf.org" To: Keyur Patel References: <9AF56E34-80E5-41C7-A89E-176192A11AB7@arrcus.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Sidrops] WG Adoption call for draft-spaghetti-sidrops-rpki-rsc-00 (2/4-2/18) 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, 04 Feb 2021 22:05:12 -0000 --Apple-Mail=_605DE3BB-6D8D-46C8-8122-2A5CD362F51B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I support adoption. Russ > On Feb 4, 2021, at 1:07 PM, Keyur Patel wrote: >=20 > Hi Folks, > =20 > The draft author has requested SIDROPS working group adoption call of = =E2=80=9CRPKI Signed Checklists=E2=80=9D, = https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-rsc/ = . > =20 > =20 > Please send your comments to the list. This adoption call will = conclude on February 18 2021. > =20 > Regards, > Chris, Nathalie & Keyur > =20 > =20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops = --Apple-Mail=_605DE3BB-6D8D-46C8-8122-2A5CD362F51B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = support adoption.

Russ

On Feb 4, 2021, at 1:07 PM, = Keyur Patel <keyur@arrcus.com> wrote:

Hi Folks,
 
The draft author has requested SIDROPS working group = adoption call of =E2=80=9CRPKI Signed = Checklists=E2=80=9D, https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-r= sc/.
 
 
Please send your comments to the list. This =
adoption call will conclude on February 18 2021.
 
Regards,
Chris, Nathalie & Keyur
 
 
_______________________________________________
Sidrops mailing list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

= --Apple-Mail=_605DE3BB-6D8D-46C8-8122-2A5CD362F51B-- From nobody Thu Feb 4 14:51:35 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 BE8C93A1908 for ; Thu, 4 Feb 2021 14:51:34 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrJe5-s3ZJzB for ; Thu, 4 Feb 2021 14:51:32 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [46.182.8.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087BB3A1909 for ; Thu, 4 Feb 2021 14:51:29 -0800 (PST) X-Envelope-To: sidrops@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.16.1/8.16.1) with ESMTPSA id 114MpM09095413 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Feb 2021 22:51:22 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local To: Keyur Patel Cc: "sidrops@ietf.org" , Russ Housley References: <9AF56E34-80E5-41C7-A89E-176192A11AB7@arrcus.com> <1AE0C159-6339-4922-840D-37F98C182C8E@vigilsec.com> From: Nick Hilliard Message-ID: <0fcc2eae-84af-e210-a8de-0af8bdb8e788@foobar.org> Date: Thu, 4 Feb 2021 22:51:20 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.46 MIME-Version: 1.0 In-Reply-To: <1AE0C159-6339-4922-840D-37F98C182C8E@vigilsec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Sidrops] WG Adoption call for draft-spaghetti-sidrops-rpki-rsc-00 (2/4-2/18) 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, 04 Feb 2021 22:51:35 -0000 This seems like a good idea. We should adopt. Nick Russ Housley wrote on 04/02/2021 22:05: > I support adoption. > > Russ > >> On Feb 4, 2021, at 1:07 PM, Keyur Patel > > wrote: >> >> Hi Folks, >> The draft author has requested SIDROPS working group adoption call of >> “RPKI Signed >> Checklists”,https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-rsc/. >> Please send your comments to the list. This adoption call will >> conclude on February 18 2021. >> Regards, >> Chris, Nathalie & Keyur >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops > > > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > From nobody Thu Feb 4 21:13:26 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 AE1913A0CC7 for ; Thu, 4 Feb 2021 21:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taPWku06djZe for ; Thu, 4 Feb 2021 21:13:18 -0800 (PST) Received: from smtpbgeu2.qq.com (smtpbgeu2.qq.com [18.194.254.142]) (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 97F3B3A1BFD for ; Thu, 4 Feb 2021 21:13:17 -0800 (PST) X-QQ-mid: bizesmtp23t1612501988tpodhl2d Received: from [192.168.218.230] (unknown [202.173.9.210]) by esmtp6.qq.com (ESMTP) with id ; Fri, 05 Feb 2021 13:13:07 +0800 (CST) X-QQ-SSF: 00400000002000Z0Z000000A0000000 X-QQ-FEAT: sj2Ih1w5Qj8dXP6xgYXqehF+553hYit8bQI6bPuFV84ktD/xQM8Ds1V6TXN8V 174kSpU/VAP25Ohw0Kx1ZqSdvvFQt4SS62XEOLn0rmEe4jWrFOpe0w0lMK/xUBnLzc8lHUs 8l35AI0jr0t8In1hz4veg7Dr/d8YLruKG8WHdmlAaorqfSvDQaOXhXRPEFOnEGnEbQ2pu4f GmGN+xaNC0cjlrTkgRte5aGN/XaTMWuntY4uSMnvRF3IppCEXn7+duk/wg8Alse71hLGeUl qxPy+Gc0eX0U/ArrCW0UoF+MI51ISQJB2z2jUploiqbs8+OnTbyUNd85q4H0XkojCTMnh92 Bl2HO3RG7/f1T5nM26e23857a8UxbyzsqqPyhsFXdK7SGOM9AU= X-QQ-GoodBg: 2 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Di Ma In-Reply-To: <20210202175608.0e8a58cb@glaurung.nlnetlabs.nl> Date: Fri, 5 Feb 2021 13:13:03 +0800 Cc: Job Snijders , sidrops@ietf.org 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> <20210112145800.nocjbd4millmbx4i@benm-laptop> <20210202175608.0e8a58cb@glaurung.nlnetlabs.nl> To: Martin Hoffmann X-Mailer: Apple Mail (2.3654.40.0.2.32) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign5 X-QQ-Bgrelay: 1 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: Fri, 05 Feb 2021 05:13:25 -0000 Based our experience of evolving and operating RPSITR2, I don=E2=80=99t = really think multiple signatures on RTA is good idea as per current RPKI = repository architecture. It will bring about complexity to RP=E2=80=99s = validation algorithm. Through a separate system that RPs achieve RTAs could be an option. Di > 2021=E5=B9=B42=E6=9C=883=E6=97=A5 00:56=EF=BC=8CMartin Hoffmann = =E5=86=99=E9=81=93=EF=BC=9A >=20 > Job Snijders wrote: >>=20 >> I've consulted with various subject matter experts, and at George's >> request I again reconsidered. Unfortunately I could not arrive at a >> different conclusion about the current RTA proposal, it is too >> complicated for me to support. >=20 > There=E2=80=99s a detail I would like to point out: You can only use = the > existing software more or less unchanged if you distribute RTAs = through > the regular RPKI repository system. I think doing so is a bad idea > for two reasons. >=20 > For one, an RTA is an exchange between a very small number of > participants -- typically just two --, but distribution via the RPKI > repository system results in every single relying party having to > downloading the object. That strikes me as rather wasteful. At the = very > least relying parties need to download the object and calculate a hash > over them to determine whether the manifest is valid. Every one needs > to do that. Yet only really one or two parties actually care. >=20 > Second, distribution through the RPKI repository is actually quite > cumbersome as it involves a kind of break of gauge: You exchange > documents in whatever way you choose (likely some kind of HTTP API) = but > then have to stop, fire up an RPKI relying party tool and wait until = it > sees the promised object. Because there uncertainties in timing of = RPKI > publication, you need to be prepared to wait for quite a bit. >=20 > If, conversely, the RTA can be distributed by any other means, i.e., = it > is just a file, it can be transferred as part of your document > exchange. Bundle it with your document for automated processing or > upload it manually via a browser. No waiting involved: both parties > know that the RTA has been transmitted. >=20 > But if you allow that, you can=E2=80=99t use RFC 6488 signed objects = anymore -- > or, well, not properly since at the very least you don=E2=80=99t have = the a > signedObject SIA rsync URI anymore. (And yes, the current draft = glances > over this fact.) >=20 > So, if you have to change your code anyway, why not allow it to deal > with a legitimate, existing use case? >=20 > In addition to allow multiple signatures, the draft also allows the > signer to include all necessary certificates and CRLs so that for > validation you wouldn=E2=80=99t even need to access the RPKI = repository system > at all. Needless to say, doing that requires quite a bit of different > code but, I do believe that this is worth it, as it seriously > streamlines any process that involves validating RTAs as it can now be > done in a library pretty much without keeping state. =20 >=20 > - Martin >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Feb 5 01:01:25 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 B6A743A1DAE for ; Fri, 5 Feb 2021 01:01:23 -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 WU-r1VA9AdM2 for ; Fri, 5 Feb 2021 01:01:21 -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 EB17F3A1DAB for ; Fri, 5 Feb 2021 01:01:20 -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 611F56084A; Fri, 5 Feb 2021 09:01:18 +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=1612515676; bh=1bY5VBPjtjpLAoiH6jyZE4Xdnkozu651WlMGeX7Eaes=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=LmB2zgMOUZqHWcAYhugToFluAIhuGIN1MzUeHLyOCo+IJHWTeOjI6qoPUbwRBtWN9 w5t5nuLix501ftoSrUV7eMhgq/AeCa8OWwwVlb+ZxHbtap15Zo18+igW0J0dKm5ORG Db1/HnEPctkJAHnRQVB0n7O6eK9FquAYkwmGLYtH1GCNHHlL/gV6gsbv6CbKNwaJGa NigpHYsl0zRW9QYvgqat8iOxDr3IJmhSErrHngNmJ4TbazGWYUg99vM0SXQ9OhMUfw JdZ2KA+5pQFVPhPG5QcWgraUkjHsik/H1xWY5VrzoezTIyhwk4KavTtJB6yrynraII 8VInzrsRMdHFQ== 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, 5 Feb 2021 10:01:09 +0100 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Job Snijders Archived-At: Subject: Re: [Sidrops] RPKI Signed Checklists - draft-spaghetti-sidrops-rpki-rsc-00 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, 05 Feb 2021 09:01:24 -0000 Dear Job, WG, > On 4 Feb 2021, at 18:33, Job Snijders = wrote: >=20 > Dear Working Group, >=20 > I've produced a specification which at a high level might appear = similar > to RTA, but has fundamentally different semantics. >=20 > RTA enables multiple signers to attest exactly one hash for an unnamed > digital object, but RSC on the other hand enables a single signer to > attest one or more named digital objects. >=20 > I believe the ability to pass filenames around will greatly improve > operations for administrators. >=20 > Another advantage of RSC should be that in closely following the RFC > 6488 template the burden of implementation is significantly reduced. >=20 > I would appreciate the working group taking a look and considering > adoption. After adoption the IANA early allocation procedure can be = used > to obtain OIDs, after which running code can demonstrated, and then > perhaps onwards to deployment. I have spoken with the other co-authors of the RTA document. We are not = oppositional to this work. I think some words to this extend were expressed earlier, but again, if = the working group prefers to have a single signed object which does not = include a certificate and CRL chain for out-of-band validation, then a = much simpler profile based on rpki signed objects (6488), as you are = proposing, makes perfect sense. I believe that a possible constructive way forward would be to adopt = your proposal and define single signed RSC objects there. I will repeat = my support in the appropriate thread. The existing work on RTA can then be modified to leverage RSCs for other = use cases. So rather then re-defining the signatures, RTAs could include = one or more RSC objects. E.g.: 1) out-of-band validation RTA could define a profile where a user can be sent an RSC, and some or = all CA certificates and CRLs needed for validation for complete = out-of-band validation. The CMS profile allows to include these, but = 6488 does not, and if we do not wish to complicate RSC with this = concern, then a level of indirection can help. 2) multi-signing For those use cases where multiple signatures across different resource = sets *are* required (yes, I know this is a corner case), the RTA can = define a profile where multiple single signed RSC objects are bundled = together. Of course there are details to cover, but hopefully this gives a good = high-level idea, and this approach will allow us all to work = constructively together on complementary work. So, we intend to draft a new version of the RTA specification along = these lines. Please speak up if you feel this is not a good way forward. Kind regards Tim >=20 > Kind regards, >=20 > Job >=20 > ----- Forwarded message from internet-drafts@ietf.org ----- >=20 > Date: Thu, 04 Feb 2021 09:20:26 -0800 > From: internet-drafts@ietf.org > To: Job Snijders > Subject: New Version Notification for = draft-spaghetti-sidrops-rpki-rsc-00.txt >=20 >=20 > A new version of I-D, draft-spaghetti-sidrops-rpki-rsc-00.txt > has been successfully submitted by Job Snijders and posted to the > IETF repository. >=20 > Name: draft-spaghetti-sidrops-rpki-rsc > Revision: 00 > Title: RPKI Signed Checklists > Document date: 2021-02-04 > Group: Individual Submission > Pages: 8 > URL: = https://www.ietf.org/archive/id/draft-spaghetti-sidrops-rpki-rsc-00.txt > Status: = https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-rsc/ > Htmlized: = https://datatracker.ietf.org/doc/html/draft-spaghetti-sidrops-rpki-rsc > Htmlized: = https://tools.ietf.org/html/draft-spaghetti-sidrops-rpki-rsc-00 >=20 >=20 > Abstract: > This document defines a Cryptographic Message Syntax (CMS) profile > for a general purpose listing of checksums (a 'checklist'), for use > with the Resource Public Key Infrastructure (RPKI). The objective = is > to allow an attestation, in the form of a listing of one or more > checksums of arbitrary digital objects (files), to be signed "with > resources", and for validation to provide a means to confirm a > specific Internet Resource Holder produced the signed checklist. = The > profile is intended to provide for the signing of a checksum listing > with an arbitrary set of Internet Number Resources. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 > ----- End forwarded message ----- >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Feb 5 06:07: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 BBD543A115A for ; Fri, 5 Feb 2021 06:07:53 -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=swm.pp.se 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 0lK2Sk228uM2 for ; Fri, 5 Feb 2021 06:07:51 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 455823A1157 for ; Fri, 5 Feb 2021 06:07:50 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8805EAF; Fri, 5 Feb 2021 15:07:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1612534068; bh=pub3VsyQ0tcVPCMDsWYhlSWclvjQBtNc6XJZ+KlRZpw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=W62nPJ49RRKFig0TUGBWQUsABlKdifyu0T5ScYO2tSYnft4XQMBUOdW3EdVZONmSt zrEt+708c9xH3cOw/et1744QUxivw8kWxAErUKvY/wquU97YMdRfRnVglr191Jq6cI ip00i8QSrcOkG+t+4KSdIdmNpCKWHpj+3B2hoLJQ= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 85CF69F; Fri, 5 Feb 2021 15:07:48 +0100 (CET) Date: Fri, 5 Feb 2021 15:07:48 +0100 (CET) From: Mikael Abrahamsson To: Keyur Patel cc: "sidrops@ietf.org" In-Reply-To: <9AF56E34-80E5-41C7-A89E-176192A11AB7@arrcus.com> Message-ID: References: <9AF56E34-80E5-41C7-A89E-176192A11AB7@arrcus.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-137064504-1974464138-1612534068=:12861" Archived-At: Subject: Re: [Sidrops] WG Adoption call for draft-spaghetti-sidrops-rpki-rsc-00 (2/4-2/18) 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, 05 Feb 2021 14:07:55 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1974464138-1612534068=:12861 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 4 Feb 2021, Keyur Patel wrote: > Hi Folks, > > > The draft author has requested SIDROPS working group adoption call of “RPKI Signed Checklists”, https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-rsc/. > > Please send your comments to the list. This adoption call will conclude on February 18 2021. I support adoption. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1974464138-1612534068=:12861-- From nobody Fri Feb 5 14:07:11 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 C94C63A0C56 for ; Fri, 5 Feb 2021 14:07:09 -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 54HqcPR6l-6f for ; Fri, 5 Feb 2021 14:07:08 -0800 (PST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 378D13A0C55 for ; Fri, 5 Feb 2021 14:07:07 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id b3so9346195wrj.5 for ; Fri, 05 Feb 2021 14:07:06 -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=3r/7usR5btsXin54tFrzHLXFUstXdtqvrUaZifh8voc=; b=gZgQgMz7H1u3gn/fxJIvfry20TKshp4EVVrC4Oi1UdZN9KVTyCyR7CODXj3FoZX12u lLP0rhGgelt1uFYOfz2Dpe/a8I6ST5mSQ+X3FLximC4IDQWQIBiffh2Jt0NExt3Qkb2z Amt9shW9UcffnmGMuyXHFC643kUCMaT+vYn5w= 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=3r/7usR5btsXin54tFrzHLXFUstXdtqvrUaZifh8voc=; b=ExDLGDKiHvn4Bd5ajFg4U3M80s4tGNvJ7XiJGZECRw3AamzAMpyYTNF6thggSPBhDU YmUtW2/Ym/fC3bHW9vQOVI5pRpCMgbILsjT7B0qS3DFktcn1SXIKP+8WHvtwllUM53iv 6KzODlPZU1pUMeLBMRoXyHC7f4UOq77DUUCXNmF3b/CqrMadrZyg33xj1haDoV1U+aXZ JpQ2C+Xcx9Ga649IobQL2Zdrult1KP/fAt2SZIsYbzD5kCKCeKAeQSPAZYj0O3vdVhdg AV1CMTzB0VwOruDHfeK0S227o87XD8ouGPZLLMyvcKozEmWUfFdJtDOMjxfk9gIMgYVh REIQ== X-Gm-Message-State: AOAM530+CWn+xNcutiewIRN/r6I6/sD2i/h2So4SXKEsCQC6FyYj+9U4 lOXgUSfbmuONpyHfKty+LKgS7XVrZyfHqamzpgjIQemkK2rHpBiseDnn+YC5m2/3Ixe0hGs8s6w icwbcpVPEvlOTBqVQG6A1IlGwDSCEvmUKL2ojvGiff1CWzLa+Dnz9RTE= X-Google-Smtp-Source: ABdhPJzmko3r0KqV1baq0uKcg9D7uk30wYCnP53iwXhTE7yNbkzQqrucO6J5CRn2GuNJr3pQPPnmWg== X-Received: by 2002:a5d:6191:: with SMTP id j17mr7114060wru.281.1612562825016; Fri, 05 Feb 2021 14:07:05 -0800 (PST) Received: from snel (mieli.sobornost.net. [45.138.228.4]) by smtp.gmail.com with ESMTPSA id b4sm13056692wrn.12.2021.02.05.14.07.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Feb 2021 14:07:03 -0800 (PST) Date: Fri, 5 Feb 2021 23:07:01 +0100 From: Job Snijders To: sidrops@ietf.org Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="McZkFGNLFxCT+zU9" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] RPKI Signed Checklists - draft-spaghetti-sidrops-rpki-rsc-01 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 22:07:10 -0000 --McZkFGNLFxCT+zU9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear working group, I.... hopefully managed to generate the world's first RPKI Signed Checklist! It is possible this RSC was generated incorrectly, I don't have a proper validator yet. Generating this RSC .sig involved an ASN.1 to C to XML to DER conversion process, the Lament Configuration, and vi. Attached to this email are 3 files: 432K Feb 5 21:31 b42_ipv6_loa.png \_ arbitrary files 212B Feb 5 21:31 b42_service_definition.json / 1.6K Feb 5 21:31 checklist.sig Diff: draft-ietf-sidrops-8210bis-01.txt - draft-ietf-sidrops-8210bis.txt
< draft-ietf-sidrops-8210bis-01.txt   draft-ietf-sidrops-8210bis.txt >
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft IIJ & Arrcus Internet-Draft IIJ & Arrcus
Updates: 8210 (if approved) R. Austein Updates: 8210 (if approved) R. Austein
Intended status: Standards Track Dragon Research Labs Intended status: Standards Track Dragon Research Labs
Expires: August 8, 2021 February 4, 2021 Expires: August 14, 2021 February 10, 2021
The Resource Public Key Infrastructure (RPKI) to Router Protocol, The Resource Public Key Infrastructure (RPKI) to Router Protocol,
Version 2 Version 2
draft-ietf-sidrops-8210bis-01 draft-ietf-sidrops-8210bis-02
Abstract Abstract
In order to verifiably validate the origin Autonomous Systems and In order to verifiably validate the origin Autonomous Systems and
Autonomous System Paths of BGP announcements, routers need a simple Autonomous System Paths of BGP announcements, routers need a simple
but reliable mechanism to receive Resource Public Key Infrastructure but reliable mechanism to receive Resource Public Key Infrastructure
(RFC 6480) prefix origin data and router keys from a trusted cache. (RFC 6480) prefix origin data and router keys from a trusted cache.
This document describes a protocol to deliver them. This document describes a protocol to deliver them.
This document describes version 2 of the RPKI-Router protocol. RFC This document describes version 2 of the RPKI-Router protocol. RFC
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 8, 2021. This Internet-Draft will expire on August 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 18 skipping to change at page 3, line 18
1. Introduction 1. Introduction
In order to verifiably validate the origin Autonomous Systems (ASes) In order to verifiably validate the origin Autonomous Systems (ASes)
and AS paths of BGP announcements, routers need a simple but reliable and AS paths of BGP announcements, routers need a simple but reliable
mechanism to receive cryptographically validated Resource Public Key mechanism to receive cryptographically validated Resource Public Key
Infrastructure (RPKI) [RFC6480] prefix origin data and router keys Infrastructure (RPKI) [RFC6480] prefix origin data and router keys
from a trusted cache. This document describes a protocol to deliver from a trusted cache. This document describes a protocol to deliver
them. The design is intentionally constrained to be usable on much them. The design is intentionally constrained to be usable on much
of the current generation of ISP router platforms. of the current generation of ISP router platforms.
This document updates [RFC6810]. This document updates [RFC8210].
Section 3 describes the deployment structure, and Section 4 then Section 3 describes the deployment structure, and Section 4 then
presents an operational overview. The binary payloads of the presents an operational overview. The binary payloads of the
protocol are formally described in Section 5, and the expected protocol are formally described in Section 5, and the expected
Protocol Data Unit (PDU) sequences are described in Section 8. The Protocol Data Unit (PDU) sequences are described in Section 8. The
transport protocol options are described in Section 9. Section 10 transport protocol options are described in Section 9. Section 10
details how routers and caches are configured to connect and details how routers and caches are configured to connect and
authenticate. Section 12 describes likely deployment scenarios. The authenticate. Section 12 describes likely deployment scenarios. The
traditional security and IANA considerations end the document. traditional security and IANA considerations end the document.
skipping to change at page 3, line 43 skipping to change at page 3, line 43
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. Changes from RFC 8210 1.2. Changes from RFC 8210
This section summarizes the significant changes between [RFC6810] and This section summarizes the significant changes between [RFC8210] and
the protocol described in this document. the protocol described in this document.
o New ASPA PDU type (Section 5.12) added to support o A new ASPA PDU type (Section 5.12) has added to support
[I-D.ietf-sidrops-aspa-profile]. [I-D.ietf-sidrops-aspa-profile].
o A small section, Section 11, has been added to handle two ROA PDU o A small section, Section 11, has been added to handle two ROA PDU
race conditions, Break Before Make and Shorter Prefix First. race conditions, Break Before Make and Shorter Prefix First.
o Protocol version number incremented from 1 (one) to 2 (two). o The protocol version number incremented from 1 (one) to 2 (two)
and the Section 7 section has been updated accordingly.
2. Glossary 2. Glossary
The following terms are used with special meaning. The following terms are used with special meaning.
Global RPKI: The authoritative data of the RPKI are published in a Global RPKI: The authoritative data of the RPKI are published in a
distributed set of servers at the IANA, Regional Internet distributed set of servers at the IANA, Regional Internet
Registries (RIRs), National Internet Registries (NIRs), and ISPs; Registries (RIRs), National Internet Registries (NIRs), and ISPs;
see [RFC6481]. see [RFC6481].
skipping to change at page 10, line 20 skipping to change at page 10, line 20
changes between the Serial Number specified by the router and the changes between the Serial Number specified by the router and the
cache's current Serial Number, the cache MUST merge those changes to cache's current Serial Number, the cache MUST merge those changes to
present the simplest possible view of those changes to the router. present the simplest possible view of those changes to the router.
In general, this means that, for any particular prefix or router key, In general, this means that, for any particular prefix or router key,
the data stream will include at most one withdrawal followed by at the data stream will include at most one withdrawal followed by at
most one announcement, and if all of the changes cancel out, the data most one announcement, and if all of the changes cancel out, the data
stream will not mention the prefix or router key at all. stream will not mention the prefix or router key at all.
The rationale for this approach is that the entire purpose of the The rationale for this approach is that the entire purpose of the
RPKI-Router protocol is to offload work from the router to the cache, RPKI-Router protocol is to offload work from the router to the cache,
and it should therefore be the cache's job to simplify the change and it should therefor be the cache's job to simplify the change set,
set, thus reducing work for the router. thus reducing work for the router.
If the cache does not have the data needed to update the router, If the cache does not have the data needed to update the router,
perhaps because its records do not go back to the Serial Number in perhaps because its records do not go back to the Serial Number in
the Serial Query, then it responds with a Cache Reset PDU the Serial Query, then it responds with a Cache Reset PDU
(Section 5.9). (Section 5.9).
The Session ID tells the cache what instance the router expects to The Session ID tells the cache what instance the router expects to
ensure that the Serial Numbers are commensurate, i.e., the cache ensure that the Serial Numbers are commensurate, i.e., the cache
session has not been changed. session has not been changed.
skipping to change at page 19, line 23 skipping to change at page 19, line 23
+-------------------------------------------+ +-------------------------------------------+
| | | | | | | |
| Flags | zero | Provider AS Count | | Flags | zero | Provider AS Count |
| | | | | | | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Customer Autonomous System Number | | Customer Autonomous System Number |
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Provider Autonomous System Number(s) | | Provider Autonomous System Numbers |
| | | |
~-------------------------------------------~ ~-------------------------------------------~
The ASPA PDU is to support [I-D.ietf-sidrops-aspa-profile]. An ASPA The ASPA PDU is to support [I-D.ietf-sidrops-aspa-profile]. An ASPA
PDU represents one single customer AS and zero or more provider ASs PDU represents one single customer AS and one or more provider ASs
for a particular Address Family. Receipt of an ASPA PDU announcement for a particular Address Family. Receipt of an ASPA PDU announcement
when the router already has an ASPA PDU with the same Customer when the router already has an ASPA PDU with the same Customer
Autonomous System Number and the same Address Family (see Flags Autonomous System Number and the same Address Family (see Flags
field), replaces the previous one. This is to avoid a race condition field), replaces the previous one. This is to avoid a race condition
when a BGP announcement is received between an withdrawn PDU and a when a BGP announcement is received between an withdrawn PDU and a
new announced PDU. Therfore, the cache SHOULD deliver entire data of new announced PDU. Therefor, the cache MUST deliver entire data of
an ASPA record in a single ASPA PDU. an ASPA record in a single ASPA PDU.
The router should only see one ASPA for a particular Customer
Autonomous System Number active at any time. This may place a burden
on the cache to merge multiple ASPA records it has received from the
global RPKI into one ASPA PDU.
The Flags field is defined as follows: The Flags field is defined as follows:
Bit Bit Name Bit Bit Name
---- ------------------- ---- -------------------
0 Announce/Withdraw (ann == 0, with == 1) 0 Announce/Withdraw (ann == 0, with == 1)
1 AFI (IPv4 == 0, IPv6 == 1) 1 AFI (IPv4 == 0, IPv6 == 1)
2-7 Reserved, must be zero 2-7 Reserved, must be zero
The Provider AS Count is the number of Provider Autonomous System The Provider AS Count is the number of Provider Autonomous System
Number(s) at the end of the PDU, and may be zero or more. Number(s) at the end of the PDU, and MUST be one or more.
The Customer Autonomous System Number is the 32-bit Autonomous System The Customer Autonomous System Number is the 32-bit Autonomous System
Number of the customer which signed the PDU. There may be only one Number of the customer which signed the PDU. There MUST be one and
ASPA for a Customer Autonomous System Number active at any time. only one ASPA for a Customer Autonomous System Number active in the
router at any time.
The Provider AS Count is the number of 32-bit Provider Autonomous The Provider AS Count is the number of 32-bit Provider Autonomous
System Numbers in the PDU. There may be none. System Numbers in the PDU. It MUST be one or greater.
There are zero or more 32-bit Provider Autonomous System Number There are one or more 32-bit Provider Autonomous System Number
fields; see [I-D.ietf-sidrops-aspa-profile]. fields; see [I-D.ietf-sidrops-aspa-profile].
6. Protocol Timing Parameters 6. Protocol Timing Parameters
Since the data the cache distributes via the RPKI-Router protocol are Since the data the cache distributes via the RPKI-Router protocol are
retrieved from the Global RPKI system at intervals which are only retrieved from the Global RPKI system at intervals which are only
known to the cache, only the cache can really know how frequently it known to the cache, only the cache can really know how frequently it
makes sense for the router to poll the cache, or how long the data makes sense for the router to poll the cache, or how long the data
are likely to remain valid (or, at least, unchanged). For this are likely to remain valid (or, at least, unchanged). For this
reason, as well as to allow the cache some control over the load reason, as well as to allow the cache some control over the load
skipping to change at page 21, line 30 skipping to change at page 21, line 34
Caches MUST set Expire Interval to a value larger than either Refresh Caches MUST set Expire Interval to a value larger than either Refresh
Interval or Retry Interval. Interval or Retry Interval.
7. Protocol Version Negotiation 7. Protocol Version Negotiation
A router MUST start each transport connection by issuing either a A router MUST start each transport connection by issuing either a
Reset Query or a Serial Query. This query will tell the cache which Reset Query or a Serial Query. This query will tell the cache which
version of this protocol the router implements. version of this protocol the router implements.
If a cache which supports version 1 receives a query from a router If a cache which supports version N receives a query from a router
which specifies version 0, the cache MUST downgrade to protocol which specifies version Q < N, the cache MUST downgrade to protocol
version 0 [RFC6810] or send a version 1 Error Report PDU with Error version Q [RFC6810] or [RFC8210] or send a version 1 Error Report PDU
Code 4 ("Unsupported Protocol Version") and terminate the connection. with Error Code 4 ("Unsupported Protocol Version") and terminate the
connection.
If a router which supports version 1 sends a query to a cache which If a router which supports version N sends a query to a cache which
only supports version 0, one of two things will happen: only supports version C < N, one of two things will happen:
1. The cache may terminate the connection, perhaps with a version 0 1. The cache may terminate the connection, perhaps with a version 0
Error Report PDU. In this case, the router MAY retry the Error Report PDU. In this case, the router MAY retry the
connection using protocol version 0. connection using protocol version C.
2. The cache may reply with a version 0 response. In this case, the 2. The cache may reply with a version C response. In this case, the
router MUST either downgrade to version 0 or terminate the router MUST either downgrade to version C or terminate the
connection. connection.
In any of the downgraded combinations above, the new features of In any of the downgraded combinations above, the new features of the
version 1 will not be available, and all PDUs will have 0 in their hogher version will not be available, and all PDUs will have the
version fields. negotiated lower version number in their version fields.
If either party receives a PDU containing an unrecognized Protocol If either party receives a PDU containing an unrecognized Protocol
Version (neither 0 nor 1) during this negotiation, it MUST either Version (neither 0, 1, nor 2) during this negotiation, it MUST either
downgrade to a known version or terminate the connection, with an downgrade to a known version or terminate the connection, with an
Error Report PDU unless the received PDU is itself an Error Report Error Report PDU unless the received PDU is itself an Error Report
PDU. PDU.
The router MUST ignore any Serial Notify PDUs it might receive from The router MUST ignore any Serial Notify PDUs it might receive from
the cache during this initial startup period, regardless of the the cache during this initial startup period, regardless of the
Protocol Version field in the Serial Notify PDU. Since Session ID Protocol Version field in the Serial Notify PDU. Since Session ID
and Serial Number values are specific to a particular protocol and Serial Number values are specific to a particular protocol
version, the values in the notification are not useful to the router. version, the values in the notification are not useful to the router.
Even if these values were meaningful, the only effect that processing Even if these values were meaningful, the only effect that processing
skipping to change at page 33, line 35 skipping to change at page 33, line 35
corruption attacks. As pointed out in Section 9, TCP-AO is the corruption attacks. As pointed out in Section 9, TCP-AO is the
long-term plan. Protocols which provide integrity and long-term plan. Protocols which provide integrity and
authenticity SHOULD be used, and if they cannot, i.e., TCP is used authenticity SHOULD be used, and if they cannot, i.e., TCP is used
as the transport, the router and cache MUST be on the same as the transport, the router and cache MUST be on the same
trusted, controlled network. trusted, controlled network.
15. IANA Considerations 15. IANA Considerations
This section only discusses updates required in the existing IANA This section only discusses updates required in the existing IANA
protocol registries to accommodate version 1 of this protocol. See protocol registries to accommodate version 1 of this protocol. See
[RFC6810] for IANA considerations from the original (version 0) [RFC8210] for IANA considerations from the original (version 0)
protocol. protocol.
All existing entries in the IANA "rpki-rtr-pdu" registry remain valid All existing entries in the IANA "rpki-rtr-pdu" registry remain valid
for protocol version 0. All of the PDU types allowed in protocol for protocol version 0. All of the PDU types allowed in protocol
version 0 are also allowed in protocol version 1, with the addition version 0 are also allowed in protocol version 1, with the addition
of the new Router Key PDU. To reduce the likelihood of confusion, of the new Router Key PDU. To reduce the likelihood of confusion,
the PDU number used by the Router Key PDU in protocol version 1 is the PDU number used by the Router Key PDU in protocol version 1 is
hereby registered as reserved (and unused) in protocol version 0. hereby registered as reserved (and unused) in protocol version 0.
The policy for adding to the registry is RFC Required per [RFC8126]; The policy for adding to the registry is RFC Required per [RFC8126];
skipping to change at page 36, line 29 skipping to change at page 36, line 29
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key
Formats, and Signature Formats", RFC 8208, Formats, and Signature Formats", RFC 8208,
DOI 10.17487/RFC8208, September 2017, DOI 10.17487/RFC8208, September 2017,
<https://www.rfc-editor.org/info/rfc8208>. <https://www.rfc-editor.org/info/rfc8208>.
[RFC8210] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol, Version 1",
RFC 8210, DOI 10.17487/RFC8210, September 2017,
<https://www.rfc-editor.org/info/rfc8210>.
16.2. Informative References 16.2. Informative References
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
August 1996, <https://www.rfc-editor.org/info/rfc1996>. August 1996, <https://www.rfc-editor.org/info/rfc1996>.
[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5",
RFC 4808, DOI 10.17487/RFC4808, March 2007, RFC 4808, DOI 10.17487/RFC4808, March 2007,
<https://www.rfc-editor.org/info/rfc4808>. <https://www.rfc-editor.org/info/rfc4808>.
 End of changes. 24 change blocks. 
31 lines changed or deleted 44 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--Multipart_Wed_Feb_10_17:00:54_2021-1-- From nobody Wed Feb 10 18:27: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 EDA263A0EEA for ; Wed, 10 Feb 2021 18:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=KZpZUi7a; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Euyhztoy 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 52PNuKjGsi2J for ; Wed, 10 Feb 2021 18:27:34 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297833A0EEB for ; Wed, 10 Feb 2021 18:27:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2167; q=dns/txt; s=iport; t=1613010453; x=1614220053; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zbYYyijymcud+KHxNbzGtqYzr6fqaHADf9QTPVScMBQ=; b=KZpZUi7acv0i+GphB3WB8igzyZwi6dt+ttlNVQrzcwJ1iH1xP6cr1lVC UXx4hdXLXJCXL6iLbIG7ze5xKNeSG7ZIwtNknyKPyxTDttEL9oqPAyN8F 3C653oXyXiQ5oqgmfgg5VARImL3bSBusyuhXBK+kQigU3b3i2074BUs/C M=; IronPort-PHdr: =?us-ascii?q?9a23=3A01S5bxauK7N30euj5Hu7Ux3/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaRD4HH8fMChveF+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGHNrkZhvfvy764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D?= =?us-ascii?q?=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAAArlSRg/5pdJa1iGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIE7BQEBAQELAYFSUQd2WjYxiAkDhFmJNwO?= =?us-ascii?q?ZHIEugSUDVAsBAQENAQEYCwoCBAEBhAdEAoIDAiU0CQ4CAwEBCwEBBQEBAQI?= =?us-ascii?q?BBgRxhWENhkMBAQEBAwEBJRMGAQEsBAcBCwQCAQgRBAEBAR0BECcLHQgBAQQ?= =?us-ascii?q?BDQUIgmmCVQMuAQ6lFQKKJXSBATODBAEBBoE3AoNSGIISAwaBOAGCdYpHJhu?= =?us-ascii?q?BQT+BEUOCVj6CXQEBAgGBXoNIgiuCRG4UPQJbPWtIuUAKgnqJNpJzoyiQAoQ?= =?us-ascii?q?0iyuWTAICAgIEBQIOAQEGgVU6gVdwFTuCaVAXAg2OH4NxhRSFRXMCNQIGCgE?= =?us-ascii?q?BAwl8ij1aAQE?= X-IronPort-AV: E=Sophos;i="5.81,169,1610409600"; d="scan'208";a="850685495" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Feb 2021 02:27:32 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 11B2RWmA021492 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Feb 2021 02:27:33 GMT Received: from xfe-aln-005.cisco.com (173.37.135.125) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 10 Feb 2021 20:27:32 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Wed, 10 Feb 2021 20:27:32 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 10 Feb 2021 20:27:32 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Jvxjuk8zqaMs4AMKn3u2kLIEaG5vWaHvQXxSB3sX3hYx0yhmhmA1cDhr6Bd5+fuhHcuce7V1f5wBwQvmNP5mZbVzwC40hWnunoX5mCBVlXvEKSFFCORDr04zXNSApUB0cRAxhJBFNWwVPFrMr/TM1MvTaj3qCCejucfKWjxbqMgJtRB7oJc4Tq8gpUZ1fmkwvMB1FnOtbwvVZwxMMd0bg/PHcPZpTDYMvb1N4ZC9x804HGyltOQu1zDdAsWFE7+LEZlGlkI5Ufm3660FDP3+ahAjejmxHXfiKHitkM2RRRB6qGzP96S0SqaK1nFNySTwA9njMaA6JXhIGWBm4Ng1wg== 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=CwoRdWkePQq7Thb19r/Ncf0FZuf089uuepmZuoswi+E=; b=jnKvW5B41+EVgvVwL3sQY4lgI/mIszfFbqfZ/aljFBUGbHMwV22rQVXyyQvxgg2fiOHdCvaqlaX4EGZ4unYPvQjYPLu2cc3kSBlz6inGuH3FljzgrCVZoHJ2JcGS/6X10VnFGfNbk9lTin7i3WPbhjpTf8gbiiuwEk8B7jBZjrW5malOQZ6ODXYO4cfCFtlukThDE74Ji7nA3iY3H+dmiwm4ubHyA4ZugBOPCyGFdouDaYG0vC5nShvjNaVamAarxOZ7VwRebDa3YSXZNaRZKyfK9xqXyEQJYUHX+5/Xw74JITDFVRYMpXN4Ig74rg+m3eyhG9vG7SDpgLyKAB1M0w== 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=CwoRdWkePQq7Thb19r/Ncf0FZuf089uuepmZuoswi+E=; b=EuyhztoyvUMv2U8us2ZsOiwqxsXH5kjSx+qoDJvEkeG0+G+BAevfGusIiJkbTdyvaN6/im4XLGgDgQ97OmXVEKCscf5dKlfs6ut8L8pfwTjYv5YwNn/juOGJ/OyYocH/xywlNa6LPvtvMt4fIz9QNNwbNZRIQvQo/0V6E7AAuFc= Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by BY5PR11MB4069.namprd11.prod.outlook.com (2603:10b6:a03:191::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.25; Thu, 11 Feb 2021 02:27:31 +0000 Received: from BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::c951:3ae4:1aca:9daf]) by BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::c951:3ae4:1aca:9daf%3]) with mapi id 15.20.3825.030; Thu, 11 Feb 2021 02:27:31 +0000 From: "Jakob Heitz (jheitz)" To: Lukas Tribus , "Jakob Heitz (jheitz)" CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] ASPA verification algorithm error Thread-Index: AdbwhlK9z1axTpzkRWyI9nY082H2KAPh4G+AAANgFnA= Date: Thu, 11 Feb 2021 02:27:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ltri.eu; dkim=none (message not signed) header.d=none;ltri.eu; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2601:647:5701:46e0:a466:79fe:7183:c553] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e0e52d33-172e-4648-7d5b-08d8ce349553 x-ms-traffictypediagnostic: BY5PR11MB4069: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YT4nn00QKAmLZAAj3LazzLL6VkzGoLCsj6MILTBLoWwf082HCoaYqiku5rOA0AE+awBVY5J5NzFocEtLI1mGj+6vUKz4/1MNJekj/ydcSXTxRv3zvz+f4ot4o1z87vLH5p5Jj6mM4botr7/Y94Xa8W5JRlkkknr2MnJ1A3i/9Kg6iGU2CM4Cz8NWqrd85j+dShZka9IQ9xpKxiOZIWqvTC7BRRLcBnFPpDGVjNynidQ8Yz4r56WFubq28vrBLZf2snmUSJS8fpG95Q510QonTuwx5HTsM1MBtu/TKwIvySqZ6FLw4jJIv7a8e1qt/JMDVbgwVju18D3FSpUFGF6QNobWPvHV32tuRbPcoBLyi+/eA3yBef1K7s72Rgh3QDI0bySSjWVG7rhuPR4sM3gK0wI8ZzZ8KvOGW5WOXP9C4Iq4/QFiedP6OoO0u0FJqQauoDBTabu6yZ7r5+nsVMvIHB3oWucUJQmlfBaAHzFwZPpiXK8UhIAhT0pUPMC/VJebtinDgDbj2FKj4F0YF9hVPICpg+CzdQ9JUO4LMWK1crDFxpipkygsOEK7KfshYeuiquGomNpmdtY9PX7hIjvREd8mj67gwAkC7O1gRnnjyKs= 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:(376002)(39860400002)(346002)(396003)(136003)(366004)(71200400001)(4326008)(8676002)(2906002)(6506007)(53546011)(52536014)(33656002)(110136005)(66446008)(64756008)(66556008)(66476007)(83380400001)(76116006)(7696005)(5660300002)(86362001)(478600001)(66946007)(8936002)(9686003)(316002)(15650500001)(55016002)(186003)(966005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?gN7NYqcOtHObbcGO3b24DBNn8T5TF8jNI9B3ElIiZG6QDEXf5Dd3T/Bmfpp9?= =?us-ascii?Q?2KA4gVuthMuiMabcwr7c4d2HgIfvZKO3qa2CwwgrKNeku8Yig4vXRyC+83SI?= =?us-ascii?Q?4mJP5k5XYeH2N16b9kLH0KHUI4h9hpI3RmmsBo7qriLsFCPcEAo8ub5B+qyN?= =?us-ascii?Q?VId+ayUZyprslConBMVkullewPV5yu7uhoqw05JTEU2ymlUUAuT41u0R/aPF?= =?us-ascii?Q?//VmO9EVAjUkGk/+c+bvDl8k6E1ue7QcZvH749DnlMSBWDKo4blfhRuxKDWP?= =?us-ascii?Q?V1/bN27wD2ufDHj/SZTPlc5zHw7UKTfXQApK74aX8bL6r2Hh4wSOqaeIEO5D?= =?us-ascii?Q?f86H5/gD2QA+81Z3RLXgnGyCwz47yAk+GjjwQZrKAqyMXcwwKwVKh3/uLcEx?= =?us-ascii?Q?SZbXLqN1Kq1YQiIrw6/+tE+hpuvN5PsVKjMi3P/2VNfsbcMOX++MB0kxfIYN?= =?us-ascii?Q?vGlz5YO+WPBu7iN6mj1D2xgrIncQ1ez+4cZoEG/bfrEUonG49fqMPY93ovIy?= =?us-ascii?Q?o2W/31nPC/jZ9PVfiSCAdO/kfWaDFqEb3d2PZP6W4MWbtF1xFp5Lm05QhV9Z?= =?us-ascii?Q?6lRibr/n/EDlbMP9MgCzjvAfHQG8arjROyE09A6L7nqEIf8j1VwMMtFgFY4D?= =?us-ascii?Q?cEEeQcScfta88I6CzJ67g36iHevfc8EHJ4Q462SFnWFhn6XUCDC3i5kEsZXz?= =?us-ascii?Q?ZdwGnMQeRMr55zH8UMrjy1iBNhrBsEDfafBfA4TtWarJI7d65tNd89XpwPvL?= =?us-ascii?Q?xcXZaTXUAHTdCL+UX1EAh33iV4HZGPHbtP4gLo6vecmC6q/ZkyrXeZbIWvRY?= =?us-ascii?Q?WloOT4Lh0XW91U3jVdfmoh0IOeVS4g7MbiOV7Wq5OO6TL095BabeSd+y1Vqk?= =?us-ascii?Q?SC5EBGs4b2+qd4RO4/NegRWBmQIad3dnQEWt1t0POM7Ex7JVBpTMbgHgsXRs?= =?us-ascii?Q?ZVGV+R+9jW1Tif9/z1kDMNK/fLgph8XQQit7tGIkNnpd8vcfltSsGxEfVNOs?= =?us-ascii?Q?zH9ERoOhojyYsuli0/Z9vMrh7PtfkrpBdzU0ZHA9KnPkO8U3qI1Qh6kGMLTI?= =?us-ascii?Q?olhfwHJ47cZmw/TOxCftPN5Qdcy/LC9TBu7QDcJIODbaxmvlhiaaKQxQUvQO?= =?us-ascii?Q?Ag+dxWJMgqyU1+956ONmjfVn6N7Zvb4PcFF+qXHF1nVlvlNBmvlC4WXwy3AE?= =?us-ascii?Q?8gM/AOiaFR3L4ZPTIjfGoAlQl2wlAlEh5RQdiF8+tiiuYh5Zy5wV3e7Boarv?= =?us-ascii?Q?7u6VqvH6Q9y4RXFt6n0QzTX3+e3NUyMGfNv7gcM9j3Kuf7ggZ83HaJJTQqJ9?= =?us-ascii?Q?YAZa5oh8dOYB1ozbMN6HvcYHlpKl+4+nmsbzTh7YyvAeNZGaQcDuC7q3rhLE?= =?us-ascii?Q?UWA8fCrrfA47w6RcXWljnigwCFzv?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3207.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e0e52d33-172e-4648-7d5b-08d8ce349553 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2021 02:27:31.0573 (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: w6w4KPhpFzltUMR9Z5RImNh2to9WTW24M3LHkUUeMK2JOgSnzGLzSlj7xYfee0HFdP9zF4EU/Y+hwiqFCNz2lA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4069 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [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: Thu, 11 Feb 2021 02:27:36 -0000 All we have is the attestations. We don't know the actual relationships. Thus we need to try all possible relationships given the available attestat= ions. Using the notation where the arrow points to the provider: A -> B means B is provider for A A <- B means A is provider for B A -- B means A and B are bilateral peers A <> B means A and B are complex or siblings. then the possible relationships are: 1 -> 2 -- 3 <- 4 1 -> 2 -- 3 <> 4 1 -> 2 -> 3 <- 4 1 -> 2 -> 3 <> 4 1 -> 2 <- 3 <- 4 1 -> 2 <- 3 <> 4 1 -> 2 <> 3 <- 4 1 -> 2 <> 3 <> 4 1 <> 2 -- 3 <- 4 1 <> 2 -- 3 <> 4 1 <> 2 -> 3 <- 4 1 <> 2 -> 3 <> 4 1 <> 2 <- 3 <- 4 1 <> 2 <- 3 <> 4 1 <> 2 <> 3 <- 4 1 <> 2 <> 3 <> 4 All of these possible relationships represent a valid AS_PATH. Regards, Jakob. -----Original Message----- From: Sidrops On Behalf Of Lukas Tribus Sent: Wednesday, February 10, 2021 4:36 PM To: Jakob Heitz (jheitz) Cc: sidrops@ietf.org Subject: Re: [Sidrops] ASPA verification algorithm error On Fri, 22 Jan 2021 at 07:21, Jakob Heitz (jheitz) wrote: > > 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-veri= fication-06 > > would incorrectly return "unknown" I assume 2 is not a provider for 3 (but a peer)? Wouldn't section 5.2. "Downstream Paths" make this "valid" then? Are they "special" non-peers? Then "7. Mutual Transit (Complex Relations)" would apply (in that case, without attestation "unkown" would be expected and a positive attestation required for a "valid" result) - which I believe is what we want. I think in this case it would be helpful to include the actual relationship between the AS you have on your mind, not only the ASPA attestations. Lukas _______________________________________________ Sidrops mailing list Sidrops@ietf.org https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Feb 10 18:36:41 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 F07B23A0F2E for ; Wed, 10 Feb 2021 18:36:39 -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 0xbKLBryfCMs for ; Wed, 10 Feb 2021 18:36:38 -0800 (PST) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 6667F3A0F22 for ; Wed, 10 Feb 2021 18:36:38 -0800 (PST) Received: by mail-wm1-x32f.google.com with SMTP id l17so2076502wmq.2 for ; Wed, 10 Feb 2021 18:36:38 -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=3gZSsWHQQACArbr+u/Nh3MnE10o+JfZSd8PY11guhe0=; b=Ccw7fkP1PaYZ1dwYD/ci0LBUBrhjw5w0MGAevZprpYhlkRcO6c5t/B5zz2TCi5+YgV Zwfq+YwMlhNeHNLvshPHqfZV4HF+wTWazrwZDeyQE7sRKkrbAJtgvJS/krAVx3kwC4e1 /N+1LitAfh3Q/Xwnfv9SYTR370v3yc1/KeGps= 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=3gZSsWHQQACArbr+u/Nh3MnE10o+JfZSd8PY11guhe0=; b=uXuu1+9PLw1/buzyHBudgITgmJJMNZitRcHVT/h4u+vk8U+Fu7DTfgVDp5Wup7P80V ho7dw/hiBmkfQ2GSey23PVfYZ9kIpjkkjPptOK7vmsAsaDakbxWKWVs1KYLQREE+B9lW 8xblXmU2EOlV78aOTljr8yqtMzmnlpenOOmUFTGA9uH+9kq2yrSwJgDAZaV5cZQVGdZY PbU5flb7XEEaRQtA9GbHh85wI6nzrHiOf34u4JEFxrC3vTX6Fo66/AjbU3g2WAATg0hB OptB5nzyeMwIud+aRtFCDolEyb2g6D1erCnmLnOOvS9jQlLFafqftX+MJVitPPFNgcrM dC+w== X-Gm-Message-State: AOAM532KI8qnwjytAlO5KHxOEGT6LzLk9O7g+L5ADW6MMl4SXCSjbGnJ GxixNxIHU8JtrPMV8SNB1YpVBiBjbg7vj2zRfA3JoYGBjAF/TsJdepcQMtlKHDCVaba7PQQYHet ok9Norheh9Q9XqEp6FPrdAVZM9Do+/6iZj7geKEPacNvJEE1WEJwFMqE= X-Google-Smtp-Source: ABdhPJz9cmulxZxp6ee975pFhNHsujSyANN/sWwXTPtmR0OFZzfiC2MQR9IrDP9YyOGKrGxnuhIr1A== X-Received: by 2002:a1c:f70c:: with SMTP id v12mr2304684wmh.77.1613010995527; Wed, 10 Feb 2021 18:36:35 -0800 (PST) Received: from snel (mieli.sobornost.net. [45.138.228.4]) by smtp.gmail.com with ESMTPSA id w11sm6023565wmi.37.2021.02.10.18.36.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Feb 2021 18:36:35 -0800 (PST) Date: Thu, 11 Feb 2021 03:36:33 +0100 From: Job Snijders To: sidrops@ietf.org Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="PZzwAvamYJ6I2yXm" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] RPKI Signed Checklists - draft-spaghetti-sidrops-rpki-rsc-01 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 02:36:40 -0000 --PZzwAvamYJ6I2yXm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear group, On Fri, Feb 05, 2021 at 11:07:01PM +0100, Job Snijders wrote: > I.... hopefully managed to generate the world's first RPKI Signed > Checklist! It is possible this RSC was generated incorrectly, I don't > have a proper validator yet. Generating this RSC .sig involved an ASN.1 > to C to XML to DER conversion process, the Lament Configuration, and vi. > > Attached to this email are 3 files: > > 432K Feb 5 21:31 b42_ipv6_loa.png \_ arbitrary files > 212B Feb 5 21:31 b42_service_definition.json / > 1.6K Feb 5 21:31 checklist.sig